Hey guys, While our infrastructure team has some nice technical competence, the recent disaster and ongoing embarrassing aftermath has made ever more urgent the need to have end-to-end signatures between developers and users. While the infrastructure team seems fairly impressive at deploying services and keeping the house running smoothly, I'd rather we don't place additional burden on them to do everything they're doing securely. Specifically, I'd like to ensure that 100% of Gentoo's infrastructure can be hacked, yet not backdoor a single witting user of the portage tree. Right now, as it stands, rsync distributes signatures to users that are derived from some infrastructure-controlled keys, not from the developers themselves.
Proposal: - Sign every file in the portage tree so that it has a corresponding .asc. Repoman will need support for this. - Ensure the naming scheme of portage files is sufficiently strict, so that renaming or re-parenting signed files doesn't result in RCE. [*] - Distribute said .asc files with rsync per usual. - Never rsync into the /usr/portage directory, but rather into an unused shadow directory, and only copy files from the shadow directory into /usr/portage after verification succeeds. (The fact that those files are visible to portage prior to verification and following a failed verification is a shameful oversight of the current system.) - Have verification use a keyring of all Gentoo developers, with a manual prompt to add new Gentoo developers to it. - Eventually acquire (sponsors?) nitrokeys/yubikeys for all developers, and mandate everyone stores their Gentoo key material in there exclusively. This is very similar to what Arch Linux is doing, and AFAIK, it works well there. I'm sure this list will want to bikeshed over the particulars of the implementation, but the two design goals from this are: - Signatures are made by developers, not by infra. - Portage doesn't see any files that haven't yet been verified. Regarding the [*] comment above about the directory tree. There might be more clever ways of handling this, like having the last developer who modified the tree compute some kind of holistic signature, in addition to each of the individual ones. Or, perhaps, this is the one place where we would consider relying on infrakeys, provided portage isn't victim to clever RCE by rearrangement. Other attacks include, of course, downgrades and DoS. Hopefully we can move Gentoo's portage tree security up to modern security expectations, and no longer be forced to trust vulnerable sitting-duck infra machines for our signatures. Jason
