On Tue, Jan 19, 2010 at 03:43, Sidney Markowitz <[email protected]> wrote:
> Daryl C. W. O'Shea wrote, On 19/01/10 3:41 PM:
>> Skimming...
>>
>> On 18/01/2010 9:10 PM, Sidney Markowitz wrote:
>>> There is a new signing key for the 3.3.0 release and which will be used
>>> for sa-update rules starting now.
>>
>> We're still going to use the old key for updates for 3.2, if we do them,
>> right?  Forcing a key change for 3.2 would be bad, IMO.
>
> The more I thought about it as I started to answer you the more
> confusing things I though of... First, are we going to update the 3.2
> channel after 3.3.0 is released? If we aren't, then the key is
> irrelevant for 3.2. If we are, then are we going to ignore bug 5924 with
> regards to 3.2? Keeping the old key means that people who update on the
> 3.2 channel have to keep an old version of gpg installed. Finally, what
> was the reason for generating a new key rather than fixing bug 5924 by
> cross-signing the old one? Wasn't it a security reason? Was it because
> the old key was one of the flawed ones that resulted from that rng bug
> that made lots of people have to make new keys? If it's a security flaw,
> we have to go to the new one.

hey guys -- this is a non-issue.

The rule update signing key did not change, as it was already 4096 bits:

pub  4096R/5244EC45 2005-12-20 updates.spamassassin.org Signing Key
<[email protected]>

So both 3.2.x and 3.3.x updates are signed with that, and have been
signed with that for years.

The _release_ signing key had to change, since it was 1024 bits:

pub  4096R/F7D39814 2009-12-02 SpamAssassin Signing Key (Code Signing Key,
replacement for 1024D/265FA05B) <[email protected]>

that'll be used for releases going forward, but sa-update doesn't need
to change to take that into account.

That key was changed due to a potential security issue _in the future_
with too-short (1024-bit) keys.  Currently it's still safe, but not wise
to continue using for the long term.

I guess 3.2.x users will have to keep an old version of gpg installed :(

-- 
--j.

Reply via email to