cryptodev

Robert Connolly robert at linuxfromscratch.org
Sun Sep 17 14:53:16 PDT 2006


On Sunday 17 September 2006 12:38, Alex Merry wrote:
> On Sunday 17 September 2006 00:00, Robert Connolly wrote:
> > I'm not much of an sh scripter. I think a shell script would be
> > better than patching Coreutils to use libcrypto. OpenSSL also
>
> Why?

openssl already does what md5sum does, and more. Patching Coreutils is higher 
maintenance because I'm pretty sure GNU wouldn't accept the patch, and even 
if they did we'd have two applications which do exactly the same thing. 
Meanwhile, OpenSSL might accept a portable sh script to mimic md5sum/sha1sum, 
in a contrib/ directory. Either way, I think this could be the beginning of 
integrating OpenSSL over the core system... perhaps libcrypto can replace 
libcrypt from libc later on (for shadow-utils). From my perspective this is 
better because it helps concentrate our development efforts... when OpenSSL 
adds a new algorithm, or upgrades an existing one, it would be available to 
all applications which use crypto, and ditto /dev/crypto is used.

>
> > supports a few other digest algorithms. A single script could have
> > md5sum/sha1sum/ripemd160sum symlinks to it, using:
>
> I happen to agree with the FSF that programs should not change their
> behaviour because their name has been changed, but that's just personal
> preference. I think there should be an override option that selects the
> digest independently of the executable name, at least.

It's possible to move /usr/bin/md5sum to /usr/bin/md5sum.coreutils, and have 
a /usr/bin/md5sum.openssl script, and /usr/bin/md5sum symlinked to one, but 
if they both do exactly the same thing with exactly the same output and 
options, I don't see the point.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20060917/7fe21fd4/attachment.sig>


More information about the hlfs-dev mailing list