anselmolsm has quit [Quit: Konversation terminated!]
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-security
hmpffff_ has joined #nixos-security
hmpffff has quit [Ping timeout: 265 seconds]
KeiraT has quit [Ping timeout: 240 seconds]
KeiraT has joined #nixos-security
hmpffff has joined #nixos-security
hmpffff_ has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-security
hmpffff_ has joined #nixos-security
hmpffff has quit [Ping timeout: 256 seconds]
kamil_ has joined #nixos-security
<kamil_>
Hello. Has there been efforts made to mandate that most if not all commits contributed to the nixpkgs repository are signed? I haven't been able to find a follow-up to RFC0034 concerning this in particular. I'm considering migrating my production machine to NixOS, but I've refrained from doing so on the grounds that it is unclear to me whether my system will remain unaffected in case of the infrastructure used by NixOS being e
<kamil_>
ver compromised. I apologize if this isn't the right channel of communication for making such inquiries in advance.
<qyliss>
So your threat model is that GitHub is hacked or malicious, and inserts commits into Nixpkgs?
hmpffff has joined #nixos-security
hmpffff_ has quit [Ping timeout: 260 seconds]
<kamil_>
qyliss, Correct. However, as my understanding of the extent of danger of not signing all commits is limited, I am not entirely sure what the exact threat model is/should be like. That is to say, my recent discovery of RFC0034 and issues brought up by it have raised red flags for me, and have made me uncertain of the efficacy of security measures taken by the project, which brings me here to have my (mis)understanding of the se
<kamil_>
curity model of your infastrcuture cleared up.
<qyliss>
well, I can confirm that commits to Nixpkgs are not currently required to be signed
<qyliss>
(but fwiw, requiring signed commits is very unusual in my experience. commits to the kernel don't have to be signed, for example.)
<qyliss>
I'd be happy for us to adopt mandatory signed commits, but can foresee a couple of problems in doing so:
<qyliss>
1. Pushback from committers who find it annoying and don't think it provides a meaningful security benefit
<qyliss>
2. I haven't tested it, but I suspect that the GitHub "require all commits to be signed" option would want commits from non-committers to be signed, which would mean we might not be able to merge commit. A sensible implementation would only require that commits in the first-parent chain were signed. Maybe that's how it's implemented, maybe not. I don't know.
<qyliss>
Another benefit of requiring signed commits is that it would stop committers impersonating each other, but since Github has started treating the PR author as committer when squash-merging, committer metadata is now useless anyway
<qyliss>
(I'm very annoyed about that)
hmpffff_ has joined #nixos-security
hmpffff has quit [Ping timeout: 272 seconds]
hmpffff has joined #nixos-security
<kamil_>
Oh, now I understand. Either way, even if we assume that it's unlikely that Nixpkgs would be negatively affected by a successful attack on GitHub's infrastructure, what safety measures are currently taken to protect Nixpkgs against a committer or a non-committer trying to sneak malicious, backdoored code?
hmpffff_ has quit [Ping timeout: 265 seconds]
Dianalondon has joined #nixos-security
Dianalondon has quit [Client Quit]
hmpffff_ has joined #nixos-security
hmpffff has quit [Ping timeout: 272 seconds]
<pie_>
i think we might need a faq a tthis point
<gchristensen>
kamil_: one question I have for you is signed by who, and why do you trust those signatures?
<kamil_>
gchristensen, I can only speculate what signing practices guarantees the best result security-wise. The thing is I thought it was a common practise to sign commits coming to this channel. Now I know that it isn't true, and that it's disputable whether there's a benefit by doing so. My argument for signing is solely based on the premise that there's an improvement to be made *if* there was a RFC made about it.
<gchristensen>
kamil_: I don't think that premise really holds exactly
<gchristensen>
anybody can make an RFC, it doesn't make it valuable by definition
<gchristensen>
that said, i believe I wrote a long comment on that RFC about what I thought, in more detail
<kamil_>
Security research is not my area of expertise, sadly; this fact must be glaring, especially now that my thinking process has been challenged. Personally, I'm happy to learn something new and be proven wrong. Anyway, thank you for your input on this matter. I'll make sure to read that comment of yours.
<gchristensen>
kamil_: I would say that NixOS's tree is quite safe, and if it helps I could easily appeal to the authority of many businesses who would suffer an extreme loss if such an event were to take place -- but have decided to trust NixOS
<gchristensen>
if you have a specific threat model to consider, that would be useful :)
<MichaelRaskin>
«11 years since the last reminder that the entire industry depending on a specific not even unprecedented event not happenning doesn't guarantee anything»
<MichaelRaskin>
But yeah, an attack on Nixpkgs security via manipulation of CVE patch choice is cheaper
<MichaelRaskin>
Our upstreams are not perfect, and our understanding of which patch to apply is not perfect…
zarel has joined #nixos-security
<Foxboron>
Who can merge patches to the nixpkgs repository? Is there a list?
zarel_ has joined #nixos-security
zarel has quit [Ping timeout: 246 seconds]
<qyliss>
the list is unfortunately not public, because GitHub doesn't provide a way to make it public
<qyliss>
I feel very strongly that the list should be public
<qyliss>
but somebody would need to do something with the API I think
<Foxboron>
And afaik the merging of said package patches is a bit over the place depending who is the "maintainer" and who merges the patches. Right?
<Foxboron>
all over the place*
<qyliss>
What do you mean?
<Foxboron>
Maintaing a nixos package doesn't entail commit access to the repository and is more an formality then a duty?
<kamil_>
gchristensen, No, there's nothing for me to add, I think. There's still one unanswered question I have, it's buried in the chat. If I've missed a reply to it, I apologize.
<qyliss>
Foxboron: correct
<MichaelRaskin>
qyliss: I think you could start an RFC asking for permission for any committer to publish snapshots of the list. It's a few pages on Github, so forget API, Save Page As is good enough.
<Foxboron>
qyliss: So you have maintainers and "maintainers. Maintainers with commit access that merges patches on behalf of the "maintainers". Excuse the quotes :p
<qyliss>
Foxboron: no, you have maintainers and committers
<Foxboron>
qyliss: a committer isn't always the maintainer of said package?
<qyliss>
no
<qyliss>
a committer is somebody who can commit to all of nixpkgs
<qyliss>
most packages are not maintained by a committer
<kamil_>
_pie, I second this idea if I am allowed to elaborate
<Foxboron>
qyliss: I'm trying to figure out the word usage here. A committer is someone who can merge patches?
<qyliss>
Yes
<qyliss>
One who can make commits directly in the Nixpkgs repository
<Foxboron>
I'd call them nixpkgs maintainers :p But okay.
<Foxboron>
But you still have two sort of unpriviledges contributors? One who can maintain a package and one who is just doing a one-off contribution?
<qyliss>
Well, maintainers means something else in nixpkgs, hence we call them committers
<Foxboron>
unpriviledged*
<Foxboron>
qyliss: ah ok
<MichaelRaskin>
I would say there is a spectrum of being well-known in various ways
<Foxboron>
So you have committers, maintainers and then everyone else. Committers are priviledges, maintainers and rest of the people are not priviledges?
<qyliss>
there's not really a distinction between maintainers vs non-maintainers
<MichaelRaskin>
Including the entry in the maintainer-list, yes
<qyliss>
the maintainer list is just an entry of who to contact about package updates
zarel_ has quit [Ping timeout: 258 seconds]
<qyliss>
anybody can add themselves to it, remove themselves, and it makes no difference in terms of access
<MichaelRaskin>
Well, it might one day for merging very well-localised patches
<MichaelRaskin>
But not yet
<Foxboron>
Right, but is there some implicit trust at play here?
zarel has joined #nixos-security
<MichaelRaskin>
It's a spectrum. I would say that trust is a three-argument function here, community member X trusts community member Y on topic Z
<MichaelRaskin>
Note that for most people there are topics where they do not trust their own judgement
<Foxboron>
So compromising the supply chain of nixpkgs you would in theory have to compromise this trust chain, and not really commiters nor github itself?
<MichaelRaskin>
Well, committers do look that changes look non-malicious
<MichaelRaskin>
But easily trust maintainers' word on the software still working
<MichaelRaskin>
But you can probably convince people to use an incomplete patch for many CVEs… especially when there are multiple upstream versions, and there often are
<Foxboron>
I'll make a bold statement and say bandwidth issue could be a problem as well?
<Foxboron>
E.g the number of committers doesn't scale with the number of PRs that needs reviews?
<MichaelRaskin>
Yes, which leads to some PRs not getting feedback in reasonable time
<Foxboron>
I think it's probably the weak point of the void and nixos way of package management. People have mentioned they want something similar in Arch but I'm not really convinced
<MichaelRaskin>
Well, we are a bit behind on giving out commit access to well-recognised people with a good track record of contributions, as well
<qyliss>
I think we do that fairly effectively
<qyliss>
new committers are being added all the time
<Foxboron>
And nixos doesn't do source authentication yet either?
<MichaelRaskin>
qyliss: we do miss people, I say it as someone who has at a time run uniformly automated analytics on the repo, then reviewed the outliers — I was probably the driving force behing a majority of invitations in that period
<MichaelRaskin>
We like when upstream publishes official checksums, in that case we use them
<Foxboron>
Signatures is authentication. So gnupg or PKCS signatures
<Foxboron>
Published checksums without signatures isn't really worth a lot either.
<qyliss>
sure they are
<qyliss>
where are you going to download gnupg keys from?
<MichaelRaskin>
They are usually on a different system, which helps a ton
<qyliss>
either way your root of trust is a certificate authority
<Foxboron>
qyliss: Keyservers or locate-key?
<Foxboron>
How is the root of trust a CA in this case?
<qyliss>
By locate-key I assume you mean WKD
<Foxboron>
It supports a few more, but yes :)
<qyliss>
which roots trust in a certificate authority by looking up a key over HTTPS
<qyliss>
If you do gpg --locate-key hi@alyssa.is, it'll try to download my key from my website over HTTPS, and trust whatever it gets back
<qyliss>
therefore rooting trust in a CA
<qyliss>
SXS keyservers give you no root of trust at all, you have to bring your own, which approximately nobody is capable of doing
<qyliss>
*SKS
<qyliss>
Hagrid keyservers root trust in the kerserver operator
<Foxboron>
Right. But now you are talking about fetching the key. That isn't really the issue, is it?
<Foxboron>
You have the tarball and the signature from upstream. Fetching the key to verify these two parts doesn't make for an easy attack vector
<MichaelRaskin>
Depends on how long-lived and well-known upstream keys are
<qyliss>
Almost all upstream keys will not be well-known
<qyliss>
we've tried this for decades
<Foxboron>
But even if the keys are well-known then
<MichaelRaskin>
About that you need to ask people who maintain the corresponding packages…
<MichaelRaskin>
This is a rare enough case that a Nixpkgs-wide mechanism won't make much sense…
justanotheruser has quit [Ping timeout: 244 seconds]
justanotheruser has joined #nixos-security
anselmolsm has joined #nixos-security
Lutrulo has joined #nixos-security
kamil_ has quit [Ping timeout: 244 seconds]
kamil_ has joined #nixos-security
FRidh has quit [Quit: Konversation terminated!]
<kamil_>
Regarding the conversation that my questions sparked a few hours ago, would it be feasible to issue a statement about the Nix infrastructure from the security perspective? There's clearly a lot of going on behind the scenes, and I feel strongly that this information should be released to the public. There are potentially harmful opinions about the state of security on NixOS that I have come across on the internet, and can crea
<kamil_>
te confusion, dissuading potential users and contributors from using NixOS in the first place. While there's only a handful of them, a lacking documentation on the workings of Nixpkgs is ultimately why I came in here to ask these clichéd questions to begin with. In the same vein, there's still one thing unclear to me, namely: "what safety measures are currently taken to protect Nixpkgs against a committer or a non-committer t
<kamil_>
rying to sneak malicious, backdoored code?"--that I hope addresses my last concern. In the meantime, I'll be eagerly looking forward to flake authentication.
justanotheruser has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-security
Lutrulo has quit [Remote host closed the connection]
Lutrulo has joined #nixos-security
anselmolsm has quit [Remote host closed the connection]