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 <levi...@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, <m...@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 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/
