Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

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