You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2005/12/20 19:52:54 UTC

notes on how I made the updates signing key

[for the record.  let me know if you see anything iffy. based on
http://www.stillhq.com/extracted/gnupg-api/doc/faq.html#q4.13 btw.]

[compile and install gpg 1.4.2 into /local/gnupg-1.4.2]

sudo mkdir /home/updatesd/key
[chown, make writable etc]

/local/gnupg-1.4.2/bin/gpg --homedir /home/updatesd/key --gen-key
[data used:]
updates.spamassassin.org Signing Key
release [AT] spamassassin.org

[results:]
pub   4096R/5244EC45 2005-12-20
      Key fingerprint = 5E54 1DC9 59CB 8BAC 7C78  DFDC 4056 A61A 5244 EC45
uid                  updates.spamassassin.org Signing Key <re...@spamassassin.org>

/local/gnupg-1.4.2/bin/gpg --homedir /home/updatesd/key --edit-key 5244EC45
addkey

/local/gnupg-1.4.2/bin/gpg --homedir /home/updatesd/key --export-secret-subkeys --no-comment 24F434CE  > secring.auto
mkdir ../key.full
cp * ../key.full

/local/gnupg-1.4.2/bin/gpg --homedir /home/updatesd/key --edit 24F434CE
[passphrase]
[enter twice]
[yes I really want to do this]
quit
[y]

[tarred up key.full, gpg -c encrypted with old signing passphrase,
left in /home/updatesd/BACKUP; also copied this new, phraseless
key to BACKUP/key.nonfull.backup, just in case.]

[results:]
: jm 319...; sudo /local/gnupg-1.4.2/bin/gpg --homedir /home/updatesd/key --list-keys --fingerprint
gpg: WARNING: unsafe ownership on homedir `/home/updatesd/key'
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
/home/updatesd/key/pubring.gpg
------------------------------
pub   4096R/5244EC45 2005-12-20
      Key fingerprint = 5E54 1DC9 59CB 8BAC 7C78  DFDC 4056 A61A 5244 EC45
uid                  updates.spamassassin.org Signing Key <re...@spamassassin.org>
sub   4096R/24F434CE 2005-12-20



Re: notes on how I made the updates signing key

Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, Dec 20, 2005 at 03:15:24PM -0800, Justin Mason wrote:
> +1 to the safe route.

Ok, so good idea on making a new key. :)

> OK, I guess this is now a separate issue, though.   It would be nice,
> but I wouldn't want to hold up releases for it; we already do a *lot*
> of due-diligence hoop-jumping at release time anyway!

Yeah.  I think switching to personal signing is still a good idea though.
Perhaps something simple like: when voting on a release, if it's +1, sign the
files.

> > Right now, we flag on /^\[GNUPG:\] GOODSIG \S+(\S{8})/, and just use
> > the 8 byte keyid.  It would be hard to add to the validation code to

err.  "it would *not* be hard to ..."

> > look for "VALIDSIG <fingerprint>" and if there is no such line then use
> > "GOODSIG <16bytes>", or else "GOODSIG <8bytes>".

> Anyway, requiring that the user import the key is a new requirement for
> sa-update.  This may be tricky given that updates are run as root, not as
> a specific userid -- so "sudo gpg --import" may not work since it'd use
> the wrong $HOME.  Also is it really a good idea for us to overload the
> root user's (email) keyring with (code-signing) keys?

Well, a few things:
1) sa-update doesn't need root, it depends how the user has things setup.
2) sa-update causes a lot of new requirements so importing the key isn't a huge deal imo.
3) "sudo -H gpg --import key.asc" solves the $HOME issue
4) various other packages require a key import.

> RPM does this by creating its own keyring btw.  maybe we should do that;
> it's easy enough, we run "gpg --homedir /path/blah".

Hrm.  I think I'd rather use the default, but I could go either way I guess.

> by the way, I'm not sure how useful the already-released versions of
> "sa-update" are going to be, anyway -- I'm coming up with quite a few
> bugfixes as I go along. ;)

Oh, I see how it works ... <G>

Yeah, that's fine.  sa-update has only had a small amount of testing done on
it so far, figuring that we'd pay more attention when we got closer to doing
updates.

FWIW, I want us to keep in mind that sa-update is meant to be a generic
tool, not one specifically designed for just us to use.  So I don't want
to over-code it to our situation/plans/etc.

-- 
Randomly Generated Tagline:
Ask not for whom the Bell tolls, and you will pay only the station-to-station
 rate.
 		-- Howard Kandel

Re: notes on how I made the updates signing key

Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, Dec 20, 2005 at 12:01:44PM -0800, Justin Mason wrote:
> We can still do that, but we'd need to decide how that works.  I think
> that'd mean:
> 
>   - 1. edit the main signing key, remove passphrase, move it to the zone

That was my plan, though now that I think about it, it has an obvious
disadvantage of opening up potential questions about trusting the signatures
for older releases.  Hrm.  Ok, I can go either way on this.  New key is
probably safer, old key is already listed in sa-update.  It's pretty trivial
to add in new keys to sa-update though so we may want to go the safe route
instead.

>   - 2. work out the procedure for release signatures.  Does that require
>     just one committer to sign the distro file?  PMC member?  more than
>     one?  What commands are used?

I'd say that anyone can sign it if they want to, though it'll need at least 1
PMC signature from the person who rolled the release.  Commands are pretty
simple:

gpg -abs Mail-SpamAssassin...tar.gz

generates Mail-SpamAssassin...tar.gz.asc.  Various people can generate a
detattached signature and concat them.  ie:


$ gpg -abs --default-key E580B363 file

You need a passphrase to unlock the secret key for
user: "Theo Van Dinter <fe...@kluge.net>"
1024-bit DSA key, ID E580B363, created 1997-11-09

[...]

$ gpg -o foo.asc -abs --default-key E93C82BB file

You need a passphrase to unlock the secret key for
user: "Theo Van Dinter <fe...@kluge.net>"
1024-bit DSA key, ID E93C82BB, created 2005-12-18

[...]

$ cat foo.asc >> file.asc 
$ gpg --verify file.asc
gpg: Signature made Tue 20 Dec 2005 03:37:13 PM EST using DSA key ID E580B363
gpg: Good signature from "Theo Van Dinter <fe...@kluge.net>"
gpg:                 aka "Theo Van Dinter <tv...@techtarget.com>"
gpg:                 aka "Theo Van Dinter <fe...@spamassassin.org>"
gpg:                 aka "Theo Van Dinter <tv...@bblisa.org>"
gpg:                 aka "Theo Van Dinter <fe...@mkrdns.org>"
gpg:                 aka "Theo Van Dinter <fe...@apache.org>"
gpg: Signature made Tue 20 Dec 2005 03:37:25 PM EST using DSA key ID E93C82BB
gpg: Good signature from "Theo Van Dinter <fe...@kluge.net>"
gpg:                 aka "Theo Van Dinter <fe...@apache.org>"
gpg:                 aka "Theo Van Dinter (Work) <tv...@techtarget.com>"


> by the way, another question: for sa-update, is it safe to just pass/fail
> keys by their keyid alone?  Does that require that the user have imported
> the signing public key into their personal keyring?  If not, should it?

Good questions.  The statistical likelihood of having a keyid collision
is small, but possible.  We could definitely do full fingerprint and
fall back to keyid only if the fingerprint isn't in the gpg output
or something.  The output from gpg that sa-update uses is:

gpg: Signature made Tue 20 Dec 2005 03:40:23 PM EST using DSA key ID E580B363
[GNUPG:] SIG_ID /DIRK45vokLUKqzmod79PsJu3lI 2005-12-20 1135111223
[GNUPG:] GOODSIG 02E39051E580B363 Theo Van Dinter <fe...@kluge.net>
gpg: Good signature from "Theo Van Dinter <fe...@kluge.net>"
gpg:                 aka "Theo Van Dinter <tv...@techtarget.com>"
gpg:                 aka "Theo Van Dinter <fe...@spamassassin.org>"
gpg:                 aka "Theo Van Dinter <tv...@bblisa.org>"
gpg:                 aka "Theo Van Dinter <fe...@mkrdns.org>"
gpg:                 aka "Theo Van Dinter <fe...@apache.org>"
[GNUPG:] VALIDSIG 75B1F6D0836838E7A4C5F6C202E39051E580B363 2005-12-20 1135111223 0 3 0 17 2 00 75B1F6D0836838E7A4C5F6C202E39051E580B363
[GNUPG:] TRUST_ULTIMATE

Right now, we flag on /^\[GNUPG:\] GOODSIG \S+(\S{8})/, and just use
the 8 byte keyid.  It would be hard to add to the validation code to
look for "VALIDSIG <fingerprint>" and if there is no such line then use
"GOODSIG <16bytes>", or else "GOODSIG <8bytes>".

I was going to say the user didn't need to import the key, but yes, they do
apparently.  For instance, if I check a signature for a key I haven't
imported, I get:

gpg: Signature made Sun 21 Aug 2005 04:14:06 PM EDT using DSA key ID 16D8B41C
[GNUPG:] ERRSIG D6C6249716D8B41C 17 2 00 1124655246 9
[GNUPG:] NO_PUBKEY D6C6249716D8B41C
gpg: Can't check signature: public key not found

if I import the key, I get:

gpg: Signature made Sun 21 Aug 2005 04:14:06 PM EDT using DSA key ID 16D8B41C
[GNUPG:] SIG_ID e7NuaT11+52CD5ACvROtMgFjt0Q 2005-08-21 1124655246
[GNUPG:] GOODSIG D6C6249716D8B41C Jani Averbach (SVN) <ja...@jaa.iki.fi>
gpg: Good signature from "Jani Averbach (SVN) <ja...@jaa.iki.fi>"
gpg:                 aka "Jani Averbach (SVN) <ja...@iki.fi>"
[GNUPG:] VALIDSIG 3A1F5A74ADF25B0C62E21F6AD6C6249716D8B41C 2005-08-21 1124655246 0 3 0 17 2 00 3A1F5A74ADF25B0C62E21F6AD6C6249716D8B41C
[GNUPG:] TRUST_UNDEFINED
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3A1F 5A74 ADF2 5B0C 62E2  1F6A D6C6 2497 16D8 B41C

Whether or not the person who imports also wants to add trust is another
question.  I don't think we need to require a trust level.

-- 
Randomly Generated Tagline:
"You know, I rather like this God fellow.  Very theatrical, you know.
 Pestilence here, a plague there.  Omnipotence ... gotta get me some
 of that."       - Stewie Griffin, Family Guy, "Holy Crap"

Re: notes on how I made the updates signing key

Posted by Theo Van Dinter <fe...@apache.org>.
Err.

On Tue, Dec 20, 2005 at 10:52:54AM -0800, Justin Mason wrote:
> [results:]
> pub   4096R/5244EC45 2005-12-20
>       Key fingerprint = 5E54 1DC9 59CB 8BAC 7C78  DFDC 4056 A61A 5244 EC45
> uid                  updates.spamassassin.org Signing Key <re...@spamassassin.org>

We were going to use the current release key for signing updates, which
sa-update already trusts, and switch signing releases to our own personal
keys.  So I'm not sure what this key would be used for...

-- 
Randomly Generated Tagline:
"Perl appeals to the other side of your brain, whether that's associate,
 artistic, passionate, or merely spongy." - Programming Perl