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?). 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. 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. [...] > 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. [1] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00133.html
