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
that...
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
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index