>> >I considered modifying the existing cksum(1) utility, but thought
>> >that it wasn't scalable enough, and I considered using openssl, but
>> >didn't want pkgsrc to be dependent on openssl being installed, and
>> >because the output format isn't the same as md5(1).
>> 
>> i have patches to cksum that i did last week (before i read this) to
>> add md4 (a no brainer, even if it is unused), sha1 (although not the
>> large sha variants), and rmd160.  a few minor changes to cksum.c and
>> md5.c and a few new little files (eg sha1.c into which md5.c is simply
>> included) made it rather easy.  should i throw it away?
>
>Well, what did you do in cksum to do with all the existing md5
>options?  (probably the same as I did, keep them).  How do you select
>sha1 or rmd160?  Did you get rid of the md5 regression tests?  Did you
>make the existing "old" and "new" checksums into their own separate
>modules, and just use a table to call them?  Once I'd finished doing
>that, I started to get worried that I'd preserved the original
>behaviour of SYSV and BSD checksums.

uh...let's see.  kept them.  sha1 and rmd160 are selectable by
getprogname() or by a getopt() to cksum (1 for sha1, and 6 for
rmd160...crude, i know).  regression tests are intact, as is the time
testing.  i used separate modules, albeit based severely on the md5.c
module.  here's what i did:

 * in md5.c, changed all instances of the string MD% in a double
   quoted string (for a printf) to use %s and a variable
 * in md5.c, changed the names of all MDFoo() functions to be MD5Foo()
   functions (so that it looks cleaner)
 * created md4.c, which includes md4.h, md5.h, defines a bunch of
   stuff, and then includes md5.c (kinda ugly, but it works very well)
 * created sha1.c and rmd160.c in the same manner
 * altered cksum.c to deal with md4, sha1, and rmd160 via switches
   instead of md5 as a case unto itself

it all worked very smoothly, and adding rmd160 and sha1 after i'd
initially gotten md4 going was incredibly easy.
 
>> i've also attached a small patch that seems to me to be rather useful
>> in the face of the multiple algorithms that digest supports.  it
>> basically adds a "help" hash that prints the other hash names, and a
>> -h option that does the same thing.
>
>Looks good. I'll add it to the digest package, if that's OK.

that's the idea.  :)

>> i'd also like to note that the use of sha1 (although not sha256,
>> sha384, or sha512) on alpha spews a lot of messages of the form:
>>
>> pid 18514 (digest): unaligned access: va=0x12012275f pc=0x120004eb4 ra=0x12012275f op=stl
>> 
>
>With sha1 from libc, or compiled into the package from the provided source?

with whatever the digest program uses by default.  hmm...it seems to
me that it's using libc, which, by an incredible coincidence, is the
same thing that my cksum program is using.  which also spews the same
errors.  i think i'll have to gdb that.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."