Re: [gentoo-dev] Trustless Infrastructure

[Mariusz Ceier]

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 <zx2c4@g.o> 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
>