[SM-Discuss] Threat profile analysis for spackages not signed by authors
Sergey A. Lipnevich
sergey at optimaltec.com
Wed Aug 31 12:21:37 EDT 2005
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
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
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.
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?
More information about the SM-Discuss