From levitte at openssl.org Tue Jul 2 13:36:14 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 02 Jul 2019 15:36:14 +0200 Subject: OSSL_PARAM thought In-Reply-To: <1D323FCB-DEC1-4C37-AE34-5D16ADB2D112@oracle.com> References: <1D323FCB-DEC1-4C37-AE34-5D16ADB2D112@oracle.com> Message-ID: <87pnmsimnl.wl-levitte@openssl.org> This was actually discussed in the design phase, and I think we concluded that all arrays of this sort should be terminated rather than counted. I frankly cannot remember what the reasoning was behind this, and suspect it came down to personal taste. However, whatever way we choose should be a consistent pattern. The worst we can do is to have some arrays counted while having others terminated with a special value. That's a recipe for confusion. (I'll note, though, that some arrays must be counted because there is no special terminating value to be had. As far as I can recall, though, this is uniquely for arrays of bytes) Cheers, Richard On Mon, 24 Jun 2019 03:04:21 +0200, Dr Paul Dale wrote: > > [1 ] > [2 ] > We?re only starting out, so there isn?t any issue yet. I am wondering if instead of terminating > out OSSL_PARAM arrays with an empty element, would it make sense to pass a size and the array? > > I.e. changing this code sequence (from crypto/evp/digest.c): > > params[i++] = OSSL_PARAM_construct_size_t(OSSL_DIGEST_PARAM_XOFLEN, > &size, NULL); > params[i++] = OSSL_PARAM_construct_end(); > EVP_MD_CTX_set_params(ctx, params); > > into: > > params[i++] = OSSL_PARAM_construct_size_t(OSSL_DIGEST_PARAM_XOFLEN, > &size, NULL); > EVP_MD_CTX_set_params(ctx, i, params); > > For fixed arrays OSSL_NELEM would be used instead of the counter variable. > > There are downsides with both approaches of course and neither jumps out as being obviously > superior. > > To me, at least, it looks like we?re going to have a lot of END?s throughout the codebase. Saving > one line many times seems like a win. > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Wed Jul 3 13:59:58 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 Jul 2019 14:59:58 +0100 Subject: Monthly Status Report (June) Message-ID: <57e80270-11fe-c936-ccfb-d651e4058f9d@openssl.org> 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 making the threading code provider aware - leading to that PR being merged. - Continued to handle feedback and issues with the PRs to enable RAND in the FIPS module - ultimately resulting in this code being merged - Added the ability for "make doc-nits" to complain about newly added symbols that do not have documentation - Fixed "enable-ssl3" - Investigated a memory corruption issue, which turned out to be a documentation bug in the d2i docs - and then fixed those docs - Implemented a PACKET/WPACKET version of some simple ASN.1 utils for DSA - Made the BIGNUM code available from within the FIPS provider - Fixed a compilation issue with gcc 7.4.0 not recognising a "fall through" comment - Fixed the no-dh build - Implemented some significant updates to allow TLSv1.3 even in a no-ec build. This was made possible by the recent integration of TLSv1.3 FFDHE support. This work also fixed the no-ec build. - Fixed building with enable-trace - Fixed a number of race conditions in the TLSv1.3 handling of supported groups and some other similar fields - Fixed a bug in the FIPS provider which was creating an OPENSSL_CTX twice by mistake - Moved the public SIV mode functions to internal headers. There was no need for these functions to be public, and it reduced the number of newly added undocumented symbols. - Documented the ECP_CIPHER_fetch and EVP_CIPHER_up_ref functions - Created a PR to move PKCS#3 DH to the default provider - Fixed a bug which resulted in an assertion failure in master - Fixed a mem leak in evp_test - Resolved a crash in rc5 when using a key longer than 2040 bits Matt From levitte at openssl.org Thu Jul 4 16:01:59 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 04 Jul 2019 18:01:59 +0200 Subject: Vote FYI: Remove function codes from error reporting functions as per PR#9058 Message-ID: <877e8xiya0.wl-levitte@openssl.org> topic: Remove function codes from error reporting functions as per PR#9058. comment: Discussed in https://mta.openssl.org/pipermail/openssl-project/2019-June/001426.html Proposed by Richard Levitte opened: 2019-07-04 closed: yyyy-mm-dd I will follow up with the tally when the vote is concluded. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Sat Jul 6 07:32:23 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 07:32:23 +0000 Subject: Cleaning up include file inconsistencies Message-ID: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> Hi all, pull request #9274 started out as a task to clean up inconsistencies in the naming of the include guards. It turned out that there are also some inconsistencies in the naming of the include files. Please take a look at the general discussion starting at https://github.com/openssl/openssl/pull/9274#issuecomment-508824668 between Bernd and me. In particular, in https://github.com/openssl/openssl/pull/9274#issuecomment-508826903 and following the question was raised whether all local `*_lcl.h` files should be renamed to `*_locl.h` for consistency reasons, and the pros and cons discussed. The latter choice was suggested by a source tree vote: ~/src/openssl$ find -name '*_lcl.h' | wc -l 19 ~/src/openssl$ find -name '*_locl.h' | wc -l 30 What's your opinion about renaming of those files? Matthias From beldmit at gmail.com Sat Jul 6 08:44:33 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 6 Jul 2019 11:44:33 +0300 Subject: Cleaning up include file inconsistencies In-Reply-To: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> References: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> Message-ID: Hello, I'd like either _lcl.h or _local.h. _locl.h seems weird to me :) On Sat, Jul 6, 2019 at 10:32 AM Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > Hi all, > > pull request #9274 started out as a task to clean up inconsistencies in > the naming > of the include guards. It turned out that there are also some > inconsistencies in the > naming of the include files. > > Please take a look at the general discussion starting at > https://github.com/openssl/openssl/pull/9274#issuecomment-508824668 > between Bernd and me. > > In particular, in > https://github.com/openssl/openssl/pull/9274#issuecomment-508826903 and > following the question was raised whether all local `*_lcl.h` files should > be renamed > to `*_locl.h` for consistency reasons, and the pros and cons discussed. > The latter choice was suggested by a source tree vote: > > ~/src/openssl$ find -name '*_lcl.h' | wc -l > 19 > ~/src/openssl$ find -name '*_locl.h' | wc -l > 30 > > What's your opinion about renaming of those files? > > Matthias > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sat Jul 6 09:50:48 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 09:50:48 +0000 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> References: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> Message-ID: There are more oddities in the organization of the internal header files. 1) It appears to me that there are three different levels of internal header files - headers in `include/internal` - headers in `crypto/include/internal` - headers in `crypto/` along with the source files Having such a finegrained distinction is not the problem, but (at least to me) it is not entirely clear which include file goes into which directory. 2) Some of the header files carry an `_int.h` suffix while others not, for seemingly no particular reason. ~/src/openssl$ find -name '*_int.h' ./crypto/crmf/crmf_int.h ./crypto/include/internal/err_int.h ./crypto/include/internal/ess_int.h ./crypto/include/internal/ec_int.h ./crypto/include/internal/rand_int.h ./crypto/include/internal/store_int.h ./crypto/include/internal/asn1_int.h ./crypto/include/internal/modes_int.h ./crypto/include/internal/cryptlib_int.h ./crypto/include/internal/bn_int.h ./crypto/include/internal/evp_int.h ./crypto/include/internal/x509_int.h ./crypto/cmp/cmp_int.h ./crypto/x509/pcy_int.h In particular for the headers the `include/internal` folder this suffix is superfluous, because these files are (or should be) included via relative paths. So instead of #include #include "internal/evp_int.h" It could just be #include #include "internal/evp.h" Matthias From Matthias.St.Pierre at ncp-e.com Sat Jul 6 10:20:11 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 10:20:11 +0000 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: References: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> Message-ID: <671c91e5779b45a99e8367307d00c8b8@Ex13.ncp.local> > Having such a finegrained distinction is not the problem, but (at least to me) > it is not entirely clear which include file goes into which directory. Note: the high score seems to lie at four different header files for the same package, not counting the generated error header file: ~/src/openssl$ find -name 'store*.h' ./crypto/store/store_locl.h ./crypto/include/internal/store.h ./crypto/include/internal/store_int.h ./include/openssl/store.h ./include/openssl/storeerr.h Matthias From levitte at openssl.org Sat Jul 6 16:49:32 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 06 Jul 2019 18:49:32 +0200 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: References: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> Message-ID: <87v9wfglb7.wl-levitte@openssl.org> On Sat, 06 Jul 2019 11:50:48 +0200, Dr. Matthias St. Pierre wrote: > > There are more oddities in the organization of the internal header files. > > 1) It appears to me that there are three different levels of internal header files > > - headers in `include/internal` For internal things that we want to make available for both libcrypto and libssl (i.e. they are exported in libcrypto.so) > - headers in `crypto/include/internal` For internal things that we only want available inside libcrypto (i.e. they are NOT exported in libcrypto.so) > - headers in `crypto/` along with the source files For things that are private to that sub-system (sorry, "package" doesn't sound right) > Having such a finegrained distinction is not the problem, but (at least to me) > it is not entirely clear which include file goes into which directory. > > 2) Some of the header files carry an `_int.h` suffix while others not, > for seemingly no particular reason. > > ~/src/openssl$ find -name '*_int.h' > ./crypto/crmf/crmf_int.h Should have been named crmf_locl.h > ./crypto/include/internal/err_int.h > ./crypto/include/internal/ess_int.h > ./crypto/include/internal/ec_int.h > ./crypto/include/internal/rand_int.h > ./crypto/include/internal/store_int.h > ./crypto/include/internal/asn1_int.h > ./crypto/include/internal/modes_int.h > ./crypto/include/internal/cryptlib_int.h > ./crypto/include/internal/bn_int.h > ./crypto/include/internal/evp_int.h > ./crypto/include/internal/x509_int.h The reason for this is to avoid confusion between headers in crypto/include/internal and headers in include/internal. It's not quite as necessary as all these names seem to suggest, but we do have these as an example: : ; find . -name 'err*.h' | grep /include/internal/ ./include/internal/err.h ./crypto/include/internal/err_int.h > ./crypto/cmp/cmp_int.h Should have been named cmp_locl.h > ./crypto/x509/pcy_int.h Should have been named pcy_locl.h > In particular for the headers the `include/internal` folder this suffix > is superfluous, because these files are (or should be) included via > relative paths. So instead of > > #include > #include "internal/evp_int.h" > > It could just be > > #include > #include "internal/evp.h" In most cases, you're right. I suspect "_int" was habitually added to ensure we know exactly where that header comes from. Me, I'm wondering if it wouldn't be clearer if we renamed crypto/include/internal -> crypto/include/crypto, and thereby did this: #include "crypto/evp.h" That, to me, is much clearer than the "_int" suffix. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Jul 6 16:54:06 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 06 Jul 2019 18:54:06 +0200 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: <671c91e5779b45a99e8367307d00c8b8@Ex13.ncp.local> References: <1580a71ce2b84dbaa58b1016f96a3937@Ex13.ncp.local> <671c91e5779b45a99e8367307d00c8b8@Ex13.ncp.local> Message-ID: <87tvbzgl3l.wl-levitte@openssl.org> On Sat, 06 Jul 2019 12:20:11 +0200, Dr. Matthias St. Pierre wrote: > > > Having such a finegrained distinction is not the problem, but (at least to me) > > it is not entirely clear which include file goes into which directory. > > Note: the high score seems to lie at four different header files for the same package, > not counting the generated error header file: > > ~/src/openssl$ find -name 'store*.h' > ... > ./crypto/include/internal/store.h > ./crypto/include/internal/store_int.h ... I have *no* idea why there are two header files. I must have forgotten about one of them when creating the other... They should be merged into one. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Sat Jul 6 17:03:27 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 17:03:27 +0000 Subject: Cleaning up include file inconsistencies Message-ID: <779d85fc2e77478f9d6ce4f447727c34@Ex13.ncp.local> > For things that are private to that sub-system (sorry, "package" doesn't sound right) Neither does it to me, apologies. I was looking for the right word, but nothing except "package" came to my mind. And I was too lazy to search for it in the docs. > Me, I'm wondering if it wouldn't be clearer if we renamed > crypto/include/internal -> crypto/include/crypto, and thereby did > this: > > #include "crypto/evp.h" > > That, to me, is much clearer than the "_int" suffix. This sounds like an excellent idea to me. Matthias From Matthias.St.Pierre at ncp-e.com Sat Jul 6 17:04:40 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 17:04:40 +0000 Subject: Cleaning up include file inconsistencies Message-ID: <69fc2e5751564bf899d4ccb90e03b4c3@Ex13.ncp.local> > > ./crypto/include/internal/store.h > > ./crypto/include/internal/store_int.h > ... > > I have *no* idea why there are two header files. I must have > forgotten about one of them when creating the other... > > They should be merged into one. Ok, I can take care of it. Matthias From levitte at openssl.org Sat Jul 6 17:22:37 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 06 Jul 2019 19:22:37 +0200 Subject: Cleaning up include file inconsistencies In-Reply-To: <779d85fc2e77478f9d6ce4f447727c34@Ex13.ncp.local> References: <779d85fc2e77478f9d6ce4f447727c34@Ex13.ncp.local> Message-ID: <87r273gjs2.wl-levitte@openssl.org> On Sat, 06 Jul 2019 19:03:27 +0200, Dr. Matthias St. Pierre wrote: > > > For things that are private to that sub-system (sorry, "package" doesn't sound right) > > Neither does it to me, apologies. I was looking for the right word, but nothing except > "package" came to my mind. And I was too lazy to search for it in the docs. It's not in the docs. The original term is "library", and that's because SSLeay and early OpenSSL were designed to make it possible to build a separate library from any of those subdirectories. Traces of this is still seen in the error codes. "sub-system" is a term that some of us have started using, mostly on github. I find it catchy enough that I've started using it regularly. > > Me, I'm wondering if it wouldn't be clearer if we renamed > > crypto/include/internal -> crypto/include/crypto, and thereby did > > this: > > > > #include "crypto/evp.h" > > > > That, to me, is much clearer than the "_int" suffix. > > This sounds like an excellent idea to me. "Someone" should create a PR... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Sat Jul 6 17:25:01 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 17:25:01 +0000 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: <779d85fc2e77478f9d6ce4f447727c34@Ex13.ncp.local> References: <779d85fc2e77478f9d6ce4f447727c34@Ex13.ncp.local> Message-ID: <21865d5d7df34a70af777422e952c217@Ex13.ncp.local> > > Me, I'm wondering if it wouldn't be clearer if we renamed > > crypto/include/internal -> crypto/include/crypto, and thereby did > > this: > > > > #include "crypto/evp.h" > > > > That, to me, is much clearer than the "_int" suffix. > > This sounds like an excellent idea to me. Wouldn't it even be better to move `crypto/include/internal` to `include/internal/crypto` and include it as #include "internal/crypto/evp.h" this would have the advantage that _all_ shared include files can be found in the `include` folder, the public ones inside `include/openssl` and the internal ones in `include/internal`. Also, it would be a very consistent structure and easy to remember. #include "internal/foo.h" /* shared between libcrypto and libssl */ #include "internal/crypto/bar.h" /* shared by libcrypto modules only */ #include "internal/ssl/bar.h" /* shared by libssl modules only */ ... and so on: ... #include "internal/engines/baz.h" /* shared by engine modules */ Matthias From Matthias.St.Pierre at ncp-e.com Sat Jul 6 17:29:10 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 17:29:10 +0000 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: <87r273gjs2.wl-levitte@openssl.org> References: <779d85fc2e77478f9d6ce4f447727c34@Ex13.ncp.local> <87r273gjs2.wl-levitte@openssl.org> Message-ID: > > > That, to me, is much clearer than the "_int" suffix. > > > > This sounds like an excellent idea to me. > > "Someone" should create a PR... I wouldn't mind doing it alongside the other changes in #9274, but I'd prefer my alternative proposal, which I just posted before. That is, if you agree of course. If you insist on doing it as a separate PR, I don't mind. But it does not make sense to start on it before #9274 has been accepted and merged. Matthias From Matthias.St.Pierre at ncp-e.com Sat Jul 6 17:44:15 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 6 Jul 2019 17:44:15 +0000 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: References: <779d85fc2e77478f9d6ce4f447727c34@Ex13.ncp.local> <87r273gjs2.wl-levitte@openssl.org> Message-ID: <8b37e8b1edae4fd685f66bcdbf7dcf62@Ex13.ncp.local> A good idea just occurred to me. I will rework #9274 and create two new pull requests from it: - PR 1: restructure the internal headers and fix the internal include guards. - PR 2: fix the include guards for the public header files PR 1 could be backported to 1.1.1 which would be advantageous for cherry-picking. That's important IMHO because 1.1.1 is an LTS release. PR 2 would only go to master. What do you think about it? Matthias From Matthias.St.Pierre at ncp-e.com Sun Jul 7 14:16:50 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 7 Jul 2019 14:16:50 +0000 Subject: Cleaning up include file inconsistencies Message-ID: <5ca9feb404fe4806b26da1a909a2349e@Ex13.ncp.local> I am beginning to wonder whether it is a good idea to make the fact whether a private header file contains exported symbols as selection criterion for where the header file needs to go in the source tree: > > - headers in `include/internal` > > For internal things that we want to make available for both libcrypto > and libssl (i.e. they are exported in libcrypto.so) > > > - headers in `crypto/include/internal` > > For internal things that we only want available inside libcrypto > (i.e. they are NOT exported in libcrypto.so) If you take a look at commit d5e5e2ffafc7 (Move digests to providers) then you will notice that the `sm3.h` header file was moved: ~/src/openssl$ git show --stat d5e5e2ffafc7 | grep sm3.h {crypto/include => include}/internal/sm3.h | 7 +- So it seems like whenever the first symbol of a libcrypto-only private header file needs to be exported then we also have to move the entire header file? This is tedious and also doesn't really make sense. Because now the files sm2.h and sm3.h happen to be in two different directories: crypto/include/internal/sm2.h include/internal/sm3.h To be precise: that's only in master, because in 1.1.1 they are still in the same directory. (That's how I noticed it in the first place, because I compared source trees.) My suggestion instead would be to store all internal header files which are shared by more than one sub-system either in include/internal/crypto ( #include "crypto/filename.h") include/internal/ssl ( #include "ssl/filename.h") depending on where the code is *implemented*, not where it is *used*. The directory `include/internal` itself should not contain any include files. Whether an internal libcrypto function can be used in libssl should depend only on libcrypto.num and nothing else. Matthias From paul.dale at oracle.com Sun Jul 7 21:35:09 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 8 Jul 2019 07:35:09 +1000 Subject: Vote on PR Message-ID: The following vote passed 6 to 0. topic: Accept the changes to the OpenSSL policies as per PR#133 (openssl/web). comment: The definition of trivial being clarified and moved to the web page that the missing CLA note references. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at openssl.org Tue Jul 9 08:25:42 2019 From: tjh at openssl.org (Tim Hudson) Date: Tue, 9 Jul 2019 18:25:42 +1000 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> Message-ID: >From OMC internal discussions: For all contributions that are made to OpenSSL there are three circumstances that can exist: 1) the contribution is considered trivial - no CLA required 2) the contribution is non-trivial and the copyright is owned by the submitter (or by the company they work for) - ICLA (and CCLA) required 3) the contribution is non-trivial and the copyright is owned by someone other than the submitter and the copyright owner acknowledges that the submission is on their behalf - ICLA (and CCLA) from the copyright owner required. Our CLA policy and the CLA documents themselves operate to cover contributions as described above and the CLA policy itself notes no exceptions for contributions outside of these circumstances. The only mechanism for a contribution to be accepted that does not meet the CLA policy is if the OMC votes to explicitly accept a contribution without a CLA as a special exception to the CLA policy. Notes: a) the OMC has not to this date voted to approve inclusion of any contribution without a CLA in place since the CLA policy was established in June 2016; b) the OMC does not currently have a policy to allow exceptions to the CLA policy based on the license terms of a contribution Thanks, Tim. On Fri, Jun 21, 2019 at 4:24 PM Tim Hudson wrote: > Unfortunately, the issue isn't the compatibility of the license - they do > indeed look relatively compatible to me - and the discussion on this thread > has so far been about that. > However the contributor license agreement requires that the copyright > owner grants such permission - it is the fundamental basis of contributor > agreements. > > Both the CCLA and ICLA make that exceedingly clear the contributor > (individual or company) is "*the copyright owner or legal entity > authorized by the copyright owner*" and the grants in the CLA are not > grants that the notice in the RFC provide. > > In this case, the person who raised the PR is unable to meet those > requirements (please do correct me if I am wrong on that) and as such their > contribution is unable to be accepted. > > Tim. > > > On Fri, Jun 21, 2019 at 12:12 PM Dr Paul Dale > wrote: > >> It seems okay from here too. >> >> Pauli >> -- >> Dr Paul Dale | Cryptographer | Network Security & Encryption >> Phone +61 7 3031 7217 >> Oracle Australia >> >> >> >> > On 21 Jun 2019, at 11:59 am, Benjamin Kaduk wrote: >> > >> > On Thu, Jun 20, 2019 at 12:27:38PM -0400, Viktor Dukhovni wrote: >> >> On Thu, Jun 20, 2019 at 03:39:10PM +0100, Matt Caswell wrote: >> >> >> >>> PR 9199 incorporates the C punycode implementation from RFC3492: >> >>> >> >>> https://github.com/openssl/openssl/pull/9199 >> >>> >> >> >> >> I'd be comfortable with relicensing under Apache, while clearly >> >> indicating the provenance of the code, and indicating that the >> >> file is also available under the original terms. >> > >> > Me, too. >> > >> > -Ben >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Tue Jul 9 21:35:16 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 9 Jul 2019 21:35:16 +0000 Subject: AW: Cleaning up include file inconsistencies In-Reply-To: <5ca9feb404fe4806b26da1a909a2349e@Ex13.ncp.local> References: <5ca9feb404fe4806b26da1a909a2349e@Ex13.ncp.local> Message-ID: FYI, I opened pull request #9333 on GitHub today, which demonstrates some of the ideas which I discussed in this thread. https://github.com/openssl/openssl/pull/9333 Looking forward to your feedback. Matthias From tjh at openssl.org Wed Jul 10 01:15:02 2019 From: tjh at openssl.org (Tim Hudson) Date: Wed, 10 Jul 2019 11:15:02 +1000 Subject: punycode licensing In-Reply-To: <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Message-ID: On Wed, Jul 10, 2019 at 1:58 AM Salz, Rich wrote: > Thank you for the update. This brings to mind a few additional questions: > > 1. Does other code which is copyright/licensed under the Apache 2 license also require CLAs? See points 1-3 of previous email. CLAs are required for anything non-trivial. > 2. Does other code which is in the public domain also require CLAs? See points 1-3 of previous email. CLAs are required for anything non-trivial. > 3. Does OpenSSL expect that anyone using OpenSSL and bundling it with Apache 2 software must first ask the project for permission? That is an entirely separate question and all the project states is the license under which we offer the software. That question can be more broadly worded as "Does OpenSSL expect that anyone using OpenSSL must first ask the project for permission?" The license under which the OpenSSL software is provided does not require "permission" to be sought for use of the software. See https://www.openssl.org/source/apache-license-2.0.txt So in short the answer is "no" because the software is under a license that doesn't require permission to be sought for its use. > 4. Assuming #1 is yes and #3 is no, can you explain why there is a difference? Because 1 and 2 are about *contributing *code that the project then offers under a license, whereas 3 is about *using* the produced code under its license. They are completely different contexts (one in-bound, one out-bound). And they are completely different entities (1&2 are about requirements the *project *places on contributions, and 3 is about requirements the license places on *users* of the software). Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Jul 10 07:37:52 2019 From: levitte at openssl.org (Richard Levitte) Date: Wed, 10 Jul 2019 09:37:52 +0200 Subject: Vote FYI: Remove function codes from error reporting functions as per PR#9058 In-Reply-To: <877e8xiya0.wl-levitte@openssl.org> References: <877e8xiya0.wl-levitte@openssl.org> Message-ID: <87o922xru7.wl-levitte@openssl.org> The vote closed today, with the following result: +1: 4 0: 3 (where one is a -0) -1: 0 The vote passes. Cheers, Richard On Thu, 04 Jul 2019 18:01:59 +0200, Richard Levitte wrote: > > topic: Remove function codes from error reporting functions as per PR#9058. > comment: Discussed in > https://mta.openssl.org/pipermail/openssl-project/2019-June/001426.html > Proposed by Richard Levitte > opened: 2019-07-04 > closed: yyyy-mm-dd > > I will follow up with the tally when the vote is concluded. > > Cheers, > Richard > > -- > 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 rsalz at akamai.com Tue Jul 9 15:58:13 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 9 Jul 2019 15:58:13 +0000 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> Message-ID: <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Thank you for the update. This brings to mind a few additional questions: 1. Does other code which is copyright/licensed under the Apache 2 license also require CLAs? 2. Does other code which is in the public domain also require CLAs? 3. Does OpenSSL expect that anyone using OpenSSL and bundling it with Apache 2 software must first ask the project for permission? 4. Assuming #1 is yes and #3 is no, can you explain why there is a difference? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 10 01:31:24 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 10 Jul 2019 01:31:24 +0000 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Message-ID: Thank you for the reply. >The license under which the OpenSSL software is provided does not require "permission" to be sought for use of the software. See https://www.openssl.org/source/apache-license-2.0.txt Use, as defined by the license, doesn?t just mean end-users, and it is not limited to compiling, linking, and running executables. A recipient can make derivative items, redistribute, and so on. All of those things are what OpenSSL would do if it ?took in? code into the source base. So why does the project require permission from other Apache-licensed licensed software? In other words, why will the project not accept and use the rights, covered by copyright and license, that it grants to others? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Wed Jul 10 10:42:57 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Wed, 10 Jul 2019 20:42:57 +1000 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Message-ID: Previous assertions that if the license was compatible that we don't need a CLA in order to accept a contribution were incorrect. You are now questioning the entire purpose of contributor agreements and effectively arguing they are superfluous and that our policy should be different. You are (of course) entitled to your opinion on the topic - however the project view and policy on this is both clear and consistent even if it is different from what you would like to see. If someone else wants to create a derivative of the software and combine in packages under other licenses (Apache License or otherwise) without having CLAs in place then that is their choice to do so as long as they adhere to the license agreement. Again, all of this is use under the license. What our policies cover is for contributions that the project itself will distribute - and entirely separate context for what others can do with the resulting package. The CLAs are not the same as code being contributed under an Apache License 2.0. There are many sound reasons for CLAs existing, and discussion of those reasons isn't an appropriate topic IMHO for openssl-project. Tim. On Wed, Jul 10, 2019 at 8:08 PM Salz, Rich wrote: > Thank you for the reply. > > > > *>*The license under which the OpenSSL software is provided does not > require "permission" to be sought for use of the software. > > See https://www.openssl.org/source/apache-license-2.0.txt > > > > > Use, as defined by the license, doesn?t just mean end-users, and it is not > limited to compiling, linking, and running executables. A recipient can > make derivative items, redistribute, and so on. All of those things are > what OpenSSL would do if it ?took in? code into the source base. > > > > So why does the project require permission from other Apache-licensed > licensed software? In other words, why will the project not accept and use > the rights, covered by copyright and license, that it grants to others? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 10 12:10:34 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 10 Jul 2019 12:10:34 +0000 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Message-ID: <5CD04F84-C340-41CE-83DC-4D5E71FD693B@akamai.com> I will take the hint and stop commenting on this thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulsheer at gmail.com Tue Jul 9 20:46:42 2019 From: paulsheer at gmail.com (Paul Sheer) Date: Tue, 9 Jul 2019 15:46:42 -0500 Subject: SHA-256 assembly language optimization Message-ID: Hello, I'd like to ask about improving SHA-256 performance: I see on this page, https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/sha-256-implementations-paper.pdf Intel gives a reference implementation of SHA-256 for its own processors. How is OpenSSL's implementation related to that implementation? Is there much opportunity for improvement? I assume the person who wrote the current OpenSSL assembly probably looked into every avenue for improvement of performance, but just in case, I feel I should ask. Can it get much faster? Thanks Paul From beldmit at gmail.com Wed Jul 10 14:37:40 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 10 Jul 2019 17:37:40 +0300 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Message-ID: Dear Tim, Formally I am a contributor with a signed CLA. I took a code definitely permitting any usage without any feedback, slightly modified it (at least by openssl-format-source and splitting between header and source), and submitted it as my feedback to OpenSSL. I still think that it will be a good idea if Adam signs the CLA, but if he declines, we still have a correct interpretation. On Wed, Jul 10, 2019 at 1:43 PM Tim Hudson wrote: > Previous assertions that if the license was compatible that we don't need > a CLA in order to accept a contribution were incorrect. > You are now questioning the entire purpose of contributor agreements and > effectively arguing they are superfluous and that our policy should be > different. > > You are (of course) entitled to your opinion on the topic - however the > project view and policy on this is both clear and consistent even if it is > different from what you would like to see. > > If someone else wants to create a derivative of the software and combine > in packages under other licenses (Apache License or otherwise) without > having CLAs in place then that is their choice to do so as long as they > adhere to the license agreement. > Again, all of this is use under the license. What our policies cover is > for contributions that the project itself will distribute - and entirely > separate context for what others can do with the resulting package. > > The CLAs are not the same as code being contributed under an Apache > License 2.0. > There are many sound reasons for CLAs existing, and discussion of those > reasons isn't an appropriate topic IMHO for openssl-project. > > Tim. > > > > On Wed, Jul 10, 2019 at 8:08 PM Salz, Rich wrote: > >> Thank you for the reply. >> >> >> >> *>*The license under which the OpenSSL software is provided does not >> require "permission" to be sought for use of the software. >> >> See https://www.openssl.org/source/apache-license-2.0.txt >> >> >> >> >> Use, as defined by the license, doesn?t just mean end-users, and it is >> not limited to compiling, linking, and running executables. A recipient >> can make derivative items, redistribute, and so on. All of those things are >> what OpenSSL would do if it ?took in? code into the source base. >> >> >> >> So why does the project require permission from other Apache-licensed >> licensed software? In other words, why will the project not accept and use >> the rights, covered by copyright and license, that it grants to others? >> >> >> > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 10 15:34:03 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 10 Jul 2019 11:34:03 -0400 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Message-ID: <7851FB50-219C-4CF1-842C-E3E37DDC6485@dukhovni.org> > On Jul 10, 2019, at 10:37 AM, Dmitry Belyavsky wrote: > > Formally I am a contributor with a signed CLA. > I took a code definitely permitting any usage without any feedback, slightly modified it (at least by openssl-format-source and splitting between header and source), and submitted it as my feedback to OpenSSL. Your ICLA does not cover code for which you as an individual are not the copyright holder. Merely having license to *use* the code is not sufficient to make license assignments to the project. I think we have two possible paths forward: 1. The copyright owner signs an ICLA 2. The OMC votes to accept *this particular* code (which published under a permissive license in an RFC, and widely used) without an ICLA. Perhaps 2 is the best way forward, but for the record the outcome is not *automatic*. It requires an explicit decision to accept the specific contribution in question. -- Viktor. From tjh at cryptsoft.com Wed Jul 10 23:44:34 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Thu, 11 Jul 2019 09:44:34 +1000 Subject: punycode licensing In-Reply-To: References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org> <20190620162738.GP84864@straasha.imrryr.org> <20190621015945.GL52381@kduck.mit.edu> <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com> <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com> Message-ID: On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky wrote: > Dear Tim, > > Formally I am a contributor with a signed CLA. > I took a code definitely permitting any usage without any feedback, > slightly modified it (at least by openssl-format-source and splitting > between header and source), and submitted it as my feedback to OpenSSL. > > I still think that it will be a good idea if Adam signs the CLA, but if he > declines, we still have a correct interpretation. > In your ICLA it contains the instructions you have to follow (reproduced here to save you time): 7. Should You wish to submit work that is not Your original creation, You may submit it to the Foundation separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]". Your current PR at https://github.com/openssl/openssl/pull/9199 does not actually do this - basically you have to have punycode.c, punycode.h in a separate submission not intermixed with anything else. The reason for not intermixing the code should be pretty clear - as we need to know which parts belong to someone else and aren't covered by your ICLA and which parts are - with no possibility of confusion. You would also need to include the *license* that those files are under which you have not done so - which according to the RFC is: Regarding this entire document or any portion of it (including the pseudocode and C code), the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms. Separately, Rich Salz indicated he had email from the author with respect to being willing to license under the Apache License 2.0 which you would need to get directly from the author (or Rich would need to be the submitter). Only the author (actually copyright owner) can change the license terms of code they create. This isn't about the license. You really should reach out to the author to ask if he is willing to sign an ICLA - that is the normal steps involved. There is nothing particularly onerous in the ICLAs - they are basically there to provide certainty and a legal background for the project to be able to provide the code that it does. You should also note that the license noted in the RFC misses many of the provisions within the ICLA and within the Apache License 2.0 itself and is incompatible with the Apache License 2.0 because it contains restrictions and conditions beyond those stated in this license. After all the work that the project did to be able to move to its current license (and a lot of that work was Rich Salz's efforts) it is important that we maintain the foundation of the clear license terms for the entire code base. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Mon Jul 15 12:58:42 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 15 Jul 2019 14:58:42 +0200 Subject: Do we really want to have the legacy provider as opt-in only? Message-ID: Hi everyone, if the Subject was already fully discussed and thought through then please disregard this but otherwise I'd like this e-mail to be a starting point for discussion. I suppose the current intention is to make the legacy provider as opt- in only by either application explicitly loading it or by having it added to the default configuration file. Is there anywhere any document which categorizes the current set of algorithms with which are considered legacy and which not? I understand that for the current digest algos implemented in the legacy provider the problem might not be as pressing as these algorithms are not widely used however which other algorithms are going to be moved into the legacy provider? Wouldn't it be better to make the legacy provider opt-out? I.E. require explicit configuration or explicit API call to not load the legacy provider. -- 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 matt at openssl.org Mon Jul 15 13:19:22 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Jul 2019 14:19:22 +0100 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: Message-ID: On 15/07/2019 13:58, Tomas Mraz wrote: > Hi everyone, > > if the Subject was already fully discussed and thought through then > please disregard this but otherwise I'd like this e-mail to be a > starting point for discussion. > > I suppose the current intention is to make the legacy provider as opt- > in only by either application explicitly loading it or by having it > added to the default configuration file. The current plan is that if no provider is loaded by the time the first "fetch" is done, then then "default" provider gets loaded automatically. In other words the "legacy" provider won't get loaded automatically *unless* it is loaded by the default configuration file. I don't recall any discussion about what will be in the default configuration file. My assumption has always been that the legacy provider would not be automatically loaded. > > Is there anywhere any document which categorizes the current set of > algorithms with which are considered legacy and which not? The algorithms planned to be moved to the legacy provider are: Blowfish CAST DES (but not 3DES) DSA IDEA MD2 MD4 MDC2 RC2 RC4 RC5 RIPEMD160 SEED Whirlpool This is documented in the "Legacy Provider Module" section of the Design Document: https://www.openssl.org/docs/OpenSSL300Design.html Note the following caveat that document has about the above list: "this is not meant to be an exhaustive list, even though fairly complete for the moment" > > I understand that for the current digest algos implemented in the > legacy provider the problem might not be as pressing as these > algorithms are not widely used however which other algorithms are going > to be moved into the legacy provider? My guess is that the ones likely to give us the most problems would be DES, DSA and RC4 > > Wouldn't it be better to make the legacy provider opt-out? I.E. require > explicit configuration or explicit API call to not load the legacy > provider. > IMO this is a major release and therefore we should be taking the opportunity to encourage applications to move away from these legacy algorithms. That's kind of the point of having a legacy provider in the first place. Most applications should not need to use these legacy algos so in my mind it is a sensible default to not have them available. Only if you *really* need them should you load the legacy provider. Matt From tmraz at redhat.com Mon Jul 15 13:43:17 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 15 Jul 2019 15:43:17 +0200 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: Message-ID: <4c084d6d35816d8a72bf59fb3e80a6f59347cb2e.camel@redhat.com> On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote: > > On 15/07/2019 13:58, Tomas Mraz wrote: > > Hi everyone, > > > > if the Subject was already fully discussed and thought through then > > please disregard this but otherwise I'd like this e-mail to be a > > starting point for discussion. > > > > I suppose the current intention is to make the legacy provider as > > opt- > > in only by either application explicitly loading it or by having it > > added to the default configuration file. > > The current plan is that if no provider is loaded by the time the > first "fetch" > is done, then then "default" provider gets loaded automatically. In > other words > the "legacy" provider won't get loaded automatically *unless* it is > loaded by > the default configuration file. > > I don't recall any discussion about what will be in the default > configuration > file. My assumption has always been that the legacy provider would > not be > automatically loaded. > > > Is there anywhere any document which categorizes the current set of > > algorithms with which are considered legacy and which not? > > The algorithms planned to be moved to the legacy provider are: > > Blowfish > CAST > DES (but not 3DES) > DSA > IDEA > MD2 > MD4 > MDC2 > RC2 > RC4 > RC5 > RIPEMD160 > SEED > Whirlpool > > This is documented in the "Legacy Provider Module" section of the > Design Document: > > https://www.openssl.org/docs/OpenSSL300Design.html > > Note the following caveat that document has about the above list: > > "this is not meant to be an exhaustive list, even though fairly > complete for the > moment" > > > I understand that for the current digest algos implemented in the > > legacy provider the problem might not be as pressing as these > > algorithms are not widely used however which other algorithms are > > going > > to be moved into the legacy provider? > > My guess is that the ones likely to give us the most problems would > be DES, DSA > and RC4 > > > Wouldn't it be better to make the legacy provider opt-out? I.E. > > require > > explicit configuration or explicit API call to not load the legacy > > provider. > > > > IMO this is a major release and therefore we should be taking the > opportunity to > encourage applications to move away from these legacy algorithms. > That's kind of > the point of having a legacy provider in the first place. Most > applications > should not need to use these legacy algos so in my mind it is a > sensible default > to not have them available. Only if you *really* need them should you > load the > legacy provider. OK, but then for the applications that *really* need the legacy algorithms the move to 3.0.0 will definitiely not be just a recompilation. But then I agree with the notion that the default config file should not load the legacy provider. Otherwise we will see very mixed reports of what legacy applications fail or not based on whether the legacy application loads the default configuration file or not, whether the default configuration file was updated with the new version that loads the legacy provider, etc. etc. So to encourage the right implementation of legacy apps perhaps the openssl application (here by adding a -legacy option for example?) and the test apps should explicitly load legacy provider if asked to work with legacy algorithm. -- 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 matt at openssl.org Mon Jul 15 13:48:45 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Jul 2019 14:48:45 +0100 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <4c084d6d35816d8a72bf59fb3e80a6f59347cb2e.camel@redhat.com> References: <4c084d6d35816d8a72bf59fb3e80a6f59347cb2e.camel@redhat.com> Message-ID: On 15/07/2019 14:43, Tomas Mraz wrote: > On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote: >> >> On 15/07/2019 13:58, Tomas Mraz wrote: >>> Hi everyone, >>> >>> if the Subject was already fully discussed and thought through then >>> please disregard this but otherwise I'd like this e-mail to be a >>> starting point for discussion. >>> >>> I suppose the current intention is to make the legacy provider as >>> opt- >>> in only by either application explicitly loading it or by having it >>> added to the default configuration file. >> >> The current plan is that if no provider is loaded by the time the >> first "fetch" >> is done, then then "default" provider gets loaded automatically. In >> other words >> the "legacy" provider won't get loaded automatically *unless* it is >> loaded by >> the default configuration file. >> >> I don't recall any discussion about what will be in the default >> configuration >> file. My assumption has always been that the legacy provider would >> not be >> automatically loaded. >> >>> Is there anywhere any document which categorizes the current set of >>> algorithms with which are considered legacy and which not? >> >> The algorithms planned to be moved to the legacy provider are: >> >> Blowfish >> CAST >> DES (but not 3DES) >> DSA >> IDEA >> MD2 >> MD4 >> MDC2 >> RC2 >> RC4 >> RC5 >> RIPEMD160 >> SEED >> Whirlpool >> >> This is documented in the "Legacy Provider Module" section of the >> Design Document: >> >> https://www.openssl.org/docs/OpenSSL300Design.html >> >> Note the following caveat that document has about the above list: >> >> "this is not meant to be an exhaustive list, even though fairly >> complete for the >> moment" >> >>> I understand that for the current digest algos implemented in the >>> legacy provider the problem might not be as pressing as these >>> algorithms are not widely used however which other algorithms are >>> going >>> to be moved into the legacy provider? >> >> My guess is that the ones likely to give us the most problems would >> be DES, DSA >> and RC4 >> >>> Wouldn't it be better to make the legacy provider opt-out? I.E. >>> require >>> explicit configuration or explicit API call to not load the legacy >>> provider. >>> >> >> IMO this is a major release and therefore we should be taking the >> opportunity to >> encourage applications to move away from these legacy algorithms. >> That's kind of >> the point of having a legacy provider in the first place. Most >> applications >> should not need to use these legacy algos so in my mind it is a >> sensible default >> to not have them available. Only if you *really* need them should you >> load the >> legacy provider. > > OK, but then for the applications that *really* need the legacy > algorithms the move to 3.0.0 will definitiely not be just a > recompilation. It can still be a simple recompilation even in this case - combined with a configuration change. > But then I agree with the notion that the default config file should > not load the legacy provider. Otherwise we will see very mixed reports > of what legacy applications fail or not based on whether the legacy > application loads the default configuration file or not, The plan is to change things so that the configuration file is *always* loaded by default. So even if an application didn't explicitly load it before - they will do with 3.0. > whether the > default configuration file was updated with the new version that loads > the legacy provider, etc. etc. > > So to encourage the right implementation of legacy apps perhaps the > openssl application (here by adding a -legacy option for example?) and > the test apps should explicitly load legacy provider if asked to work > with legacy algorithm. I do think the openssl apps need to have some option to make them work with legacy algos ("-provider legacy" perhaps). Matt From matt at openssl.org Mon Jul 15 14:00:10 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Jul 2019 15:00:10 +0100 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> References: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> Message-ID: <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> On 15/07/2019 14:46, Salz, Rich wrote: > >> DSA > > What is the cryptographic weakness of DSA that you are avoiding? It's a good question. I don't recall the specific reason why that was added to the list. Perhaps others can comment. Matt From rsalz at akamai.com Mon Jul 15 13:46:49 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 15 Jul 2019 13:46:49 +0000 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: Message-ID: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> > DSA What is the cryptographic weakness of DSA that you are avoiding? From tmraz at redhat.com Mon Jul 15 14:15:01 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 15 Jul 2019 16:15:01 +0200 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: <4c084d6d35816d8a72bf59fb3e80a6f59347cb2e.camel@redhat.com> Message-ID: On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote: > > On 15/07/2019 14:43, Tomas Mraz wrote: > > On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote: > > > On 15/07/2019 13:58, Tomas Mraz wrote: > > > > > > > IMO this is a major release and therefore we should be taking the > > > opportunity to > > > encourage applications to move away from these legacy algorithms. > > > That's kind of > > > the point of having a legacy provider in the first place. Most > > > applications > > > should not need to use these legacy algos so in my mind it is a > > > sensible default > > > to not have them available. Only if you *really* need them should > > > you > > > load the > > > legacy provider. > > > > OK, but then for the applications that *really* need the legacy > > algorithms the move to 3.0.0 will definitiely not be just a > > recompilation. > > It can still be a simple recompilation even in this case - combined > with a > configuration change. This might be fine for a special build of openssl included within an application. But what would you recommend for a distribution wide openssl? If the legacy provider is not supposed to be loaded for normal applications then the system-wide configuration file must not load the provider. And then you have the special legacy apps that need it and so they need to explicitly load the legacy provider. So saying this is "just recompliation and configuration change" is at least somewhat oversimplified. But I am OK with that. I'm just saying it should be better advertised and that internally openssl should not use the "load legacy provider by having it in default config file" to actively encourage the "load legacy provider only if you *really* need it" behavior. -- 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 matt at openssl.org Mon Jul 15 14:22:21 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Jul 2019 15:22:21 +0100 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: <4c084d6d35816d8a72bf59fb3e80a6f59347cb2e.camel@redhat.com> Message-ID: <425c4daf-9683-165a-ba48-9d1ab3ece412@openssl.org> On 15/07/2019 15:15, Tomas Mraz wrote: > On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote: >> >> On 15/07/2019 14:43, Tomas Mraz wrote: >>> On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote: >>>> On 15/07/2019 13:58, Tomas Mraz wrote: >>>>> >>>> IMO this is a major release and therefore we should be taking the >>>> opportunity to >>>> encourage applications to move away from these legacy algorithms. >>>> That's kind of >>>> the point of having a legacy provider in the first place. Most >>>> applications >>>> should not need to use these legacy algos so in my mind it is a >>>> sensible default >>>> to not have them available. Only if you *really* need them should >>>> you >>>> load the >>>> legacy provider. >>> >>> OK, but then for the applications that *really* need the legacy >>> algorithms the move to 3.0.0 will definitiely not be just a >>> recompilation. >> >> It can still be a simple recompilation even in this case - combined >> with a >> configuration change. > > This might be fine for a special build of openssl included within an > application. But what would you recommend for a distribution wide > openssl? > > If the legacy provider is not supposed to be loaded for normal > applications then the system-wide configuration file must not load the > provider. And then you have the special legacy apps that need it and so > they need to explicitly load the legacy provider. So saying this is > "just recompliation and configuration change" is at least somewhat > oversimplified. Agreed. There will certainly be cases where code change *is* required. I'm just saying that not all apps will have to do this. > > But I am OK with that. I'm just saying it should be better advertised > and that internally openssl should not use the "load legacy provider by > having it in default config file" to actively encourage the "load > legacy provider only if you *really* need it" behavior. > Also agreed. I don't think we should load it in the default config file. We *should* provide an option to the apps to enable it to be loaded on a case-by-case basis where appropriate. This will certainly need some explaining at some point. As will the whole concept of providers and how the new architecture works. I expect to see (eventually) blog posts/wiki pages/man pages/CHANGES entries about the whole provider thing - and that will have to include the concept of the legacy provider. Matt From levitte at openssl.org Mon Jul 15 14:25:23 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Jul 2019 16:25:23 +0200 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: <4c084d6d35816d8a72bf59fb3e80a6f59347cb2e.camel@redhat.com> Message-ID: <87pnmbwf1o.wl-levitte@openssl.org> On Mon, 15 Jul 2019 16:15:01 +0200, Tomas Mraz wrote: > > So saying this is "just recompliation and configuration change" is > at least somewhat oversimplified. > > But I am OK with that. I'm just saying it should be better advertised > and that internally openssl should not use the "load legacy provider by > having it in default config file" to actively encourage the "load > legacy provider only if you *really* need it" behavior. I'm a little confused. "configuration changes" is about "having it in the config file", so I don't quite understand "oversimplified". Regardless of where this discussion gets us, it has always been the aim that this will be configurable with the config file. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Mon Jul 15 14:27:44 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 15 Jul 2019 14:27:44 +0000 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> References: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> Message-ID: >> DSA > > What is the cryptographic weakness of DSA that you are avoiding? It's a good question. I don't recall the specific reason why that was added to the list. Perhaps others can comment. The only weakness I know about is that if you re-use the nonce, the private key is leaked. It's more brittle than RSA-PKCS, but not as flawed as RC4. I think this should be removed from the "legacy" list unless someone can point out why it's like the others in the list. From tmraz at redhat.com Mon Jul 15 14:50:23 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 15 Jul 2019 16:50:23 +0200 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <87pnmbwf1o.wl-levitte@openssl.org> References: <4c084d6d35816d8a72bf59fb3e80a6f59347cb2e.camel@redhat.com> <87pnmbwf1o.wl-levitte@openssl.org> Message-ID: <01beed4bb423ad9e02f01d1407f3e88f57921c83.camel@redhat.com> On Mon, 2019-07-15 at 16:25 +0200, Richard Levitte wrote: > On Mon, 15 Jul 2019 16:15:01 +0200, > Tomas Mraz wrote: > > So saying this is "just recompliation and configuration change" is > > at least somewhat oversimplified. > > > > But I am OK with that. I'm just saying it should be better > > advertised > > and that internally openssl should not use the "load legacy > > provider by > > having it in default config file" to actively encourage the "load > > legacy provider only if you *really* need it" behavior. > > I'm a little confused. "configuration changes" is about "having it > in > the config file", so I don't quite understand "oversimplified". Basically no application that would like to work with algo from legacy provider and that always needs it to work properly - let's say for example something that needs to connect legacy Windows shares which use MD4 to compute some password hash - that application cannot depend on having the legacy enabled in the openssl config file. It should explicitly load the legacy provider. > Regardless of where this discussion gets us, it has always been the > aim that this will be configurable with the config file. Sure. What I'm just saying is that having it configurable does not always mean it can be depended on. I can see for example an application that works with various hashes and by default uses secure ones and you as user need the app to check some old file with old MD4 or RIPEMD160 hash as an exception - this can be done by the user enabling the legacy provider in the openssl config file. -- 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 kurt at roeckx.be Tue Jul 16 18:19:10 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 16 Jul 2019 20:19:10 +0200 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: Message-ID: <20190716181910.GA20796@roeckx.be> On Mon, Jul 15, 2019 at 02:58:42PM +0200, Tomas Mraz wrote: > Wouldn't it be better to make the legacy provider opt-out? I.E. require > explicit configuration or explicit API call to not load the legacy > provider. I'm not even sure why they need to move to a different provider (at this time). Instead I think we should have a mechanism to enable/disable the individual algorithms, and still have everything in the default provider, possibly disabled by default. At some point in the future we could remove the code from OpenSSL, and move it to different repository that only contains such legacy code that we no longer ship as part of OpenSSL. Kurt From matt at openssl.org Tue Jul 16 18:24:40 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jul 2019 19:24:40 +0100 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <20190716181910.GA20796@roeckx.be> References: <20190716181910.GA20796@roeckx.be> Message-ID: <15daf26b-9a49-f55c-0e44-a1b6ea848e07@openssl.org> On 16/07/2019 19:19, Kurt Roeckx wrote: > On Mon, Jul 15, 2019 at 02:58:42PM +0200, Tomas Mraz wrote: >> Wouldn't it be better to make the legacy provider opt-out? I.E. require >> explicit configuration or explicit API call to not load the legacy >> provider. > > I'm not even sure why they need to move to a different provider > (at this time). Instead I think we should have a mechanism to > enable/disable the individual algorithms, and still have > everything in the default provider, possibly disabled by default. > > At some point in the future we could remove the code from OpenSSL, > and move it to different repository that only contains such legacy > code that we no longer ship as part of OpenSSL. I think the reasoning behind having the legacy provider was as a first step to doing just that, i.e. we move the legacy stuff to a legacy provider and then at some later point we could choose to separate out the legacy provider as a separate thing which we don't release with mainline OpenSSL - but if people want to add it back in then they download and build the legacy provider separately and just drop it back in and it automatically becomes available again. Matt From openssl-users at dukhovni.org Tue Jul 16 19:06:28 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Jul 2019 15:06:28 -0400 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> Message-ID: <20190716190628.GJ84864@straasha.imrryr.org> On Mon, Jul 15, 2019 at 02:27:44PM +0000, Salz, Rich wrote: > >> DSA > > > > What is the cryptographic weakness of DSA that you are avoiding? > > It's a good question. I don't recall the specific reason why that was added to > the list. Perhaps others can comment. > > The only weakness I know about is that if you re-use the nonce, the private > key is leaked. It's more brittle than RSA-PKCS, but not as flawed as RC4. > > I think this should be removed from the "legacy" list unless someone can point out why it's like the others in the list. 1. DSA is not supported in TLS 1.3. 2. DSA is almost never used with TLS 1.2, the public CAs and the vast majority of users employ RSA. 3. Historical DSA was limited to 1024-bit keys and SHA-1. IIRC we now support stronger combinations, but these are not widely used. 4. As mentioned key disclosure is more likely than with RSA. 5. Attack-surface reduction. If DSA is almost never used, why enable it by default? I might note that I don't count myself amont the "crypto maximalists" And I'm generally of the "raise the ceiling not the floor" mindset, RFC7435 and all that. However, once an algorithm is sufficiently disused (raising the ceiling worked, and everybody we care about has moved on) it is then time to turn out the lights. So what are the reasons for *keeping* DSA enabled by *default* (at runtime)? Compile-time still delivers the legacy module, and the configuration file can enable it with no recompilation. -- Viktor. From kurt at roeckx.be Tue Jul 16 19:47:10 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 16 Jul 2019 21:47:10 +0200 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <20190716190628.GJ84864@straasha.imrryr.org> References: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> <20190716190628.GJ84864@straasha.imrryr.org> Message-ID: <20190716194710.GA24031@roeckx.be> On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote: > On Mon, Jul 15, 2019 at 02:27:44PM +0000, Salz, Rich wrote: > > > >> DSA > > > > > > What is the cryptographic weakness of DSA that you are avoiding? > > > > It's a good question. I don't recall the specific reason why that was added to > > the list. Perhaps others can comment. > > > > The only weakness I know about is that if you re-use the nonce, the private > > key is leaked. It's more brittle than RSA-PKCS, but not as flawed as RC4. > > > > I think this should be removed from the "legacy" list unless someone can point out why it's like the others in the list. > > 1. DSA is not supported in TLS 1.3. > 2. DSA is almost never used with TLS 1.2, the public > CAs and the vast majority of users employ RSA. > 3. Historical DSA was limited to 1024-bit keys and SHA-1. > IIRC we now support stronger combinations, but these > are not widely used. > 4. As mentioned key disclosure is more likely than with RSA. > 5. Attack-surface reduction. If DSA is almost never used, > why enable it by default? > > I might note that I don't count myself amont the "crypto maximalists" > And I'm generally of the "raise the ceiling not the floor" mindset, > RFC7435 and all that. However, once an algorithm is sufficiently > disused (raising the ceiling worked, and everybody we care about > has moved on) it is then time to turn out the lights. There used to be DSA certificates used in TLS, but the last one expired years ago. DSS based ciphers are also disabled by default since 1.1.0. Kurt From rsalz at akamai.com Tue Jul 16 23:25:28 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Jul 2019 23:25:28 +0000 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <20190716190628.GJ84864@straasha.imrryr.org> References: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> <20190716190628.GJ84864@straasha.imrryr.org> Message-ID: > If DSA is almost never used, why enable it by default? I am amused/bemused that, after years of saying we do not know what people are doing with OpenSSL, it now is now becoming common practice to blithely assert "this is not used" when it fits the personal viewpoint of some folks. From tjh at cryptsoft.com Wed Jul 17 08:25:22 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Wed, 17 Jul 2019 18:25:22 +1000 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> <20190716190628.GJ84864@straasha.imrryr.org> Message-ID: My view point (which has been stated elsewhere) is that OpenSSL-3.0 is about internal restructuring to allow for the various things noted in the design documents. It is not about changing the feature set (in a feature reduction sense). In future releases we will make the mixture of providers available more capable and may adjust what algorithms are available and may even do things like place national ciphers in separate providers. But OpenSSL-3.0 is *not* the time to do any of those things. We should be focused on the restructuring and getting the FIPS140 handling in place and not making policy decisions about changing algorithm availability or other such things. The objective is that the vast majority of applications that use OpenSSL-1.1 can use OpenSSL-3.0 with a simple recompilation without any other code changes. That I believe has been our consistent out-bound message in discussions as a group and our overall driver. In the future, things may become more dynamic and we may change the algorithm sets and may use more configuration based approaches and may even place each algorithm in a separate provider and allow for a whole range of dynamic handling. But those are for the future. OpenSSL-3.0 is basically an internally restructured version of OpenSSL-1.1 with a FIPS140 solution. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Jul 18 13:24:12 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 18 Jul 2019 15:24:12 +0200 Subject: Taking some rest Message-ID: <874l3jwk5f.wl-levitte@openssl.org> I've more or less been typing around the clock since tuesday and cranking out one commit or PR after the other at high pace... with very little reaction, so I think it's time I take a bit of rest and let everyone catch up, comment (boo?) etc as you please. Apart from a phone call with Matt tomorrow, I plan on being fairly minimally present until Monday (just in case you find my responses slow). Cheers, Richard ( feels like a balloon that lost all its air ) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaduk at mit.edu Fri Jul 19 23:39:11 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 19 Jul 2019 18:39:11 -0500 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: <20190716190628.GJ84864@straasha.imrryr.org> References: <74BB66F7-2D52-4B12-A834-ACD4F2207380@akamai.com> <6942b39b-ebfd-e9f8-9189-62d0ed6c34c3@openssl.org> <20190716190628.GJ84864@straasha.imrryr.org> Message-ID: <20190719233910.GJ8050@kduck.mit.edu> On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote: > On Mon, Jul 15, 2019 at 02:27:44PM +0000, Salz, Rich wrote: > > > >> DSA > > > > > > What is the cryptographic weakness of DSA that you are avoiding? > > > > It's a good question. I don't recall the specific reason why that was added to > > the list. Perhaps others can comment. > > > > The only weakness I know about is that if you re-use the nonce, the private > > key is leaked. It's more brittle than RSA-PKCS, but not as flawed as RC4. > > > > I think this should be removed from the "legacy" list unless someone can point out why it's like the others in the list. > [...] > 4. As mentioned key disclosure is more likely than with RSA. Huh, and it looks like we don't even implement deterministic DSA (RFC 6979) which is a partial mitigation. -Ben From kaduk at mit.edu Fri Jul 19 23:43:35 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 19 Jul 2019 18:43:35 -0500 Subject: Do we really want to have the legacy provider as opt-in only? In-Reply-To: References: Message-ID: <20190719234334.GK8050@kduck.mit.edu> On Mon, Jul 15, 2019 at 02:19:22PM +0100, Matt Caswell wrote: > > > On 15/07/2019 13:58, Tomas Mraz wrote: > > > > > I understand that for the current digest algos implemented in the > > legacy provider the problem might not be as pressing as these > > algorithms are not widely used however which other algorithms are going > > to be moved into the legacy provider? > > My guess is that the ones likely to give us the most problems would be DES, DSA > and RC4 To add a bit of anecdata, Debian and Fedora are removing DES support from (MIT) krb5. So far all we've seen as bug reports are that the kernel may still have that enctype in its list to use for NFS (as well as other, still-useful, ones), and so we need to ignore it instead of bailing. But given that it provides only ca. $20 of protection, it's not especially surprising that we aren't seeing much using it. On the other hand, krb5 is not going around and disabling RC4, even though RFC 8429 is a thing. -Ben From Matthias.St.Pierre at ncp-e.com Tue Jul 23 21:15:22 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 23 Jul 2019 21:15:22 +0000 Subject: Two Travis Jobs are failing on master Message-ID: It looks like currently two jobs of every travis build are failing on master, each with two different tests. Since this affect the builds of the pull requests, it would be nice if they could be fixed. Is anybody taking care of the problem already? Matthias Travis Job 11 https://travis-ci.org/openssl/openssl/jobs/562765539 not ok 1 - parameter_test not ok 2 - running ectest Travis Job 12 https://travis-ci.org/openssl/openssl/jobs/562765540 not ok 1 - running krb5 tests not ok 1 - running Python Cryptography tests From kurt at roeckx.be Tue Jul 23 22:03:28 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 24 Jul 2019 00:03:28 +0200 Subject: Two Travis Jobs are failing on master In-Reply-To: References: Message-ID: <20190723220328.GA9670@roeckx.be> On Tue, Jul 23, 2019 at 09:15:22PM +0000, Dr. Matthias St. Pierre wrote: > It looks like currently two jobs of every travis build are failing on master, each with two different tests. > Since this affect the builds of the pull requests, it would be nice if they could be fixed. Is anybody taking > care of the problem already? Is is related to 9442? Note that the failing tests are part of the extended tests, so we don't see a problem during pull requests. Pull requests pass without problems. It seems that we don't notice things even if master is broken for a while, because they are only tested after they've been commited, and it doesn't affect other pull requests. I wonder if we can somehow get notificated of that. Kurt From matt at openssl.org Tue Jul 23 22:39:50 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Jul 2019 23:39:50 +0100 Subject: Two Travis Jobs are failing on master In-Reply-To: References: Message-ID: <31891b3d-444e-35d7-6cb9-6eeb2bd70dd0@openssl.org> On 23/07/2019 22:15, Dr. Matthias St. Pierre wrote: > It looks like currently two jobs of every travis build are failing on master, each with two different tests. > Since this affect the builds of the pull requests, it would be nice if they could be fixed. Is anybody taking > care of the problem already? > > Matthias > > > Travis Job 11 > https://travis-ci.org/openssl/openssl/jobs/562765539 > > not ok 1 - parameter_test > not ok 2 - running ectest The ectest failure is due to this: https://github.com/openssl/openssl/issues/9251 > > > Travis Job 12 > https://travis-ci.org/openssl/openssl/jobs/562765540 > > not ok 1 - running krb5 tests > not ok 1 - running Python Cryptography tests > The python tests have been failing for a long while: https://github.com/openssl/openssl/issues/8968 Matt From matt at openssl.org Tue Jul 23 22:41:47 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Jul 2019 23:41:47 +0100 Subject: Two Travis Jobs are failing on master In-Reply-To: <20190723220328.GA9670@roeckx.be> References: <20190723220328.GA9670@roeckx.be> Message-ID: On 23/07/2019 23:03, Kurt Roeckx wrote: > On Tue, Jul 23, 2019 at 09:15:22PM +0000, Dr. Matthias St. Pierre wrote: >> It looks like currently two jobs of every travis build are failing on master, each with two different tests. >> Since this affect the builds of the pull requests, it would be nice if they could be fixed. Is anybody taking >> care of the problem already? > > Is is related to 9442? No...at least not as far as I know. 9442 came about because of a runchecker failure. > > Note that the failing tests are part of the extended tests, so we > don't see a problem during pull requests. Pull requests pass > without problems. > > It seems that we don't notice things even if master is broken for > a while, because they are only tested after they've been commited, > and it doesn't affect other pull requests. I wonder if we can > somehow get notificated of that. Travis and Appveyor both send notifications to openssl-commits. Matt From levitte at openssl.org Thu Jul 25 11:29:38 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 25 Jul 2019 13:29:38 +0200 Subject: Time off the next two weeks Message-ID: <87sgquuzbx.wl-levitte@openssl.org> I will take partial time off from Monday July 29th to the weekend after and full time off from Sunday August 4th to Thursday August 9th. Partial time off means that I might still spend a couple of hours daily on OpenSSL, as time allows. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Thu Jul 25 20:10:08 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 25 Jul 2019 22:10:08 +0200 Subject: Machine downtime tomorrow morning Message-ID: <87muh1vpsv.wl-levitte@openssl.org> I'm in the process of moving our VMs to a new volume with more space, which as running short in the current VM partition. Most of them are quite unremarkable, running services such as DNS and similar that's cached or not very visible to the outside world... those have already moved to the new volume today. However, two of the VMs are more noticable: our main git server / web server / ftp server and our mail server. I will move them to the new volume tomorrow morning anywhere between 08:00 and 10:00, Swedish time. The downtime will be somewhere around 30 minutes for each VM. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Thu Jul 25 20:13:23 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 25 Jul 2019 22:13:23 +0200 Subject: Planning for future downtime Message-ID: <87lfwlvpng.wl-levitte@openssl.org> Our main server, which hosts all our VMs, will need some maintenance some time soon. I plan to do this in the second half of August. Flag day will be announced after my time off. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Jul 26 07:52:25 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 26 Jul 2019 09:52:25 +0200 Subject: Machine downtime tomorrow morning In-Reply-To: <87muh1vpsv.wl-levitte@openssl.org> References: <87muh1vpsv.wl-levitte@openssl.org> Message-ID: <87ftmtutae.wl-levitte@openssl.org> Now done. It all went smoothly. Cheers, Richard ( your friendly sysadmin of the day ) On Thu, 25 Jul 2019 22:10:08 +0200, Richard Levitte wrote: > > I'm in the process of moving our VMs to a new volume with more space, > which as running short in the current VM partition. > > Most of them are quite unremarkable, running services such as DNS and > similar that's cached or not very visible to the outside world... > those have already moved to the new volume today. > > However, two of the VMs are more noticable: our main git server / web > server / ftp server and our mail server. I will move them to the new > volume tomorrow morning anywhere between 08:00 and 10:00, Swedish > time. The downtime will be somewhere around 30 minutes for each VM. > > Cheers, > Richard > > -- > 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 paul.dale at oracle.com Tue Jul 30 02:42:33 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 30 Jul 2019 12:42:33 +1000 Subject: Thread sanitiser problems Message-ID: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> Bringing the discussions over to the project list. The problem is initially mentioned in #9454. Followup issues with infinite recursion and use after free also get mentioned in #9455. These are addressed by #9477 which clears the flush flag before flushing and removes the dependence on the RAND call. Reproduction seems to require gcc-8, gcc-7 doesn?t have the appropriate thread sanitisation. Overly simplified, the problem boils down to the CTR DRBG needing an AES CTR cipher context to work. When creating the former, a recursive call is made to get the latter. A deadlock results due to a cycle in the locking. The RAND/DRBG code will not be the only place where this occurs. KDF, MAC and some public key operations will suffer a similar issue. This is almost certainly going to hurt moving forward. On to possible mitigations: 1. Make our locks recursive. Add a reference counter and a thread ID to the lock structure. There would be no need to make either use atomic operations. Getting a read lock after a write lock would be considered an extra write lock, handing a write lock while holding a read lock could be problematic. This seems very messy. 2. Return dependent algorithms as part of the registration process. The particular algorithm could be preloaded somehow. I?m not sure how ugly this will become but it will need names (nids) for each possible DRBG type. Thoughts anyone? Any better solutions? Any other solutions? Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From Matthias.St.Pierre at ncp-e.com Tue Jul 30 07:08:37 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 30 Jul 2019 09:08:37 +0200 Subject: Thread sanitiser problems In-Reply-To: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> Message-ID: On 30.07.19 04:42, Dr Paul Dale wrote: > Bringing the discussions over to the project list. That's a very good idea Pauli to bring this subject to a wider audience for discussion. I would like to take the opportunity to re-post? a general remark which I made in https://github.com/openssl/openssl/issues/9455#issuecomment-515340391 > I am convinced that issues #9454 and #9455 might be only the tip of an iceberg > and we shouldn't just narrow down our focus and fix them as isolated issues. > Instead, the @openssl/omc should take them as an indication that it might be > necessary to pause and rethink the rules for how and when the low level core > routines are allowed to utilize higer level crypto routines (like RAND_bytes()). > Also, locking rules might be necessary to prevent lock-order inversion (#9454 (comment)). > Or it might be necessary to simplify the design, e.g. by replacing the context lock > and the store lock by a single lock. > > There has been a lot of replumbing going on recently and we need to take care that > the overall structure of OpenSSL remains stable and manageable. The double and > recursive lock issues are an indicator that things have become more complicated > "under the hood" (or should I say more appropriately "under the washing stand"?) > The original OpenSSL 3.0.0 Design document is only a snapshot from the very beginning. > It has not changed recently, and it might be a good time now to explitly write down > all the changes and innovations which have taken place since then. Matthias From kurt at roeckx.be Tue Jul 30 09:59:40 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 30 Jul 2019 11:59:40 +0200 Subject: Thread sanitiser problems In-Reply-To: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> Message-ID: <20190730095938.GA7075@roeckx.be> On Tue, Jul 30, 2019 at 12:42:33PM +1000, Dr Paul Dale wrote: > Overly simplified, the problem boils down to the CTR DRBG needing an AES CTR cipher context to work. When creating the former, a recursive call is made to get the latter. I'm not sure what you mean with "CTR" both times. Are you saying that an AES requires a DRBG now? Kurt From Matthias.St.Pierre at ncp-e.com Tue Jul 30 10:41:16 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 30 Jul 2019 12:41:16 +0200 Subject: Thread sanitiser problems In-Reply-To: <20190730095938.GA7075@roeckx.be> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> <20190730095938.GA7075@roeckx.be> Message-ID: <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com> On 30.07.19 11:59, Kurt Roeckx wrote: > On Tue, Jul 30, 2019 at 12:42:33PM +1000, Dr Paul Dale wrote: >> Overly simplified, the problem boils down to the CTR DRBG needing an AES CTR cipher context to work. When creating the former, a recursive call is made to get the latter. > I'm not sure what you mean with "CTR" both times. > > Are you saying that an AES requires a DRBG now? > No. Pauli simply meant that the CTR DRBG utilizes an EVP_CIPHER_CTX for its internal implementation. (The original FIPS 2.0 implementation was based on low level crypto calls, but that was changed by you to EVP in commit https://github.com/openssl/openssl/commit/dbdcc04f27db70ac71748eb595ce23c9733afbe7 for performance reasons.) Matthias From kurt at roeckx.be Tue Jul 30 10:43:45 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 30 Jul 2019 12:43:45 +0200 Subject: Thread sanitiser problems In-Reply-To: <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> <20190730095938.GA7075@roeckx.be> <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com> Message-ID: <20190730104344.GA9041@roeckx.be> On Tue, Jul 30, 2019 at 12:41:16PM +0200, Matthias St. Pierre wrote: > On 30.07.19 11:59, Kurt Roeckx wrote: > > On Tue, Jul 30, 2019 at 12:42:33PM +1000, Dr Paul Dale wrote: > > > Overly simplified, the problem boils down to the CTR DRBG needing an AES CTR cipher context to work. When creating the former, a recursive call is made to get the latter. > > I'm not sure what you mean with "CTR" both times. > > > > Are you saying that an AES requires a DRBG now? > > > > No. Pauli simply meant that the CTR DRBG utilizes an EVP_CIPHER_CTX for its internal implementation. I currently fail to see how that's a problem, unless that EVP_CIPHER_CTX tries to use a DRBG. Kurt From Matthias.St.Pierre at ncp-e.com Tue Jul 30 10:47:51 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 30 Jul 2019 12:47:51 +0200 Subject: Thread sanitiser problems In-Reply-To: <20190730104344.GA9041@roeckx.be> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> <20190730095938.GA7075@roeckx.be> <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com> <20190730104344.GA9041@roeckx.be> Message-ID: <69cb9f0b-b1b6-8c7f-49ff-1ced2c9d7139@ncp-e.com> On 30.07.19 12:43, Kurt Roeckx wrote: > > I currently fail to see how that's a problem, unless that > EVP_CIPHER_CTX tries to use a DRBG. This is what I mean when I say that things have gotten more complicated under the hood due to the replumbing. To understand the problem, please take at a look of the sanitizer callstack in https://github.com/openssl/openssl/issues/9455 Matthias From Matthias.St.Pierre at ncp-e.com Tue Jul 30 10:52:10 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 30 Jul 2019 12:52:10 +0200 Subject: Thread sanitiser problems In-Reply-To: <69cb9f0b-b1b6-8c7f-49ff-1ced2c9d7139@ncp-e.com> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> <20190730095938.GA7075@roeckx.be> <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com> <20190730104344.GA9041@roeckx.be> <69cb9f0b-b1b6-8c7f-49ff-1ced2c9d7139@ncp-e.com> Message-ID: <855d4517-e226-f6b5-9f4f-f13689f53941@ncp-e.com> Sorry, my reply was misleading, since Pauli is talking mainly about #9454. Please take a look at the issue description https://github.com/openssl/openssl/issues/9454 instead. Matthias On 30.07.19 12:47, Matthias St. Pierre wrote: > > > On 30.07.19 12:43, Kurt Roeckx wrote: >> >> I currently fail to see how that's a problem, unless that >> EVP_CIPHER_CTX tries to use a DRBG. > > This is what I mean when I say that things have gotten more complicated under the hood > due to the replumbing. To understand the problem, please take at a look of the sanitizer > callstack in > > https://github.com/openssl/openssl/issues/9455 > > > Matthias > > > From rsalz at akamai.com Tue Jul 30 13:16:28 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 30 Jul 2019 13:16:28 +0000 Subject: Thread sanitiser problems In-Reply-To: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> Message-ID: <3C5A1A1A-0F83-496B-A25D-C26AA973B0A1@akamai.com> Do you need to hold the lock across dependant items? For example, why can't the DRBG code unlock before fetching the AES-CTR code? From openssl at openssl.org Tue Jul 30 14:27:56 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 30 Jul 2019 14:27:56 +0000 Subject: OpenSSL Security Advisory Message-ID: <20190730142756.GA5502@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [30 July 2019] ======================================== Windows builds with insecure path defaults (CVE-2019-1552) ========================================================== Severity: Low OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. The mitigations are found in these commits: - - For 1.1.1, commit 54aa9d51b09d67e90db443f682cface795f5af9e - - For 1.1.0, commit e32bc855a81a2d48d215c506bdeb4f598045f7e9 and b15a19c148384e73338aa7c5b12652138e35ed28 - - For 1.0.2, commit d333ebaf9c77332754a9d5e111e2f53e1de54fdd The 1.1.1 and 1.1.0 mitigation set more appropriate defaults for mingw, while the 1.0.2 mitigation documents the issue and provides enhanced examples. This issue was reported by Rich Mirth. The fix was developed by Richard Levitte from the OpenSSL development team. It was reported to OpenSSL on 9th Jun 2019. Note ===== OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end on 11th September 2019. Users of these versions should upgrade to OpenSSL 1.1.1. Referenses ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20190730.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl1AU3sACgkQ1enkP335 7oxnEw//ebb9FK16oXpvW6nifNgSHUBYRaq+3ApvSfGG8Er1M0Zn80iD/WY8wzM7 ZabUUNlOdnOs0iQivMYzy+8QzP9NRaqX2WZk/Q1koNT5WAt9+VDCw6hhbp6FN8B9 9aeRvdawNME9JPysl3KOR6DnYJQnpJgV0yQ2pJM2yMKNuDFkvy6E9ieMoWAGx5Ya 8JZ4KGFubA1vDPj5xowkRDxZo+SLdAaEMQw0YG8DWSK5BViZV+3d4OMAAL1RjnZy s4OSghqi7wUbgo8XO38/roN4y4BEgmEXU0IpSRNf1xrwCoFM82hEgOO3xWxPtbZk EtDcMUTtMYa1g5IMdGIkVvS4wnNr2j2BAi8WECkPf5QCzCoaX/Xc9jutslTw20M/ UoZnyGgVoOQCsO6ECwLUnSEp772mhS1056c4OKb62kfhlIcGkWi5vk5wjWVZFxEx rXJC7xabp29e051mnrJtLr85UWUv5B/ywREPyvbdjWg6lJBxB0dOYXMQLpJi6B5i /bDX7czP/1EeOg+FDSGOR174JGIyMYmPqpyzGpdds72GfOQqtGHC2z41FlvHMglB 9VobSZnF97MIan4/9H4ge+gUUq0PeIZ+invvgCHzuW4oYBOngwwVD5QXfSQUjA9a etYHkJx+3t4hPrPKAT/J0jHA7AbWtYK7dL6qTxSwli2Gl/D4ipk= =gxli -----END PGP SIGNATURE----- From paul.dale at oracle.com Wed Jul 31 02:02:46 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 31 Jul 2019 12:02:46 +1000 Subject: Thread sanitiser problems In-Reply-To: <855d4517-e226-f6b5-9f4f-f13689f53941@ncp-e.com> References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> <20190730095938.GA7075@roeckx.be> <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com> <20190730104344.GA9041@roeckx.be> <69cb9f0b-b1b6-8c7f-49ff-1ced2c9d7139@ncp-e.com> <855d4517-e226-f6b5-9f4f-f13689f53941@ncp-e.com> Message-ID: Yes, I?m mostly talking about #9454 here. #9455 is a bug (clearing the flush flag after flushing not before). The fix in #9477 addresses this and also removes the dependence on RAND_bytes. The #9454 description includes thread sanitisizer logs showing different lock orderings ? this has the potential to dead lock. Agreed with Rich that giving up the lock would make sense, but I don?t see a way for this to be easily done. That this also involves the RAND subsystem could be coincidental. The other stack trace is getting an MD via a digest operation (i.e. both traces are for algorithms that use other algorithms). The locks in question are the provider store lock and the context lock. crypto/context.c: OPENSSL_CTX *ctx; /* function argument */ CRYPTO_THREAD_read_lock(ctx->oncelock); crypto/provider_core.c: OPENSSL_CTX *ctx; /* function argument */ struct provider_store_st *store = get_provider_store(ctx); CRYPTO_THREAD_read_lock(store->lock); Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 30 Jul 2019, at 8:52 pm, Matthias St. Pierre wrote: > > Sorry, my reply was misleading, since Pauli is talking mainly about #9454. > Please take a look at the issue description > > https://github.com/openssl/openssl/issues/9454 > > instead. > > Matthias > > > > On 30.07.19 12:47, Matthias St. Pierre wrote: >> >> >> On 30.07.19 12:43, Kurt Roeckx wrote: >>> >>> I currently fail to see how that's a problem, unless that >>> EVP_CIPHER_CTX tries to use a DRBG. >> >> This is what I mean when I say that things have gotten more complicated under the hood >> due to the replumbing. To understand the problem, please take at a look of the sanitizer >> callstack in >> >> https://github.com/openssl/openssl/issues/9455 >> >> >> Matthias >> >> >> > From openssl-users at dukhovni.org Wed Jul 31 04:10:40 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 31 Jul 2019 00:10:40 -0400 Subject: Thread sanitiser problems In-Reply-To: References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com> <20190730095938.GA7075@roeckx.be> <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com> <20190730104344.GA9041@roeckx.be> <69cb9f0b-b1b6-8c7f-49ff-1ced2c9d7139@ncp-e.com> <855d4517-e226-f6b5-9f4f-f13689f53941@ncp-e.com> Message-ID: > On Jul 30, 2019, at 10:02 PM, Dr Paul Dale wrote: > > The #9454 description includes thread sanitisizer logs showing different lock orderings ? this has the potential to dead lock. Agreed with Rich that giving up the lock would make sense, but I don?t see a way for this to be easily done. My take is that we should never hold any lock long enough to even consider acquiring another lock. No more than one lock should be held at any one time, and only long enough to bump a reference count to ensure that the object of interest is no deallocated before we (or our caller in a "get1" type interface) is done with it. I don't know what "long-term" locks we're holding, but it would be great if it were possible to never (or never recursively) hold any such locks. -- Viktor.