sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support
- 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: Wed, 31 Aug 2005 19:36:24 -0400
On Wed, 2005-08-31 at 17:59 -0500, Jeremy Blosser (emrys) wrote:
> You appeared to state in one of the other threads today that you *would*
> object:
No, it says "as a response to your question." I said multiple times that
I don't mind other people doing that if they like. I always said that I
oppose mandatory policy on signatures, not use of maintainer signatures.
>
> > 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.
No I don't. I was explaining my view, not making a suggestion.
> 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.
Jeremy, I asked that we don't go there, but you try paint me in the
corner. Are you trying to say I have some kind of phobia? Than go ahead
and say it. I'll reply, but that's the last time I'm doing this.
Remember how long it took for GNU to recover after their servers were
breached? Why do you think it was? If they disclaim all warranties, why
would they take it upon themselves to verify each and every file before
putting it back on the server. And not just verify, but go back to the
author(s) of each source and make sure they verify it? Obviously, this
involves trust. They feel that they have to keep your trust in taking
the breaches seriously. If I were put in this position, I would be very
disappointed that something I signed could not be trusted.
I explained once that there are projects that are run so well I would
trust them. Subversion and Apache are the examples. They have excellent
visibility. Excellent contributors. Straight-forward review and
demanding policy. They disclaim all warranties, true, but they in good
faith try to deliver the best product. I trust them. I would sign their
source. But that's not often that I can do that, because I can't become
part of every project whose spell I modify.
> > 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.
Agreed, but I didn't see proof of having more security with signatures
(not the ones vendors supply, but ours). I didn't see reasoning of why
signatures are better. In all four scenarios I presented, they weren't.
> > > 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.
...and because I think you are "simply wrong," we can't resolve it just
between ourselves. I want to hear a definitive decision on this. It
doesn't interest me to hear things about myself, I am awaiting the
decision on the policy. If you intend continue to attack me personally
like that, please talk to /dev/null instead.
> > > 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.
I just did. Even more so. I showed you arguments that you couldn't argue
against: the attacks are possible regardless of use of
hashes/signatures, and using signatures doesn't improve anything.
> > > 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.
Do you know this old joke David is referring to? If any thread continues
long enough, it will end up mentioning the word Hitler. It was
originally said about newsgroup arguments I believe. That's why I
suggested a response that was saying, in essence, let's just keep the
feature in the sorcery and leave the nazis alone.
> > > 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
I did. I particularly liked the phrase that hashes and signatures
provide the same functionality. Thank you for that.
> 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.
See above.
> > > 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.
Seth said both hashes and signatures have nothing to do with security.
That's why I'm saying you're misled: you think we're arguing about
better security. Nope.
> > > 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.
No problem. I'm glad you found it useful.
Sergey.
-
Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support
, (continued)
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Sergey A. Lipnevich, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Seth Alan Woolley, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Sergey A. Lipnevich, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, dave, 08/30/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Sergey A. Lipnevich, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Andrew, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Sergey A. Lipnevich, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Dave Josephsen, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Sergey A. Lipnevich, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Jeremy Blosser (emrys), 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Sergey A. Lipnevich, 08/31/2005
- Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support, Seth Alan Woolley, 08/31/2005
Archive powered by MHonArc 2.6.24.