Hi, I wonder how would the local changes to ebuilds be handled ? Currently it's possible to change ebuild, do "ebuild package.ebuild manifest" and emerge package - will this still be supported ?
If not, would there be any plans for a tool for creating trusted local overlays ? This feature is useful when fixing ebuilds or adding new versions by copying existing ones locally. Best regards, Mariusz Ceier On 2 July 2018 at 17:36, Jason A. Donenfeld <zx...@gentoo.org> wrote: > 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 >
