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.
The reason I dislike this is this is the first thing in the article:
> in nixpkgs that would have allowed us to pwn pretty much the entire nix ecosystem and inject malicious code into nixpkg
OP provided a mechanism to stymie the attack. The counter from your position needs to be how the nix project otherwise solves this problem, not “this isn’t the right approach for hand wavy reasons”. Given the reasonings stated, OP has convinced me that Nix isn’t actually serious about security as this should be treated as an absolutely critical vulnerability that has several hardening layers wrapped to prevent such techniques.
> in nixpkgs that would have allowed us to pwn pretty much the entire nix ecosystem and inject malicious code into nixpkg
Isn't that what happens when a build server or source code is compromised? I'm not sure if the existence of this exploit was egregious, but the blast radius seems normal for a build server exploit.
> how the nix project otherwise solves this problem
You can go into `/etc/nix/nix.conf` and remove `trusted-public-keys` so that you don't trust the output of the build servers. Then you just need to audit a particular commit from nixpkgs (and the source code of the packages that you build) and pin your config to that specific commit.
Otherwise, it seems like the solution is to harden the build system and source code control so that you can freely trust the source code without auditing it yourself. I'm not sure what else can be done.
If your threat model is that the 10+ nixpkg contributors are trustworthy but the github repo is untrustworthy, then git signing would make you safe.
Personally, I worry that a carelessly approved merge in nixpkg or an upstream supply attack is a bigger threat then a github repo exploit (as described here), but I imagine that reasonable minds could disagree.
Regardless, I'm very excited to see that nix builds are almost fully reproducible. That seems great! It seems like this could potentially be the foundation on which a very secure distro is built.
You absolutely should never trust a centralized build server. Any security critical software distribution process should have all packages independently built, verified to have identical hashes, and signed by systems controlled by as many different trusted maintainers or third parties as possible.
Then any user can prove the binary they got was built faithfully from source due to those redundant build system signatures. We designed ReprOS for this purpose.
stagex has also been 100% deterministic, full source bootstrapped, and independently reproduced/signed by multiple maintainers since our first release with a small team of 10ish regular contributors, so it can be done.
> the major blocker with this is the lack of an ability for contributors to sign from mobile devices
Do you mean a significant number of nixpkgs contributors make nixpkgs PRs from their phones... via the github web editor?
That seems weird to me at face value... editing code is hard enough on a phone, but this is also for a linux distro (definitely not a mobile os today), not a web app or something else you could even preview on your phone.
Sorry to be that guy, but if someone cannot afford a $10 bit of hardware for the most basic attempt at protecting others from being harmed by someone impersonating them... then they have no business being a trusted maintainer in a Linux distribution relied on for billions of dollars in infrastructure.
That would be like someone saying they could not afford a mask in COVID or something. It is hard to believe these people really exist. I could go find $10 in change looking on the ground of a few nearby fast food pick-up windows, because I have done it. Many times. Free money!
Anyway, such people will be easy to bribe, easy to target, easy to steal from. Letting that sort of person have trust in a major OS is endangering them, and frankly irresponsible.
For anyone that makes excuses about being unable to produce a hardware signing device, of course let them contribute, but then let two confirmed real humans with hardware keys adopt, review, and sign that PR, and always have at least two real confirmed humans with hardware keys sign every change both as code, and as reproducible artifacts after.
We have taken in tons of drive-by unsigned contributions in stagex. This is no problem. We just pretend an AI bot wrote it, and require one maintainer to "adopt" the commit to sign it (maintaining attribution), and then a second maintainer reviews, and does a signed merge as usual.
Lack of supply chain integrity controls as a means to reduce contribution friction to maximize the number of packages contributed is a perfectly valid strategy for a workstation distribution targeted at hobby developers.
Volunteers can do what they want, so that RFC convinced me stagex needed to exist for high security use cases, as Nix was explicitly not interested in those.
This is all fine. The reason I speak in a tone of frustration whenever Nix comes up is because as a security auditor I regularly see Nix used to protect billions of dollars in value or human lives. Sysadmins uneducated on supply chain integrity just assume Nix does security basics and has some sort of web of trust solution like even OG distros like Debian, but that is just not the case.
Nix maintainers did not ask to be responsible for human lives and billions in value, but they are, and people will target them over it. I am afraid this is going to get people hurt.
Nix choosing low supply chain security to maximize the total number of packages endangers themselves and others every time someone ignorantly deploys nix for high value applications.
If nix chooses to maintain their status quo of no commit signing, no review signing, no developer key pinning, and no independent reproducible build signing, they need to LOUDLY warn people seeking to build high risk systems about these choices.
Even those basic supply chain controls which we use in stagex, are nowhere near enough, but they are the bare minimum for any distro seeking to be used in production.
Out of curiosity, why don't/didn't you start a new version of nixpkgs with hardened source? You could forgo the build server, forcing users to build from scratch (at least to start). You could leverage the plentiful, albeit, less secure, packaging code in the nixpkgs to quickly build out your hardened versions.
Effectively, you're building out an audited copy of nixpkgs on the same build engine, but with hardened configs. Write wrappers to validate git signatures when users update, and you got yourself a chain of trust on the source code distribution for your hardened nixpkg.
I'm sure you had reasons, I'm just interested to know your thought process.
I ultimately thought out what would be easier, a decade political fight to make massive changes to nix, or a fork of it written solo to improve auditability and security, or starting over from the top with a design that checks every dream box I wanted from a linux distro.
I had many RFCs that would have followed this rejected one if there was any change tolerance... so my fastest path to prove out my ideas for a distro with decentralized trust was to start one with that explicit goal.
If I wanted to make things maximally auditable and portable to different build engines, a published dead simple spec with multiple competing implementations that most software engineers already know how to write would be ideal. People could review an engine they use, or ensure all existing implementations on any operating system get identical results and are thus trusted that way. If it natively supports a ton of features to make deterministic builds wildly simpler, major bonus.
OCI/Containerfile was a check on all fronts, and some early maintainers and I riffed on design patterns and realized the OCI ecosystem already had specified multi party signing and verification, artifact integrity, smart layer by layer caching etc etc. This fit our dev experience and threat model perfectly and we could just skip implementing the package build and distribution layer and just start writing packages, like that day. None of us needed to learn or invent a new language or ask auditors to do so or fork nix ecosystem to have proper signing support and write a sane spec... that could be years of wheel spinning.
The time saved by choosing an existing widely used and implemented spec meant we were able to put all energy into full source bootstrapping, universal multi party hardware signing on every build, change, review, and reproduction. Just full source bootstrapped linux from scratch in containerfiles with OCI native multi party signing if all parties independently get the same oci hashes from local builds. Oh and we are going LLVM native like Chimera next week. Big sweeping changes like that are easy with our ultralight setup.
I would note that the features we need for deterministic builds in docker, the most popular OCI implementation, only landed a couple of months before we started stagex, and the full source bootstrapping work by the bootstrappable builds team only got a complete bootstrap for the first time a few months before that and Guix shortly after. Tons of reference material.
If stagex had started before 2022 I imagine we might have used a heavily trimmed down nix clone or tried to convince guix to adopt our threat model, which is much further along in supply chain security than nix but scheme would have been a very isolating choice. I think stagex got lucky starting at exactly the right time when two huge pieces of the puzzle were done for us.
It is way behind Debian on even the basics sadly. Maintainers do not even sign in NixOS making them easy to impersonate. Debian security is a joke too though in other areas, and like nix, should never be used in production either.
NixOS at least has immutable read-only system images. This makes it a thousand times less interesting to a potential attacker than a Debian system.
For every Mossad agent crafting elaborate impersonation scheme to steal state secrets, there are a million script kiddies looking for insecure servers for a botnet.
P.S. A bigger issue is the complete inability of the "security industry" to understand even basic threat model issues. More proof that this entire "industry" is a joke and a clown show.
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.
I love that this goes both ways. What other pair of Linux distros mutually offer first class support for using each other's package managers alongside their own??
It's a cute little testament to the fundamental strengths of the functional package management paradigm, as well as helping users on either side of the fence fill some gaps in a pinch and providing more/easier opportunities to compare notes and inspire improvements.
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 raises interesting moral questions that I'm not sure I have an answer to.
For one, I don't believe this place fosters a hostile environment, although it's definitely a place where people love to tell you how you're technically wrong about something.
For another, I would guess that there are a very limited number of websites that would opt into this sort of anti-traffic behavior. Hacker news could certainly choose to honor it, but it also feels within their right to bypass the block.
I wonder if there's a sort of middle ground, where HN alerts the user of the redirect that would have occurred, but still shoots the user to the desired location.
But now you're getting into user flows and begging the question as to why the redirect is there in the first place.
I'd love to know more about the perceived hostility, even reading up on Mastodon left me with more questions than answers.
there is constant transphobia against Asahi contributors on display on this site. Every single article that gets to the frontpage will have dozens of vile posts in the deads and a couple sprinkled inbetween. I’m not sure if HN staff doesn’t care about it, agrees with them or simply isn’t aware.
It’s not limited to the Asahi project, either. The site isn’t safe for queer folks.
I had a look at the comments on this post. I don't see any saying anything at all about gender, pronouns, trans-ness, etc. (Other than in this little discussion right here about what is allegedly wrong with HN.) I have showdead on, incidentally; I'm not seeing any dead comments on those topics either.
Maybe for whatever reason this particular post is better than others? I put <<asahi site:news.ycombinator.com>> into DuckDuckGo. (Not because there's anything magic about DuckDuckGo search results, but to get a sample of Asahi-related HN posts without cherrypicking.) The first hit is to https://news.ycombinator.com/item?id=35394297; no trans-related things there that I can see either. (It does have some discussion of why the Asahi Linux site was turning away people coming from HN, and the reason given there was nothing to do with "Lina", nor with transphobia, but was that marcan feels that HN discussions of Asahi are full of mistakes.)
(To look for trans-related things I (1) skim-read the comments by eye and then (2) searched for "trans", "gender", "pronoun" and "man", the last because people being obnoxious about trans issues often can't resist going out of their way to call someone a "man" or a "woman" if they think they might be upset by being called that. I specifically kept an eye out for dead comments. It's very possible that I missed things, but it seems to me that a minimum threshold for saying that there's "constant transphobia on display" is that someone explicitly and somewhat carefully looking for it should be able to find at least one example.)
Next few links aren't obviously strongly-Asahi-related articles. Next one that is is to a comment about "Lina" somewhere in the middle of https://news.ycombinator.com/item?id=35233479, so I took a look at the comments there. There was indeed a "Lina" subthread, some of which was pretty rude but none of it in a visibly-trans-related way.
My general impression of the HN comments on Asahi-related threads, from this, is that they are on the whole very positive, that some people think marcan is weird for Lina-related reasons (which may or may not actually make sense; I have no knowledge of that business), and that if anyone is being obnoxious at or about trans people in those threads then either they're doing it in ways I'm failing to see or else it's being cleaned up effectively enough that it's gone by the time I look.
It seems your experience is very different. Where should I be looking for some examples?
I’m confused by this comment. I follow the asahi Linux developments here on hn and read the comments. In this thread alone there are several high rated posts to the effect of “this project rocks!!”
The only reference I can find to trans- anything is basically this comment. Quite honestly, I recommend a thicker skin. Some people will be assholes, whether you’re trans, straight, bi, whatever. Pretending that assholes don’t exist will just make you angry… you can’t just wish away the assholes but you can ignore them and prove them wrong by being awesome (which in this case the asahi linux developers work speaks for itself!)
It seems HN's philosophy is like that of (early) Reddit, where the commenters self-govern and down/flag comments like that - and it seems to be working if they're all dead, right? They're hidden unless you have an account and specifically enable showdead.
> vile posts in the deads and a couple sprinkled inbetween. I’m not sure if HN staff doesn’t care about it, agrees with them or simply isn’t aware.
So basically you're judging a community by the posts the community and moderators deemed inappropriate and moderated away? Rather curious metric.
If you don't want to see dead posts then turn showdead off (which is the default). That you get some transparency in the moderation is a feature, IMHO, but it's also opt-in.
Maybe there should be a "verydead" for these kind of outright idiotic posts so they just won't display at all for anyone, but then how do you prevent abuse and keep the mod workload reasonable marking endless posts as "verydead"?
> there is constant transphobia against Asahi contributors on display on this site
Could you be so kind as to link me to an example?
People have discussed Marcan's anime alter ego, certainly, but I've never seen anything transphobic in the slightest. Maybe it's all flagged before I get to see it, but I honestly can't figure out what you might even be referring to. I enjoy reading Asahi updates when they come up, so I am unsure how I could be missing something so 'constant'.
> It’s not limited to the Asahi project, either. The site isn’t safe for queer folks.
As a 'queer person' myself, I find that statement utterly ludicrous and I reject it completely.
This is pure and poor conjecture, just like the rumor (originating on chan boards and KF) that a person close to marcan had faked suicide. Exactly this sort of rumor mill is what is wrong with HN linking to Asahi developers.
> As a 'queer person' myself, I find that statement utterly ludicrous and I reject it completely.
Are you a cis gay? I remember a few cases where people reached out to have information redacted to dang and it took weeks. While the people mentioned above were digging into private lives. This site absolutely requires you to shut the fuck up about your own life if you are at risk of being turned into a "lolcow" or pedojacked or whatever else these people will come up with. I understand that's not a consideration yet for 'queer people' currently not conscripted to the front of the culture war.
I can honestly say I've never, ever, heard anyone call anyone else these terms on Hacker News. I don't think I've ever even heard those terms before. It sounds like you might be very online, in a way that seems to be making you unhappy.
Some of my most upvoted comments on here have been from a 'queer' perspective. It helps to assume good intentions and engage with others constructively and in good faith.
I must admit, I feel saddened by your dismissiveness of certain 'queer people'. You have no idea who I am, what my identity is, and yet you so casually dismiss members of the marginalised group you purport to be defending. How callous of you.
Perhaps the reason I can so easily dismiss your hysterical claim that HN is unsafe is that - in my day - 'unsafe for queer people' meant 'reasonable likelihood of getting a brick to the face', and not 'seeing words online you don't agree with'.
this is very dismissive for how much you're projecting i'm dismissing you. it's okay if you can't relate to me, just don't assume you understand.
hn is unsafe in the way that it provides zero control over what you have submitted and a perfect history of your posts, mostly set in stone unless you email an administrator. at least reddit lets you self-service delete posts.
those are perfect conditions for a certain kind of group that spend way too much time digging up and correlating info to then start harassment campaigns that exceed 'seeing words online you don't agree with' quite often.
you can of course now go on to scold me and others with this problem about how we need to up our opsec or shouldn't post in the first place. i find such arguments, if you were to make them, entirely unconvincing. being aware of your risk profile is one thing, shifting all the blame for making it harder to retroactively rectify little pieces of information (these people found a place from a blurry 500x500 picture of a parking lot out a window) on the user is just a bad excuse for shitty UX.
> you can of course now go on to scold me and others with this problem about how we need to up our opsec or shouldn't post in the first place
Not at all. I neither think you should up your opsec nor avoid posting. I think you should be unabashed of what you have to say. I also think you should hear out others doing the same, generously and in good faith.
That tiny minority who harass and abuse queer people today? That used to be virtually everybody, all the time, everywhere you'd go.
The only reason queer rights are where they are today is because people weren't afraid to speak up, even when they had every right to be. When coming out meant admitting to criminal acts - proclaiming them in public, no less. Had they not put themselves out there - had they refused to speak to those that didn't already agree with them - this would be a much darker world, and your definition of 'unsafe' would be a lot more visceral.
People used to march, faces out in the open, in their small towns, for their rights, past neighbours who hated them. That's what 'unsafe for queer people' means. I'm just never going to be able to see 'people disagree with me online sometimes' as being in any way comparable.
A key tenet for many people appears to be that they should be able to do whatever is within their rights, but that leaves out the fact that sometimes doing something within your rights makes you an asshole.
> This raises interesting moral questions that I'm not sure I have an answer to.
It's not really all that much of a moral conundrum. Marcan's belief - expressed a number of times on his Mastodon - appears to be that he can prevent other people from discussing something, for the sole reason he doesn't want it discussed. It's not a particularly defensible position in an open society.
In particular, he is upset that people on Hacker News tend to point out that a contributor on Asahi - Lina - appears to be a computer-generated anime alter ego of Marcan himself.
Me, I have absolutely no problem with Marcan having an anime alter ego, but I don't think it's entirely reasonable to expect people to refrain from noticing this and remarking on it. Marcan disagrees, and this is the source of the HN-Marcan rift.
(As I've remarked before, I do mind OSS projects listing fake contributors, for both ethical and legal reasons, but that's another discussion.)
Quit with the gaslighting. It's not about an anime avatar, and you know it.
The problem is more that HN is perceived, with good reason, to be transphobic, and Asahi has several trans developers. This is also the reason why a couple of other people I won't mention don't want HN to link to their projects either, because for every link, several people will bitch in the comments about the validity of their gender and pronouns. (As if creating a web app somehow makes one an authority in biology.)
I mean, obviously, it's not like everybody who comments here takes part in the abuse, but when you spend every damn day of your life seeing it and depending on where you live, possibly being harassed by the government over it too, HN turns out to be one more place where you simply can't have any peace.
(And honestly, even if Lina is a anime alter ego, which you haven't proven, and only suspect, why the fuck do you care? Don't you have something better to spend your time on?)
I'm always so knowledgeable in the eyes of people who criticise me!
No, I didn't know Asahi had a single trans developer. I've never seen it come up on HN, where I most often hear about the cool work being done by the Asahi team. The vast majority of comments on here about every new Asahi article are effusive praise.
I dispute the characterisation of HN as some transphobic hellsite. That characterisation is simply not accurate, in the slightest, whatever perception may prevail on the Asahi Discord.
> why the fuck do you care
My other comment below, explaining the legal issue with fake OSS contributors, was already up by the time of your comment, so I refer you there. More broadly, I think Marcan should get to have as many anime alter-egos as he wishes. I'm just not particularly surprised that people find that noteworthy, and I think if you choose to have a public anime alter ego, you probably should be able to deal with that? I feel like Marcan's attempt to shut down this discussion is a perfect example of the Streisand effect - I certainly would have never found out about 'Lina' were it not for this silly feud.
> several people will bitch in the comments about the validity of their gender and pronouns.
I've seen these posts, and they're horrible, mean-spirited, and hurtful.
But as far as I've seen all those posts have also been downvoted to hell, flagged, and hidden, and the users often banned, and they're often from new "green" users rather than regulars. It's entirely possible that some of these posts remained (especially if they're posted after the conversation died down and there are less eyes), but I'm certain that if you email dang that he will take action.
At some point the first comment on one of my articles was "gay n---r soiboy" or something to that effect from a new account – a curious comment since my website has a picture of me being white enough to get a sunburn in Ireland – but how do you prevent that? Limiting sign-ups is the only thing I can think of.
I can definitely understand that people feel very negative about these things, but I think it's unfair to judge all of HN by it – you're essentially judging a community by the posts that were considered inappropriate and were removed.
And if you don't like HN (for any reason) then that's fine, so don't visit HN then. All this tomfoolery with referer blocks seems rather at odds with how the internet is supposed to work; "microsoft.com blocks links of the referer is from lwn.net" would cause a loud uproar here.
You are misunderstanding. You can discuss your conspiracies anywhere you want, just not on a post pointing to the people that have to deal with the fallout of your unfounded conjecture.
Also assuming there is a "fake contributor", who cares under which names contributions are split up? The work still got one. Also, it is absolutely not your project, you don't get to demand people show their ID when they write code for a project.
> Also assuming there is a "fake contributor", who cares under which names contributions are split up? The work still got one. Also, it is absolutely not your project, you don't get to demand people show their ID when they write code for a project.
If I contribute my code to an open source project, then I - as the copyright holder - agree to license my work under an open licence.
If I use an OSS project, I am using other people's copyrighted work under an open licence from them. Without that licence, I have no legal basis on which to use that work.
Only real people can (currently) hold copyright. If person X writes some code, but the licence (incorrectly) attributes the copyright to person Y, and person Y purports to give me an open licence to use that work, then - crucially - I have no license from the actual copyright holder (person X) to use their work.
Until an effective open source license is made, this code is not open source; it is completely proprietary. If person X chooses to sue you for copyright infringement, it is no defence to say that you're using it under a license from person Y, because person Y had no right to give you that licence.
This is a major ethical and legal problem. I would be very wary of the Asahi codebase.
If you wanted to split hairs this thin, you wouldn't use any project with at least one german citizen as contributor, since they can never truly yield all copyright on a work. You'll be fine. Anonymous contributions to free software (or even entire releases done anonymously, e.g. Bitcoin) are not actually uncommon.
As I said, very weird hangup to have, definitely not motivated by other reasons.
> If you wanted to split hairs this thin, you wouldn't use any project with at least one german citizen as contributor, since they can never truly yield all copyright on a work.
Nor can anyone else, copyright is not generally 'destructible'. That's why it's a licence. The holder keeps the copyright, but licenses the work to the general public. (Assignments are another way to achieve something like this, provided the assignee then licenses the work.)
I assume what you're referring to is inalienable moral rights - hence the reference to Germany - but those are a feature of many (most?) of the world's legal systems. They are included in one of the revisions to the Berne Convention, if I recall correctly, which is an international treaty on intellectual property.
I understand you're sceptical, but the legal dimension of OSS does matter. Using copyrighted material without a licence would constitute a major business risk. I would appreciate it if you could kindly refrain from making ungenerous assumptions about the intentions of others.
The most commonly cited example is a musician objecting to use of their music during a neo nazi rally. They won that case as the court judged the integrity of the work to be compromised.
I see. Well, I don't think that would affect code in the same way. If they have already contributed it then it's out in the open, and unless the maintainer was doing something objectionable they wouldn't have a case, and even if they did it would only be enforceable in Germany.
> that he can prevent other people from discussing something
And again, when some rando says "they want to prevent people from discussing, free speech!" the topic is always the same, they want to be freely racist, homophobic, whatever. Cmon man, just stop.
Forced participation has no place in open society. In such a society, when in private spaces, the valid response when told "You are not welcome here" is to leave and not to harangue the host about open societies.
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.
> This link is useless, it just links to a substack article with a basic single-paragraph description of the project.
In general, I too prefer a straight link to the repo. But in this particular case, that's literally the first thing in the post, which does an excellent job of summarizing what it's about and is immediately followed by a lengthy interview with the author.
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.