Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

Remko van der Vossen (wich AT yuugen.jp) wrote [11.12.02 09:04]:
> On Fri, Dec 02, 2011 at 02:02:29AM +0900, flux wrote:
> > You completely missed the points I've made in previous posts in this
> > thread. It is precisely not about us vs. them, but about single vs.
> > multiple points of failure.
> 
> Note that using upstream gpg with signature hashes still does not remove
> the single point of failure, we only move it, or actually reduce the
> number of single points of failure from two to one. If the grimoire is
> compromised the pgp key in the grimoire could simply be replaced by
> another key, the key url can be changed and the signature hash can be
> changed, still a single point of failure. If we really want to remove
> the single point of failure we need to take part of the equation out of
> the grimoire.

This is a good point. It would require more work on the part of the
compromiser(s), but certainly is a possibility. They would actually need
to modify our spells, in addition to swapping keys/hash values, and they
would need to modify *all* spells that made use of a given upstream key
(easy for keys from small projects, more work for, say, a GNU key, but
the work can be scripted too).

> What we could do is require that upstream keys are signed by SMGL owned
> keys, this could either be with some single SMGL authority key, or with
> a web of trust kind of deal where a certain number of gurus need to have
> signed the key. If we go this route however we should be very careful
> with how people use their keys etc. Right now a number of people,
> including myself use or used their regular gpg key for source signing in
> the grimoire. If we start signing other keys with our keys we can't use
> our normal keys anymore as that would invalidate the normal worldwide
> web of trust since we don't actually do any identity check for those
> keys with the owners. Note that of course the authority key and/or the
> list of guru keys needs to external to the grimoire, preferably external
> to SMGL itself, i.e. people should need to put the keys into a keyring
> themselves or whichever. Should we just put it up on the SMGL server the
> server just becomes the signle point of failure.

The docs regarding source signing actually state explicitly that you
should not be using your personal key, but rather one created explicitly
for source signing. The source signing key could, of course, be signed
by your regular real-world key in order to add some real-world trust to
it (and then it could be signed by others, etc.). However, I don't think
this would solve the problem you pointed out above. It would still just
be moving the single point of failure elsewhere. Even if the keys are
all external to SMGL itself, if a developer's machine gets compromised
and an attacker gets that developer's key, the attacker is free to
modify whatever they want in the grimoire using that developer's key.
The only difference with having the keys outside SMGL is that it
wouldn't be guaranteed that the attacker would simultaneously get access
to all of the keys at once.

What we need to do is have the grimoire itself signed/hashed/whatever
and published. That can of course be compromised too, and if the web
site is hosted on the same server as the grimoire releases then the
published sig/hash/etc. could easily be gotten to if the grimoire itself
were compromised. If we switched to using git for grimoire updates
instead of tarballs, this might be mitigated by the fact that all
developers would have their own clones of the repo to compare against so
any single compromise could be caught pretty easily, but then users
wouldn't have the ease of grabbing single releases as tarballs. Maybe if
we have a release sig/hash file kept in the grimoire repo, in addition
to publishing it on the web...? There are a lot of catch-22/chicken-egg
problems regardless of what route we take, it seems.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpAH3jH2m55F.pgp
Description: PGP signature