<tilpner>
lrvick - There was talk about moving away from GH when MS bought it, but the actual decision was postponed
<tilpner>
Restarting that discussion would lead to a lot of work, but with an added incentive it might succeed
<elvishjerricco>
I dunno if moving off GH is necessary. We just need some reliable way for every PR to be signed by the maintainer who merged it.
<tilpner>
elvishjerricco - It would make using a web UI not as bad, with self-hosted infrastructure
<tilpner>
(But then, you'd need something actually self-hosted, not just some cloud thing)
<srhb>
I doubt that would be realistic
<elvishjerricco>
For those who missed the context on #nixos, we're talking about signing nixpkgs so that GH becomes much less of a point of failure for security
<srhb>
The cost in loss of contributors seems staggering
<elvishjerricco>
agreed
<tilpner>
srhb - Right now it does, I agree
<lrvick>
I think moving off github is solving the wrong problem
<tilpner>
I didn't say it would solve all problems
<ekleog>
distrusting the infrastructure is the right solution imo
<lrvick>
^^^
<ekleog>
which is basically having each commit signed
<elvishjerricco>
So what does it take to enable maintainers to personally sign every PR they merge?
<lrvick>
Assume -any- VCS you use has a 0-day you don't know about
<tilpner>
I'm all for that, assuming it can be done without moving from GH
<ekleog>
elvishjerricco: first, disable merging through GH interface
<lrvick>
ekleog: you don't have to do that
<elvishjerricco>
ekleog: Ah, so they have to merge to master and push from their local machines. Not too bad, really
<ekleog>
then, maintainers use git merge -s for merging
adisbladis has joined #nixos-security
<lrvick>
using the merge button is just fine, as long as the commits themselves are signed, and releases are multisig signed
<elvishjerricco>
ekleog: Anyway to *enforce* that a maintainer doesn't forget the `-s`?
<ekleog>
with the trick of pulling a PR as a ref without having to add a remote, it's ok
<lrvick>
elvishjerricco: easy to enforce. caching servers will do a verification process
<ekleog>
elvishjerricco: the git pre-push hook that I linked above
<lrvick>
if multiple mirrors all agree, then you can assume/hope they all did the same verifications
<ekleog>
(and I was working on a pre-receive hook, but git doesn't have it)
<ekleog>
lrvick: releases having to be multisig signed would mean having to review all changes before the last real signature :/
<elvishjerricco>
lrvick: How does multisig signing prevent GH's merge button from introducing malicious changes?
<ekleog>
my security model was basically “master is actually the latest commit on master signed by a contributor” and “each contributor, when signing a commit, takes responsibility on all commits since the last signed one”
<lrvick>
elvishjerricco: because as long as you signed the -patch-id- and not the ref
<lrvick>
even after githubs merge commit, the patch id won't change
<lrvick>
so long as there were no actual code changes
<ekleog>
lrvick: the question is, who signs the patch-id?
<elvishjerricco>
lrvick: How does signing the patch-id work?
<lrvick>
you can rebase and squash 50 commits and the patch id won't change so long as the head is the same
<ekleog>
it needs to be a member with commit bit, otherwise it makes no sense
<lrvick>
so when you run a patch id signature you are sort of catting all files together and signing them as a unit.
<lrvick>
what is cool about this is you can verify the sig without git if you wanted.
<ekleog>
and if it's a member with commit bit, as well leave them sign the merge directly :)
<lrvick>
when you sign patch ids, you can squash 20 commits into one commit, and the signature is still valid.
<ekleog>
(not necessarily advocating not using git notes, just that anyway the maintainer will have to do something manual, so as well disable the web interface)
<elvishjerricco>
lrvick: But like what's the actual git interface? I didn't know it had this feature
<srhb>
iiuc the cache is still fairly irrelevant here. Nix itself would have to be able to verify the signatures (because what if a user doesn't use the cache)
<lrvick>
now even if you totally change history but the result ends up being no lines of code change
<lrvick>
the signature is still valid
<lrvick>
githubs merge commit is not a line of code
<lrvick>
so patch-id does not care
<elvishjerricco>
srhb: Well hydra be extended with an ability to check the signatures on the git repo and refuse to sign the cache unless the git commit is signed
<srhb>
elvishjerricco: Sure, but that seems like the wrong solution
<elvishjerricco>
srhb: How so?
<ekleog>
srhb: imo once we get all developers to sign the commits they merge / push, fixing nix-channel's fetcher to check the signatures is the easy part .)
<srhb>
If nix does the verification, the problem is solved for Hydra AND everyone that doesn't use the cache
<adisbladis>
I would theoretically be in favour. But we would lose drive-by commits and we are already swamped with PRs that never gets merged..
<adisbladis>
It would hurt scalability a lot
<srhb>
And losing verification because you overrideAttrs something far down the tree is painful.
<ekleog>
lrvick: the reason why I say disable the github merge button is so that a commit could not, by mistake, make it into github master without being signed (or have its patch-id signed or whatever)
<adisbladis>
And `git patch-id` is seriously slow on large repos
<srhb>
Well, maybe that wouldn't be the case...
<srhb>
It's all very "how-to-implement"
<lrvick>
ekleog: the way you avoid that is make sure you have a CI check that forbids allowing the merge button to go green unless signing rules are met.
<lrvick>
I do that on all my repos. ez pz
<ekleog>
lrvick: so then the model is having the maintainer first clone the pr, sign it, push the signature, then go back to the github merge interface to merge?
<adisbladis>
lrvick: Do you do that on any repos with a significant number of ppl with commit bits?
<lrvick>
once it is green you can presume signing really passed and merge (and if someone made the CI lie, downstream verifiers will notice the bad sig)
<ekleog>
must say it doesn't sound much better than just merge -s && push :°
<ekleog>
(though it does have the advantage of forcing other CI tests to pass)
<elvishjerricco>
I'm not clear on how Nix itself could verify this stuff. Nix doesn't care about git, or any Nix-code-signing.
<lrvick>
elvishjerricco: I can explain that
<lrvick>
so
<lrvick>
every cache server signs its own cache right?
<ekleog>
elvishjerricco: it's nix-channel that should be fixed to check the signature (though tbh so long as the binary cache is enabled it's no loss to trust hydra anyway)
<srhb>
lrvick: The point is to take the cache server out of the equation
<srhb>
lrvick: nix should continue working if the cache is offline
<srhb>
lrvick: And that is the default behaviour.
<srhb>
lrvick: The user will just be building the expressions themselves
<lrvick>
Fair. So then nixpkg itself should verify sigs
<srhb>
So we need to ensure that it's not suddenly insecure just because the cache went down
<elvishjerricco>
we should open an rfc for this
<lrvick>
I am happy to do so
<lrvick>
where at?
<ekleog>
scheme: 1. have a way to verify nixpkgs is signed, 2. have nix-channel check signature of things downloaded
<ekleog>
if a developer uses a local checkout of nixpkgs they can handle themselves verification of signatures
<adisbladis>
Technically it _would_ be possible to implement signing in nix... In practice it would be a bit painful
<srhb>
2. sounds bad. A lot of people never rely on nix-channel
* adisbladis
never uses channels
<ekleog>
-> see the following sentence :p
* srhb
nods
<lrvick>
The only thing developers would need to change is publish their public key hash id to the maintainers list on their first contribution, and then CI validates all their commits are signed with that key.
<lrvick>
layer one trust solved
<ekleog>
I personally know when I have my own checkout, I don't want it to be checked by signatures, because it's local anyway and I have patches that couldn't be signed as I don't have the commit bit
<adisbladis>
lrvick: How do you scale it to 100+ ppl with commit bits?
<lrvick>
those with actual master access would need to do a bit more work
<lrvick>
but not the majority of package authors
<adisbladis>
How do you make sure all these people have good key management?
<lrvick>
adisbladis: I have scaled it to companies with hundreds of employees. It is easy. Just make CI enforce it and provide detaild instructions on setting up git signing.
<ekleog>
lrvick: 100+ persons have master access here (and it's still not enough to keep the pr backlog from growing)
<lrvick>
debian does it with way more people.
<lrvick>
so does arch
<adisbladis>
lrvick: Companies have an incentive to do so
<pie_>
ekleog, what if i dont use nix-channel?
<adisbladis>
It's harder to migrate a community of volunteers
<lrvick>
arch and debian are not companies. They are distros that care deeply about security and choose not to have maintainers that don't
<ekleog>
adisbladis: you don't enforce good key management, but it's still better than nothing :)
<pie_>
nvm already mentioned
<adisbladis>
lrvick: I'm not saying impossible. It's just not going to be easy and we are not going to enforce signing any time soon I think.
<srhb>
Maybe the "cost tally" could be punted for a bit.
<adisbladis>
And there is still a lot of question marks what it would mean
<lrvick>
adisbladis: honestly do you really want people maintaining your packages that are unwilling to take 10 minutes to learn to sign their commits? Why not help educate people.
<adisbladis>
What is signed and verified how?
<lrvick>
If this were to ship I know I would gladly help.
<ekleog>
adisbladis: tbh, slowly having all developers signing things would be good first step
<ekleog>
tbh, at first I was hesitant to use nix because of this
* ekleog
happy to have made the switch, but that's still a major security problem imo
<adisbladis>
ekleog: Btw, I sign all my commits. By no means against this.
<ekleog>
like, if there's a backdoor, noone knows who put it in there
<lrvick>
ekleog: that is terrifying and now that I know this I have to go to work tomorrow and ban everyone from using nixos
viaken has joined #nixos-security
<lrvick>
which makes me sad
<ekleog>
lrvick: that's the case of most projects, fwiw
<adisbladis>
lrvick: Though does debian sign package descriptions?
<adisbladis>
Or just binary artifacts?
<lrvick>
adisbladis: they sign the sources, as well as build the artifacts in multiple locations and ensure they get the same hashes, to ensure CI is not compromised
<pie_>
ekleog, even if local devs dont sign their own stuff what about the rest of history
<ekleog>
except most projects have fewer committers, so it's less of an issue
<pie_>
that should still be checked i think?
<lrvick>
debian is the gold standard of package integrity, because they got burned until they got it right.
<pie_>
lrvick, huh
<ekleog>
lrvick: the “CI not compromised” part will be handled by reproducible builds when we'll manage to get to it :)
<srhb>
That can't be right...
<pie_>
lrvick, youre saying debian has reproducble builds?
<srhb>
Debian would have way fewer packages if they enforced reproducible builds
<ekleog>
pie_: that should be checked by a receive-hook… that git didn't have last time I checked :/
<lrvick>
most packages are reproducible now
<lrvick>
by buster it should be 100%
<ekleog>
ha ha ha
<srhb>
lrvick: Can you point me to some evidence?
<adisbladis>
lrvick: `git patch-id` has been running for 6 minutes on nixpkgs master..
<ekleog>
elvishjerricco: tbh, I fear that means it'll go nowhere
<adisbladis>
others*
<ekleog>
but well, at least there'll be a RFC to refer to
<elvishjerricco>
ekleog: It goes even more no where if it doesn't leave this IRC channel :P
<ekleog>
yeah :D
<ekleog>
gotta love inertia
<adisbladis>
Well in Nix if you want something done you do it yourself :P
ckauhaus has joined #nixos-security
<lrvick>
adisbladis: debian does not have a PR workflow but I think gits built in signing can cover this.
<ekleog>
adisbladis: well, I want all committers to sign their commits, I can't do it myself :'(
<lrvick>
sure you can
<elvishjerricco>
lrvick: Keep in mind it sounds like the patch-id thing isn't going to work for nixpkgs, based on adisbladis's observation that it takes an ungodly amount of time to run on a repo this size.
<adisbladis>
ekleog: You can. It's just not practical.
<lrvick>
make a CI that rejects anyone violating the new rules
<lrvick>
elvishjerricco: patchid should be tiny
<lrvick>
adisbladis: what command did you run exactly?
<andi->
well enforcing CI would start by disabling pushes on branches that aren't from merging PRs..
<ekleog>
lrvick: there's an issue I have with patch-id: how do you recover when someone makes a mistake and pushes an unsigned patch-id?
<lrvick>
andi-: you only enforce it for merges to master
<andi->
lrvick: does github allow that? :)
<lrvick>
ekleog: no problem! you can sign after the fact at any time
<lrvick>
andi-: they sure do.
* lrvick
has deployed these approaches to 3 companies
<ekleog>
lrvick: ok, next question: what about a patch noone would want to sign getting pushed?
<lrvick>
ekleog: like what?
<ekleog>
someone actually trying to introduce a backdoor
<tilpner>
Push a reversal and sign that?
<ekleog>
I wonder if that's possible :)
<lrvick>
so they push it unsigned, and every client rejects it
<lrvick>
that is the point
<elvishjerricco>
ekleog: if they have the ability to push why would they refuse to sign?
<ekleog>
lrvick: so you do need a pre-receive-hook, don't you?
<elvishjerricco>
They'd sign it to remove suspicion
<andi->
yeah, pre-receie hook is what worries me..
<ekleog>
elvishjerricco: to not be responsible when it's found
<lrvick>
ekleog: you just need to make sure it is signed before a merge to master is allowed. And if someone cheats the hook clients will all reject the current head, and go back to the last head that was properly signed
<elvishjerricco>
ekleog: Ah. Then yea, I'd hope everyone's things would just refuse to accept the change, and all changes after it.
<ekleog>
andi-: I had a working patch to git for adding a pre-receive hook, but it never made it upstream and they completely changed the interface they wanted, never got back to redoing it from scratch :/
<lrvick>
as long as the clients verify the central repo state then we are good
<andi->
GH can enforce signed commits for everything..
<adisbladis>
lrvick: It seems I was confused as to the usage of patch-id
<ekleog>
lrvick: the question is, how will clients all reject the current head?
<andi->
but you can't tell it which ekys are required :D
<adisbladis>
Anyhow. Now when I understand how to use it I don't think it's a good fit.
<ekleog>
andi-: oh. just had a false hope xD
<adisbladis>
lrvick: How dou you integrate signed patch ids into your workflow?
<adisbladis>
I _love_ my git commit auto signing
<ekleog>
^
<lrvick>
adisbladis: I have a tool I maintain called "git-signatures" as a git plugin
<adisbladis>
I hate when security gets in my way
<pie_>
signing will only ensure integrity up to the source of wherever the stuff comes from, it wont prevent backdoors, just make them attributable
<lrvick>
so I do "git signatures add"
<lrvick>
the end
<andi->
ekleog: I think they just use the keys for the people that they uploaded - if they verify it at all..
<pie_>
to "whatever it is that signed this"
<lrvick>
well. "git signatures add --push"
<ekleog>
andi-: so, well, it's useless :'(
<adisbladis>
lrvick: That's probably not gonna fly in something like nixpkgs
<andi->
yes
<ekleog>
andi-: do you know if there's a way to have a receive-hook or equivalent on the server side from github? I think not, but…
<lrvick>
adisbladis: only those with merge access to master would need to use that
<andi->
ALso what benefit is signing to us? What stops me from rolling a random key on each commit..
<lrvick>
adisbladis: individual contributors would just use regular git signing
<elvishjerricco>
I'd rather change the workflow to require maintainers to sign merges locally and push, rather than introduce extra required tooling for all maintainers and conusmers
<ekleog>
andi-: your key would be in a nixos keyring, associated to your identity
<adisbladis>
I think that's the only way to operate at scale
<ekleog>
elvishjerricco++
<{^_^}>
elvishjerricco's karma got increased to 6
<adisbladis>
We can't force contributors to sign
<ekleog>
andi-: so if you insert a backdoor, you get banned
<andi->
agreed... adding/changing tooling is hard
<adisbladis>
The long tail of contributors will get very short
<lrvick>
You can't force contributors to sign but as long as a trusted maintainer signes the merge commit, then that is probably fine
<pie_>
eh...you could have an unsigned commits section or something
<adisbladis>
andi-: My main point whatever flow we decide has to fit in very well with how git is used "normally"
<andi->
adisbladis: yes, I agree
<pie_>
what lrvick said
<lrvick>
presumably the maintainer is doing code review
<lrvick>
So really we just need all nixos -maintainers- to publish their signing key fingerprints as job #1
<andi->
I would alos just go with "merges from PR must be signed by the person merging it" & "people with commit bit MUST sign their commits"
<elvishjerricco>
This is going to have problems with the staging branches. We're going to have to treat merges to staging branches with the same process as master: must be signed. Otherwise the massive merges from staging to master will be un-signable
<ekleog>
andi-: hmm, that looks… hard to handle on the server side :/
<ekleog>
lrvick++
<{^_^}>
lrvick's karma got increased to 1
<ekleog>
deciding the tooling is only after each committer has a signing key published
<adisbladis>
andi-: Yeah. Not too bad.
<elvishjerricco>
Yea, I was talking about maintainers having to sign; not regular contributors
<ekleog>
andi-++
<{^_^}>
andi-'s karma got increased to 5
<pie_>
lrvick, how do you handle key revocation? if its included in nixpkgs, moving around in the timeline would only give you the revoked keys at any given time
<lrvick>
I think git-signtures could really help here and make multi-branch maintianing easy, and multisig... buuuuut if you wanted to nest merge commits you could.
<lrvick>
it just means rebases can never ever happen
<srhb>
Asking out of curiosity: Is going from git repo with all-signed commits to flat tarball of the tip of $somebranch where everything is still somehow verifiably signed trivial?
<ekleog>
andi-: btw, your sentence can be summed up into just “people with commit bit MUST sign their commits”, and disable the merging from web ui
<andi->
ekleog: yes it can be but makes it more explicit IMO ;)
<adisbladis>
srhb: Nope.
<srhb>
That could be a problem...
<lrvick>
pie_: same way arch and debian do it: Have a tool that syncs keys of all maintainers.
<adisbladis>
srhb: Git signatures are not over the full tree, so you'd pretty much have to trust hydra to re-sign the tarball.
<lrvick>
of a given maintainers key expires in WKD or keyservers that package is nos untrusted
<ekleog>
srhb: no, but anyway if the tarball's from nix-channel it's not a big deal, just trust the cache
<lrvick>
now*
<srhb>
ekleog: Yeah, I don't want to do that. :P
<ekleog>
people who don't trust the cache will likely have their own hydra or equivalent anyway
<elvishjerricco>
srhb: I don't think so. We're trusting maintainers' signatures anyway. Why wouldn't we trust them to produce tarballs only from signed commits too?
<srhb>
True enough
<srhb>
Thanks :)
<pie_>
its not the maintainers producing the tarballs
<pie_>
its the build systems
<pie_>
thats why? :P
<andi->
we would need a way to verify peoples keys and should start cross-signing them so we do not have to trust githubs registry of keys..
<elvishjerricco>
True... So we have to trust the build system. Which is managed by maintainers. soo...
<ekleog>
andi-: tbh, TOFU sounds acceptable here
<srhb>
Trust whoever setup hydra to ensure that it verifies the commits before producing and signing the tarball. That's fine
<adisbladis>
andi-: A good start is to use the github registry?
<srhb>
The chain is still unbroken.
<lrvick>
reproducible builds that multiple build systems agree on a hash on can be trusted from cache, else build locally. Could be a security config option
<pie_>
elvishjerricco, the one CI vulnerability i raise as a counterpoint
<srhb>
(It's just another attack vector)
<pie_>
there needs to be a way to show integrity between the tarball and git repo
<ekleog>
andi-: in https://github.com/Ekleog/signed-git/ my PKI is just “a commit must be signed by a key already present in the last signed commit”
<andi->
ekleog, adisbladis: yes that is a start but for example I am migrating from RSA to edd25519 GPG keys.. So my key will change in a while and then there is no trust from any of you ;)
<elvishjerricco>
Anyway, I think the CI / build system stuff is a discussion for a later time, after we have a signed commit history
<lrvick>
^^
<lrvick>
I can talk about lots of ways to solve that problem, and it is a solved problem
<lrvick>
debian and arch do a great job at this
<lrvick>
but bigger problem is git
<pie_>
yeah
<pie_>
@ later
<ekleog>
andi-: so you'd first push a commit adding your ed25519 key signed with your RSA key, and then push a commit removing your RSA key signed with your ed25519 key
<elvishjerricco>
lrvick: Can I ask that your RFC include both alternatives; the patch-id thing and ordinary git signing?
<lrvick>
elvishjerricco: I'll even provide one liners.
<lrvick>
but tomorrow. For now I gotta sleep :)
<andi->
ekleog: yeah, thats fair enough (the key change procedure).
<pie_>
and once this is done people need to go and start reviewing the unsigned nixpkgs code ;P
<andi->
we would have to run those check regulary and if a commit splits through SOMEONE will have to rewrite history (thus invalidating all signatures inbetween)?
<adisbladis>
Or just sign it all in one big go and say "trust epoch starts here"
<adisbladis>
andi-: Not rewrite history but correct it and push a signed correction.
<elvishjerricco>
As a tangent, how hard do you guys think it'd be to write some underhanded Nix? Disregarding the ability to introduce underhanded C with patches :P
<andi->
adisbladis: my feeling there is that some day we might let commits without signatures through that are contentwise okay
<ekleog>
andi-: ideally I'd have a receive-hook on client, so noone would be able to fetch an errorring commit, and the rewrite of history would just be removing the failed commit
<ekleog>
andi-: but that's the patch to git that didn't get accepted :'(
<lrvick>
andi-: if you did that clients should reject it.
<pie_>
elvishjerricco, i do wonder about a nixpkgs red-team sometimes :P
<lrvick>
actually there are -three- options
<lrvick>
you could just commit a detached signature .nix and .nix.sig
<lrvick>
everything else could go unsigned
<andi->
That smells like a lot of bloat for all the files :/
<ekleog>
^
<adisbladis>
And requires special nix tooling to maintain :/
<adisbladis>
It's already hard enough to explain how to make a PR to nix without introducing extra fluff
<lrvick>
you need special nix tooling to enforce verification no matter which of the 3 options happen
<andi->
Security is mostly a user experience problem :)
<adisbladis>
lrvick: Special tooling for verification is fine. That runs on build systems. Not on every contributors computer.
<lrvick>
Honestly though do you really want maintainers that can't generate a pgp ky?
<adisbladis>
lrvick: Not maintainers, but contributors.
<ekleog>
lrvick: IMO special tooling should be 1. transparent once the setup is done, and 2. requiredonly from maintainers
<pie_>
adisbladis, only if you can provide a checkable verification artefact to users
<lrvick>
I am a bit extreme in that I turn on requirement that all commits must be signed on the repo and call it good. I also offer to teach any contributors/maintianers on my projects how to PKI.
<pie_>
s/artefact/witnett/
<pie_>
witness
<lrvick>
I write lots of docs on how to use yubikeys for gpg/ssh etc
<ekleog>
I *think* my commit signing model with pre-push and receive hooks on the client handles these two requirements about correctly :)
<lrvick>
it is easy. There is no excuse for not using a smartcard for ssh/signing/etc these days. When contributors whine about it and are clearly talented I buy them yubikeys out of pocket
<lrvick>
:-P
<ekleog>
(ie. just “signing a commit takes responsibility for all unsigned commits since the last signed commit)
<ekleog>
lrvick: let's see that in a second step, would you? :p
<pie_>
ekleog, eh, what if you check out an unsigned commit between signed ones
<lrvick>
phase one is get maintainers doing it so every HEAD in master is signed, then fanout to the contributors...
<ekleog>
pie_: you can't thanks to the receive hook (which… doesn't exist yet :()
<andi->
lrvick: which ed25519 hardware key would you buy? ;)
<ekleog>
lrvick: agreed
<pie_>
ekleog, preferably a backdoored one ;D
<lrvick>
andi-: andi- FST-01 or nitrokey
<lrvick>
FST-01 is easiest to trust
<ekleog>
andi-: I think the gnuk keys have that (though they're not secure components, it still reduces a lot the attack surface)
<lrvick>
can build it yourself with a soldering iron
<lrvick>
easy
<adisbladis>
lrvick: But no secure element
<ekleog>
but anyway that's irrelevant to the conversation
<lrvick>
True. Personally I use yubikeys and RSA4096
<ekleog>
so. 1. get every maintainer to sign before pushing, 2. add in tooling to actually check that, 3. have nix-channel check that for users, 4. ???, 5. profit
<ekleog>
right?
<pie_>
its really annoying how closed security elements are, im not sure if there's obscurity requirements to get certain certifications
<lrvick>
ekleog: sounds about right. I'll detail the RFC to that end
<andi->
ekleog: how do we handle issues? I am still not sure how we do that if we want to ensure the entire chain of commits is okay?
<ekleog>
pie_: there aren't, but CC does give bonus points for obscurity, so people do it to get free bonus points and have less security otherwise :(
<andi->
I mean invalid/missing/wrong signatures on the path
<lrvick>
pie_: poking holes in HSMs is what I do for a living. All of them are shit >.>
<pie_>
ekleog, i still dont like that no checking if no nix channel :P what if you use a raw tarball or something and set your nixpath
<pie_>
i think checking should be at the point of consumption
<lrvick>
most HSM makers don't even do shit in constant time so you can just use classic power analysis to dump keys
<pie_>
lrvick, oh huh, that sounds pretty interesting
<pie_>
lrvick, which lents a certain amount of credence to sou saying certain ones are most trustble :p
<ekleog>
andi-: Before 2, there will be invalid signatures. After 2, invalid signatures should be rewritten out of the history
<pie_>
lrvick, haha really?
<ekleog>
*or*
* adisbladis
can corroborate
<lrvick>
pie_: least shitty is all I can say.
<adisbladis>
I have _way_ more trust in consumer devices (like yubikeys) than for example safenet
<ekleog>
andi-: actually better: Before 2, there will be invalid signatures. After 2, a reverting commit should be pushed and signed so that the result is null
<lrvick>
^^^^^
<lrvick>
fuck safenet
<lrvick>
*my opinions may not reflect that of my employer yadda yadda*
<lrvick>
lets just say I got close and personal with safenet hsms for weeks and wanted to vomit.
<adisbladis>
lrvick: There there..
<elvishjerricco>
with regular git signing, can github be configured to reject pushes to master that aren't signed? Otherwise someone can just push an unsigned commit, another maintainer can unwittingly pull it and merge a PR on top of this unsigned commit, and push a signature causing the unsigned changes to be signed.
<andi->
mhm, I am not sure how that fixes validating the chain of commits because the revert will be on top and then you probably wnat the smae guy to add the changes (which break other stuff?) to commit again with signature.. My model here is the sleepy developer not attacker ;)
<elvishjerricco>
I suppose you'd hope that the maintainers verify sigs on pull
<pie_>
lrvick, i dont suppose the analyses are public :p
<ekleog>
elvishjerricco: yeah, maintainers should verify signs on pull
<ekleog>
though git currently lacks tooling for that, so it'd need to just override git-fetch
<lrvick>
pie_: I'll be making a -lot- of my research public once things are patched.
<pie_>
lrvick, cool
<pie_>
or rather, are they ever going to get patched lol
<ekleog>
andi-: sleepy developer has installed a pre-push hook at step 2 that blocks pushes :)
<pie_>
lrvick, where will one be able to find it
<adisbladis>
I have a feeling that there might be a completely different model for nix given it's lazy tree structure
<ekleog>
(well, during step 1, actually)
<elvishjerricco>
ekleog: Git lacks tooling for verifying on pull?
<andi->
ekleog: what is signed with $workKey vs $privateKey? ;)
<lrvick>
probablly not, but at least I'll be long gone on different hardware I trust more for every org I care about.
<elvishjerricco>
I thought you could set `merge.verifySignatures` in git config?
<pie_>
lrvick, no patch no public research though :p
<elvishjerricco>
So that you never merge something or fast forward to something that isn't signed
<andi->
ekleog: okay, I'll check that when this phone call is done :)
<lrvick>
pie_: when vendors refuse to do anything after 90 days I generally say fuck it and publish as long as I am no longer using their shit.
<ekleog>
(though it's missing the receive hook for the time being)
<pie_>
lrvick, ah, the latter half
<ekleog>
lrvick: just curious, are you talking of certified HSMs, or not? (couldn't find easily accessible info. on whether safenet hsms are certified)
<lrvick>
ekleog: certified does not mean anything. FIPS is mostly a joke.
<lrvick>
there are FIPs certified windows xp hsms
<andi->
ekleog: hows the runtime of that script?
<ekleog>
andi-: I haven't tested it on nixpkgs (don't have commit bit there :p), but it's basically handling only commits in the from..to range with git rev-list keys/keys and checking these with git verify-commit, so shouldn't be too slow
<andi->
It would be nice if we could write the idea(s) down in an RFC..
<ekleog>
lrvick: I know only EAL
<andi->
or a draft before pushing it for review (to avoid initial fallout of flames? ;))
<ekleog>
(worked in an EAL lab for java card, hence my question, because timing attacks were among the things tested :))
<ekleog>
lrvick: oh, yeah, as andi- says, don't submit the PR immediately, send a draft here first :)
<ekleog>
(basically, if the RFC doesn't pull everyone together, it'll never be merged, so its first draft already needs to be perfect…)
<pie_>
eh, i thik rfc would be fine for discussion with the caveat that the rfc by itself will not result in something happening :P
<pie_>
</bikeshed
<andi->
we do one RFC for discussing and another one that will be "perfect" with all the feedback that the first received? ;)
<lrvick>
I implemented "git signatures --verfiy" in my git-signatures tool. More importantly --min-sigs=2 for multisig for high security repos.
<elvishjerricco>
ekleog: Ah, so your issue is that git doesn't verify signatures on fetch; merge.verifySignatures only covers merges and fast forwards.
<elvishjerricco>
Does merge.verifySignatures cover hard resets?
<ekleog>
hmm actually re-reading the discussion makes me think that with a custom remote helper, things can be done :)
<ekleog>
would need more thought, though
<ekleog>
lrvick: if your tools can do both the 1. only require work during setup, don't change anything else in the standard git workflow, and 2. only require work from maintainers, then it's likely great :) but it didn't sound like it from the way I understood it
<lrvick>
Yep I am confident I can hit those boxes.
<lrvick>
Will detail when I am more awake
<lrvick>
Sleep time
<sphalerite>
oh boy I've missed a lot of discussion
<ekleog>
'night :)
<{^_^}>
Night!
<adisbladis>
It all sounds possible. We would likely have to give up some conveniences like the github merge button.
<andi->
adisbladis: or you trust the github key ;) j/k
<adisbladis>
=)
<andi->
ekleog: does signature verification also verify that the authors name/email is the right one for the key? I haven't used that yet.
<adisbladis>
andi-: It's just GPG, it checks if a key is in the keyring.
<andi->
Not ideal
<adisbladis>
Also not too bad. It's easier to enforce signing since re-signing someone elses commits are an option.
copumpkin has quit [Read error: Connection reset by peer]
copumpkin has joined #nixos-security
<gchristensen>
GitHub signs merges
<pie_>
resigning should not need to be part of main workflow
<pie_>
(did not keep track of previous discussion too well in case thats not implied)
<pie_>
i mean, fail fast
<pie_>
</bikeshed>
johnnyfive has joined #nixos-security
<ekleog>
andi-: so long as it's a key from the keyring, it means it's easy to check who signed the commit (it displays in `git verify-commit HEAD`, for instance)
<ekleog>
so yeah, imo just verifying that the commit has been signed from a key in the keyring is enough imo
<ekleog>
gchristensen: the problem of using github's merge signature is that the whole point of signing commits is to be able to distrust github :)
<ekleog>
(like, currently potentially quite a few github employees could sneak in a backdoor at any time, and likely noone (apart from maybe github) could trace the source of the backdoor)
<ekleog>
(well, signing commits also “distrusts committers” in a way, given if they do introduce a backdoor it'll be signed by their key, but I'm not sure that's the main point)
<pie_>
IIRC a very long detailed post on how to do this right
<pie_>
it's been ages since I read it though
<ekleog>
pie_: same here, and I've eventually come to the idea that their idea 2 was about the best one, except it doesn't allow for any kind of recovery, hence my modification of it to say “there can be unsigned commits on master, but master's head must always be signed, and each signature takes responsibility for all commits between it and the last signature” :)
<pie_>
so re: i dont know how this works outpractically and i barely know how git works, the reason that makes me uneasy is what if there are unexpected failure modes and suddenly you have an unattributed commit somehow
<pie_>
but i mean, feel free to ignore me if what i ay doesnt really make sense. a sort of contrived example that may or may not work idk, is what if someone puts shell control characters in their commit and makes it look like something else when a maintainer is reviewing in a terminal
<pie_>
*i say
<gchristensen>
every commit signature implicitly signs every parent
<pie_>
i guess im kind of conflating things there though
<gchristensen>
imo major problems include (1) gpg sucks (2) gpg is hard to use safely (3) gpg is hard to use at all
<pie_>
all of those sound important
<pie_>
i started using enigmail recently, did have some small issues but did seem to succeed at getting it working
<gchristensen>
so any solution, I think, has to focus heavily on how to not make it miserable
<pie_>
so it /was/ nontrivial
* pie_
runs off
pie_ has quit [Ping timeout: 272 seconds]
<ekleog>
gchristensen: imo good tooling can make it easy. also, for git signing we don't need the wot or whatever, just gpg's signature option, so there's really nothing hard to configure apart from 1. generate a key, 2. [insert here tooling-specific stuff, eg. adding the public key to the repo and setting a few hooks], 3. let the tooling do all the job
<ekleog>
gpg being hard to use is a big problem when you're trying to do complex things with it, like WoT or whatever, for simple things (here, just signing/verifying) there's not much that can go wrong, and a script could even automate the “generate key” portion (though the usual “stick to defaults” argument holds)
<gchristensen>
the value of gpg assumes the user can safely use gpg
pie_ has joined #nixos-security
* ekleog
don't understand
pie_ has quit [Ping timeout: 264 seconds]
pie_ has joined #nixos-security
<lrvick>
gchristensen: signing a git commit is literally 'git commit -m "some thing"'
<lrvick>
git has built in gpg signing
<lrvick>
plug in a smartcard, generate a key, add one line to git config
<lrvick>
volia, you are signing stuff
<gchristensen>
yes I know
<lrvick>
people make gpg seem way harder than it is
<gchristensen>
oh I see
<lrvick>
as a counter point I would argue gpg signing commits is so easy there is no excuse for any engineer to -not- do it.
<lrvick>
I have done a lot of writeups on all these workflows and am happy to help make them more accessible.
<lrvick>
public key cryptography is pretty easy to use. Somehow we finally got everyone to learn to use "ssh-keygen" to generate a key to authenticate to servers.
<lrvick>
gpg builds that in now
<lrvick>
oh actually to those asking for RFC review: I will be copy pasting most of the commit signing link above
<samueldr>
though, imho, gpg signature shouldn't be made automatically; only with aa verified action from the developer: you don't want a malicious commit signed because of too much automatization
<samueldr>
thinking about both local access to the machine (unlocked session) and remote access types of attack
<samueldr>
signing shouldn't be a byproduct of a process
<samueldr>
(still in my opinion)
<andi->
would it be a byproduct for you if you specify -S when commiting?
<samueldr>
the main idea is to make the signing a concious action, and hopefully a verifiable action (passphrase, biometrics [even though biometrics aren't authentication, but identification])
<samueldr>
it doesn't have to be inconvenient, but imho should be *an action*
<andi->
I get that, thats why I never sign per default, despit adding -S to commits that I think would benefit of a signature (like my nixpkgs commits)
<samueldr>
pretty much
<andi->
The problem is if it becomes a habit to just sign everything or always?
<samueldr>
I would like to link something I read... but it was too long ago, and can't find it :/
<samueldr>
where the idea of the text was "when you sign everything, it's as good as signing nothing"
<samueldr>
(only siths deal in absolutes)
<andi->
I am not sure I do agree with that... I would probably move it more towards what you said before.. Signing still has to be a concious action.
<samueldr>
yeah, I definitely botched the description there :)
<andi->
If you unlock your gpg keyring on login and from there on just sign whatever floats your shells...
<samueldr>
and it was more about the policy of signing everything, dealing with humans, than the technical side
<andi->
I do nit sign all my mails but most of them. Same is true for my commits. Especially since I do want to provide a secondary path of verification that it is something the allegedly I did. I get the part about humans and I vaguely remember that.. People might stop caring about the signature or enforcing one not caring about the actual validity?