I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with Shane that we should go for a single prefix and not have two alternatives. Existing prefixes for things like feature macros should remain as they are, but if the OSSL_ prefix is our choice for the future, we should start using it consistently for _all_ new APIs in 3.0. And not make it a random choice (pun intended) depending on whether the API went into master early or late. So my favorite choice is a consistent renaming, i.e.
OSSL_MAC, OSSL_KDF, OSSL_RAND, OSSL_CTX, ... OTOH, it would be ok for me if we would make an exception for EVP_MAC and EVP_KDF, because they have a long EVP history, as Matt pointed out. But using the EVP_ prefix for the new RAND interface never made sense to me. What bothers me about OPENSSL_CTX in particular is the fact that it is a mixture of a non-abbreviated and an abbreviated word. IMHO it should be either OSSL_CTX or OPENSSL_CONTEXT, and the former is obviously preferrable for its length. Matthias > -----Original Message----- > From: openssl-project <openssl-project-boun...@openssl.org> On Behalf Of > Richard Levitte > Sent: Friday, July 24, 2020 8:34 AM > To: openssl-project@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), 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... >