Subject: Re: muhah
To: Trevor Johnson <firstname.lastname@example.org>
From: Alistair Crooks <email@example.com>
Date: 03/27/2001 10:41:03
On Mon, Mar 26, 2001 at 03:33:40PM -0500, Trevor Johnson wrote:
> > > > What you are failing to understand is that if one upgrades to a current
> > > > pkgsrc while choosing not to upgrade userland/kernel beyond 1.4(.x),
> > >
> > > Yes, someone who also chooses not to install cryptosrc, doesn't want to
> > > install the OpenSSL package (pkgsrc/security/openssl), and wants to use
> > > 160-bit hashes in pkgsrc.
> > >
> > > This person fears trojaned distfiles with colliding MD5s, but doesn't mind
> > > the holes in the base system.
> > I think you'll find there are any number of those kind of people, from the ones
> > who buy NetBSD in CD-ROM format, to those of us who consider the NetBSD ftp
> > server to be as insecure as some of the sites from which we download distfiles.
> So, this is someone trusts the NetBSD CD-ROMs but does not trust
> ftp.netbsd.org. The brand-new pkgsrc came from CD-ROM rather than FTP,
> but the user didn't update the base system from the same CD-ROM. OK, I
> suppose there must be such people.
You were casting aspersions about a person "who doesn't mind the holes
in the base system". I was pointing out that md5 checksums are
present, on CD-ROM and ftp.netbsd.org, for people who are worried
about the files getting corrupted in transit.
> > Please also note that MD5 and weak checksums are provided for all the sets:
> > see src/distrib/sets/makesums
> I'm aware of this, but I'm not sure why you mention it.
To reassure people that the sets they get are the ones distributed
either by CD-ROM, since the supplier is liable to be trustworthy (if
not, suing could ensue), or from ftp.netbsd.org.
> > > > # > It's not a huge problem, it's a minor niggle. Yes, we can massage output
> > > > # > with sed, awk or expr. But I don't want to do that.
> > > > #
> > > > # You misunderstand. What I requested is output from "digest sha1 foo" in
> > > > # the format that "openssl dgst -sha1 foo" has, and likewise for "digest
> > > > # rmd160 foo" to have the same format as "openssl dgst -rmd160". That way,
> > > > # if it ever becomes desirable to use OpenSSL for hashing--for instance, in
> > > > # a future world where pre-1999 versions of NetBSD needn't to be fully
> > > > # supported--such massaging will not be necessary. I've appended a trivial
> > > > # patch which does this. For the SHA-1 and RIPEMD-160 hashes, the slightly
> > > > # different output is unnecessary. MD5 hashes have already been calculated,
> > > > # so I don't propose changing them.
> > > >
> > > > But *why* should we be doing this?
> > >
> > > I'll try to rephrase: by having the same format, it makes it possible for
> > > someone to generate hashes with either digest or openssl, whether for
> > > addition to a new "md5" file or comparison to an existing one, without
> > > having to munge the file or the output of openssl. It makes them
> > > compatible rather than gratuitously different.
> > From where I'm sitting, the *BSD md5(1) otuput is the standard. I
> > find it disappointing that openssl decided to be incompatible with
> > this.
> It's worse than that: both are preceded by the md5sum program from PGP
> (1993) and by the sample code in RFC 1321 (1992), both of which have
> slightly different formats, for a total of four different formats.
> Perhaps it would have been better if someone had proposed a standard. IMO
> it would be have been better if you hadn't created new formats for the
> SHA-1 and RIPEMD-160 hashes.
Ah, right, my fault. I'm sorry, I was only trying to be compatible with
what we'd used for the past 4 years. Why did I do it? What came over me?
The shame! The ignominy!
I suppose I'll just have to repeat myself: I did not create new
formats. openssl did.
> > > > We've been doing it this way before the
> > > > openssl stuff ever entered the picture.
> > >
> > > OpenSSL hasn't entered the picture at all, for hashing in pkgsrc, but it
> > > has been out in the world since 1997 or 1998, and has been in NetBSD since
> > > 1999, so for a slightly bigger picture, the situation is the opposite from
> > > what you see. The digest utility is just a few days old.
> > The packages collection, and the FreeBSD ports collection on which it
> > is based, are a bit older than that.
> The 160-bit hashes are new to the packages collection, and do not exist in
> the FreeBSD ports collection.
You are the only one who is making a distinction between 128 bit checksums,
and 160 bit ones. For us, they're all compatible.