Skip to Content.
Sympa Menu

sm-security - Re: [SM-Security] openPGP security by signing

sm-security AT lists.ibiblio.org

Subject: Security bugs are reported here via bugzilla

List archive

Chronological Thread  
  • From: Seth Woolley <seth AT tautology.org>
  • To: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • Cc: sm-security AT lists.ibiblio.org
  • Subject: Re: [SM-Security] openPGP security by signing
  • Date: Thu, 15 May 2003 11:23:26 -0700 (PDT)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 15 May 2003, Sergey A. Lipnevich wrote:

> Seth Woolley wrote:
>
> >
> > 1) 40 sources or just use regular MD5s. (two for each source, one for the
> > original file, second for the detached signature).
> > For the ones with lots of patches, when you add gpg to it, you just
> > renumber them 1, 2, 3 would be 1, 3, 5 with 2, 4, 6 being the respective
> > signature files.
>
> This will get us nowhere. It's not that your idea is faulty, it's that
> entire MD5[x] business. It ould be better to use some variable, say
> VERIFY, with a predefined format which would be, say, MD5:576576...78576
> or something lese for the GPG., like GPG:URL-of-the-signature.
>

That's why I brought it up. I, however, didn't want to mess with too much
code outside of libgrimoire. I'm not wedded to the MD5[x] business, in
fact, I'd love to make the variable line up with the n in SOURCEn, say
VERIFYn, and do as you say, VERIFY=MD5:dddd or VERIFY=GPG:4565 4543 ...
4545:URL-of-the-signature, while still allowing the old MD5[x] for
backwards compat until the whole grimoire changes, and people have had
time to update their sorcery. Who knows, then we could add SHA1 or any
other hash or method.

> >
> > 2) all MD5 sources that choose not to use gpg checking will require no
> > modifications. For those that do provide gpg signatures, you just do what
> > I said in answer 1), and then make sure that the additional args are
> > passed to unpack as $3 and $4.
> >
> >
> > would look like:
> >
> > ==>
> > unpack $SOURCE ${MD5[0]} $SOURCE2 ${MD5[1]} &&
> > unpack $SOURCE3 ${MD5[2]} $SOURCE4 ${MD5[3]}
> > <==
>
> Again, it's not your fault, but doesn't this indexing look like asking
> for trouble more than anything else?
>

Yeah, come to think of it, you're right ;)

> I think we need not rush into this and maybe rethink the MD5 idea better.
>

I agree. Just as long as the information is in the DETAILS file, I'm open
to pretty much everything. Thanks for your comments,

Seth

> Sergey.
>
>

- --
Seth Alan Woolley <seth at tautology.org>, SPAM/UCE is unauthorized
Key id 7BEACC7D = 2978 0BD1 BA48 B671 C1EB 93F7 EDF4 3CDF 7BEA CC7D
Full Key at seth.tautology.org and pgp.mit.edu. info: www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE+w9sh7fQ833vqzH0RAh5tAJsHv1ozvqTUDwM1I8Jz4UkIdyAD7QCfd/Et
YcteJzWEAOWhfyYO+48PsY0=
=0BWm
-----END PGP SIGNATURE-----





Archive powered by MHonArc 2.6.24.

Top of Page