On Fri, 23 Mar 2001, Trevor Johnson wrote:

# I understand that OpenSSL, whether as source or binary, is much bigger
# than your digest utility. So are other things--sh, make, tar and pax, awk,
# patch, cc, and so on--which are needed for the use of pkgsrc.

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),
because we're now using SHA1 checksums instead of MD5, since those versions
of the OS do not have OpenSSL, digest is a much better choice.

Seeing as those parts of OpenSSL which are speedier are only hand-tuned for
specific architectures, your declaration of speed advantage is moot.

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.
I can't say as much for Solaris, for example (you're relegated to GCC
or you have to buy their unbundled compiler suite for outrageou$ sums of
money).

[and the genius who decided that make belongs in /usr/ccs/bin should be
shot.  But I won't open that one.]

But to make a long diatribe short, I think that a digest utility is fine.
We have a pkgtools collection.  If we're going to be building packages,
we should probably be using a reliably available distribution for building,
don't you think?

# If, for
# example, the user hasn't installed a C compiler (not part of the base
# system on NetBSD, Solaris, or most Linux distributions),

See above.  At least ours is sitting as one of the standard available
tarballs, which is more than I can give Solaris.

# pkgsrc doesn't
# bootstrap one into place.  If the user installs the wrong C compiler--a
# buggy, old, or trojaned one (food for thought:
# http://www.acm.org/classics/sep95/)--he loses.

With comp.tgz, this is not an issue.

[Note:  I don't want to hear the specious portability issues, here, for
what are hopefully obvious reasons.]

# > 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?  We've been doing it this way before the
openssl stuff ever entered the picture.

				--*greywolf;
--
*BSD: the Berkeley redemption.