[Exherbo-dev] [Exherbo Security] Package Distfile Signing Proposal

Jason A. Donenfeld Jason at zx2c4.com
Thu May 10 01:08:21 UTC 2012

Hi All,

Exherbo is such a delightfully clean distro, I love having it on my
server, because I can see how all the moving parts work. It's nearly
everything I've always wanted fixed from Gentoo. One thing, however,
that I really do miss from Gentoo is the security provided by package

It's not just an academic issue. Now a days, every blackhat and their
mother has owned a major distfile mirror, and it's something of a
weekend sport to own the smaller more obscure distros (like Exherbo)
and trojan their OpenSSH. It's a real threat. It's happening now; it's
part of the world we live in. There's little excuse for not focusing
on appropriate signing.

First I'd like to outline a couple existing and proposed approaches
and their benefits and detriments:

- Exheres in git repos: Works great, the Linux kernel project relies
on git's native crypto as well, and if there's not a regular culture
of rebasing, this defeats backdooring well. Distributing exheres via
git repo as we do now is a good thing.

- Exherbo_repositories.tar.bz2: The lack of signing here is a big
issue and should be discussed in any practical solution.

- Automatically mirroring packages on Exherbo infrastructure: While
this might have certain benefits of not having to rely on other
infrastructure, it actually just increases the attack surface, since
everything is automatic. An attack either owns one of the many mirrors
that we download from, or he owns our own infrastructure. There's no
security benefit from doing this, though there might be non-security
related technical benefits.

- Unpacking distfiles into a git repo: While this seems a good idea at
first, doing this automatically suffers from the same issue as the
above bullet point -- mirrors that we automatically unpack from can be
owned, and the consequences will trickle down to us. Additionally,
there are the usual time/bandwidth/size concerns that come with this,
and the usual headaches of shallow git checkouts that most people
don't want to reckon with.

- Gentoo's manifest files: This is pretty decent in a lot of ways, but
lots of developers don't like the patch flow with trying to keep these
up to date and the various headaches of that. I get the sense there's
a kind of implicit "we're not doing that way, regardless", based on
everyone's past experiences, so for all intensive purposes, I'm
assuming we nix this possibility. Correct me if my presumption is
silly though.

- A separate git repo that has all the manifests: dunno if there are
many supporters of this, but if you see that it has architectural
benefits, please pipe up.

These are what I've heard being discussed and past around prior.

There are actually three problems to solve:
a) exheres integrity
b) exheres source integrity (exherbo_repositories.tar.bz2)
c) distfiles integrity

We have solved (a) with git but neglected (b) and (c).

Here's one proposal I'd support for solving (c):

We add two global options for build_options:

- require-checksum-success: Builds fail if the distfiles have the
wrong checksums. This would be enabled by default.
- require-checksum-existance: Build fails if checksum does not exist.
This probably should be enabled by default, but I could imagine some
people wanting it opt-in. Up for debate.

We add a global variable like DOWNLOADS to exheres called CHECKSUMS:

CHECKSUMS="foobar-1.2.tar.gz - sha1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
           barhaz-0.8.tar.bz2 - sha1:254c83b354a04b5c06bcb18671f2dcb340ce3165
           floradora.patch.xz - md5:5d41402abc4b2a76b9719d911017c592

We define a stage called src_checksum() that runs the checksums on
everything from DOWNLOADS and all other non git-tree sources, such as
those brought about in custom ways from src_fetch or src_nofetch, or
manually downloaded undistributable tarballs, or likewise. I say "non
git-tree sources", because the patches in
sys-apps/foobar/files/fix-for-gcc-1.2.patch are already verified by
item (a) exheres integrity above.

src_checksum bails if require-checksum-success is set and the checksum
fails. src_checksum bails if require-checksum-existance is set and the
CHECKSUMS variable has not yet been defined.

Bumping a package will then involve the usual filename rename as well
as updating the CHECKSUMS values. The integrity of CHECKSUMS itself is
provided by (a).

Please note that this proposal only works if *developers are
responsible and follow upstream's own tarball signing verification
protocols, and not blindly updating the CHECKSUM to whatever trojan'd
tarball they've downloaded*.

Of course, all the names and syntax introduced above can change
according to preferred conventions.

The solution to (b) exheres source integrity
(exherbo_repositories.tar.bz2) is even simpler. We include, as well
exherbo_repositories.tar.bz2.gpg-signature, which is a GPG signature
of the tarball. The public signing key is posted to the public key
servers for verification, and the file is checked to see if it's
authentic before unpacking. The private key is placed on a USB token
device offline so that it can't be stolen.

Well, that's what I got. It's likely to be imperfect, but at least
it's a place to start discussion. Hopefully we'll be able to do things
without too much bikeshedding and try out a few experimental things.
After all, one of the benefits of Exherbo from the website is, "We
need the freedom to break things when necessary."

That said, I don't think this proposal or any others will be
disruptive at all, and will definitely provide a real world essential
security improvement.


Jason A. Donenfeld

More information about the Exherbo-dev mailing list