Stephen Hahn wrote:
> * Darren J Moffat <Darren.Moffat at Sun.COM> [2007-01-23 03:12]:
>>> I've taken a look at the code; the engineering effort required appears
>>> small if we extend libmd to add the *_stream() calls used by the
>>> coreutils md5sum (which is the basis of all the sha*sum utilities).
>> Given that libmd is designed to be compatible with libmd on other
>> systems for exactly this reason if we need to add *_stream() interfaces
>> then I'm more than happy to do so.
>>
>> Given there are multiple issues with these specific commands I would
>> highly recommend that they been dealt with in a case other than this one.
>
> That bring us to two choices for sha*sum:
I have a third: included it! Yes I'm changing my mind but please read
the full rationale below for why (basically I saw sense!).
> A. These commands will be withdrawn from this case. As far as I
> can see, the appropriate steps are:
>
> 1. File RFE against libmd5 for the new *_stream() interfaces.
Nit: That would be libmd not libmd5.
This seems like a perfectly reasonable RFE. One the other hand I do
wonder why stdio is being used to digest files - it isn't exactly the
most performance efficient way of reading files. Update: It later
became clear to be that this is because GNU coreutils md5sum has a text
and binary mode that the OpenSolaris digest(1) command does not.
> 2. Make upstream code corrections to sha*sum.
If libmd has the _stream interfaces I don't see why you would need any
upstream corrections at all, just ensure that they link to libmd.
Now that I've had time to think about this a bit more the real issue
here is actually not about staking out filename space but about what the
appropriate command to digest a file actually is for Solaris [ I'm
explicitly saying Solaris here because the code underreview here isn't
actually OpenSolaris code and each distribution using OpenSolaris code
is free to follow or not follow what this case chooses to do, it would
appear that only Solaris is committed to doing so ].
When the crypto framework was introduced that command was digest(1),
there wasn't anything else in Solaris as we had never shipped md5sum or
equivalent as part of Solaris before.
However we later added OpenSSL and with it came the OpenSSL
implementations of MD5, SHA1, etc etc and the openssl(1) command [ and
thus the subcmd dgst].
$ /usr/bin/digest -v -a md5 /etc/profile
$ /usr/sfw/bin/openssl dgst -md5 /etc/profile
The digest(1) command uses libmd. The OpenSSL suite does not.
We also have bart(1) on Solaris that does something similar, but with
different file formats, to the --check argument of the GNU coreutils
md5sum command.
So there is already precedence for multiple commands that provide a
"digest a file" functionality.
'PSARC/2005/530 digest(1) md5/md5sum compatibility' has not actually
integrated yet and in reality it was filed to provide a GNU coreutils
compatible md5sum.
I think the correct and acceptable to me thing to do is for this case to
*include* the GNU coreutils {md5,sha*}sum commands and for this case to
*explicitly* supersede PSARC/2005/530.
> 1. "Non-FIPS" disclaimer text will be added to required
> manual pages.
>
Having thought about this more in the context of OpenSolaris not just
Solaris this is was not actually an appropriate request. FIPS
certification is (generally) applicable only to a specific set of
binaries that means a specific patch release of a product such as
Solaris. A FIPS certification achieved by Solaris does not
automatically apply to any other OpenSolaris distribution by virtue of
them using the same code.
So withdraw this request it doesn't make sense.
> (shred is already en route to handling similar to B. su is being
> omitted based on an assessment that the cost of steps similar to A
> would be uneconomic.)
The really important issue with su is that unless changed the /usr/gnu
variant would allow switching to users without Audit records being
written since it is the responsibility of the application authenticating
the user to write the records. See
http://opensolaris.org/os/project/audit/ and PSARC/2007/016
http://opensolaris.org/os/community/arc/caselog/2007/016/. The GNU
coreutils version also does not use PAM and would fall foul of this
policy: http://opensolaris.org/os/community/arc/policies/PAM/
Aside: I find it interesting that there is a GNU coreutils su(1) but not
a login(1), and also that it is su(1) not su(1M) (and lives in /usr/bin
not /usr/sbin).
If that is your rationale for saying uneconomic then I agree. I know
that the GNU coreutils su(1) command has options the OpenSolaris su(1M)
command does not, I would welcome the appropriate RFEs for the
OpenSolaris version.
--
Darren J Moffat
