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

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

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

> > > 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.
-- 
Trevor Johnson
http://jpj.net/~trevor/gpgkey.txt