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: Dave Josephsen <dave AT sourcemage.org>
  • 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 14:09:51 -0500

On Wed, Aug 31, 2005 at 11:43:41AM -0400, Sergey A. Lipnevich wrote:
> Quoting dave AT sourcemage.org:
>
> >> It's a good thing you're reading standards, but let me ask about your
> >> entitlements. Disclosure: I don't have any security-related
> >> certifications. Do
> >> you? If we're just two guys arguing about merits of the standard, then
> >> I'm
> >> afraid we read remain at a disagreement.
> >
> > For what it's worth, I'm a CISSP. You can look up my last name here:
> > https://www.isc2.org/cgi/cert_verification.cgi?displaycategory=1300
>
> It's great we have CISSP among us.

I only mention it because you asked Seth if he had any security certs.
If having a security cert matters to you, I have one, and I can vouch
for Seth's interpretation of the standards in question, again, if that
actually means anything to you.

> > Your fellow developers are telling you the truth dude.
>
> What exactly do you mean? The part that the signature allows to check
> for authenticity of the package and the identity of the originator,
> established with Seth's help, I actually agree with. Hence my
> objection to being such an originator. Disclaiming authenticity and
> identity means that only integrity is left. And we agree I believe
> that integrity is adequately assured by hashes. Eric suggested
> stronger hashes. I agreed.
>
> Moreover, I am suggesting moving to an SCM system that has built-in
> commit signatures. If I'm not mistaken, Montone can do that, and
> Subversion with client certificates (not using PGP, but e-commerce
> style PKI).

I mean what I said in my original mail in this thread. You are factually
incorrect when you try to assign some intrinsic meaning to signatures in
general outside of repudiating your agreement to the stated terms. The
rest is double speak, to what end I have no idea.

> > I can't believe
> > this discussion has gone on as long as it has.
>
> Me neither, but for different reasons I guess.
>
> > The very idea that so
> > many of the primary developers of this project would be asking you to do
> > something grossly irresponsible, or worse, trying to trick you into it
> > with word games is adolescent and ridiculous. Look at the guys who are
>
> It is. To me it's ridiculous too that I have to sign (assure authenticity
> and
> identify myself as originator of ) a package I didn't inspect under pressure
> from fellow developers.
>
> > talking to you, and look at what they are saying, and ask yourself
> > what's more likely, that there's some GPG conspiracy sweeping through
>
> No conspiracy. I believe Jeremy made it clear that the agenda of the sorcery
> team is such that they don't want to support hashes.
>
> > the leadership of SMGL, or that your understanding of signatures might
> > have been a bit off.
>
> I understand signatures correctly. That's why I don't sign things blindly to
> begin with.
>
> > I'm not trying to be mean, but the wording of some of your latest emails
> > has ticked me off a bit.
>
> Could you please respond to my "threat profile analysis" message then? As a
> CISSP, you must be familiar with this process, as it's one of the first
> steps
> to securing the infrastructure: understanding and prioritizing the threats.
> Isn't that right?

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
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
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.

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.

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
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
verification model down to the package level. Jblosser already has a
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
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
Sergey.


> Thanks,
> Sergey.

--dave.

Attachment: pgpULYSuKCFFv.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page