[SM-Discuss] gnupg signatures on website available now for sorcery and grimoires. Plus draft text of gpg source validation for grimoires.
Seth Alan Woolley
seth at positivism.org
Thu Dec 23 16:39:45 EST 2004
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
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
> 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
> 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.
> 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
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20041223/3d643ea3/attachment.bin
More information about the SM-Discuss