Bill Sommerfeld wrote: > On Mon, 2007-01-22 at 14:49 -0800, Stephen Hahn wrote: >>> wes-1 "printenv", "whoami", and "users" are currently delivered in >>> solaris in /usr/ucb. Are the versions you propose to deliver >>> as part of this project upwards-compatible with the /usr/ucb >>> variants? >> >> Unknown at this time. I am not sure that I agree that tools delivered >> in /usr/bin need to be upwards compatible with a specific >> environment's implementation, if that environment never delivered its >> implementations into the default path. > > Please investigate this. > >>> wes-2 With respect to "shred": the limitations of this tool in the >>> Solaris environment need to be very carefully documented. >>> I'd like to see it withdrawn from this case to get appropriate >>> individual scrutiny. >> Unless further discussion arises, I will amend to withdraw. I assume >> that this request is similar in spirit to the current non-delivery of >> GNU su. > > No. I believe this issue can be resolved through documentation updates. > >>> wes-4 the sha*sum commands (and any other commands delivered by this >>> project which use cryptographic hashes) should use one of the >>> existing hash function implementations in Solaris rather than >>> delivering a new copy. (see libmd(3LIB)). >> Disagree on economic grounds. The cryptographic functions in the >> package are Project Private and, at present, deviation would introduce >> a maintenance cost not borne by other distributions that choose to >> include these utilities. > > I don't believe this analysis is as straightforward as you think. > > We do processor-specific performance tuning of many cryptographic > algorithms; by delivering additional implementations, you either (a) > dilute the value of this performance tuning effort, or (b) require the > additional implementations to be tuned, which will more than eliminate > any savings from delivering a redundant implementation. > > This may also complicate cryptographic certification.
Here I believe Bill means FIPS 140-2 certification not "US Export approval". We are currently going through a FIPS 140-2 export approval for Solaris (and I do mean Solaris not OpenSolaris - contact me offline if you want to know why there is a difference here). If this case introduces a additional implementation of algorithms covered by FIPS (which the SHA2 suite is but MD5 is not) then we need to make it clear to out customers that if they use digest(1) they are using the FIPS approved versions but if they use the /usr/gnu/bin/sha*sum variants they are not. I'd rather not have to make that distinction. The SHA2 suite of algorithms has a common API and libmd (PSARC 2005/426) was introduced with a Committed (nee Stable) taxonomy explicitly so that commands like this could use it rather than having to provide their own. > 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. -- Darren J Moffat
