[Exherbo-dev] [Exherbo Security] Package Distfile Signing Proposal
eternaleye+usenet at gmail.com
Fri May 11 10:36:16 UTC 2012
Jason A. Donenfeld wrote:
> 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:
I'd like to propose another:
A per-repo git submodule of manifest-like things. Personally, I'd like if we
could use metalink, since it has some rather nice properties I brought up in
Making a tool that maintains those submodules, even if automatic, doesn't
necessarily fail where you seem to think it will. I'll try to address that
> 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):
I think a safe way to do it within what I described above might be:
1.) Start using mirrors:// a lot more heavily
2.) Note (in the exheres?) the public-key fingerprint(s) allowed to sign for
a distfile, if applicable
3.) In the manifest-managing tool, download a statistically significant
subset (or all) of the mirrors of a given file.
4.) Download the upstream checksums and gpg signatures as well, in addition
to whatever ones we choose to provide.
5.) Validate all of the above (cross product of file-mirrors and
6.) If a copy fails any check, mark that mirror as untrusted/blacklisted.
Refuse to download any distfile from it.
7.) Multiplex the list of good mirrors and the checksums/signatures for
*all* of the downloads of an exheres into a single metalink file. Yes, it
8.) On fetch, simply use a metalink client (there are several) to fetch
them. At least one metalink client supports downloading all files within the
metalink simultaneously, providing an added benefit of improving download
A useful property is that steps 3-8 can be fully automatic, and omitting
steps 1, 2, and the 'provide-our-own-checksums' part of 4/5 can only reduce
our security to what it currently is, doing no harm in the security sense.
That also means that such things could be added gradually, rather than
having a 'flag day' by which everything has to have been modified.
We could even make running the manifest tool a pre-receive hook on g.e.o,
which would mean that any pull would always have up-to-date manifests.
(cd to a clone that uses --reference, check out the HEAD that would be
pushed, run manifest generator on each changed exheres, commit to manifest
The main downside there would be the added latency for pushes, especially
for the more ridiculous distfiles *cough*libreoffice*cough*.
Something that may benefit this would be changing the layout of the distdir.
$hashtype:$hash -> ../../by-hash/$hashtype:$hash
$hash -> ../../../canonical/<actual file>
<by hash? which hash?>
Note: in by-hash, $hash should probably be trie-ified to reduce directory
When foo/bar-1.2-r1 is fetched, we look in the index to see if we already
have a distfile matching *all* the hashes we want for bar-1.2.tar.bz2. If we
find it, we copy it into the per-package foo/bar-1.2-r1/ distdir. We then
run the fetch as normal, not refetching stuff pulled from the index (as long
as it validates). Any files that were not in the index are added to
canonical/ and linked into the index. Further phases proceed as usual, and
then as part of tidyup we remove the per-package distdir.
This would also help solve how some packages try to download distfiles with
the same name but different contents - rather than requiring a blacklist
(what arrows in DOWNLOADS were introduced to fix, IIRC), this solves the
entire class of problems.
> 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.
The best way to solve this might simply be to make playboy commit to a git
repository instead of making a tarball. For those in the know: Is there a
reason it doesn't do so?
> 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