API renaming

[SHANE LONTIS]

I think the KDF and MAC got back ported also...

> On 24 Jul 2020, at 4:33 pm, Richard Levitte <levitte at openssl.org> 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 <levitte at openssl.org> 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, <matt at openssl.org> 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         levitte at openssl.org
>>> OpenSSL Project         https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$ 
>> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!LSCv_eY9cQfTVYkr1BXae4hxPy7nvs5sQQo1POAOF9yQFVSUvHdlaFUwYGSPI67pMw$ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200724/f9f3e1a6/attachment-0001.html>