From matt at openssl.org Fri Jul 3 09:25:37 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Jul 2020 10:25:37 +0100 Subject: Naming conventions In-Reply-To: References: <87tuz8mvhd.wl-levitte@openssl.org> Message-ID: On 19/06/2020 08:15, Tomas Mraz wrote: > to something like: > > int EVP_MacInit(EVP_MAC_CTX *ctx); > > int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); > > int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); > > or at least > > int EVP_MACInit(EVP_MAC_CTX *ctx); > > int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); > > int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); > > Should we do that? I hope for the sheer ugliness of the supposedly > consistent names that we do not. This pattern is not universally used (as you mention the EVP_PKEY API does something different). This is one of the areas of existing quirkiness, so I'd be ok with leaving these names as they are. But the fact that there is some strangeness in this area that we may be willing to accept does not mean we should accept a totally new pattern in other function names, i.e. EVP_MAC_CTX_new -> EVP_MAC_new_ctx EVP_MAC_CTX_free -> EVP_MAC_free_ctx EVP_MAC_CTX_dup -> EVP_MAC_dup_ctx EVP_MAC_CTX_mac -> EVP_MAC_get_ctx_mac EVP_MAC_CTX_get_params -> EVP_MAC_get_ctx_params EVP_MAC_CTX_set_params -> EVP_MAC_set_ctx_params I remain strongly opposed to this renaming as I really don't think it helps to do this sort of thing now. It just introduces significant confusion without a long term strategy. We are too close to 3.0 beta1 to embark on this journey now. I'm also not convinced that strategically this is the right pattern to use. In the interests of getting to some kind of decision on this I think a simple OTC vote is probably in order. I already have a PR to revert this (12186) which has an OTC hold on it. Therefore a simple vote to lift the hold would be sufficient to at least make a decision for now. My proposed vote text is: "We should lift the OTC hold on PR12186 and continue the normal review process" Matt From tjh at openssl.org Fri Jul 3 10:15:44 2020 From: tjh at openssl.org (Tim Hudson) Date: Fri, 3 Jul 2020 20:15:44 +1000 Subject: Vote results for PR#12089 Message-ID: topic: Change some words by accepting PR#12089 4 against, 3 for, no absensions The vote failed, the PR will now be closed. Thanks, Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Jul 6 06:41:54 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 06 Jul 2020 08:41:54 +0200 Subject: Naming conventions In-Reply-To: References: <87tuz8mvhd.wl-levitte@openssl.org> Message-ID: <877dvhi1ql.wl-levitte@openssl.org> On Fri, 03 Jul 2020 11:25:37 +0200, Matt Caswell wrote: > On 19/06/2020 08:15, Tomas Mraz wrote: > > to something like: > > > > int EVP_MacInit(EVP_MAC_CTX *ctx); > > > > int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); > > > > int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); > > > > or at least > > > > int EVP_MACInit(EVP_MAC_CTX *ctx); > > > > int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); > > > > int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); > > > > Should we do that? I hope for the sheer ugliness of the supposedly > > consistent names that we do not. > > This pattern is not universally used (as you mention the EVP_PKEY > API does something different). Er, you've choose what you wanted to read, I suppose... For fairly high level EVP APIs, the CamelCase form is actually quite consistent. For EVP_PKEY, we have them covering most if not all higher level usages: EVP_Sign{Init, Update, Final} EVP_Verify{Init, Update, Final} EVP_Open{Init, Update, Final} EVP_Seal{Init, Update, Final} > I remain strongly opposed to this renaming as I really don't think it > helps to do this sort of thing now. It just introduces significant > confusion without a long term strategy. We are too close to 3.0 beta1 to > embark on this journey now. I'm also not convinced that strategically > this is the right pattern to use. What I hear from this is that 3.0 is the wrong time to introduce a new (and hopefully better) public API, that we should post-pone that to something like 4.0. I can get along with that line of thought. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Jul 6 10:33:55 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 6 Jul 2020 11:33:55 +0100 Subject: Naming conventions In-Reply-To: <877dvhi1ql.wl-levitte@openssl.org> References: <87tuz8mvhd.wl-levitte@openssl.org> <877dvhi1ql.wl-levitte@openssl.org> Message-ID: <25b36bf8-4d52-0f22-b5c9-9b79c97fcbbe@openssl.org> On 06/07/2020 07:41, Richard Levitte wrote: > On Fri, 03 Jul 2020 11:25:37 +0200, > Matt Caswell wrote: >> On 19/06/2020 08:15, Tomas Mraz wrote: >>> to something like: >>> >>> int EVP_MacInit(EVP_MAC_CTX *ctx); >>> >>> int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); >>> >>> int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); >>> >>> or at least >>> >>> int EVP_MACInit(EVP_MAC_CTX *ctx); >>> >>> int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); >>> >>> int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); >>> >>> Should we do that? I hope for the sheer ugliness of the supposedly >>> consistent names that we do not. >> >> This pattern is not universally used (as you mention the EVP_PKEY >> API does something different). > > Er, you've choose what you wanted to read, I suppose... For fairly > high level EVP APIs, the CamelCase form is actually quite consistent. > For EVP_PKEY, we have them covering most if not all higher level > usages: I'm actually ok with using the CamelCase versions as well. But in the interests of choosing my battles I'm for the moment just focusing on getting us back to where we started. > > EVP_Sign{Init, Update, Final} > EVP_Verify{Init, Update, Final} > EVP_Open{Init, Update, Final} > EVP_Seal{Init, Update, Final} > >> I remain strongly opposed to this renaming as I really don't think it >> helps to do this sort of thing now. It just introduces significant >> confusion without a long term strategy. We are too close to 3.0 beta1 to >> embark on this journey now. I'm also not convinced that strategically >> this is the right pattern to use. > > What I hear from this is that 3.0 is the wrong time to introduce a new > (and hopefully better) public API, that we should post-pone that to > something like 4.0. I can get along with that line of thought. Ok. Good. Matt From matt at openssl.org Thu Jul 9 09:13:25 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 9 Jul 2020 10:13:25 +0100 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: <34612f3c-b985-356f-2672-57c99a326b8b@openssl.org> On 02/06/2020 15:29, Matt Caswell wrote: > > There's been no further discussion on this for quite a while, so I will > start an OTC vote based on the vote text proposed by Matthias and report > back the results here. Sorry, I forgot to report back. The final result was: +1: 4 -1: 4 0: 3 So the result was tied. According to our bylaws this means that the vote does not pass. Matt From matt at openssl.org Thu Jul 9 10:49:52 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 9 Jul 2020 11:49:52 +0100 Subject: Monthly Status Report (June) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Continued work on and subsequently merged PR 11834 to check signature algorithms are available before offering or accepting them - Continued work on and subsequently merged PR 11898 to avoid downgrading keys in libssl - Continued work on and subsequently merged PRs 11972 and 12107 to ensure CMAC_CTX is correctly initialised - Performed the alpha 3 release - Continued work on and subsequently merged PR 11914 for fully pluggable TLSv1.3 key exchange - Significant review work on the CMP chunk 12 contribution - Fixed the s_server -dtls option via PR 12179 - Fixed some SSL_dup issues and provided better documentation for it via PR 12180 and 12245 - Fixed an issue to ensure we use the passed libctx when loading EC private keys (PR12159) - Fixed some man page typos (PR 12185) - Created PR to revert the KDF/MAC renaming (PR 12186) - Fixed an issue where the provider ctx was forgotten during a reset function call (PR 12229) - Helped out on PR 12228 to ensure the ASYNC code behaved correctly with respect to OPENSSL_CTX_set0_default() - Performed the alpha 4 release - Fixed some CMP related msan failures (PR 12275) - Created PR to move the TLS CBC code into the providers (PR12288) - Provided a fix for OSSL_PROVIDER_get_capabilities() (PR12292) Matt From Matthias.St.Pierre at ncp-e.com Sat Jul 11 23:16:07 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 11 Jul 2020 23:16:07 +0000 Subject: Cherry-pick proposal In-Reply-To: <34612f3c-b985-356f-2672-57c99a326b8b@openssl.org> References: <34612f3c-b985-356f-2672-57c99a326b8b@openssl.org> Message-ID: <7df53a823ca64437be66bf73837638ff@Ex13.ncp.local> Independently of the outcome of the vote I think we should adopt the habit to wait with the merging of a backport PR until the original PR has been approved and merged. As an indicator and reminder, I added a new label (hold: wait for master), which I applied to #12417. https://github.com/openssl/openssl/labels/hold%3A%20wait%20for%20master Matthias > -----Original Message----- > From: openssl-project On Behalf Of Matt Caswell > Sent: Thursday, July 9, 2020 11:13 AM > To: openssl-project at openssl.org > Subject: Re: Cherry-pick proposal > > > > On 02/06/2020 15:29, Matt Caswell wrote: > > > > There's been no further discussion on this for quite a while, so I will > > start an OTC vote based on the vote text proposed by Matthias and report > > back the results here. > > Sorry, I forgot to report back. The final result was: > > +1: 4 > -1: 4 > 0: 3 > > So the result was tied. According to our bylaws this means that the vote > does not pass. > > Matt From openssl at openssl.org Thu Jul 16 13:48:29 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 16 Jul 2020 13:48:29 +0000 Subject: OpenSSL version 3.0.0-alpha5 published Message-ID: <20200716134829.GA923@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 3.0 alpha 5 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 5 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha5.tar.gz Size: 13919931 SHA1 checksum: 0e2aded2b2bd2104bcee6bfcd10132a8aec87776 SHA256 checksum: 09ad89af04cbf36dbbce1fc7063e18fcc333fcaaf3eccecf22c4a99bac83e139 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha5.tar.gz openssl sha256 openssl-3.0.0-alpha5.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEeVOsH7w9yLOykjk+1enkP3357owFAl8QVLgUHGxldml0dGVA b3BlbnNzbC5vcmcACgkQ1enkP3357owlsxAAsESoir2B2o8zLiBgZpo24k+FGcsb zu6unJnYp0IZH+UkK+EXU4q440vpOcXaxC9zyXUKrdUp7e6iXzsVhqkTHFqkG+sE wiEjCO5VS/gPWo3Alrr1Lyzuc9EFLk5XzU0/p2MEVMwjxwHGuqshmJe5dgkv/NCa /SebPbzbKpCKnfnUhmEiiXzG8Sujit8zVl0bKSXsF0hgfm6bWzeuBUj2wqoUFmFe OlPuZ53cYYaF6Hw0XjSiW20RVJ9wD+jgJoQbos7l8QORzuOGsgxYExG0+M+0ketY W1TttXKZrPyO4qj/mdojrPOZWQQT3v5yInGI0wWLzPvXFBs4bKB088uKZQUyicd1 VJyvJBYR5K64podAoQSSjATo8zDZxts1A8JcfGKeLuIeXhhcOf+h75X0pk4+Sqaz +YQLj7lupg9Hksu8UGIcFZNc4zDvDdeFMxphAUkbnlBt7wB+sGSKMcxciYYGh7Vf 8PBTqFS3QcTe33m8KFJMNSwSNDyFILbqskltRQ4vxIquNQu3b1pgfNpKetGnQZJs hv1Ruc4o8rtkntMXx7xpY/uRnWDkdPtybZJNgUMc/iUe88p6YjXFq7q+PDtVAhYk 0EVNlU2lVjM0DZoi4aWKtqCWExJ/rFzuAeCNEXI8oFMSV3/wwE5WFv/uQC45vDuS yuGJQvyOaBjoJws= =uL/G -----END PGP SIGNATURE----- From beldmit at gmail.com Thu Jul 23 07:35:51 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 23 Jul 2020 10:35:51 +0300 Subject: My vacation Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Thu Jul 23 07:43:50 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 23 Jul 2020 09:43:50 +0200 Subject: My vacation In-Reply-To: References: Message-ID: <699309d37b4daa10949c228fc9b4bb041065e551.camel@redhat.com> 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. I will read only the personal e-mail address e-mails (tm at t8m.info) occassionally. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From paul.dale at oracle.com Thu Jul 23 10:18:10 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 23 Jul 2020 20:18:10 +1000 Subject: API renaming Message-ID: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> 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 Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Jul 23 15:52:04 2020 From: levitte at openssl.org (Richard Levitte) Date: Thu, 23 Jul 2020 17:52:04 +0200 Subject: API renaming In-Reply-To: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> Message-ID: <87365igrff.wl-levitte@openssl.org> 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"... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu Jul 23 15:56:26 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Jul 2020 16:56:26 +0100 Subject: API renaming In-Reply-To: <87365igrff.wl-levitte@openssl.org> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> Message-ID: <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> 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 From tjh at cryptsoft.com Thu Jul 23 21:30:25 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 24 Jul 2020 07:30:25 +1000 Subject: API renaming In-Reply-To: <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> Message-ID: 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, 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Jul 24 05:20:32 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 Jul 2020 07:20:32 +0200 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> Message-ID: <87zh7pfpzz.wl-levitte@openssl.org> 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, 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 http://www.openssl.org/~levitte/ From paul.dale at oracle.com Fri Jul 24 05:26:23 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 24 Jul 2020 15:26:23 +1000 Subject: API renaming In-Reply-To: <87zh7pfpzz.wl-levitte@openssl.org> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> Message-ID: <113B5F23-A882-4A11-BEAD-56DF5B6B311E@oracle.com> 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 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, 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 http://www.openssl.org/~levitte/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Jul 24 05:52:29 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 Jul 2020 07:52:29 +0200 Subject: API renaming In-Reply-To: <113B5F23-A882-4A11-BEAD-56DF5B6B311E@oracle.com> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <113B5F23-A882-4A11-BEAD-56DF5B6B311E@oracle.com> Message-ID: <87wo2tfoiq.wl-levitte@openssl.org> 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's what sparked the discussion at the time... and that's why we now have a OSSL_STORE) Cheers, Richard On Fri, 24 Jul 2020 07:26:23 +0200, Dr Paul Dale wrote: > 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 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, 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 http://www.openssl.org/~levitte/ > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From shane.lontis at oracle.com Fri Jul 24 05:55:10 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Fri, 24 Jul 2020 15:55:10 +1000 Subject: API renaming In-Reply-To: <87zh7pfpzz.wl-levitte@openssl.org> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> Message-ID: 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 > 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, 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$ From levitte at openssl.org Fri Jul 24 06:33:45 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 Jul 2020 08:33:45 +0200 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> Message-ID: <87tuxxfmly.wl-levitte@openssl.org> 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 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, 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 http://www.openssl.org/~levitte/ From shane.lontis at oracle.com Fri Jul 24 06:37:02 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Fri, 24 Jul 2020 16:37:02 +1000 Subject: API renaming In-Reply-To: <87tuxxfmly.wl-levitte@openssl.org> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> Message-ID: <499AD091-9D31-4B58-9904-4F84F4BF8945@oracle.com> 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 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 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, 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: From Matthias.St.Pierre at ncp-e.com Fri Jul 24 07:38:07 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 24 Jul 2020 07:38:07 +0000 Subject: API renaming In-Reply-To: <87tuxxfmly.wl-levitte@openssl.org> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> Message-ID: 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 On Behalf Of Richard Levitte > Sent: Friday, July 24, 2020 8:34 AM > To: openssl-project at 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... > From Matthias.St.Pierre at ncp-e.com Fri Jul 24 07:40:54 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 24 Jul 2020 07:40:54 +0000 Subject: API renaming In-Reply-To: <499AD091-9D31-4B58-9904-4F84F4BF8945@oracle.com> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> <499AD091-9D31-4B58-9904-4F84F4BF8945@oracle.com> Message-ID: <9f29be8e2f70426bb5d85ebaea180cfd@Ex13.ncp.local> > I think the KDF and MAC got back ported also... In this case it would be no question that we should keep the names EVP_KDF and EVP_MAC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Fri Jul 24 07:42:59 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Fri, 24 Jul 2020 17:42:59 +1000 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> Message-ID: I was thinking OSSL_LIBCTX? > On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre wrote: > > 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 On Behalf Of Richard Levitte >> Sent: Friday, July 24, 2020 8:34 AM >> To: openssl-project at 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... >> From shane.lontis at oracle.com Fri Jul 24 07:44:05 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Fri, 24 Jul 2020 17:44:05 +1000 Subject: API renaming In-Reply-To: <9f29be8e2f70426bb5d85ebaea180cfd@Ex13.ncp.local> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> <499AD091-9D31-4B58-9904-4F84F4BF8945@oracle.com> <9f29be8e2f70426bb5d85ebaea180cfd@Ex13.ncp.local> Message-ID: <137F717F-BF4E-4040-9609-98A7E28F0FA3@oracle.com> As @levitte pointed out - it was not back ported (not sure why I thought it was) > On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre wrote: > > > I think the KDF and MAC got back ported also... > > In this case it would be no question that we should keep the names EVP_KDF and EVP_MAC. > > > Dr. Matthias St. Pierre > > Senior Software Engineer > matthias.st.pierre at ncp-e.com > Phone: +49 911 9968-0 > www.ncp-e.com > > Follow us on: Facebook | Twitter | Xing | YouTube | LinkedIn > > Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? Nuremberg > North American HQ: NCP engineering Inc. ? 601 Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 > > Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich > Registry Court: Lower District Court of Nuremberg > Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619 > > This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Jul 24 08:15:42 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 24 Jul 2020 08:15:42 +0000 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> Message-ID: <5ea5b4a123cc4ec0916028d12423e06d@Ex13.ncp.local> > I was thinking OSSL_LIBCTX? That's a good choice and consistent with how we name the variable in most (but not all) places: OPENSSL_CTX *libctx; I volunteer to raise a pull request which does a scripted bulk rename, as soon as we have made a decision. Ideally, the bulk renaming should go in shortly before the next alpha. Having it automated by a script would ease rebasing of other still unmerged pull requests over the change. Matthias > -----Original Message----- > From: SHANE LONTIS > Sent: Friday, July 24, 2020 9:43 AM > To: Dr. Matthias St. Pierre > Cc: Richard Levitte ; openssl-project at openssl.org > Subject: Re: API renaming > > I was thinking OSSL_LIBCTX? > From tshort at akamai.com Thu Jul 23 16:45:49 2020 From: tshort at akamai.com (Short, Todd) Date: Thu, 23 Jul 2020 16:45:49 +0000 Subject: API renaming In-Reply-To: <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> Message-ID: They also correspond directly to EVP_MAC and EVP_KDF types. Would the types change as well? -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." > On Jul 23, 2020, at 11:56 AM, Matt Caswell 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Matthias.St.Pierre at ncp-e.com Fri Jul 24 08:20:38 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 24 Jul 2020 08:20:38 +0000 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> Message-ID: > They also correspond directly to EVP_MAC and EVP_KDF types. Would the types change as well? Yes, if we would decide to change the EVP_MAC and EVP_KDF prefix, then this would not only apply to the functions, but to the types as well. Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri Jul 24 08:41:15 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 24 Jul 2020 18:41:15 +1000 Subject: API renaming In-Reply-To: <5ea5b4a123cc4ec0916028d12423e06d@Ex13.ncp.local> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> <5ea5b4a123cc4ec0916028d12423e06d@Ex13.ncp.local> Message-ID: <446EC290-6662-4B5C-A44D-266D28AD4214@oracle.com> Adherence to the code style will also be required (indentation will change). This will be harder to automate. Changing EVP_RAND -> OSSL_RAND is worse because it will change line breaks as well as indentation. OSSL_RNG avoids this, if we accept not using RAND in the name. KDF and MAC also get longer and would have the same issue. Then there are the inevitable merge conflicts?. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Jul 2020, at 6:15 pm, Dr. Matthias St. Pierre wrote: > >> I was thinking OSSL_LIBCTX? > > That's a good choice and consistent with how we name the variable in most (but not all) places: > > OPENSSL_CTX *libctx; > > I volunteer to raise a pull request which does a scripted bulk rename, as soon as we have made > a decision. Ideally, the bulk renaming should go in shortly before the next alpha. Having it > automated by a script would ease rebasing of other still unmerged pull requests over the change. > > Matthias > >> -----Original Message----- >> From: SHANE LONTIS >> Sent: Friday, July 24, 2020 9:43 AM >> To: Dr. Matthias St. Pierre >> Cc: Richard Levitte ; openssl-project at openssl.org >> Subject: Re: API renaming >> >> I was thinking OSSL_LIBCTX? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri Jul 24 08:42:00 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 24 Jul 2020 18:42:00 +1000 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> Message-ID: <414CF0CF-CEBE-4EED-8E40-7A14AECAD425@oracle.com> I think the types should change to match any function name changes. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Jul 2020, at 2:45 am, Short, Todd wrote: > > They also correspond directly to EVP_MAC and EVP_KDF types. Would the types change as well? > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by the Internet." > >> On Jul 23, 2020, at 11:56 AM, Matt Caswell > 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Jul 24 14:55:40 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 Jul 2020 16:55:40 +0200 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> Message-ID: <87mu3pezdf.wl-levitte@openssl.org> We're talking APIs (*), that includes the types. So yes, that's a safe assumption. Cheers, Richard (*) if people stopped using "API" when they mean "function", that would save the world from a pile of confusion. On Thu, 23 Jul 2020 18:45:49 +0200, Short, Todd wrote: > > > They also correspond directly to EVP_MAC and EVP_KDF types. Would the types change as well? > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by the Internet." > > On Jul 23, 2020, at 11:56 AM, Matt Caswell 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 > > > No public key for CFC553A2BA1A0ED1 created at 2020-07-23T18:45:49+0200 using RSA -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Jul 24 19:41:51 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 Jul 2020 21:41:51 +0200 Subject: API renaming In-Reply-To: References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> Message-ID: <87lfj8g0ow.wl-levitte@openssl.org> Why? Just because some of us used such variable names when there was a need to distinguish it from other contexts that are sometimes juggled with at the time time? (and yeah, I've made that a habit... but why that would determine the type name, I cannot understand) Cheers, Richard On Fri, 24 Jul 2020 09:42:59 +0200, SHANE LONTIS wrote: > > I was thinking OSSL_LIBCTX? > > > On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre wrote: > > > > 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 On Behalf Of Richard Levitte > >> Sent: Friday, July 24, 2020 8:34 AM > >> To: openssl-project at 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... > >> > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Mon Jul 27 01:08:04 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 27 Jul 2020 11:08:04 +1000 Subject: RAND_DRBG Message-ID: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly with the move to provider based infrastructure. They are definitely being deprecated in master but without more, the extra layer of indirection and additional complexity generating random numbers will remain. The option I see are: 1. Remove, rather than deprecate, RAND_DRBG in 3.0. This is a breaking change. 2. Bypass RAND_DRBG and live with a breaking change (refer: https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828) 3. Leave things as they currently are in master. The first two are breaking changes and will require an OMC vote. Some pertinent points: 1. RAND_bytes will continue to work as is ? this API is perfect for almost everyone. 2. The RAND_METHOD functionality remains ? this allows wholesale replacement of OpenSSL?s RNGs if desired. 3. The name EVP_RAND is the working name and might change ? this is not relevant to this discussion. 4. The RAND_DRBG APIs are unlikely to be widely used ? they were introduced in 1.1.1. The two users I know of (Akamai and NCP) are both fine with them being removed. Thoughts anyone? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Mon Jul 27 01:14:27 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Mon, 27 Jul 2020 11:14:27 +1000 Subject: RAND_DRBG In-Reply-To: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> References: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> Message-ID: <8BE6D766-1AEC-4FE3-A9A5-BEDFCA23B388@oracle.com> If this is not going to break 99% of users + it improves the interface + the replacement to achieve the same is a few lines of code and is likely to occur in one place in an app, then it seems reasonable to change it to me. > On 27 Jul 2020, at 11:08 am, Dr Paul Dale wrote: > > The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly with the move to provider based infrastructure. > They are definitely being deprecated in master but without more, the extra layer of indirection and additional complexity generating random numbers will remain. > > The option I see are: > > 1. Remove, rather than deprecate, RAND_DRBG in 3.0. This is a breaking change. > 2. Bypass RAND_DRBG and live with a breaking change (refer: https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 ) > 3. Leave things as they currently are in master. > > The first two are breaking changes and will require an OMC vote. > > > Some pertinent points: > > 1. RAND_bytes will continue to work as is ? this API is perfect for almost everyone. > 2. The RAND_METHOD functionality remains ? this allows wholesale replacement of OpenSSL?s RNGs if desired. > 3. The name EVP_RAND is the working name and might change ? this is not relevant to this discussion. > 4. The RAND_DRBG APIs are unlikely to be widely used ? they were introduced in 1.1.1. The two users I know of (Akamai and NCP) are both fine with them being removed. > > > Thoughts anyone? > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Mon Jul 27 02:57:33 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Mon, 27 Jul 2020 12:57:33 +1000 Subject: RAND_DRBG In-Reply-To: <8BE6D766-1AEC-4FE3-A9A5-BEDFCA23B388@oracle.com> References: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> <8BE6D766-1AEC-4FE3-A9A5-BEDFCA23B388@oracle.com> Message-ID: <6A490206-3F9E-4735-ACA5-2B6308F7E349@oracle.com> i.e. Choose option (1) > On 27 Jul 2020, at 11:14 am, SHANE LONTIS wrote: > > If this is not going to break 99% of users + it improves the interface + the replacement to achieve the same is a few lines of code and is likely to occur in one place in an app, then it seems reasonable to change it to me. > > >> On 27 Jul 2020, at 11:08 am, Dr Paul Dale > wrote: >> >> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly with the move to provider based infrastructure. >> They are definitely being deprecated in master but without more, the extra layer of indirection and additional complexity generating random numbers will remain. >> >> The option I see are: >> >> 1. Remove, rather than deprecate, RAND_DRBG in 3.0. This is a breaking change. >> 2. Bypass RAND_DRBG and live with a breaking change (refer: https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 ) >> 3. Leave things as they currently are in master. >> >> The first two are breaking changes and will require an OMC vote. >> >> >> Some pertinent points: >> >> 1. RAND_bytes will continue to work as is ? this API is perfect for almost everyone. >> 2. The RAND_METHOD functionality remains ? this allows wholesale replacement of OpenSSL?s RNGs if desired. >> 3. The name EVP_RAND is the working name and might change ? this is not relevant to this discussion. >> 4. The RAND_DRBG APIs are unlikely to be widely used ? they were introduced in 1.1.1. The two users I know of (Akamai and NCP) are both fine with them being removed. >> >> >> Thoughts anyone? >> >> >> Pauli >> -- >> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations >> Phone +61 7 3031 7217 >> Oracle Australia >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Jul 27 07:48:20 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 27 Jul 2020 07:48:20 +0000 Subject: RAND_DRBG In-Reply-To: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> References: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> Message-ID: <282ccd9d25f247b2a620c08eb0a59757@ncp-e.com> > The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly with the move to provider based infrastructure. Actually, it is not the RAND_DRBG API itself (as it is in 1.1.1) which is messy. It?s the fact that part of its interface is very low level and that the EVP_RAND interface tries to move away from that. In particular, in the future seed sources will be pluggable by chaining the primary DRBG to an entropy source which is provided as a fetchable EVP_RAND interface, not by replacing some internal callbacks. (Note however, that fetchable entropy sources, in particular sources of low quality, are not implemented yet and won?t be implemented in time for version 3.0. But as far as I?m concerned, I can wait for 3.1, since my company is still transitioning from 1.0.2 to 1.1.1. ) Moving to the new approach while at the same time having to retain compatibility to the old approach, that?s what is creating the mess under the hood. Most notably, it?s the two functions RAND_DRBG_set_callbacks() and RAND_DRBG_set() which are creating the problems. Pull Request #12509 attempts to untangle the two RNG interfaces by providing two unrelated triples of RNGs (option 2 in Pauli?s proposal), an EVP_RAND triple and a RAND_DRBG triple. This does not work out well, as pointed out by me in [1]. There might be a variant of option (2) however to fix the problem described in [1], which could provide better compatibility: 4. Offer legacy RAND_METHOD (e.g. RAND_drbg_method(), RAND_OpenSSL_legacy(), ?) as an alternative to RAND_OpenSSL() Anybody who currently uses the RAND_DRBG callback mechanism, could activate this legacy RAND_METHOD to switch from the new EVP_RAND triple to the legacy RAND_DRBG triple of random generators, and their callbacks would continue to work as expected. I still favour option (1), but (4) might be a reasonable compromise. It comes at a price, because both RAND_METHODs need to be fully supported and tested thoroughly. Matthias [1] https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 From: openssl-project On Behalf Of Dr Paul Dale Sent: Monday, July 27, 2020 3:08 AM To: openssl-project at openssl.org Subject: RAND_DRBG The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly with the move to provider based infrastructure. They are definitely being deprecated in master but without more, the extra layer of indirection and additional complexity generating random numbers will remain. The option I see are: 1. Remove, rather than deprecate, RAND_DRBG in 3.0. This is a breaking change. 2. Bypass RAND_DRBG and live with a breaking change (refer: https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828) 3. Leave things as they currently are in master. The first two are breaking changes and will require an OMC vote. Some pertinent points: 1. RAND_bytes will continue to work as is ? this API is perfect for almost everyone. 2. The RAND_METHOD functionality remains ? this allows wholesale replacement of OpenSSL?s RNGs if desired. 3. The name EVP_RAND is the working name and might change ? this is not relevant to this discussion. 4. The RAND_DRBG APIs are unlikely to be widely used ? they were introduced in 1.1.1. The two users I know of (Akamai and NCP) are both fine with them being removed. Thoughts anyone? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From tm at t8m.info Fri Jul 24 17:10:59 2020 From: tm at t8m.info (Tomas Mraz) Date: Fri, 24 Jul 2020 19:10:59 +0200 Subject: API renaming In-Reply-To: <137F717F-BF4E-4040-9609-98A7E28F0FA3@oracle.com> References: <50D169B8-96A9-4CF2-ACB8-13BF0D1CBB83@oracle.com> <87365igrff.wl-levitte@openssl.org> <55b244b5-3a45-e8c7-59a3-e484273d552b@openssl.org> <87zh7pfpzz.wl-levitte@openssl.org> <87tuxxfmly.wl-levitte@openssl.org> <499AD091-9D31-4B58-9904-4F84F4BF8945@oracle.com> <9f29be8e2f70426bb5d85ebaea180cfd@Ex13.ncp.local> <137F717F-BF4E-4040-9609-98A7E28F0FA3@oracle.com> Message-ID: It was backported to Fedora and RHEL openssl packages. But of course that's our problem and is not a blocker for the rename. On the other hand KDFs and MACs being a class of algorithms similarly to ciphers and digests gives some argument why to keep the EVP prefix. ?Tom??? ?Tom??? 24. 7. 2020 9:46, 9:46, SHANE LONTIS napsal/a: >As @levitte pointed out - it was not back ported (not sure why I >thought it was) > >> On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre > wrote: >> >> > I think the KDF and MAC got back ported also... >> >> In this case it would be no question that we should keep the names >EVP_KDF and EVP_MAC. >> >> >> Dr. Matthias St. >Pierre >> >> Senior Software Engineer >> matthias.st.pierre at ncp-e.com >> Phone: +49 911 9968-0 >> www.ncp-e.com > >> >> Follow us on: Facebook > >| Twitter > >| Xing > >| YouTube > >| LinkedIn > >> >> Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? >90449 ? Nuremberg >> North American HQ: NCP engineering Inc. ? 601 Cleveland Str., Suite >501-25 ? Clearwater, FL 33755 >> >> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate >Dietrich >> Registry Court: Lower District Court of Nuremberg >> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: >DE 133557619 >> >> This e-mail message including any attachments is for the sole use of >the intended recipient(s) and may contain privileged or confidential >information. Any unauthorized review, use, disclosure or distribution >is prohibited. If you are not the intended recipient, please >immediately contact the sender by reply e-mail and delete the original >message and destroy all copies thereof. >> >> From tm at t8m.info Mon Jul 27 05:50:57 2020 From: tm at t8m.info (Tomas Mraz) Date: Mon, 27 Jul 2020 07:50:57 +0200 Subject: RAND_DRBG In-Reply-To: <6A490206-3F9E-4735-ACA5-2B6308F7E349@oracle.com> References: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> <8BE6D766-1AEC-4FE3-A9A5-BEDFCA23B388@oracle.com> <6A490206-3F9E-4735-ACA5-2B6308F7E349@oracle.com> Message-ID: +1 for the removal ?Tom??? 27. 7. 2020 4:58, 4:58, SHANE LONTIS napsal/a: > >i.e. Choose option (1) > >> On 27 Jul 2020, at 11:14 am, SHANE LONTIS >wrote: >> >> If this is not going to break 99% of users + it improves the >interface + the replacement to achieve the same is a few lines of code >and is likely to occur in one place in an app, then it seems reasonable >to change it to me. >> >> >>> On 27 Jul 2020, at 11:08 am, Dr Paul Dale > wrote: >>> >>> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and >sit badly with the move to provider based infrastructure. >>> They are definitely being deprecated in master but without more, the >extra layer of indirection and additional complexity generating random >numbers will remain. >>> >>> The option I see are: >>> >>> 1. Remove, rather than deprecate, RAND_DRBG in 3.0. This is a >breaking change. >>> 2. Bypass RAND_DRBG and live with a breaking change (refer: >https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 >) >>> 3. Leave things as they currently are in master. >>> >>> The first two are breaking changes and will require an OMC vote. >>> >>> >>> Some pertinent points: >>> >>> 1. RAND_bytes will continue to work as is ? this API is perfect for >almost everyone. >>> 2. The RAND_METHOD functionality remains ? this allows wholesale >replacement of OpenSSL?s RNGs if desired. >>> 3. The name EVP_RAND is the working name and might change ? this is >not relevant to this discussion. >>> 4. The RAND_DRBG APIs are unlikely to be widely used ? they were >introduced in 1.1.1. The two users I know of (Akamai and NCP) are both >fine with them being removed. >>> >>> >>> Thoughts anyone? >>> >>> >>> Pauli >>> -- >>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations >>> Phone +61 7 3031 7217 >>> Oracle Australia >>> >> From matt at openssl.org Mon Jul 27 08:51:09 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jul 2020 09:51:09 +0100 Subject: RAND_DRBG In-Reply-To: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> References: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> Message-ID: <1a4da0b6-6b5d-1292-b76f-7ba138380ccb@openssl.org> I'm ok with option 1 (but it will require a vote). I think the percentage of our user base that are using the existing API is sufficiently close to zero that we're not breaking our compatibility promises. Matt On 27/07/2020 02:08, Dr Paul Dale wrote: > The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit > badly with the move to provider based infrastructure. > They are definitely being deprecated in master but without more, the > extra layer of indirection and additional complexity generating random > numbers will remain. > > The option I see are: > > 1. Remove, rather than deprecate, RAND_DRBG in 3.0. ?This is a breaking > change. > 2. Bypass RAND_DRBG and live with a breaking change (refer: > https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828) > 3. Leave things as they currently are in master. > > The first two are breaking changes and will require an OMC vote. > > > Some pertinent points: > > 1. RAND_bytes will continue to work as is ? this API is perfect for > almost everyone. > 2. The?RAND_METHOD functionality remains ? this allows wholesale > replacement of OpenSSL?s RNGs if desired. > 3. The name EVP_RAND is the working name and might change ? this is not > relevant to this discussion. > 4. The RAND_DRBG APIs are unlikely to be widely used ? they were > introduced in 1.1.1. ?The two users I know of (Akamai and NCP) are both > fine with them being removed. > > > Thoughts anyone? > > > Pauli > --? > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? > Phone +61 7 3031 7217 > Oracle Australia > From paul.dale at oracle.com Mon Jul 27 22:49:12 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 28 Jul 2020 08:49:12 +1000 Subject: RAND_DRBG In-Reply-To: <1a4da0b6-6b5d-1292-b76f-7ba138380ccb@openssl.org> References: <36726ADB-DBF4-4691-916C-33E2A2BB62D8@oracle.com> <1a4da0b6-6b5d-1292-b76f-7ba138380ccb@openssl.org> Message-ID: <071AE4C3-7F32-4C29-8F8C-536E928B044A@oracle.com> So far a universal voice for removal of the DRBG_RAND APIs. I?ll write up an OMC vote. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 27 Jul 2020, at 6:51 pm, Matt Caswell wrote: > > I'm ok with option 1 (but it will require a vote). I think the > percentage of our user base that are using the existing API is > sufficiently close to zero that we're not breaking our compatibility > promises. > > Matt > > > On 27/07/2020 02:08, Dr Paul Dale wrote: >> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit >> badly with the move to provider based infrastructure. >> They are definitely being deprecated in master but without more, the >> extra layer of indirection and additional complexity generating random >> numbers will remain. >> >> The option I see are: >> >> 1. Remove, rather than deprecate, RAND_DRBG in 3.0. This is a breaking >> change. >> 2. Bypass RAND_DRBG and live with a breaking change (refer: >> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828) >> 3. Leave things as they currently are in master. >> >> The first two are breaking changes and will require an OMC vote. >> >> >> Some pertinent points: >> >> 1. RAND_bytes will continue to work as is ? this API is perfect for >> almost everyone. >> 2. The RAND_METHOD functionality remains ? this allows wholesale >> replacement of OpenSSL?s RNGs if desired. >> 3. The name EVP_RAND is the working name and might change ? this is not >> relevant to this discussion. >> 4. The RAND_DRBG APIs are unlikely to be widely used ? they were >> introduced in 1.1.1. The two users I know of (Akamai and NCP) are both >> fine with them being removed. >> >> >> Thoughts anyone? >> >> >> Pauli >> -- >> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations >> Phone +61 7 3031 7217 >> Oracle Australia >> -------------- next part -------------- An HTML attachment was scrubbed... URL: