<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I think the KDF and MAC got back ported also...<div class=""><div class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br class=""></div></div><div><blockquote type="cite" class=""><div class="">On 24 Jul 2020, at 4:33 pm, Richard Levitte <<a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'm fine with that, really.<br class=""><br class="">I have a preference for OSSL_, but if we look through the source,<br class="">there's reason for either. So far, we've majorly used OPENSSL_ for<br class="">things like feature macros (disabling macros, really), environment<br class="">variables, that sort of thing, while OSSL_ has become the primary<br class="">choice for new APIs ("less klunky", I think the judgement was in that<br class="">past discussion I keep referring to).<br class=""><br class="">And yeah, I hear you from all the way around the planet, there are<br class="">some recent name choice that were made that give pause and are<br class="">arguably a mistake in this regard. EVP_MAC and EVP_KDF could have<br class="">been OSSL_MAC and OSSL_KDF. OPENSSL_CTX could have been OSSL_CTX.<br class="">I have no problem recognising that. But, they are there, even though<br class="">only in master (*). This is question of what we do going forward (a<br class="">yet unmerged PR with a new API is as good a target as any).<br class=""><br class="">Cheers,<br class="">Richard<br class=""><br class="">(*) I'm not sure I see master as something untouchable in this regard,<br class="">as the development is still not frozen (alpha), so I for one could<br class="">easily see a rename fest happening, should we decide for it. That<br class="">must happen before we enter the beta phase, though...<br class=""><br class="">On Fri, 24 Jul 2020 07:55:10 +0200,<br class="">SHANE LONTIS wrote:<br class=""><blockquote type="cite" class=""><br class="">For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’ is not a particularly great rule either.<br class="">We should decide which one to use and stick to it.<br class=""><br class=""><blockquote type="cite" class="">On 24 Jul 2020, at 3:20 pm, Richard Levitte <<a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a>> wrote:<br class=""><br class="">A couple of points:<br class=""><br class="">1. Quite a while ago, we (the team at the time) made a decision to<br class=""> have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'. It seems<br class=""> that we never voted on it, though, but still.<br class=""><br class="">2. The new RAND API hasn't been merged yet, so it's not like we're<br class=""> renaming something that already exists.<br class=""><br class="">So in terms of "it's just a prefix", OSSL_ would be just as suitable.<br class="">It's a bit more blatantly "OpenSSL", though.<br class=""><br class="">Cheers,<br class="">Richard<br class=""><br class="">On Thu, 23 Jul 2020 23:30:25 +0200,<br class="">Tim Hudson wrote:<br class=""><blockquote type="cite" class="">Placing everything under EVP is reasonable in my view. It is just a prefix and it really has no<br class="">meaning these days as it became nothing more than a common prefix to use.<br class=""><br class="">I don't see any significant benefit in renaming at this point - even for RAND.<br class=""><br class="">Tim.<br class=""><br class="">On Fri, 24 Jul 2020, 1:56 am Matt Caswell, <<a href="mailto:matt@openssl.org" class="">matt@openssl.org</a>> wrote:<br class=""><br class=""> On 23/07/2020 16:52, Richard Levitte wrote:<br class=""><blockquote type="cite" class="">On Thu, 23 Jul 2020 12:18:10 +0200,<br class="">Dr Paul Dale wrote:<br class=""><blockquote type="cite" class="">There has been a suggestion to rename EVP_RAND to OSSL_RAND. This seems reasonable. Would<br class=""></blockquote></blockquote> it<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">also make sense to rename the other new APIs similarly.<br class="">More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF respectively?<br class=""></blockquote><br class="">This is a good question...<br class=""><br class="">Historically speaking, even though EVP_MAC and EVP_KDF are indeed new<br class="">APIs, they have a previous history of EVP APIs, through EVP_PKEY. The<br class="">impact of relocating them outside of the EVP "family" may be small,<br class="">but still, history gives me pause.<br class=""><br class="">RAND doesn't carry the same sort of history, which makes it much<br class="">easier for me to think "just do it and get it over with"...<br class=""></blockquote><br class=""> I have the same pause - so I'm thinking just RAND for now.<br class=""><br class=""> Matt<br class=""><br class=""><br class=""></blockquote>-- <br class="">Richard Levitte <a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a><br class="">OpenSSL Project <a href="https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$" class="">https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$</a> <br class=""></blockquote><br class=""></blockquote>-- <br class="">Richard Levitte <a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a><br class="">OpenSSL Project <a href="https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!LSCv_eY9cQfTVYkr1BXae4hxPy7nvs5sQQo1POAOF9yQFVSUvHdlaFUwYGSPI67pMw$" class="">https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!LSCv_eY9cQfTVYkr1BXae4hxPy7nvs5sQQo1POAOF9yQFVSUvHdlaFUwYGSPI67pMw$</a> <br class=""></div></div></blockquote></div><br class=""></div></body></html>