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
>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

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 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

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 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

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 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

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 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

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 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

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?

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

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 Foundations 
Phone +61 7 3031 7217
Oracle Australia



Re: My vacation

2020-07-23 Thread Tomas Mraz
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

2020-07-23 Thread Dmitry Belyavsky
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