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.  

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).

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?





Reply via email to