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: Seth Alan Woolley <seth AT positivism.org>
  • To: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • Cc: SM-Discuss <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: Tue, 30 Aug 2005 12:37:46 -0700

On Tue, Aug 30, 2005 at 02:23:56PM -0400, Sergey A. Lipnevich wrote:
> Quoting Eric Sandall <eric AT sandall.us>:
>
> > We're not asking you to sign your soul away. I cannot see how you are
> > completely missing the point of what we're saying. You are /not/
> > signing tarballs saying that you have audited the code (unless you
> > have, then you can say that), nor that you guarantee this tarball
> > won't break your computer, nor that this tarball has no viruses,
> > trojans, worms, wife beaters, etc. in it, nor that this tarball has no
> > bugs, nor many other things. The only thing the GPG signatures are for
> > is to replace the dependency on specific hashsums (md5sum, sha1sum,
> > etc.) and to allow for trusting the vendor's as much as we currently
> > trust them (I don't recall anyone doing audits of source code of any
> > packages for SMGL and no one complained that signing (yes, it's
> > technically a signature) with the md5sum said that you had done that).
>
> Let me explain it differently because we keep walking around the same
> issue. The
> users don't care no matter how you describe your use of signatures. I
> as a user
> don't care how for example Apache Software Foundation describes their use of
> signatures. When I, as a user, see a signature, I assume that they vouch for
> contents of file, not just this file's integrity.

This is a dangerous assumption.

> That's how I treat
> signatures. Tell me if I'm wrong, but you better have a good reason for it.

In transportation security systems, the above is a dangerous assumption,
because transportation security will lead to signatures on stuff that
isn't vouched for, only known to be tranported from them.

> Maybe I as a user can go and read the authors' key policy, but ususally I'd
> do
> that only when the actual problem comes up that prompts me to do so.
>
> Even more so, Apache for example doesn't have any explanation. I tried
> searching
> the site and I can't find a policy. Please find me a policy on some major
> OSS
> vendor site that says: GPG signatures are used for integrity only and do
> *not*
> mean non-repudiation and authenticity *of the code*. This file for
> example says
> "signatures are used for code signing:"

In 2002, I added signing to my entire mirror, which I had for a year.
On the public key download location I explained that I was not vouching
for the sources, only using it for transportation security. I also
explained the key bits I used, that the process was automated and there
was no passphrase, and that the signatures could be compromized if the
server were compromized. I used a separate key than my regular key.

And you're taking the three terms:

integrity, authentication, non-repudiation

and extending them to code-auditing-security in all cases. code signing
doesn't mean code-audited, it just means it was signed. Apache might
mean yeah, we vouch for it, but a few paragraphs below I explain why
this itself is dangerous.

Those three terms are relevant to transportation security alone, so you
can't assume it goes beyond it:

"*this*, *I* *transported*"
integrity [this]
authentication [I]
non-repudiation [transported] (the relationship between 'this' and 'I')

FIPS-186 is clear on this, and makes no reference to code or idealistic
guarantees that we vouch for the contents, only that we sent (or stored)
the contents.

It says it loud and clear right in section 2 of the specification, under
"GENERAL":

When a message is received, the recipient may desire to verify that
the message has not been altered in transit.

not altered in transit!

Furthermore, the recipient may wish to be certain of the originator's
identity.

Who sent it!

Both of these services can be provided by the DSA. A digital signature
is an electronic analogue of a written signature in that the digital
signature can be used in proving to the recipient or a third party
that the message was, in fact, signed by the originator. Digital
signatures may also be generated for stored data and programs so that
the integrity of the data and programs may be verified at any later
time.

We can verify it later!

It's absolutely silent on everything else!

>
> http://svn.apache.org/repos/asf/lenya/trunk/KEYS
>
> Did I make myself clear on why I don't care about what's written on our
> Web site
> about signatures, and nobody else does? I hope I did. Please understand that
> *this* point is the beef of my argument. I tried to express it as item
> #4 of my
> original email, which was not understood well.
>
> Now, as a maintainer, I am worried about perceived meaning of signatures. I
> do
> not want my users to have a false feeling of security because the tarball is
> signed. Moreover, I am not taking the responsibility of signing things I
> don't
> read, even though you try to tell me that we have a disclaimer. With or
> without
> this disclaimer, I can't do that.
>
> Finally, I'm saying, and we agree on that at least with you Eric, that hash
> values do allow for detection of integrity problems. I argue that they are
> sufficient, and there's no reason to go further. If package authors sign
> their
> packages, we support GPG verification, otherwise all bets are off. But
> please
> understand that this is just a secondary reason of why I can't sign a
> tarball.
> If there were no such thing as hash value, I couldn't sign an alien tarball
> anyway.
>
> Finally, Seth here is telling us that signatures do not mean security.

They don't necessarily mean the security of the object signed, they do
mean transportation security of the object signed from the point of
signature to the point of signature verification.

My point was that while it can be used as a means to guarantee the
security of the code, that is a use that is not normal when you find a
source and source.{asc,sig,sign} on a website.

If it were really meant to ensure security, a well-designed system would
have a way to repudiate the security so that security evaluation can be
reviewed and revoked. I take it you're not interpreting apache's old,
but still validly signed source code as actually secure as described by
the apache team? I consider this a misunderstanding of what the apache
team meant caused by your (imo) incorrect assumption of what signatures
mean. PGP has a method to revoke keys (which is useful in a
transportation security sense), but not individual signatures. If it
could revoke signatures, I might allow you your interpretation.

> Regardless of whether I agree or disagree with this, please understand that
> signatures are perceived as means to provide additional layer of... what?
> correct, *security*!

This is a mistake that if we were to assume throws the entire system of
PGP, SSL, etc, into question. I'd rather we used it correctly and
educated users of a possible, but not seemingly all too common
misconception.

> Why do I think so? Let me put our friend Andrew on the
> spot (I'm sorry Andrew, you made it too easy with your email to make my
> point).
> He recently wrote this:
> https://lists.ibiblio.org/sympa/arc/sm-discuss/2005-August/011907.html
>
> Citing it: "This is part of my new security policy I'm implementing for
> myself.
> This key expires end of the year and I will issue a new one then."
>
> So, people do perceive digital keys as a means of security. Not the
> only means,
> of course, but definitely an important one. In the U.S., you can sign
> your name
> now with the help of digital signature. Not GPG I think. Nevertheless, in
> the
> public eye digital signature is very much alike the real deal. You can't try
> and change this meaning just by posting a disclaimer on the site.

Transportation security is an aspect of security. That doesn't mean a
general reference to security in reference to transportation security
implies code audited security.

He didn't mean, "I'm updating my code auditing security policy."

I'm sure he meant, "I'm updating my security policy regarding
transportation security and the use of my PGP keys."

>
> The question is, are we clear now on what I am objecting to?

I've been clear on what you have been objecting to for a while. You're
"confusing" transportation security with code audited security (and
saying this "confusion" is proper and not a confusion at all) as well as
considering the "confusion" as common enough that we should abandon
signatures for any purpose except one that meets the confused
assumption. (Please s/confuse/associate/ and related for a more tactful
phrasing.)

I disagree with both. The second part, I sympathize with, if the
confusion is really all that common. If you want to convince me of
anything, you should work from that angle, not the first angle.

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733

Attachment: pgpybH6qxTAlo.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page