I added and tested a 300 line ast sum(3) wrapper for the solaris -lmd
hash/digest functions
sum(3) is a discipline/method library used by the ast sum(1), cksum(1)
and *sum(1) command links that are implemented in the ast cmd(3) library
advantages to using the sum(3) api:
(1) to change the sum/hash/digest method for an application only the
sumopen(method_name_string) call need change
(2) implementation struct sizes are not exposed in the api (sumopen()
returns an opaque handle), so the implementation can change and
still preserve binary compatibility
relying on -lmd is not a problem for solaris ksh93 (which uses -lcmd
and -lsum) because it already pulls in -lsecdb (which pulls in -lmd)
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
On Mon, 11 Feb 2008 12:33:54 +0000 Darren J Moffat wrote:
> Joseph Kowalski wrote:
> > #### Part 5: Enhancement of /usr/bin/sum
> > The 5th part of this project specifies an enhancement to
> > /usr/bin/sum and a new ksh93 built-in with the same name based on
> > the AT&T AST "sum" command. The AT&T version of the "sum" utility
> > provides extensions not present in the current Solaris "sum"
> > utility, which are useful for small applications to generate hash
> > sums (for example using the MD5 hash for MIME "Content-MD5:"-headers).
> >
> > Like other built-in commands named in PSARC/2006/550, the "sum"
> > built-in in ksh93 will be bound to the /usr/bin/ pathname. The built-in
> > "sum" in ksh93 will only be invoked if called with no pathname
> > prefix, and if a /bin/sum or /usr/bin/sum executable is found
> > first on the user's path.
> >
> > The stability of the "/usr/bin/sum" command and built-in command-line
> > interface and the system variables documented in sum(1) is "Committed".
> >
> > An addition to the ksh93 test suite will gurantee compatibilty between
> > previous versions of the /usr/bin/sum utillity and the new version.
> For the cryptographic hash functionality does this use libmd(3lib) or
> does it introduce its own copy of the MD5/SHA* algorithm source ?
> Note that a very significant amount of work has been done (and is still
> being done) to make that libmd implementations of hash algorithms as
> fast as possible on as many of the platforms Solaris supports. This
> includes hand coded assembler variants suitable for AMD64 and EM64T and
> optimising loads on UltraSPARC etc.
> Please use libmd(3lib) unless there is a very compelling reason not to
> do so - if there I would like to see that documented here.
