Re: API renaming

2020-07-27 Thread Tomas Mraz
It was backported to Fedora and RHEL openssl packages. But of course that's our problem and is not a blocker for the rename. On the other hand KDFs and MACs being a class of algorithms similarly to ciphers and digests gives some argument why to keep the EVP prefix. ⁣Tomáš​ ⁣Tomáš​ 24. 7.

Re: API renaming

2020-07-24 Thread Richard Levitte
> > > > > >> -Original Message- > >> From: openssl-project On Behalf Of > >> Richard Levitte > >> Sent: Friday, July 24, 2020 8:34 AM > >> To: openssl-project@openssl.org > >> Subject: Re: API renaming > >>

Re: API renaming

2020-07-24 Thread Richard Levitte
We're talking APIs (*), that includes the types. So yes, that's a safe assumption. Cheers, Richard (*) if people stopped using "API" when they mean "function", that would save the world from a pile of confusion. On Thu, 23 Jul 2020 18:45:49 +0200, Short, Todd wrote: > > > They also

Re: API renaming

2020-07-24 Thread Dr Paul Dale
I think the types should change to match any function name changes. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Jul 2020, at 2:45 am, Short, Todd wrote: > > They also correspond directly to EVP_MAC and EVP_KDF

Re: API renaming

2020-07-24 Thread Dr Paul Dale
gt;> Sent: Friday, July 24, 2020 9:43 AM >> To: Dr. Matthias St. Pierre >> Cc: Richard Levitte ; openssl-project@openssl.org >> Subject: Re: API renaming >> >> I was thinking OSSL_LIBCTX? >> >

RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
> They also correspond directly to EVP_MAC and EVP_KDF types. Would the types > change as well? Yes, if we would decide to change the EVP_MAC and EVP_KDF prefix, then this would not only apply to the functions, but to the types as well. Matthias

Re: API renaming

2020-07-24 Thread Short, Todd
They also correspond directly to EVP_MAC and EVP_KDF types. Would the types change as well? -- -Todd Short // tsh...@akamai.com // “One if by land, two if by sea, three if by the Internet." > On Jul 23, 2020, at 11:56 AM, Matt Caswell wrote: > > > > On 23/07/2020 16:52, Richard Levitte

RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
> Cc: Richard Levitte ; openssl-project@openssl.org > Subject: Re: API renaming > > I was thinking OSSL_LIBCTX? >

Re: API renaming

2020-07-24 Thread SHANE LONTIS
As @levitte pointed out - it was not back ported (not sure why I thought it was) > On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre > wrote: > > > I think the KDF and MAC got back ported also... > > In this case it would be no question that we should keep the names EVP_KDF > and

Re: API renaming

2020-07-24 Thread SHANE LONTIS
OPENSSL_CONTEXT, and the former is obviously preferrable for its length. > > Matthias > > >> -Original Message- >> From: openssl-project On Behalf Of >> Richard Levitte >> Sent: Friday, July 24, 2020 8:34 AM >> To: openssl-project@openssl.org >&g

RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
> I think the KDF and MAC got back ported also... In this case it would be no question that we should keep the names EVP_KDF and EVP_MAC.

RE: API renaming

2020-07-24 Thread Dr. Matthias St. Pierre
ect@openssl.org > Subject: Re: API renaming > > I'm fine with that, really. > > I have a preference for OSSL_, but if we look through the source, > there's reason for either. So far, we've majorly used OPENSSL_ for > things like feature macros (disabling macros, really)

Re: API renaming

2020-07-24 Thread SHANE LONTIS
I think the KDF and MAC got back ported also... > On 24 Jul 2020, at 4:33 pm, Richard Levitte wrote: > > I'm fine with that, really. > > I have a preference for OSSL_, but if we look through the source, > there's reason for either. So far, we've majorly used OPENSSL_ for > things like feature

Re: API renaming

2020-07-24 Thread Richard Levitte
I'm fine with that, really. I have a preference for OSSL_, but if we look through the source, there's reason for either. So far, we've majorly used OPENSSL_ for things like feature macros (disabling macros, really), environment variables, that sort of thing, while OSSL_ has become the primary

Re: API renaming

2020-07-23 Thread SHANE LONTIS
For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’ is not a particularly great rule either. We should decide which one to use and stick to it. > On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote: > > A couple of points: > > 1. Quite a while ago, we (the team at the time) made a decision to >

Re: API renaming

2020-07-23 Thread Richard Levitte
Er, I don't feel like I was part of this "we". I was very much part of the discussion that introduced OSSL_ and OPENSSL_ as a common prefix, thought... actually only three years ago. (historical note: I had written the STORE API, using STORE_ as a prefix, but that was judged too common, and

Re: API renaming

2020-07-23 Thread Dr Paul Dale
The exact same points apply to EVP_MAC & EVP_KDF. We have also been telling people “use EVP” for ages. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote: > > A couple of

Re: API renaming

2020-07-23 Thread Richard Levitte
A couple of points: 1. Quite a while ago, we (the team at the time) made a decision to have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'. It seems that we never voted on it, though, but still. 2. The new RAND API hasn't been merged yet, so it's not like we're renaming

Re: API renaming

2020-07-23 Thread Tim Hudson
Placing everything under EVP is reasonable in my view. It is just a prefix and it really has no meaning these days as it became nothing more than a common prefix to use. I don't see any significant benefit in renaming at this point - even for RAND. Tim. On Fri, 24 Jul 2020, 1:56 am Matt

Re: API renaming

2020-07-23 Thread Matt Caswell
On 23/07/2020 16:52, Richard Levitte wrote: > On Thu, 23 Jul 2020 12:18:10 +0200, > Dr Paul Dale wrote: >> There has been a suggestion to rename EVP_RAND to OSSL_RAND. This seems >> reasonable. Would it >> also make sense to rename the other new APIs similarly. >> More specifically, EVP_MAC

Re: API renaming

2020-07-23 Thread Richard Levitte
On Thu, 23 Jul 2020 12:18:10 +0200, Dr Paul Dale wrote: > There has been a suggestion to rename EVP_RAND to OSSL_RAND. This seems > reasonable. Would it > also make sense to rename the other new APIs similarly. > More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF respectively?

API renaming

2020-07-23 Thread Dr Paul Dale
There has been a suggestion to rename EVP_RAND to OSSL_RAND. This seems reasonable. Would it also make sense to rename the other new APIs similarly. More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF respectively? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic