Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Aug 31, Sergey A. Lipnevich [sergey AT optimaltec.com] wrote:
> On Wed, 2005-08-31 at 14:09 -0500, Dave Josephsen wrote:
> > Quite honestly, I don't see the point.   
> > 
> > Argument after Argument in this thread you've put the onus on the rest
> > of this development team to prove you wrong, and point after point
> 
> No, I am trying to keep a feature in the sorcery, not prove anything to
> you. If you would like to sign 3rd party packages, I don't object.

You appeared to state in one of the other threads today that you *would*
object:

> 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.
(In https://lists.ibiblio.org/sympa/arc/sm-discuss/2005-August/012180.html)

I don't 100% understand what you were getting at there, but it appears to
suggest a policy where we didn't allow maintainers (I assume this is
gurus?) to provide signatures.

Further, if you truly believe that someone signing a package is making a
claim they have audited the source, and you believe that other people share
this believe, you *should* be opposed to anyone signing something and
making that claim, because it would put our users and even our distribution
in jeopardy.  In fact, if you believe signatures mean what you say you do,
you should probably be opposed to use included upstream signatures, because
those vendors make it clear in their other documents that they disclaim all
warrantees.  If providing an upstream signature is going to make most users
believe they have guarantees they do not have, we would be irresponsible to
include them.

> I don't want to do it myself. It's not about being wrong, it's about
> choice. I do try top explain my view in more details, simply because I'm
> being forced to do something that I think is wrong, and I do fight back
> to show futility of attempts to somehow provide "better" integrity
> checking with signatures instead of hashes.

This is about security policy and best practices for our users.  Sometimes
being correct and supportable means limiting the options people have.  This
tends to be more true with security features than anything else.

> > they've done so with links to relevant texts, plain english
> > explanations, and follow-up emails where they're explanations could
> > have been misinterpreted. Each time you respond by silently abandoning
> > the point, creating a new point, Fabian-esque redefinitions of
> > terminology, and combinations thereof. I'd like to see what Jeremy asked
> 
> It's the disclaimer on the site that tries to redefine the terminology,
> not me.

I'm tired of repeating this, and now it's even become circular.  You are
simply wrong.

> > you for, a single documented example of GPG signatures being used by an
> > OSS project in the way you describe them being used. The onus is on you
> > now. 
> 
> Is that the only the only things that I missed? I missed more, simply
> because I am arguing with several people about different things, and if
> I don't address every single one of them it's because their relevance is
> lower than of the ones I try to address.

I'm sorry, but I don't think that's why you "missed" those things.  You
have several times gotten into repeating a particular point a few times,
until one of us responded and quite clearly demonstrated problems with your
argument.  You have then jumped to another argument in another part of the
thread.  In fact, yesterday you repeated this "show me one OSS project"
challenge alongside a claim your own questions were being ignored by me and
others.  Then you never responded to our response.

> > You've been confronted with the facts to the extent of Seth reading the
> > standards to you. If you're not going to be convinced that you are in
> > error by the literal text, I don't see what magical resolution my lofty
> > CISSP could bring to this thread. Perhaps someone should compare someone
> > else to a nazi so we can be done with this. 
> 
> It'd be enough to keep a feature in the sorcery.

That response is a complete non sequitur to what preceeds it.

> > What concerns me are the developers reading the thread who are actually
> > confused about the difference between hashsums and signatures, and SMGL
> > missing out on some rather wickedly cool functionality because of all
> 
> I tried to prove that this wickedly cool functionality is simply a toy
> without much practical sense. You are free to play with it; I for one am
> not interested. Let me repeat, because you seem to be confusing my point
> with something in your head: I don't mind, sign away all you want.
> 
> I'm asking that you look at "threat analysis" thread and see that I have
> actually identified most attacks and showed that signatures do not help,
> and sometimes even worsen, the consequences of the attack. The talk is
> not over in this thread, but the net result is that downloading a fresh
> signed grimoire tarball with hash values is enough.

Except that I have responded to that thread and followed through the
details of the attacks you outlined, and demonstrated that your conclusions
are at best incomplete.  At this time you have not responded to those
arguments, so I would hardly say anything about "the net result" yet.  In
particular, in the attack you outlined, "downloading a fresh signed
grimoire tarball" would have the same effect whether hashs or signatures
were used.  *Failing* to download a new grimoire tarball would leave users
vulnerable regardless, and GPG likely provides a better way to deal with
this issue.

> > the doublespeak. We could be one of the very few (only?) distros out
> > there with a fully integrated upstream GPG based web-of-trust style
> 
> I don't object to integrating upstream. Did you notice that? If upstream
> provides signatures, I'm all for including them. Judging by current
> features in devel sorcery, we already are this thing you describe. Which
> is a great accomplishment, no doubt. What I'm tryign to prevent is
> taking this accomplishment to an unnecessary and (IMO) dangerous
> extreme.

See above.  Based on your continued arguments about the meaning of
signatures and the opposite of the guarantee actually provided by upstream,
I do not see how you can support inclusion of upstream signatures.

> > verification model down to the package level. Jblosser already has a
> 
> Marketing speak alert. Buzzword in your sentence is: trust. Let me

Where is the word "trust" except in "web-of-trust", which has very specific
meaning in the science of cryptography?

> explain. Seth himself admitted that there's no added security in this
> functionality, it doesn't add any more "trust," the same as with hashes.
> I said exactly that when we were starting with MD5 signatures: calling
> this a "security" or "trust" feature is misleading. Integrity is most of
> what we can claim. I knew that somebody someday would say something like
> that, and it's funny that a CISSP did that.

Moving to signatures increases the security of our distribution by allowing
us to better maintain our integrity checking in the face of various current
and continuing academic and practical attacks.  All other things being
equal a hash may be as secure as a signature using that same hash
internally, but *all other things are not equal*, and that is the point.

> > huge head start on it, and let me tell you, it's good stuff. If anyone
> > has a problem with not being sure how it works, please grab one of us in
> 
> I know how it works, and I know it well enough. If you or anyone take it
> upon themselves to be an SMGL security architects, then maybe they
> should analyze the problem well before coming up with a solution. I
> already did some work for you.
> 
> > irc and talk about it. If you're still not sure what your sig would mean,
> > or think we're telling you to do things that will hurt your karma with
> > your private key, post a bug with your finished spell, and the requisite
> > verification homework, and I'll sign it for you. That's you included
> 
> That's all I ask: leave me alone and don't make me sign things. If you
> require me to do that, I am not interested in contributing. The bottom
> line is, I'm really interested in seeing the end of this discussion and
> hearing the final decision. Depending on it, I'll make my decisions.
> 
> Sergey.

I am also interested in seeing the end of this conversation, but I still
worry we haven't heard enough from other developers.  And I do think your
threat analysis mail was worth having, as it identified some more attacks
we should consider protecting against no matter which type of system we
use.  I would not be opposed to continuing that thread at all.

Attachment: pgpk_0u49wq_h.pgp
Description: PGP signature