On Fri, 03 Jul 2020 11:25:37 +0200,
Matt Caswell wrote:
> On 19/06/2020 08:15, Tomas Mraz wrote:
> > to something like:
> >
> > int EVP_MacInit(EVP_MAC_CTX *ctx);
> >
> > int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t
> > datalen);
> >
> > int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t
> > outsize);
> >
> > or at least
> >
> > int EVP_MACInit(EVP_MAC_CTX *ctx);
> >
> > int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t
> > datalen);
> >
> > int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t
> > outsize);
> >
> > Should we do that? I hope for the sheer ugliness of the supposedly
> > consistent names that we do not.
>
> This pattern is not universally used (as you mention the EVP_PKEY
> API does something different).
Er, you've choose what you wanted to read, I suppose... For fairly
high level EVP APIs, the CamelCase form is actually quite consistent.
For EVP_PKEY, we have them covering most if not all higher level
usages:
EVP_Sign{Init, Update, Final}
EVP_Verify{Init, Update, Final}
EVP_Open{Init, Update, Final}
EVP_Seal{Init, Update, Final}
> I remain strongly opposed to this renaming as I really don't think it
> helps to do this sort of thing now. It just introduces significant
> confusion without a long term strategy. We are too close to 3.0 beta1 to
> embark on this journey now. I'm also not convinced that strategically
> this is the right pattern to use.
What I hear from this is that 3.0 is the wrong time to introduce a new
(and hopefully better) public API, that we should post-pone that to
something like 4.0. I can get along with that line of thought.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
