The Nixpkgs PR for Sparrow 1.8.5 is now available:

GitHub

sparrow : 1.8.4 -> 1.9.0 by emmanuelrosa · Pull Request #303393 · NixOS/nixpkgs

Description of changes This PR contains three commits: Version bump of sparrow from 1.8.4 to 1.9.0. Migration from stdenv to stdenvNoCC GPG verif...

I also added build-time GPG verification using npub1hea99yd4xt5tjx8jmjvpfz2g5v7nurdqw7ydwst0ww6vw520prnq6fg9v2 public key. :) I really like the idea that if it builds, then it's also verified. Damn, Nix is awesome! It's also possible to get the update now, by getting it from my repo: $ nix run github:emmanuelrosa/erosanix#sparrow BUT, the Nixpkgs in my repo doesn't have HWI 3.0; HWI was updated to 3.0 in Nixpkgs about 4 days ago. Sparrow should still work fine with HWI 2.4, as long as you're not trying to use an emulated hardware wallet. See

GitHub

Release 3.0.0 · bitcoin-core/HWI

Also available on PyPi and can be installed with pip install -U hwi Added --emulators option to enumerate and detect emulators. Otherwise default ...

#nixos #nix

Yesterday I defeated the first two Colossusi in "Shadow of the Colossus" (https://en.wikipedia.org/wiki/Shadow_of_the_Colossus). The Playstation 2 version. Today, I'm exhausted from defeating just the third one. Phew! I think I spent about one or two hours on it. Mounting the Colossus was simple enough, but staying on was tough! I kept falling off, over and over again. When the Colossus starts trying to shake me off, it seems to depleat my stamina much quicker than usual, making it even harder to stay on. Fun game. #gamestr #retrogaming

Note: There's a bug in my Bisq 2 Nix package. The symptom is an immediate failure to connect to the Tor network, and it can happen after updating Nixpkgs. The cause is that once Bisq 2 extracts the Tor binary (BASH script) from it's JAR archive, it doesn't extract it again; At least for the same version of Bisq 2. This can lead to the extracted scripting pointing to a Tor binary that's no longer in the Nix store. I fixed it by deleting the directory where Tor is extracted, so that Bisq 2 has to extract upon every start up. #nix #bisq

One neat Linux-compatible application which I don't think I've mentioned before is Tiddly Desktop. Tiddly Desktop (https://github.com/TiddlyWiki/TiddlyDesktop) is a desktop application for Tiddly Wiki, a personal wiki as a single-page-application. Being a SPA, Tiddly Wiki (https://tiddlywiki.com/) works just fine in a web browser, but saving your wiki is weird because you effectively have to download an updated copy of the Wiki. Then you manually replace the HTML file. It works, but it's cumbersome. Tiddly Desktop is basically a wrapper around Tiddly Wiki, and it improves the saving functionality so that saving your wiki is seamless. For Linux users, Tiddly Desktop comes as a downloadable Tarball which you then extract and execute the nwjs binary within. But, if you run NixOS... you're in luck because running Tiddly Desktop is as easy as: $ nix run github:TiddlyWiki/TiddlyDesktop If it doesn't work, it's my fault! For what it's worth, I've been using the Nix flake for 2+ years without issues. I update the Nixpkgs flake input when there's a new NixOS release. If you're shopping for a note-taking app, a personal knowledge base, or even a JavaScript-based environment you can write apps in a similar fashion to Smalltalk images, I think it's worth taking a look at Tiddly Wiki and Tiddly Desktop. #nixos #nix

A desirable feature of Bitcoin-related applications is to be able to verify the downloaded installer/package. This is a bit problematic on NixOS because the package manager downloads the application, not the user. As a first step in being able to verify Bisq2 on NixOS, I implemented reproduceable build-time verification. In essence, the Nix derivation uses GPG to verify upstream's Debian package, before unpacking the .dep file; If the verification fails then the entire build fails. A failure looks like this: In the example above, I simply replaced the correct public key (which is contained in the erosanix repo for reproduceability) with my own to cause an intentional failure. The end result is that the end-user can have limited confirmation that if Bisq2 installs, then the installation is verified. I believe this form of verification is superior to what I had done before, which is to automatically or manually verify the .deb; In this form, the end user has absolutely no confirmation that the .deb file has been verified. I say "limited confirmation" because this doesn't completely absolve the user's responsibility to verify the download. For example, a malicious actor can replace the public key and source files that are in the repo. I haven't fully developed the end-user verification process, but I think it could be something like this: 1. Audit the Nix expression to understand that in fact the .dep package is being verified and no funny business is happening. 2. Compare the public key that's in the repo with the one on the Bisq website to confirm they are the same. 3. To make the process quicker in the future, use your own GPG key to create external signatures for the public key (in the repo) and the Nix expression. I'd have to modify the Nix expression a bit, but the idea is that once the code has been audited and signed, future verification can be done quickly by verifying the Nix expression and public key with the signatures. To make this work I need to store the Bisq2 version and the SHA256 checksums in a separate Nix file.

Got it. Bisq2 for NixOS :) $ nix run github:emmanuelrosa/erosanix#bisq2 #bisq1 #nix #nixos

OK, I have an initial Nix package of Bisq 2. I haven't gotten past the Tor initilization: Perhaps it's a network issue on my side. If you want to give it a go, run: nix run github:emmanuelrosa/erosanix#bisq2 If you have a 4K display, then you way want to use this: $ nix shell github:emmanuelrosa/erosanix#bisq2 $ bisq2-hidpi #nixos

I just found out that Bisq2 was released. You know, the thing with Java applications is that building them from source using Nix is really difficult. During the development of the Nix package for Bisq, I wrote a script which I would run to generate a Nix expression describing the Java packages which needed to be downloaded. Then another Nix expression would create a temporary (Maven) repository containing the downloaded dependencies. THEN, it was possible to build Bisq with Nix. But I ran into a problem: I needed to include some DAO data and there was no way to get that in a reproduceable way, causing the build to fail when the DAO data was updated by upstream. I did find a solution. It so happened that the upsteam Linux package included the DAO data. I realized that I could get the DAO data from that file, solving the reproduceability problem. But at that point I also realized that if I was going to have to download the upstream linux package to get the data I needed, why not just repackage upstream's package for NixOS? This is the reason why the current Nix Bisq package is a repackaging up upstream's package, rather than a source build. I don't know why I'm saying all of this, other than perhaps I'm feeling uncharacteristically chatty today. I'm going to take a look at Bisq2 and create a Nix package for it. I can guarantee that I won't be building it from source ;)

Nix is not complicated: #nix #nixos #memestr

The fix for the recent GLIBC advisories CVE-2023-6246, CVE-2023-6779, and CVE-2023-6780 is now merged into the NixOS master and nixos-unstable branches; I'm not sure about the NixOS 23.11 release, since I couldn't find the commit.

GitHub

glibc: 2.38-27 -> 2.38-44 and patch for glibc possible memory corruption in qsort() by LeSuisse · Pull Request #285050 · NixOS/nixpkgs

Description of changes Fixes CVE-2023-6246, CVE-2023-6779, and CVE-2023-6780 Advisories from Qualys: https://www.qualys.com/2024/01/30/cve-2023-624...

BTW, NixOS unstable is not actually unstable. It's just a rolling release. Which in my opinion is MUCH better than using releases; I don't get hit with a ton of changes all at once. I use the master branch, and even that is often stable. #nixos #nixoskicksass