Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support

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] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support
  • Date: Mon, 29 Aug 2005 12:52:03 -0400

Quoting "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>:

I would agree with you if there were an example of that. Examples of
generating a collision in the hash don't count because they do not
produce a valid source. Or, I should say, do not produce valid source
yet. Chances of this happening are much lower than producing a hash
collision.

It's probably only a matter of time at this point til it happens
publically, and keep in mind that history indicates that whatever the
private sector is doing today was done by the NSA 10 years ago.
Regardless, the sorcery team's position as I understand is that they want
to switch sooner than later so they don't have to be hash experts. Their
talents are better used elsewhere.

Encryption is always a matter of time. But the events we're anticipating here
are a matter of a *very long* time. Longer than I would care.

You're signing the receipt, meaning you agree that you received the
package. There's no analog that I can think of in terms of source code
tarballs. Package has been accepted by the carrier, inspected for
controlled objects, and was wrapped. Package has a return address that
has likely been verified, and a trail of how it got to you. There's no
wrap or return address on tarballs, and nobody inspects them. However,
see above about the analogy of signatures on documents. I think it suits
better.

I wasn't trying to make a 1-to-1 analogy, I was only noting that signatures
are used for different things, even in the real world. A signature for a
package means the person signing received the package. A signature on an
itemized invoice means that the person signing inspected the contents and
verified what was there. People can understand the difference, and this is
not dissimilar to what we're talking about doing with GPG signing, even if
it's not the exact same thing.

Please see my reply to Eric. In this analogy, I'd galdly sign the spell, but not
the tarball.

Even GPG signing an email does not mean that I completely agree with the
contents, or always will. If you pull out this signed mail in 10 years it
will not mean that you can make me say I agree with what it says (I may
have changed my mind), but you can make me say I did write it on this date.

Again please see me reply to Eric. The contents of the email are irrelevant, the
signature doesn't mean that the content is true, it means *you* wrote it and you
vouch for it. As I said, if you wrote that you'd like to rob a bank and signed
it, your malicious intent is evident. If you wrote that all your money should
be transferred into someone else's account and signed it, you'll be left
without a penny whether you agree with it later or not.

In short, I object to *mandatory* GPG signatures, and I refuse to sign source
that's not mine with my name.

Would you be willing to sign using a key that did not have your name, but
had a UID:

Not really because it makes even less sense from the security point of view.
From the "integrity checking" POV, it's probably the same as a hash, but it's a
lot more difficult to manage and control.

For the record, I originally felt as you did. I changed my mind for two
reasons (and one of them alone would have not done it):

1) I understand the sorcery team's position of wanting to offload this, and
I agree with it.

If sorcery team wants to offload some work, that would be fine, but in this case
it would be offloading work *and* responsibility. I can't accept the
responsibility part of it.

2) I believe that we can explicitly tell users what our signatures mean and
don't mean. Stuffing it in the key UID is one form of this.

I don't think so. Try to remember when was the last time you read some package
maintainers' explanation of what their signature means or doesn't mean? I bet
you can't. The reason why is because there's a common meaning of a signature,
and digital signatures were created to extend this meaning to the digital
realm. You can resist it and try to redefine it, but I wouldn't imagine you
succeed in doing so.

What we're trying to do is done by hashes, not signatures, and I have yet to see
a reason to change that. A signature fortifies a hash, but puts more
responsibility on the signee. I don't say we have to abandon the signatures, on
the contrary, but I don't want to sign what's not mine. Why is that so hard to
understand?

Sergey.





Archive powered by MHonArc 2.6.24.

Top of Page