tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dealing with hmac(3)

On Thu, Oct 05, 2017 at 05:12:07AM +0000, Taylor R Campbell wrote:
 > > 3. Going forward, create a new crypthash.h, and have it include all
 > > the hash function headers (hmac.h, md5.h, sha1.h, rmd160.h, etc etc)
 > > and document all the latter as deprecated. That is, going forward the
 > > official interface for all of these will be <crypthash.h>. Add new
 > > hash functions (and things related to hash functions, like hmac) only
 > > to this file.
 > > 
 > > 4. Sometime in the suitably distant future, like after -10 is out,
 > > remove all the individual hash function headers.
 > Why remove the individual header files?  Why not just use them as is?
 > What's the benefit of another hodgepodge <crypthash.h>?

Because it's a mess: there's already a lot of them and we're only
going to accumulate more over time. Plus, adding a new <hmac.h> with
only one thing in it isn't really a scalable strategy; collecting them
all up afterwards was supposed to be atonement of sorts for doing

But if nobody else really objects to just adding a new free-floating
hmac.h permanently, I guess I don't feel that strongly about it.

 > <bikeshed alert>
 > Should we consider putting NetBSDisms in <netbsd/....h>?
 > </bikeshed alert>

Fie! Burnt sienna with chartreuse stripes!

David A. Holland

Home | Main Index | Thread Index | Old Index