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.
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
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
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?
>>
>
> 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
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
> Cc: Richard Levitte ; openssl-project@openssl.org
> Subject: Re: API renaming
>
> I was thinking OSSL_LIBCTX?
>
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
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
> 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.
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)
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
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
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
>
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
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
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
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
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
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?
20 matches
Mail list logo
