I am seeing the same error with sa-update on 3.2.4 using gpg 2.0.8, and the
update fails with code 4.

Maybe I'm missing something here (it does say this is a subtle issue), but ...  sa-update doesn't care 
about signed keys, just that the key which signed the file is in the list of "trusted keys" as given to it.  
so cross-signing doesn't change anything for us.  Also:

"This does not mean that an attacker can issue signatures pretending to be someone else: the attacker 
cannot issue any signatures from that subkey, as all they have is the public half. The only thing this 
allows an attacker to do is to take an existing signature issued by a signing subkey, and claim that it 
was issued by the attacker's own key. The end result is that the signature can be verified by both the 
actual signer's key and the attacker's key."

So if an attacker can't fake the signature, then who cares?

> So if an attacker can't fake the signature, then who cares?

Maybe the threat is something like this, given that "The end result is that the
signature can be verified by both the actual signer's key and the attacker's
key": Alice signs her release of MalAssassin, which is going to be downloaded
and verified by Bob. Eve uses this vulnerability to cause Alice's signatures of
MalAssassin to verify against Eve's key, then convinces Bob that her key is a
new one to be used for MalAssassin downloads. Bob uses Eve's key, has no problem
verifying legitimate downloads of MalAssassin, and thus is fooled into using
Eve's key to verify a malware download of MalAssassin that Eve has signed.

And here is a stronger reason to cross-sign our key: Otherwise newer versions of
GPG will produce the scary warning message quoted in this bug's Description when
sa-update is run.

(In reply to comment #3)
> > So if an attacker can't fake the signature, then who cares?
> 
> Maybe the threat is something like this, given that "The end result is that the
> signature can be verified by both the actual signer's key and the attacker's
> key": Alice signs her release of MalAssassin, which is going to be downloaded
> and verified by Bob. Eve uses this vulnerability to cause Alice's signatures of
> MalAssassin to verify against Eve's key, then convinces Bob that her key is a
> new one to be used for MalAssassin downloads. Bob uses Eve's key, has no problem
> verifying legitimate downloads of MalAssassin, and thus is fooled into using
> Eve's key to verify a malware download of MalAssassin that Eve has signed.

If Eve convinces Bob to trust a different key, then it doesn't matter what we do.

In our situation, Bob still trusts Alice's key for signing, and Eve can't sign malware using the key, so Bob 
can still trust that what he downloads is signed by Alice.  The fact that the key is associated w/ Eve's 
other keys/identifying information instead of Alice's doesn't matter to us.

> And here is a stronger reason to cross-sign our key: Otherwise newer versions of
> GPG will produce the scary warning message quoted in this bug's Description when
> sa-update is run.

Aha.  While the initial comment implies that validation still works, and there's just a warning ...  It 
appears that (which is what comment 1 also says) apparently the newer GPGs won't validate the 
signature at all...  I just tried a 3.1 update w/ my newly installed gpg 1.4.8:

[26406] dbg: gpg: calling gpg
[26406] dbg: gpg: gpg: Signature made Thu 18 Oct 2007 02:54:04 AM EDT using RSA key ID 24F434CE
[26406] dbg: gpg: gpg: WARNING: signing subkey 24F434CE is not cross-certified
[26406] dbg: gpg: gpg: please see http://www.gnupg.org/faq/subkey-cross-certify.html for more 
information
[26406] dbg: gpg: [GNUPG:] ERRSIG 6C55397824F434CE 1 2 00 1192690444 1
[26406] dbg: gpg: gpg: Can't check signature: general error
error: GPG validation failed!
The update downloaded successfully, but the GPG signature verification
failed.
channel: GPG validation failed, channel failed
[26406] dbg: generic: cleaning up temporary directory/files
[26406] dbg: diag: updates complete, exiting with code 4


So yes, I'm +1 to cross-signing, and we need to do this asap since the channels are potentially broken 
right now...  <sigh>

There should be a way to do this w/out upgrading gpg, I'll take a look in a minute.

Hrm.

I scp'ed the files to my own machine, and tried the cross-certify:

gpg: RSA/SHA1 signature from: "24F434CE updates.spamassassin.org Signing Key 
<release@spamassassin.org>"
gpg: secret key parts are not available
gpg: update_keysig_packet failed: general error

Same error w/ an export/import.  Digging around, I found https://bugs.g10code.com/gnupg/issue673 
which seems to say this is a bug but it's "easy to fix" manually.  However, my gpg-fu is apparently not 
strong enough.

Anyone else want to take a stab at it?

Just for my own curiosity, I compiled gpg 1.4.8 on the zone machine and tried the cross-certify w/ the 
same results.

(in reply to comment #4)
> If Eve convinces Bob to trust a different key, then it doesn't matter what we do.

Security people are supposed to be paranoid about unlikely threats because
attackers are good about finding ways to make the unlikely possible.

The idea here is that Eve uses the fact that her key verifies the good signature
on the good copy of MalAssassin to trick Bob into accepting that her key is a
new one for the software releases. She can't do that if the keys are
cross-certified.

(in reply to comment #5)
> Anyone else want to take a stab at it?

I will, but I have to be reminded what is the hostname for the zone machine and
if I have to do anything special to get ssh and sudo access to it.

(In reply to comment #7)
> > Anyone else want to take a stab at it?
> 
> I will, but I have to be reminded what is the hostname for the zone machine and
> if I have to do anything special to get ssh and sudo access to it.

spamassassin.zones.apache.org.  looking at the passwd file, you already have an entry there, and you 
have sudo access as well.  :)

The 1.4.8 gpg is in /tmp (gnupg-1.4.8/g10/gpg, iirc).

And how do I get the key?

(In reply to comment #9)
> And how do I get the key?

The initial comment has the path to the key.  You'll want to be the updatesd user.  I'd do any attempts in a 
different location, just to be safe.

Ok, I think I figured it out.  It appears the key files that we're actively using doesn't have the full set of 
secret keys associated with it.  Specifically, it appears that it's a stub secret key.   I found a backup copy 
of the key files w/ the full set of secret keys under the BACKUP dir and was able to cross-certify. :)

The new public key was imported into the normal key directory, and I uploaded the key to pgp.mit.edu.  
I'll update the included pubkey in 3.1, 3.2, and trunk in a minute.

However ...  We need to document somewhere that if people can't do an update, and they see the error 
in the debug output, they'll need to get the new pubkey imported.  Ala:

sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --import /usr/share/spamassassin/sa-
update-pubkey.txt

or

sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --keyserver pgp.mit.edu --recv-key 5244EC45

Ok, it's committed.  It's seemed like a text/documentation file, so I went CTR on it.  If people disagree, I 
can put up the patch.

Sending        spamassassin-3.1/rules/sa-update-pubkey.txt
Sending        spamassassin-3.2/rules/sa-update-pubkey.txt
Sending        spamassassin-head/rules/sa-update-pubkey.txt
Transmitting file data ...
Committed revision 610699.

(In reply to comment #11)
> Ok, I think I figured it out.  It appears the key files that we're actively
using doesn't have the full set of 
> secret keys associated with it.  Specifically, it appears that it's a stub
secret key.   I found a backup copy 
> of the key files w/ the full set of secret keys under the BACKUP dir and was
able to cross-certify. :)

too much paranoia!  I shouldn't have done that.
can you put the full set of secret keys into the "key" directory in case we
need to do something similar again?

> The new public key was imported into the normal key directory, and I uploaded
the key to pgp.mit.edu.  
> I'll update the included pubkey in 3.1, 3.2, and trunk in a minute.
> 
> However ...  We need to document somewhere that if people can't do an update,
and they see the error 
> in the debug output, they'll need to get the new pubkey imported.  Ala:
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --import
/usr/share/spamassassin/sa-
> update-pubkey.txt
> 
> or
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --keyserver
pgp.mit.edu --recv-key 5244EC45

damn, that's annoying. stupid gpg!  still, we probably have a while
before the distros start packaging 1.4.8.

it's lucky I spotted the message; I wouldn't have seen it otherwise, since it
only appears with sa-update --debug in gpg 1.4.7.

a poster on the users list has just noted a problem that could be this bug.

'Even though I have followed the intructions in the error message twice now, I 
still have the same error when sa-update is run:

# /usr/bin/sa-update --allowplugins --gpgkey 
D1C035168C1EBC08464946DA258CDB3ABDE9DC10 --channel saupdates.openprotect.com
error: GPG validation failed!
The update downloaded successfully, but it was not signed with a trusted GPG
key.  Instead, it was signed with the following keys:

    BDE9DC10

Perhaps you need to import the channel's GPG key?  For example:

    wget http://spamassassin.apache.org/updates/GPG.KEY
    sa-update --import GPG.KEY

channel: GPG validation failed, channel failed

New secret process guys?  But I note the signature key is the last 8 digits of 
the GPG.KEY my cron job was using.'

actually, looks like this needs to be reverted.  A couple of users have reported
failures to validate sa-updates today, and one notes their gpg version as
gpgme-1.1.5-4.fc8....

(In reply to comment #15)
> actually, looks like this needs to be reverted.  A couple of users have reported
> failures to validate sa-updates today, and one notes their gpg version as
> gpgme-1.1.5-4.fc8....

The one I saw on the users@ list was having a problem with the saupdates.openprotect.com channel, not 
ours.  I responded to that thread already.

it's been reported, btw, that the key being served from pgp.mit.edu is the old
one, not the cross-certified one.  I've sent the key there a few times now, I
don't know if an earlier update just got lost, or if the keyserver doesn't see a
difference from the cross certification.  but if I delete the key locally, then
recv-key, I do in fact get the old one.  so that kind of sucks.


I actually would expect the key to include the subkey signature in "--list-sig"
output, but it doesn't...  The difference is:

pub   4096R/5244EC45 2005-12-20
uid                  updates.spamassassin.org Signing Key <release@spamassassin.org>
sig 3        5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>
sub   4096R/24F434CE 2005-12-20
sig          5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>

becomes

pub   4096R/5244EC45 2005-12-20
uid                  updates.spamassassin.org Signing Key <release@spamassassin.org>
sig 3        5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>
sub   4096R/24F434CE 2005-12-20
sig          5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>
sig          5244EC45 2008-01-10  updates.spamassassin.org Signing Key
<release@spamassassin.org>

that's how you can tell which one you have.

Daryl, has your key been cross-signed too?
  http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
  http://daryl.dostech.ca/sa-update/sare/GPG.KEY
I can't find a fresher one, and newer gpg complains with this one.

What's the complaint it's giving?  I don't use a sub key to generate the channel
file signatures.

> What's the complaint it's giving?  I don't use a sub key to generate
> the channel file signatures.

gpg (GnuPG) 1.4.8

[5135] dbg: http: GET request,
 http://daryl.dostech.ca/sa-update/zmi/70_zmi_german.cf/200705271208.tar.gz.asc
[5135] dbg: sha1: verification wanted: 5991893117da2b7bda8566b719823ba93dbc44b6
[5135] dbg: sha1: verification result: 5991893117da2b7bda8566b719823ba93dbc44b6
[5135] dbg: channel: populating temp content file
[5135] dbg: gpg: populating temp signature file
[5135] dbg: gpg: calling gpg
[5135] dbg: gpg: gpg: Signature made Sun May 27 12:24:08 2007 CEST
  using DSA key ID 856AA88A
[5135] dbg: gpg: [GNUPG:] SIG_ID xx47/E6NVGUIqF6ZqotZXrkEX/Y
  2007-05-27 1180261448
[5135] dbg: gpg: [GNUPG:] GOODSIG 3C5C05EB856AA88A Daryl C. W.
  O'Shea <spamassassin@dostech.ca>
[5135] dbg: gpg: gpg: Good signature from "Daryl C. W. O'Shea
  <spamassassin@dostech.ca>"
[5135] dbg: gpg: [GNUPG:] VALIDSIG ABE0C8743B87262E5FB04F2B3C5C05EB856AA88A
  2007-05-27 1180261448 0 3 0 17 2 00 ABE0C8743B87262E5FB04F2B3C5C05EB856AA88A
[5135] dbg: gpg: [GNUPG:] TRUST_UNDEFINED
[5135] dbg: gpg: gpg: WARNING: This key is not certified with a 
  trusted signature!
[5135] dbg: gpg: gpg: There is no indication that the signature belongs
  to the owner.
[5135] dbg: gpg: Primary key fingerprint: ABE0 C874 3B87 262E 5FB0 4F2B
  3C5C 05EB 856A A88A
[5135] dbg: gpg: found signature made by key
  ABE0C8743B87262E5FB04F2B3C5C05EB856AA88A
[5135] dbg: gpg: key id 856AA88A is not release trusted
  error: GPG validation failed!
The update downloaded successfully, but the GPG signature verification
  failed.
channel: GPG validation failed, channel failed

> [5135] dbg: gpg: key id 856AA88A is not release trusted
>   error: GPG validation failed!

Looks like you forgot to add --gpgkey 856AA88A to your command line.

> Looks like you forgot to add --gpgkey 856AA88A to your command line.

Right. Sorry for the noise.

I mistook a success on the other host for a difference in gpg versions,
whereas that host was already up-to-date with SARE rules and didn't
download any files, so didn't complain despite a missing --gpgkey.

> However ...  We need to document somewhere that if people can't do an update,
and they see the error 
> in the debug output, they'll need to get the new pubkey imported.  Ala:
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --import
/usr/share/spamassassin/sa-
> update-pubkey.txt
> 
> or
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --keyserver
pgp.mit.edu --recv-key 5244EC45

we still need to do this bit.

how does http://wiki.apache.org/spamassassin/SaUpdateKeyNotCrossCertified
look?  feel free to hack it about.

instead of the complex

sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys \
   --keyserver pgp.mit.edu --recv-key 5244EC45

I changed it to just use 

    wget http://spamassassin.apache.org/updates/GPG.KEY
    sa-update --import GPG.KEY

which seems a lot simpler, and appears to work in my testing
(at least the --list-sig change is visible).

Just for your information, this is hitting people now with a stable, fully updated Gentoo installation. See http://bugs.gentoo.org/show_bug.cgi?id=218239

we should probably push out a 3.2.5 just to get this into a release.