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

Alex Elsayed 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
> signing.
> 
> 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:
*snip*

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 
http://thread.gmane.org/gmane.linux.distributions.exherbo.devel/1049 . 
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 
below.

> 
> 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):
*snip*

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 
checksums/signatures)
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 
supports that.
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 
speeds.

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 
repo, done)

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.


Something like:

$DISTDIR/
  index/
    by-canonical/
      <as canonical>/
	$hashtype:$hash -> ../../by-hash/$hashtype:$hash
    by-hash/
      $hashtype/
         $hash -> ../../../canonical/<actual file>
  canonical/
      <by hash? which hash?>
  foo/
    bar-1.2-r1/
      bar-1.2.tar.bz2


Note: in by-hash, $hash should probably be trie-ified to reduce directory 
size.

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.
> 
> Thanks,
> Jason
> 
> --
> Jason A. Donenfeld
> www.zx2c4.com





More information about the Exherbo-dev mailing list