Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Threat profile analysis for spackages not signed by authors

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Threat profile analysis for spackages not signed by authors
  • Date: Wed, 31 Aug 2005 12:21:37 -0400

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?








Archive powered by MHonArc 2.6.24.

Top of Page