Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

Thanks for the reply, comments below...

On Thu, Dec 23, 2004 at 08:37:17PM +0100, Mads Laursen wrote:
> On 23/12/04 00.03, Seth Alan Woolley wrote:
> [snip a lot of really good stuff about pgp in SMGL]
> 
> Two small questions:
> 
> 1) Is signing less than a full grimoire (spell or section) supported,
> or is such support intended/planed? Would it make sense? (Signatures
> on single spells could be done manually, by the guru fixing the spell.)
> (Implementation idea: Define spell (section) signature as the
> signature of a tarball with a specific set of options/excludes (no
> need to sign stuff like pgpkeys and sigs, or files that are otherwise
> not interesting) of the spell.)

The unit of spell aggregation which scribe can download is the grimoire, 
which could be as small as a single spell if you wanted.

To distribute your own grimoire, you would provide a spell within the 
grimoire that contains the keyring and installs it to 
/etc/sorcery/local/grimoire-$NAME-$GENID.gpg (see the latest 
sorcery-pubkeys spell).

scribe add $NAME .... would then ask for confirmation the first time, 
but after you cast the spell containing the public key inside it 
upgrades would then be able to be signed.

Or if it is us that is adding a grimoire, we just add it directly to the 
sorcery-pubkeys spell, and it will be seamless: sorcery system-update; 
scribe add new-grimoire.

What you are proposing seems like something that would go into a source 
code manager, which is not the role sorcery plays.  You could of course 
still sign your spell submissions and gurus will be able to check them 
themselves.  Sorcery doesn't need to do this though, as the guru can 
just do the checking before putting it into sorcery.  That's one reason 
why we have gurus, in fact, to take spell submissions and check them for 
completeness before dumping it onto our users.  Sorcery goes as far as 
managing grimoires using the scribe tool.  If you want to hack scribe to 
be even more fine-grained, you can bring it up with afrayedknot, but I 
think it's fine the way it is.

> 
> 2) I read the gnupg-users list, and one of the neat features in 1.4.x
> (which is already in test (good work!)) is support for prefered key
> URL in keys and signatures. Will you make use of this? 

It's not needed.

> Maybe make it
> policy to have keys and signatures pointing at the smgl keyserver/keys
> on sourcemage.org? That way gpg knows to go there for (absolutely
> fresh) updates. 

An update of the spell through our normal update process is how we would 
install new keys.  I thought about doing keyserver-style updates, but 
that means we run an additional service or depend on another service 
running and/or depend on another third party.

The way we would update keys is to edit the sorcery-pubkeys spell to 
insert another generation, wait for people to update (about a month) and 
then start signing the grimoires with the new key, at which point we can 
remove the old key generation from sorcery-pubkeys and revocations can 
be done by adding an explicit rm to the INSTALL file of the spell.  If 
we have to quickly revoke, the old key is no longer good anyways and we 
can just update the spell and put in the rms immediately and have people 
update.  In theory, we could do as you say above and use sub-keys or 
have a master key that we would closely guard that we sign all good keys 
with.  But then it makes it centralized and not decentralized.  I really 
don't want to become a gatekeeper for everybody's custom grimoire.

The Web of Trust concept is not needed inside sorcery since we are a 
central entity providing the keys directly, and having users maintain a 
web of trust just to keep their operating system up-to-date is not user 
friendly, though still possible outside of sorcery -- users could still 
use the Web of Trust to verify that a custom grimoire they are getting 
is good.  Maybe when it becomes commonplace and everybody knows how the 
Web of Trust works and where its weaknesses are we can add a bunch of 
code to sorcery to handle that for everybody, but right now we are 
essentially just using gnupg for the digital signatures, and I'd like to 
keep it as simple as possible.  KISS is an often skipped principle in 
security.

> And sorcery could import keys from
> grimoires/sorcery/whereever to get a baseline (that will keep working
> when disconnected).
> 

We already get this feature, since it installs the keys to 
/etc/sorcery/local/ .

> Just what I thought of while reading your post. And once again:
> Wonderful to get gpg-support in sorcery. Something nice for christmas
> ;-) Thanks.

It's not in yet, just laying the groundwork and getting feedback before 
I put it all in.

> 
> /dossen
> 
> PS: Just one more. Since gpg 1.4.x can be assumed on SMGL (it's in
> there, it's the stable version, and it's new and shiny ;-)), consider
> advising the use of signing subkeys. With support for URLs in
> signatures (and sorcery supposed to import the needed keys anyway), it
> should not cause problems (in this context), and it allows the keys
> used to sign to be changed as needed, without the main key (which is
> linked in the Web of Trust) being revoked. In fact, a signing subkey
> used for automatic signing (which I assume, from reading your posting,
> will be used for at least the grimoires) can be seperated from the
> main key and set to expire really fast (to be replaced by a new one),
> reducing the risk of a compromise.

I don't use separate sub-keys to make the implementation easy for people 
to add grimoires later.  It would be fine if we were centralized, but 
I'm keeping the design decentralized so long as we don't trample upon 
each other's namespaces for grimoire names.  You could make a 
dossen-stable and dossen-test grimoire and we could decide to make you 
an official grimoire provider, or you could woo users without our 
blessing and still be able to use gnupg during updates, at least, in the 
design I proposed.

> 
> PPS: Sorry if this is longwinded, or if I'm repeating things said (or
> thought) before. I'd just like us to get this as good (and secure) as
> possible (without stopping the project dead in its tracks from
> security concerns).

Discussion is generally good, so I don't mind.  I'm not beholden to the 
system I proposed if a better one comes along.  I just want something 
done at this point.

> 
> PPPS: Merry cristmas to all. And thanks for this great distro.
> You guys Rock!
> -- 
> Common sense is the collection of prejudices acquired by age eighteen.
>                 -- Albert Einstein


-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8  3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org

Attachment: pgpy2eOJNkOyt.pgp
Description: PGP signature