On Sat, Mar 24, 2001 at 08:05:45AM -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.
Please also note that MD5 and weak checksums are provided for all the sets:
see src/distrib/sets/makesums
 
> > Seeing as those parts of OpenSSL which are speedier are only hand-tuned for
> > specific architectures, your declaration of speed advantage is moot.
> 
> It's true that the assembly code is only available for SPARC (MD5 only)
> and x86.  Supposing someone uses one of those architectures, it should be
> an advantage for that person.  Anyway, I was only responding to Alistair
> Crooks' statement that he wanted something quick and OpenSSL didn't fit
> the bill.  He seems to have withdrawn that objection.

No, I have not withdrawn any such objection, and I do resent your
saying that I have.  Once again, my apologies if you're just being
disingenuous.
 
> > On the other hand, sh, make, tar, pax, awk and patch are part of the base
> > distribution, and one need only install comp.tgz to get the compiler.
> 
> ...so relying on something in the base system, or on a packaged binary,
> can be acceptable.
> 
> > # > 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.
 
> > 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.

Regards,
Alistair