* Bill Sommerfeld <sommerfeld at sun.com> [2007-01-22 15:52]: > 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. The printenv and whoami implementations are compatible, although the GNU variants offer --help and --version.
The users implementations differ, in that the GNU variant's output matches "who -q", but the UCB variant selects a smaller set of valid utmpx entries to display. (I expect this is a bug in our UCB implementation, as users(1B) claims it should match the output of "who -q".) > > > 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. Understood. Will postpone to a separate case. > > > 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. I disagree with the premise that an alternative implementation must have (or make a best effort to achieve) equivalent performance to the default implementation. > This may also complicate cryptographic certification. > > 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). Will follow up with Security Community regards certification. At present, the intent is to leave upstream source unchanged. If that means these commands are dropped, that's an outcome consistent with the conflict in constraining policies. > One additional issue: > > wes-5 It appears that current version of coreutils is 6.7, not 6.4. > Why aren't we integrating the newest available version? I hadn't realized that a new release had been made since my pull in November. Case will be updated for 6.7. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
