pyrox

Hey! First, a disclaimer: I do not speak for anyone officially, but I am a very regular contributor to nixpkgs and have been involved in trying to increase nixpkgs' security through adopting the Full-Source Bootstrap that Guix and Stagex use. I also assume that the RFC you're talking about is RFC 0100, "Sign Commits"(ref: https://github.com/NixOS/rfcs/pull/100)

As mentioned in the RFC discussion, the major blocker with this is the lack of an ability for contributors to sign from mobile devices. Currently, building tooling for mobile devices is way out-of-scope for nixpkgs, and would be a large time sink for very little gain over what we have now. Further, while I sign my commits because I believe it is a good way to slightly increase the provenance of my commits, there is nothing preventing me from pushing an unsigned commit, or a commit with an untrusted key, and that's, in my opinion, fine. While for a project like Stagex(which as a casual cybersecurity enthusiast and researcher, I thoroughly appreciate the security work you all do), this layer of security is important, as it's clearly part of the security posture of the project, nixpkgs takes a different view to trustworthiness. While I disagree with your conclusion that having this sort of security measure would "make volunteers run screaming", I would be interested in seeing statistics on the usage of these mechanisms in nixpkgs already. Nixpkgs is also definitely not focused on being a hobby distro, considering it's in use at many major companies around the world(just look at NixCon 2025's sponsor list).

To be clear, this isn't to say that all security measures are worthless. Enabling more usage of security features is a good thing, and it's something I know folks are looking into(but I'm not going to speak for them), so this may change in the future. However, I do agree with the consensus that for nixpkgs, enabling commit signing would be very bad overall for the ecosystem, despite the advantages of them. Also, I didn't see anything in your PR about "independent signed reproducible builds", but for a project the size of nixpkgs, this would also be a massive infrastructure undertaking for a 3rd-party, though NixOS is very close to being fully reproducible(https://reproducible.nixos.org/) at the moment, we're not there yet though.

In conclusion, while I agree that signing commits would a good improvement, the downsides for nixpkgs are significant enough that I don't believe it would be a good move. It's something to definitely continue thinking about as nixpkgs and nix continue to refine and work on their security practices, though. I would also love some more information about how Stagex does two-party hardware signing, as that sounds like something interesting as well. Thank you so much!

Edit: Also, want to be very clear: I am not saying you're entirely wrong, or trying to disparage the very interesting and productive work that Stagex is doing. However, there were some (what I felt were)misconceptions I wanted to clean up.

using the Lume(https://lume.land) static site generator, which I automatically run in CI and then deploy to my VPS.

All self-hosted, no middlemen, just me, my own templates, formatting, code. I focus on design simplicity, lightweight pages, and being as accessible as I can. This means both visual accessibility(Every page is hand-checked with WAVE's browser extension(https://wave.webaim.org/) and Sa11y(https://sa11y.netlify.app/)) and technical accessibility(Low- or no-JS always, make pages as lightweight as possible).

To me, this is the ideal experience, where it's all stuff I've written, and even helped contribute to(I've been doing a lot of revising the Lume docs since the author isn't a native English speaker, been a relaxing and fun experience). Also, the entire design makes sense to me, and I haven't had that in the past with any other blog stack, so this feels like an end-game blog setup.

Nix also has a Guix service itself[^1], if you want to do the same in reverse ;)

[^1]: https://search.nixos.org/options?query=services.guix

Asahi Linux's site previously redirected any site with the Referer header set to 'news.ycombinator.com' to google.com. They did this because they believe that Hacker News' community fosters a hostile environment, and thus it was blocked. Setting `rel=noreferrer` on an `a` tag means that the browser will not submit this header, thus meaning this sort of redirect will not occur. Also(as per Marcan's Mastodon account), this rel tag has only been added to asahilinux.org links, not any other links on HN. This means that the moderators of HN believe that the commentary that has in the past been quite misinformative should be allowed, and they are deciding to bypass the block that was put in place by the Asahi team. Now, as per https://social.treehouse.systems/@marcan/110503331622393719 , they're adding an HTML header to anyone who has submitted a post to HN(or has the submit page in their history), as they have no other way of doing anything, as they no longer have the Referer header.

This link is useless, it just links to a substack article with a basic single-paragraph description of the project. A better link would be https://github.com/bluenviron/mediamtx, the actual URL to the project.