[gentoo-dev] Trustless Infrastructure

[Jason A. Donenfeld]

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