[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150114222259.GM4574@brightrain.aerifal.cx>
Date: Wed, 14 Jan 2015 17:22:59 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: crypto visibility
On Wed, Jan 14, 2015 at 09:51:37AM +0100, Daniel Cegiełka wrote:
> Hi,
> Can we make these functions visible? They are very useful.
>
> src/crypt/crypt_md5.c:
> void md5_init()
> void md5_sum()
> void md5_update()
>
> src/crypt/crypt_sha256.c:
> void sha256_init()
> void sha256_sum()
> void sha256_update()
>
> src/crypt/crypt_sha512.c:
> void sha512_init()
> void sha512_sum()
> void sha512_update()
In short, no, at least not without a lot of other things happening. To
do so would be to recreating one of the big things musl was designed
to get away from: random nonstandard interfaces with no documented
interface contract and behavior determined by whatever the existing
implementation(s) happened to do. Note that making these interfaces
public would also involve making the size and possibly representation
of the state structure a public API/ABI too.
If the code is good and you want to use it, the best way is copy and
paste. That way you avoid depending on any assumptions about an
interface contract because the code is all under your control. If you
think there would be interest in standardizing these functions, you
can pursue that with other implementations. It should involve properly
documenting the behavior including corner cases and reaching an
agreement.
Alternatively copies could just be put in a non-libc library like
libhash or something; this probably makes a lot of sense, as there's
nothing system-specific about how they're implemented.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
