Re: API renaming
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 macros (disabling macros, really), environment
> variables, that sort of thing, while OSSL_ has become the primary
> choice for new APIs ("less klunky", I think the judgement was in that
> past discussion I keep referring to).
>
> And yeah, I hear you from all the way around the planet, there are
> some recent name choice that were made that give pause and are
> arguably a mistake in this regard. EVP_MAC and EVP_KDF could have
> been OSSL_MAC and OSSL_KDF. OPENSSL_CTX could have been OSSL_CTX.
> I have no problem recognising that. But, they are there, even though
> only in master (*). This is question of what we do going forward (a
> yet unmerged PR with a new API is as good a target as any).
>
> Cheers,
> Richard
>
> (*) I'm not sure I see master as something untouchable in this regard,
> as the development is still not frozen (alpha), so I for one could
> easily see a rename fest happening, should we decide for it. That
> must happen before we enter the beta phase, though...
>
> On Fri, 24 Jul 2020 07:55:10 +0200,
> SHANE LONTIS wrote:
>>
>> 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
>>> 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 something that already exists.
>>>
>>> So in terms of "it's just a prefix", OSSL_ would be just as suitable.
>>> It's a bit more blatantly "OpenSSL", though.
>>>
>>> Cheers,
>>> Richard
>>>
>>> On Thu, 23 Jul 2020 23:30:25 +0200,
>>> Tim Hudson wrote:
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 Caswell, wrote:
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 and EVP_KDF to OSSL_MAC and OSSL_KDF
>> respectively?
>
> This is a good question...
>
> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
> APIs, they have a previous history of EVP APIs, through EVP_PKEY. The
> impact of relocating them outside of the EVP "family" may be small,
> but still, history gives me pause.
>
> RAND doesn't carry the same sort of history, which makes it much
> easier for me to think "just do it and get it over with"...
I have the same pause - so I'm thinking just RAND for now.
Matt
>>> --
>>> Richard Levitte levi...@openssl.org
>>> OpenSSL Project
>>> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$
>>>
>>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project
> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!LSCv_eY9cQfTVYkr1BXae4hxPy7nvs5sQQo1POAOF9yQFVSUvHdlaFUwYGSPI67pMw$
>
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), environment
variables, that sort of thing, while OSSL_ has become the primary
choice for new APIs ("less klunky", I think the judgement was in that
past discussion I keep referring to).
And yeah, I hear you from all the way around the planet, there are
some recent name choice that were made that give pause and are
arguably a mistake in this regard. EVP_MAC and EVP_KDF could have
been OSSL_MAC and OSSL_KDF. OPENSSL_CTX could have been OSSL_CTX.
I have no problem recognising that. But, they are there, even though
only in master (*). This is question of what we do going forward (a
yet unmerged PR with a new API is as good a target as any).
Cheers,
Richard
(*) I'm not sure I see master as something untouchable in this regard,
as the development is still not frozen (alpha), so I for one could
easily see a rename fest happening, should we decide for it. That
must happen before we enter the beta phase, though...
On Fri, 24 Jul 2020 07:55:10 +0200,
SHANE LONTIS wrote:
>
> 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
> >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 something that already exists.
> >
> > So in terms of "it's just a prefix", OSSL_ would be just as suitable.
> > It's a bit more blatantly "OpenSSL", though.
> >
> > Cheers,
> > Richard
> >
> > On Thu, 23 Jul 2020 23:30:25 +0200,
> > Tim Hudson wrote:
> >> 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 Caswell, wrote:
> >>
> >>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 and EVP_KDF to OSSL_MAC and OSSL_KDF
> respectively?
> >>>
> >>> This is a good question...
> >>>
> >>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
> >>> APIs, they have a previous history of EVP APIs, through EVP_PKEY. The
> >>> impact of relocating them outside of the EVP "family" may be small,
> >>> but still, history gives me pause.
> >>>
> >>> RAND doesn't carry the same sort of history, which makes it much
> >>> easier for me to think "just do it and get it over with"...
> >>
> >>I have the same pause - so I'm thinking just RAND for now.
> >>
> >>Matt
> >>
> >>
> > --
> > Richard Levitte levi...@openssl.org
> > OpenSSL Project
> > https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$
> >
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Re: API renaming
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 >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 something that already exists. > > So in terms of "it's just a prefix", OSSL_ would be just as suitable. > It's a bit more blatantly "OpenSSL", though. > > Cheers, > Richard > > On Thu, 23 Jul 2020 23:30:25 +0200, > Tim Hudson wrote: >> 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 Caswell, wrote: >> >>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 and EVP_KDF to OSSL_MAC and OSSL_KDF respectively? >>> >>> This is a good question... >>> >>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new >>> APIs, they have a previous history of EVP APIs, through EVP_PKEY. The >>> impact of relocating them outside of the EVP "family" may be small, >>> but still, history gives me pause. >>> >>> RAND doesn't carry the same sort of history, which makes it much >>> easier for me to think "just do it and get it over with"... >> >>I have the same pause - so I'm thinking just RAND for now. >> >>Matt >> >> > -- > Richard Levitte levi...@openssl.org > OpenSSL Project > https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$ >
Re: API renaming
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 that's what sparked the discussion at the time... and that's why we now have a OSSL_STORE) Cheers, Richard On Fri, 24 Jul 2020 07:26:23 +0200, Dr Paul Dale wrote: > 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 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 something that already exists. > > So in terms of "it's just a prefix", OSSL_ would be just as suitable. > It's a bit more blatantly "OpenSSL", though. > > Cheers, > Richard > > On Thu, 23 Jul 2020 23:30:25 +0200, > Tim Hudson wrote: > > 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 Caswell, wrote: > >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 and EVP_KDF to OSSL_MAC and > OSSL_KDF respectively? > > This is a good question... > > Historically speaking, even though EVP_MAC and EVP_KDF are indeed > new > APIs, they have a previous history of EVP APIs, through EVP_PKEY. > The > impact of relocating them outside of the EVP "family" may be > small, > but still, history gives me pause. > > RAND doesn't carry the same sort of history, which makes it much > easier for me to think "just do it and get it over with"... > >I have the same pause - so I'm thinking just RAND for now. > >Matt > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: API renaming
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 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 something that already exists. > > So in terms of "it's just a prefix", OSSL_ would be just as suitable. > It's a bit more blatantly "OpenSSL", though. > > Cheers, > Richard > > On Thu, 23 Jul 2020 23:30:25 +0200, > Tim Hudson wrote: >> 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 Caswell, wrote: >> >>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 and EVP_KDF to OSSL_MAC and OSSL_KDF respectively? >>> >>> This is a good question... >>> >>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new >>> APIs, they have a previous history of EVP APIs, through EVP_PKEY. The >>> impact of relocating them outside of the EVP "family" may be small, >>> but still, history gives me pause. >>> >>> RAND doesn't carry the same sort of history, which makes it much >>> easier for me to think "just do it and get it over with"... >> >>I have the same pause - so I'm thinking just RAND for now. >> >>Matt >> >> > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/
Re: API renaming
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 something that already exists. So in terms of "it's just a prefix", OSSL_ would be just as suitable. It's a bit more blatantly "OpenSSL", though. Cheers, Richard On Thu, 23 Jul 2020 23:30:25 +0200, Tim Hudson wrote: > 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 Caswell, wrote: > > 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 and EVP_KDF to OSSL_MAC and OSSL_KDF > respectively? > > > > This is a good question... > > > > Historically speaking, even though EVP_MAC and EVP_KDF are indeed new > > APIs, they have a previous history of EVP APIs, through EVP_PKEY. The > > impact of relocating them outside of the EVP "family" may be small, > > but still, history gives me pause. > > > > RAND doesn't carry the same sort of history, which makes it much > > easier for me to think "just do it and get it over with"... > > I have the same pause - so I'm thinking just RAND for now. > > Matt > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: API 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 Caswell, wrote: > > > 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 and EVP_KDF to OSSL_MAC and OSSL_KDF > respectively? > > > > This is a good question... > > > > Historically speaking, even though EVP_MAC and EVP_KDF are indeed new > > APIs, they have a previous history of EVP APIs, through EVP_PKEY. The > > impact of relocating them outside of the EVP "family" may be small, > > but still, history gives me pause. > > > > RAND doesn't carry the same sort of history, which makes it much > > easier for me to think "just do it and get it over with"... > > I have the same pause - so I'm thinking just RAND for now. > > Matt > >
Re: API renaming
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 and EVP_KDF to OSSL_MAC and OSSL_KDF respectively? > > This is a good question... > > Historically speaking, even though EVP_MAC and EVP_KDF are indeed new > APIs, they have a previous history of EVP APIs, through EVP_PKEY. The > impact of relocating them outside of the EVP "family" may be small, > but still, history gives me pause. > > RAND doesn't carry the same sort of history, which makes it much > easier for me to think "just do it and get it over with"... I have the same pause - so I'm thinking just RAND for now. Matt
Re: API renaming
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? This is a good question... Historically speaking, even though EVP_MAC and EVP_KDF are indeed new APIs, they have a previous history of EVP APIs, through EVP_PKEY. The impact of relocating them outside of the EVP "family" may be small, but still, history gives me pause. RAND doesn't carry the same sort of history, which makes it much easier for me to think "just do it and get it over with"... Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
API renaming
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 Foundations Phone +61 7 3031 7217 Oracle Australia
Re: My vacation
On Thu, 2020-07-23 at 10:35 +0300, Dmitry Belyavsky wrote: > Hello, > > I go on my vacation from July 24 to August 5. On vacation, my > internet access is very limited. > If you have smth urgent, please let me know via direct email. > Same here. I will be on vacation from July 24th to August 1st. I will read only the personal e-mail address e-mails (tm at t8m.info) occassionally. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
My vacation
Hello, I go on my vacation from July 24 to August 5. On vacation, my internet access is very limited. If you have smth urgent, please let me know via direct email. Many thanks! -- SY, Dmitry Belyavsky
