[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: dealing with hmac(3)
If multiple header files is leading to redundant code, I’d certainly prefer
a single header file. After all redundancy is a bad thing inside a
database, but we can have multiple copies of the database stored at
multiple locations on a distributed network (which I’m quite sure is
already the case, we have multiple servers holding the data, right?) Or at
least, if not on a distributed network at least we must be having a RAID
configuration other than RAID 0. Just my 2 cents. :)
On Thu, 5 Oct 2017 at 10:42 AM, Taylor R Campbell <
> > Date: Thu, 5 Oct 2017 04:34:08 +0000
> > From: David Holland <dholland-tech%netbsd.org@localhost>
> > 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>?
> “bikeshed alert” : “Should we consider putting NetBSDisms in
Main Index |
Thread Index |