Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

Technically speaking, you dont have to revoke the key. You resign the
tarball then, publish the grimoire, its the same thing, the old bad
signature isn't in any accesible grimoire, no more than the bad hash
would be. The problem that key revocation solves is to protect un-updated
grimoires already in the field, where either the hash, or the signature
have been compromised. Hashes alone do not solve this problem. If cast can
notice that the key is revoked automatically, then it can fail where a
simple hash would not.

-Andrew

On Wed, Aug 31, 2005 at 12:21:37PM -0400, Sergey A. Lipnevich wrote:
> The beauty of hashes is that they don't need any extra support in addition 
> to
> what's in sorcery now. Sign the grimoire tarball with a GPG signature and 
> it's
> good to go. Nothing needs to be revoked if the malicious hash code was 
> entered.
> Replace bad hash value, post a warning, issue a new grimoire, and rest. No 
> key
> revocation, no key generation, no signing of the new key. No keyservers 
> either.
> 
> To make it easier to maintain, we can agree, as Eric suggested, to support a
> single strong hash algorithm that GPG uses.
> 
> As a direct response to your question, I would go even further and forbid
> maintainers to sign tarballs. If the policy dictates using only authors'
> signatures, there's nothing to be done to protect against this attack. You 
> may
> not like it though :-). And you know what's funny? For the heck of me I 
> don't
> understand why. But let's not discuss it because it's a different subject
> altogether, and I'd prefer to stay on course.
> 
> Sergey.
> 
> Quoting "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>:
> 
> > On Aug 31, Jeremy Blosser (emrys) [jblosser-smgl AT firinn.org] wrote:
> >> This raises the point though that sorcery should be checking a gurus.gpg
> >> revocation list on the first cast of each 24-hour period or something.
> >> Note that doing the same thing with regular hashes would be more 
> >> difficult,
> >> since we'd basically have to implement the idea of a revocation list in
> >> sorcery ourselves, then publish a list of any known bad hashes for 
> >> sorcery
> >> to pull.
> >
> > On further thought we'd need to look more into what the revocation certs
> > GPG generates can be ingested by; we aren't running a keyserver.  So we 
> > may
> > need to implement some support for revocation lists ourselves regardless.
> >
> > This raises the point that this is an attack we currently can't stop via
> > GPG or hashes.  If we want to prevent it, there is work to be done
> > regardless.  This makes the question of what sorcery supports the central
> > point, as it's not a matter of not removing existing support, but adding
> > new support.  And if sorcery chooses not to implement protection for
> > regular hashes against this kind of attack you have identified, should we
> > still include any support for them if we know they are vulnerable?
> >
> 
> 
> 
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss

-- 
__________________________________________________________________________
|Andrew D. Stitt                           | astitt at sourcemage.org    |
|irc: afrayedknot                          | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus    | acedit at armory.com        |
|Sorcery Team Lead                         | ftp://t.armory.com/         |
--------------------------------------------------------------------------