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

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

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 Fou

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

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 a

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,

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

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 p

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

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 >

Re: API renaming

2020-07-23 Thread Richard Levitte
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 cho

Re: API renaming

2020-07-23 Thread SHANE LONTIS
I think the KDF and MAC got back ported also... > On 24 Jul 2020, at 4:33 pm, Richard Levitte 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