This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] sha2: new header <sha2.h>
- From: Florian Weimer <fweimer at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: shawn at churchofgit dot com, libc-alpha at sourceware dot org
- Date: Thu, 02 Apr 2015 10:00:25 +0200
- Subject: Re: [PATCH] sha2: new header <sha2.h>
- Authentication-results: sourceware.org; auth=none
- References: <1427529610-3508728-1-git-send-email-shawn at churchofgit dot com> <551C6FA4 dot 5030603 at redhat dot com> <20150402004334 dot GR6817 at brightrain dot aerifal dot cx>
On 04/02/2015 02:43 AM, Rich Felker wrote:
> I'm opposed to allocation/deallocation functions. They have no benefit
They have the benefit that the library can ensure the required
alignment, instead of the caller having to provide it.
There might be hardware implementations which require additional
alignment, to the degree that it cannot be satisfied with the current
spare space in the buffer.
The non-opaque struct also gives the impression you can copy the struct
to implement HMACs, or that the struct contents is portable across
process invocations, which is something we should not promise.
> Allocation also means you
> can't use it in an async signal context.
As far as I can tell, the functions have not been proposed as
async-signal-safe, so this does not matter.
> I agree. This is not something that should be rushed. If it's going to
> be considered, there should be input from multiple libc implementors
> (on multiple systems, e.g. also BSDs) as to how the API should work.
I would rather look at crypto libraries for inspiration.
--
Florian Weimer / Red Hat Product Security