45mg <45mg.wri...@gmail.com> writes: > Hi Tomas, > > Tomas Volf <~@wolfsden.cz> writes: > >> Right, so I finally found some time to think about this, and I believe >> doing this safely should be possible with minor modification of the >> code. >> >> Currently Guix uses *intersection* of keys from all parents. I would >> like to suggest modifying the check to use an *union* of: >> >> 1. *Intersection* of keys from all parents (the current logic). >> 2. Keys listed in $GUIX_AUTHENTICATE_EXTRA_KEYS. >> >> (and, if you are soft-forking Guix, you could also add your key to:) >> >> 3. Keys listed in new variable ((@ (guix git-authenticate) extra-keys). > > I do like the simplicity here, but I'm not too clear on how exactly this > is meant to be used. So the concerns I'm stating here are based on some > assumptions in that regard. > > Suppose you use either the GUIX_AUTHENTICATE_EXTRA_KEYS envvar or the > `extra-keys` variable to sign all your fork commits with a particular > key (I'm assuming you're not defining a new channel introduction for > your fork, as this new mechanism means you don't have to?).
You are right, I would not have to, but I would still do so, to have a known correct "starting" point. > Now suppose your key gets compromised. You still have to specify it as > one of the extra keys if you want to authenticate any of the commits > signed with it. Meanwhile, the attacker who has the compromised > private key can create new malicious commits signed with it. These > won't be authenticated if you're careful and always use the right set > of extra keys (ie. specify the compromised one only for the specific > range of commits signed with it, and make sure never to specify it > otherwise). But I'm thinking it would be pretty easy to slip up. You are right. My thinking here was (and still is) that since this is mainly intended for solo personal forks, in case my key gets compromised, I have bigger things to worry about anyway (since that likely means the SSH key able to access all those machines doing guix-pull got compromised as well). In practice in the event of key compromise I would make a new introduction with a clean key and never returned before it, since anything in there can be malicious code. > > Next, the `extra-keys` variable specifically... I have a bad feeling > about this one. My understanding is that when you `guix pull` from a > particular commit in your fork, the Guix CLI you end up with is built > from that commit, so it will use whatever that variable was defined as > in that commit. Now suppose one of the keys in `extra-keys` gets > compromised, so you remove it in a new commit. But if you ever have to > use Guix built before the new commit (eg. rollback to an old system > generation), then `guix git authenticate` will trust all commits signed > with the compromised key. Again, you'd have to be super careful and > mindful at all times. Also true. :) But in practice while the rollback *is* essential feature of Guix, I use it rarely, and when I do, it is just one generation back. I do not think I ever rollbacked enough for it to matter in this case. Notice that even with the upstream authentication mechanism, in case of key compromise (and malicious commits in the git), you can still get to them using guix time-machine (since it will not know the key was later revoked). Actually, I am not sure Guix has a policy whether to rewrite the history or just revert the (malicious) commits. Would you happen to know? > > [...] >> Sadly I have to admit I am not smart enough to be able to judge whether >> this is safe. I do understand the direction of your proposal, but I do >> not have enough confidence (especially after the flop my original patch >> is) to say either way. > > Don't be too hard on yourself; even the best of us make mistakes. I'm > definitely not "smart" enough with Guile to write something as cool as > your `fork-guix` script. If we could do everything, perfectly, on our > own, then we wouldn't need FOSS :) > > With that said - I'm actually holding off on pushing my proposal for > now, because the 'reverse-rebase' workflow that Liliana mentioned seems > like it would meet my (and most peoples') requirements [1]. I intend to > try it out the next time I have to work on some patches, and I suggest > you do as well. If it works well enough, we can document it, and then > close the issue I opened (75552). It would be far less effort than > working on and implementing a new solution and then having to convince > everyone that it's secure. Sound like a reasonable approach, let me know how it goes. :) Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
