From Matthias.St.Pierre at ncp-e.com Sun Sep 1 12:10:42 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 1 Sep 2019 12:10:42 +0000 Subject: GitHub issue template for general questions Message-ID: <1a09adab76db49469729d91d77e7b4b9@Ex13.ncp.local> Hi, I noticed that a lot of issues on GitHub containing general questions get tagged as a [bug], because the template list only gives the choice between two options, a *Bug Report* and a *Feature request*. (There is a third choice in tiny letters, which usually gets overlooked.) A recent example is https://github.com/openssl/openssl/issues/9743. For that reason, I would like to suggest adding a third template, which creates issues tagged as [question]: *Bug report* Report a defect in the software *Feature request* Propose a feature you would like to see added in the software *Question* Ask a general question about the software I am aware that this third category was probably omitted on purpose, because we would rather see those questions asked on the openssl-users mailing list, but the practice shows that user interaction on the mailing lists is fading and more and more user questions are being asked on GitHub. What do you think about the suggestion? Matthias From levitte at openssl.org Sun Sep 1 14:51:41 2019 From: levitte at openssl.org (Richard Levitte) Date: Sun, 01 Sep 2019 16:51:41 +0200 Subject: GitHub issue template for general questions In-Reply-To: <1a09adab76db49469729d91d77e7b4b9@Ex13.ncp.local> References: <1a09adab76db49469729d91d77e7b4b9@Ex13.ncp.local> Message-ID: <87mufoax36.wl-levitte@openssl.org> I don't remember why the generic template was made so small... So I think I would welcome a PR that does what you describe. Cheers, Richard On Sun, 01 Sep 2019 14:10:42 +0200, Dr. Matthias St. Pierre wrote: > > Hi, > > I noticed that a lot of issues on GitHub containing general questions get tagged as a [bug], > because the template list only gives the choice between two options, a *Bug Report* and > a *Feature request*. (There is a third choice in tiny letters, which usually gets overlooked.) > A recent example is https://github.com/openssl/openssl/issues/9743. > > For that reason, I would like to suggest adding a third template, which creates issues tagged > as [question]: > > *Bug report* > Report a defect in the software > *Feature request* > Propose a feature you would like to see added in the software > *Question* > Ask a general question about the software > > I am aware that this third category was probably omitted on purpose, because we would rather > see those questions asked on the openssl-users mailing list, but the practice shows that user > interaction on the mailing lists is fading and more and more user questions are being asked on > GitHub. What do you think about the suggestion? > > Matthias > > > > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Sun Sep 1 17:28:57 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 1 Sep 2019 17:28:57 +0000 Subject: AW: GitHub issue template for general questions In-Reply-To: <87mufoax36.wl-levitte@openssl.org> References: <1a09adab76db49469729d91d77e7b4b9@Ex13.ncp.local> <87mufoax36.wl-levitte@openssl.org> Message-ID: Ok, I'll try to come up with an issue template which manages the balancing act of facilitating questions on GitHub while still recommending the openssl-users mailing list for normal user questions. > -----Urspr?ngliche Nachricht----- > Von: Richard Levitte > Gesendet: Sonntag, 1. September 2019 16:52 > An: Dr. Matthias St. Pierre > Cc: openssl-project at openssl.org > Betreff: Re: GitHub issue template for general questions > > I don't remember why the generic template was made so small... So I > think I would welcome a PR that does what you describe. > > Cheers, > Richard From levitte at openssl.org Mon Sep 2 06:38:41 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 02 Sep 2019 08:38:41 +0200 Subject: Deprecation of stuff Message-ID: <87imqbb3ta.wl-levitte@openssl.org> The dispute in PR https://github.com/openssl/openssl/pull/7853 has made it quote obvious that we have some very different ideas on when and why we should or shouldn't deprecate stuff. What does deprecation mean? Essentially, it's a warning that at some point in the future, the deprecated functionality will be removed. I believe that part of the issue surrounding this is uncertainty about when that removal will happen, so let me just remind you what's written in our release strategy document: * No existing public interface can be removed until its replacement has been in place in an LTS stable release. The original interface must also have been documented as deprecated for at least 5 years. A public interface is any function, structure or macro declared in a public header file. Ref: https://www.openssl.org/policies/releasestrat.html I'd like to get this thread started with the following four questions, for as many of us to answer as possible: 1. Why should we deprecate stuff 2. Why should we not deprecate stuff 3. When should we deprecate stuff 4. When should we not deprecate stuff Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Sep 3 16:19:17 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Sep 2019 17:19:17 +0100 Subject: Forthcoming OpenSSL Releases Message-ID: The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t. These releases will be made available on 10th September 2019 between approximately 1200-1600 UTC. These are security fix releases. The highest severity security issue fixed by these releases is rated as LOW. Please note that this is expected to be the last release of 1.1.0 before it goes out of support on 11th September 2019. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From tmraz at redhat.com Wed Sep 4 12:43:34 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 04 Sep 2019 14:43:34 +0200 Subject: Deprecation of stuff In-Reply-To: <87imqbb3ta.wl-levitte@openssl.org> References: <87imqbb3ta.wl-levitte@openssl.org> Message-ID: <29dd8ca186d58bc20b90e3f29fbb98445f5ecd95.camel@redhat.com> On Mon, 2019-09-02 at 08:38 +0200, Richard Levitte wrote: > The dispute in PR https://github.com/openssl/openssl/pull/7853 has > made it quote obvious that we have some very different ideas on when > and why we should or shouldn't deprecate stuff. > > What does deprecation mean? Essentially, it's a warning that at some > point in the future, the deprecated functionality will be removed. I > believe that part of the issue surrounding this is uncertainty about > when that removal will happen, so let me just remind you what's > written in our release strategy document: > > * No existing public interface can be removed until its replacement > has been in place in an LTS stable release. The original > interface > must also have been documented as deprecated for at least 5 > years. > A public interface is any function, structure or macro declared > in > a public header file. > > Ref: https://www.openssl.org/policies/releasestrat.html > > I'd like to get this thread started with the following four > questions, > for as many of us to answer as possible: > > 1. Why should we deprecate stuff Because keeping every legacy API/feature/option/... increases the maintenance burden, attack surface, confuses users/developers, and in general hinders the development. > 2. Why should we not deprecate stuff If something does not really have an adequate replacement, it does not really increase the maintenance burden, does not significantly increase the attack surface, and is still used widely in applications, it should not be deprecated. > 3. When should we deprecate stuff As soon as possible when there is a better replacement for the stuff. I believe it is better to give the warning about future removal as soon as possible rather than to plan deprecating and later removing something anyway but delay the deprecation "to not scare someone early". > 4. When should we not deprecate stuff -- 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 openssl-users at dukhovni.org Wed Sep 4 12:59:22 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 4 Sep 2019 08:59:22 -0400 Subject: Deprecation of stuff In-Reply-To: <29dd8ca186d58bc20b90e3f29fbb98445f5ecd95.camel@redhat.com> References: <87imqbb3ta.wl-levitte@openssl.org> <29dd8ca186d58bc20b90e3f29fbb98445f5ecd95.camel@redhat.com> Message-ID: <20190904125922.GM70599@straasha.imrryr.org> On Wed, Sep 04, 2019 at 02:43:34PM +0200, Tomas Mraz wrote: > > The dispute in PR https://github.com/openssl/openssl/pull/7853 has > > made it quote obvious that we have some very different ideas on when > > and why we should or shouldn't deprecate stuff. > > > > What does deprecation mean? Essentially, it's a warning that at some > > point in the future, the deprecated functionality will be removed. I > > believe that part of the issue surrounding this is uncertainty about > > when that removal will happen, so let me just remind you what's > > written in our release strategy document: Actually, my issue was not timing, but whether the particular feature warrants eventual removal. I don't believe it does. > > 1. Why should we deprecate stuff > > Because keeping every legacy API/feature/option/... increases the > maintenance burden, attack surface, confuses users/developers, and in > general hinders the development. > > > 2. Why should we not deprecate stuff > > If something does not really have an adequate replacement, it does not > really increase the maintenance burden, does not significantly increase > the attack surface, and is still used widely in applications, it should > not be deprecated. This is essentially the basis of my objection, with less emphasis on "adequate replacement". Just because we *can* ask users to rewrite their code, does not mean we *should*. -- Viktor. From dwmw2 at infradead.org Wed Sep 4 14:15:48 2019 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 04 Sep 2019 15:15:48 +0100 Subject: Deprecation of stuff In-Reply-To: <87imqbb3ta.wl-levitte@openssl.org> References: <87imqbb3ta.wl-levitte@openssl.org> Message-ID: <598fd7e59930d5b75f1e241d09c2437a41ab2346.camel@infradead.org> On Mon, 2019-09-02 at 08:38 +0200, Richard Levitte wrote: > The dispute in PR https://github.com/openssl/openssl/pull/7853 has > made it quote obvious that we have some very different ideas on when > and why we should or shouldn't deprecate stuff. > > What does deprecation mean? Essentially, it's a warning that at some > point in the future, the deprecated functionality will be removed. I > believe that part of the issue surrounding this is uncertainty about > when that removal will happen, so let me just remind you what's > written in our release strategy document: > > * No existing public interface can be removed until its replacement > has been in place in an LTS stable release. The original interface > must also have been documented as deprecated for at least 5 years. > A public interface is any function, structure or macro declared in > a public header file. > > Ref: https://www.openssl.org/policies/releasestrat.html > > I'd like to get this thread started with the following four questions, > for as many of us to answer as possible: > > 1. Why should we deprecate stuff > > 2. Why should we not deprecate stuff > > 3. When should we deprecate stuff > > 4. When should we not deprecate stuff > > Cheers, (I know -project won't accept my mail; you can choose to include it in a reply if you see fit). I'd note that the question of *versioning* mechanisms is a very very special case of "when to deprecate stuff". So much so as to almost make it a completely separate question altogether. My own favourite application is littered with checks on OPENSSL_VERSION_NUMBER, and the occasional call to SSLeay() to check for things that were fixed at runtime without an ABI change. http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl-dtls.c A change to the versioning scheme is very much more than just another thing that's been deprecated; it's a change to the very mechanism by which we handle those deprecations. Changing that (and by extension, rapidly deprecating it) requires a lot more work on the part of application authors who want their code to build against whatever version of OpenSSL may be present on the platforms they need to support. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5174 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Sep 4 15:01:54 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 4 Sep 2019 11:01:54 -0400 Subject: Deprecation of stuff In-Reply-To: <598fd7e59930d5b75f1e241d09c2437a41ab2346.camel@infradead.org> References: <87imqbb3ta.wl-levitte@openssl.org> <598fd7e59930d5b75f1e241d09c2437a41ab2346.camel@infradead.org> Message-ID: <218C7EDB-539F-4B12-9054-72731B21859C@dukhovni.org> +1 (and more) to the below! > On Sep 4, 2019, at 10:15 AM, David Woodhouse wrote: > > I'd note that the question of *versioning* mechanisms is a very very > special case of "when to deprecate stuff". So much so as to almost make > it a completely separate question altogether. > > My own favourite application is littered with checks on > OPENSSL_VERSION_NUMBER, and the occasional call to SSLeay() to check > for things that were fixed at runtime without an ABI change. > > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl-dtls.c > > A change to the versioning scheme is very much more than just another > thing that's been deprecated; it's a change to the very mechanism by > which we handle those deprecations. Changing that (and by extension, > rapidly deprecating it) requires a lot more work on the part of > application authors who want their code to build against whatever > version of OpenSSL may be present on the platforms they need to > support. -- Viktor. From matt at openssl.org Fri Sep 6 10:12:59 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 6 Sep 2019 11:12:59 +0100 Subject: Monthly Status Report (August) Message-ID: <85abca01-c6f7-d4d6-7735-ab473e71cf0a@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Fixed an SSL_MODE_RELEASE_BUFFERS bug - Added documentation for the provider Key Exchange operation - Modified evp_test to run the cipher and digest test files in FIPS mode - Fixed a bug in the ECDSA_SIG docs - Fixed a bug in BN error reporting - Fixed no-ec - Fixed no-filenames - Fixed enable-ec_nistp_64_gcc_128 - Fixed an OPENSSL_init_crypto deadlock (which fixed no-engine) - Fixed a bug to ensure that RSA PSS correctly returns the right default digest - Proposed a solution to verify that an EVP_CIPHER_CTX_set_key_length() call has worked (ongoing) - Fixed bug to ensure that if we are multiblock capable we actually use that capability - Fixed problems with OPENSSL_CTX locking - Fixed a documentation bug in ec.h - Fixed no-ec (again) - Fixed no-poly1305, no-siphash and no-blake2 - Fixed no-cmac - Fixed no-des - Fixed no-engine (again) - Updated the fuzz README to document the new "no-module" requirement - also made associated updates in run-checker to provide no-module where appropriate - Investigated reported failure in DESX - Fixed a bug in pkeyutl -verifyrecover Matt From matt at openssl.org Mon Sep 9 15:31:05 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 9 Sep 2019 16:31:05 +0100 Subject: Repo Frozen Message-ID: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> Richard has just frozen the repo in advance of the releases tomorrow. There are still some PRs outstanding that we are expecting to be included and I will push as they become available: https://github.com/openssl/openssl/pull/9777 Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey Awaiting an update from Bernd https://github.com/openssl/openssl/pull/9802 drbg: ensure fork-safety [1.1.1] Approved, but awaiting input from Kurt https://github.com/openssl/openssl/pull/9811 [1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters Not sure if Nicola wanted to do a final update, but otherwise its approved and ready to go. There will also be some CHANGES/NEWS type updates required Matt From bernd.edlinger at hotmail.de Mon Sep 9 16:33:12 2019 From: bernd.edlinger at hotmail.de (Bernd Edlinger) Date: Mon, 9 Sep 2019 16:33:12 +0000 Subject: Repo Frozen In-Reply-To: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> References: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> Message-ID: On 9/9/19 5:31 PM, Matt Caswell wrote: > Richard has just frozen the repo in advance of the releases tomorrow. > > There are still some PRs outstanding that we are expecting to be included and I > will push as they become available: > > > https://github.com/openssl/openssl/pull/9777 > Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey > > Awaiting an update from Bernd > Done. I have yet another PR, which is needed for 1.1.1 https://github.com/openssl/openssl/pull/9687 Fix a potential crash in rand_unix.c Initially it was just a strict-warning issue, then in the review we found a potential crash which can happen after the entropy buffer grow patch was added, which makes this a regression introduced after 1.1.1c. Bernd. > > https://github.com/openssl/openssl/pull/9802 > drbg: ensure fork-safety [1.1.1] > > Approved, but awaiting input from Kurt > > > https://github.com/openssl/openssl/pull/9811 > [1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters > > Not sure if Nicola wanted to do a final update, but otherwise its approved and > ready to go. > > > There will also be some CHANGES/NEWS type updates required > > > Matt > > From matt at openssl.org Tue Sep 10 16:16:50 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Sep 2019 17:16:50 +0100 Subject: Forthcoming OpenSSL Releases In-Reply-To: References: Message-ID: <071f6901-1706-9c23-e626-3c11d19615ab@openssl.org> On 03/09/2019 17:19, Matt Caswell wrote: > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t. > > These releases will be made available on 10th September 2019 between > approximately 1200-1600 UTC. > > These are security fix releases. The highest severity security issue fixed by > these releases is rated as LOW. > > Please note that this is expected to be the last release of 1.1.0 before it goes > out of support on 11th September 2019. We have encountered some technical problems pushing these releases onto the website today. Until those are resolved the release tarballs are not visible via the standard links. The releases are temporarily available at this non-standard location: https://www.openssl.org/source/? You can download them directly from there until such time as we fix the website. We will send out the normal release announcements as soon as everything is working normally again. Regards Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From openssl at openssl.org Tue Sep 10 16:18:55 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 10 Sep 2019 16:18:55 +0000 Subject: OpenSSL Security Advisory Message-ID: <20190910161855.GA17572@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [10 September 2019] ============================================= ECDSA remote timing attack (CVE-2019-1547) ========================================== Severity: Low Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. OpenSSL 1.1.1 users should upgrade to 1.1.1d OpenSSL 1.1.0 users should upgrade to 1.1.0l OpenSSL 1.0.2 users should upgrade to 1.0.2t This issue was reported by Cesar Pereida Garc?a, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley. The fix was developed by Billy Brumley. It was reported to OpenSSL on 5th August 2019. Fork Protection (CVE-2019-1549) =============================== Severity: Low OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. OpenSSL version 1.1.1 is affected by this issue. OpenSSL 1.1.1 users should upgrade to 1.1.1d This issue was reported by Matt Caswell. The fix was developed by Matthias St. Pierre. It was reported to OpenSSL on 27th May 2019. Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (CVE-2019-1563) ============================================================================ Severity: Low In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. OpenSSL 1.1.1 users should upgrade to 1.1.1d OpenSSL 1.1.0 users should upgrade to 1.1.0l OpenSSL 1.0.2 users should upgrade to 1.0.2t This issue was reported by and the fix developed by Bernd Edlinger. It was reported to OpenSSL on 21st August 2019. Note ===== OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 ends on 11th September 2019 so 1.1.0l is expected to be the last 1.1.0 release. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20190910.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----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13vK0ACgkQ2cTSbQ5g RJGJIgf+Me900bLV9TrVDWvNRQbuRe0tOPPhP59J4tJAJiRZ1GG0JV2YITQynjTP hrz9mvajgWbkGYlTZmPVFOdJr7LKbrUrxk7shEfXqmiiCLG8tHYiCe3PF+/Cy7gA X1vY9CDfv//3VSqOLM9RM3CCcWAAv3KeP851X0PgCiMVvGAJbYOu3bmB+KsEKFzm fWRDabUMbl1KCSgCIvvlNv0bKR/GfpW3cWruUvG0sfjyPWwS+yn8z0T3/ibFJqkb Cmuqa3/kC9uZg8AhiODR+nz6D1mC2UiNZ2Wa/XO6O68rO/y3ZKbaiMGLze1qJep5 3PnybOw8b3JvpVRFYw09YwgLObBX8w== =8bP1 -----END PGP SIGNATURE----- From matt at openssl.org Tue Sep 10 16:27:57 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Sep 2019 17:27:57 +0100 Subject: Repo Frozen In-Reply-To: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> References: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> Message-ID: <4b083a5f-fbc2-90ce-c88e-efb7cc099a44@openssl.org> Release is semi complete and repo is unfrozen. Matt On 09/09/2019 16:31, Matt Caswell wrote: > Richard has just frozen the repo in advance of the releases tomorrow. > > There are still some PRs outstanding that we are expecting to be included and I > will push as they become available: > > > https://github.com/openssl/openssl/pull/9777 > Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey > > Awaiting an update from Bernd > > > https://github.com/openssl/openssl/pull/9802 > drbg: ensure fork-safety [1.1.1] > > Approved, but awaiting input from Kurt > > > https://github.com/openssl/openssl/pull/9811 > [1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters > > Not sure if Nicola wanted to do a final update, but otherwise its approved and > ready to go. > > > There will also be some CHANGES/NEWS type updates required > > > Matt > > From bernd.edlinger at hotmail.de Tue Sep 10 16:54:10 2019 From: bernd.edlinger at hotmail.de (Bernd Edlinger) Date: Tue, 10 Sep 2019 16:54:10 +0000 Subject: Repo Frozen In-Reply-To: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> References: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> Message-ID: will we release today? On 9/9/19 5:31 PM, Matt Caswell wrote: > Richard has just frozen the repo in advance of the releases tomorrow. > > There are still some PRs outstanding that we are expecting to be included and I > will push as they become available: > > > https://github.com/openssl/openssl/pull/9777 > Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey > > Awaiting an update from Bernd > > > https://github.com/openssl/openssl/pull/9802 > drbg: ensure fork-safety [1.1.1] > > Approved, but awaiting input from Kurt > > > https://github.com/openssl/openssl/pull/9811 > [1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters > > Not sure if Nicola wanted to do a final update, but otherwise its approved and > ready to go. > > > There will also be some CHANGES/NEWS type updates required > > > Matt > > From matt at openssl.org Tue Sep 10 17:42:22 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Sep 2019 18:42:22 +0100 Subject: Repo Frozen In-Reply-To: References: <1b424f74-8951-44f1-3aca-4b1f4b937c40@openssl.org> Message-ID: <34153833-a400-e0a9-ea17-311b3aa17635@openssl.org> As per my earlier email - the release is done and the repo is unfrozen. We are unable to update the website at the moment due to a technical problem. But I have sent a link out to openssl-project/users/announce where you can temporarily download the tarballs from until we fix the issue. Matt On 10/09/2019 17:54, Bernd Edlinger wrote: > will we release today? > > On 9/9/19 5:31 PM, Matt Caswell wrote: >> Richard has just frozen the repo in advance of the releases tomorrow. >> >> There are still some PRs outstanding that we are expecting to be included and I >> will push as they become available: >> >> >> https://github.com/openssl/openssl/pull/9777 >> Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey >> >> Awaiting an update from Bernd >> >> >> https://github.com/openssl/openssl/pull/9802 >> drbg: ensure fork-safety [1.1.1] >> >> Approved, but awaiting input from Kurt >> >> >> https://github.com/openssl/openssl/pull/9811 >> [1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters >> >> Not sure if Nicola wanted to do a final update, but otherwise its approved and >> ready to go. >> >> >> There will also be some CHANGES/NEWS type updates required >> >> >> Matt >> >> From openssl at openssl.org Wed Sep 11 15:23:15 2019 From: openssl at openssl.org (OpenSSL) Date: Wed, 11 Sep 2019 15:23:15 +0000 Subject: OpenSSL version 1.0.2t published Message-ID: <20190911152315.GA21928@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.0.2t released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2t of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2t is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2t.tar.gz Size: 5355422 SHA1 checksum: 8ac3fd379cf8c8ef570abb51ec52a88fd526f88a SHA256 checksum: 14cb464efe7ac6b54799b34456bd69558a749a4931ecfd9cf9f71d7881cac7bc The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2t.tar.gz openssl sha256 openssl-1.0.2t.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13pssACgkQ2cTSbQ5g RJFr9wf/X0fke/exS13hQb4h9RqE9fYouVbSNKTKhLp9X8BtYUOtUTjO5ispKt+1 BGWBotApoXBTopOsdJVXhzLtYst2YdKEtvyJAEFyxfpJa2PL4jmo5zxk93qWjDjA u0HXR1Tu4XTLlE3EfqbfV/8bVO4kntTCk/xvg0gql1LUCVIRtjmqmsKOe7MJAHkH 94yb3kRFMpXb2YB6/zrK+ZuruL5ejTZCcXG7Dx9+LH5X7E/8KFDknk0Zo6w6970I LbrXjtAOfHtVEK5XAFESCkMkjNqahopOs90AtemiOt1oOsNztjr7bVFHqJ3/oBMf OYamiO1W2IhyxnPbet6zUDYG0FtYpw== =sBvh -----END PGP SIGNATURE----- From openssl at openssl.org Wed Sep 11 15:23:33 2019 From: openssl at openssl.org (OpenSSL) Date: Wed, 11 Sep 2019 15:23:33 +0000 Subject: OpenSSL version 1.1.0l published Message-ID: <20190911152333.GA21951@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.0l released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0l of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0l is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0l.tar.gz Size: 5294857 SHA1 checksum: 6e3507b29e2630f56023887d1f7d7ba1f584819b SHA256 checksum: 74a2f756c64fd7386a29184dc0344f4831192d61dc2481a93a4c5dd727f41148 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0l.tar.gz openssl sha256 openssl-1.1.0l.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13okkACgkQ2cTSbQ5g RJFu5wf9HCvluEc1W1UwNqaw48n3g1ZclRdexYFO12HtUTTtriUwu0BPorvzHVmo x4I0JzUxLeRXyS2kdBBPJC0OlPlrZMkWfwNy9IF2BRFGcMuGhjIOu60FfRNkGOM8 63RdIuSy1oPnwL4kUOdQi4pru1UcQVx25l4tpB6pLMKKgioGc1x75mP+C/lxhM16 PvPSo8pETU60V2QFaxzbfOqbS8LJhbO2m+dYCzgGy6Rjrd2CyzyZbtKC/bWoyMhW s3jQ4oBjGh28y/mrzLup9oXP4f4/GlWajxd+pFXsj8xRfwEN7Zwg7eLlg6uZh6Cq 4KhsFKHIKgvba/lekhASdh71BdVVSA== =na1Q -----END PGP SIGNATURE----- From openssl at openssl.org Wed Sep 11 15:23:50 2019 From: openssl at openssl.org (OpenSSL) Date: Wed, 11 Sep 2019 15:23:50 +0000 Subject: OpenSSL version 1.1.1d published Message-ID: <20190911152350.GA22068@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1d released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1d of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1d is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1d.tar.gz Size: 8845861 SHA1 checksum: 056057782325134b76d1931c48f2c7e6595d7ef4 SHA256 checksum: 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1d.tar.gz openssl sha256 openssl-1.1.1d.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13oWoACgkQ2cTSbQ5g RJFGjwf+IA34TBZZt/lwjtsALggJuoRrYyCBCDbdwJA+rBO2uQV2h+f7Tj5FBcuI ARRhbUJqCDq7MFl1+6O5jPhTxZK0P1z242rOTvW50w4MFy+FZCwZjloxRBtgOlTy y4t7yzuvCU1RidKiK9B42a6KypgQFEEHSlCkepNAjX94OLQhB+iF20vJ86gSFzrv keJTUDXEbAa7I9MyK9p7SQbqHgFbTt0QAIYj/afNGOGv6ZyjiVrbp+4I29I0IG98 Dn4+4dp0xaY+oC1FTyO+lqfTLXuSnVR8TGDACHFyeQHCjf6wfSbFlxfH40CfeQzv 8vakK0+YhIAij7Pcm4te9ffUaSeNHg== =jsdh -----END PGP SIGNATURE----- From levitte at openssl.org Tue Sep 17 05:49:53 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 17 Sep 2019 07:49:53 +0200 Subject: Being socially aware Message-ID: <87zhj3h3pa.wl-levitte@openssl.org> ... or how our usual style of dispute can sometimes deter help from the community. https://github.com/openssl/openssl/pull/9912 In this PR, there's a lot of discussions going on, a bit back an forth, about the right way to do things, and what does what like what other thing and so on. This is often our modus operandi, and it has often given us pretty good quality code (or at least, so we hope), even though it can be a bit exhausting at times. I would like to emphasise that I think this is absolutely fine... when it's among us who have been along for a bit, perhaps have come to know each other a bit more and have some kind of sense of our respective strengths and weaknesses, or even with someone that has shown they can handle this type of discussion. However, in pull requests like the one cited, where the associated issue is marked "good first issue", and the author has done quite well what was asked from the issue, it can be quite unexpected, not to say overwhelming to be met with this discussion style that could be seen as getting out of proportion. A "good first issue" is supposed to be a bite size thing after all, and I fear that if this is how we welcome new contributors, they might more often than not choose to step away from it all. So maybe let's be a little more careful with contributions for "good first issue" and potential newcomers, yeah? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Tue Sep 17 06:07:11 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 17 Sep 2019 16:07:11 +1000 Subject: Being socially aware In-Reply-To: <87zhj3h3pa.wl-levitte@openssl.org> References: <87zhj3h3pa.wl-levitte@openssl.org> Message-ID: I?m not disputing the great effort put into this. My dispute is that it should be under the openssl list command?.. I agree, this shouldn?t have been a ?good first issue?. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 17 Sep 2019, at 3:49 pm, Richard Levitte wrote: > > ... or how our usual style of dispute can sometimes deter help from > the community. > > https://github.com/openssl/openssl/pull/9912 > > In this PR, there's a lot of discussions going on, a bit back an > forth, about the right way to do things, and what does what like what > other thing and so on. > > This is often our modus operandi, and it has often given us pretty > good quality code (or at least, so we hope), even though it can be a > bit exhausting at times. > > I would like to emphasise that I think this is absolutely fine... > when it's among us who have been along for a bit, perhaps have come to > know each other a bit more and have some kind of sense of our > respective strengths and weaknesses, or even with someone that has > shown they can handle this type of discussion. > > However, in pull requests like the one cited, where the associated > issue is marked "good first issue", and the author has done quite well > what was asked from the issue, it can be quite unexpected, not to say > overwhelming to be met with this discussion style that could be seen > as getting out of proportion. A "good first issue" is supposed to be > a bite size thing after all, and I fear that if this is how we welcome > new contributors, they might more often than not choose to step away > from it all. > > So maybe let's be a little more careful with contributions for "good > first issue" and potential newcomers, yeah? > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Tue Sep 17 07:04:21 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 17 Sep 2019 07:04:21 +0000 Subject: AW: Being socially aware In-Reply-To: <87zhj3h3pa.wl-levitte@openssl.org> References: <87zhj3h3pa.wl-levitte@openssl.org> Message-ID: <1e3637be864a4a268f3415366115f69e@Ex13.ncp.local> I appreciate your concerns Richard, but I believe they are unwarranted in this case fortunately. First, my impression is that the discussion between was objective all the time and far from being heated up with emotions. Second, looking at the profile of the contributor, one can assert that he might be relatively new to our project, but he is certainly experienced in Open Source development. So I wouldn't worry too much about his feelings ? Regards, Matthias From levitte at openssl.org Tue Sep 17 07:53:04 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 17 Sep 2019 09:53:04 +0200 Subject: AW: Being socially aware In-Reply-To: <1e3637be864a4a268f3415366115f69e@Ex13.ncp.local> References: <87zhj3h3pa.wl-levitte@openssl.org> <1e3637be864a4a268f3415366115f69e@Ex13.ncp.local> Message-ID: <87sgovgxzz.wl-levitte@openssl.org> You forget that this is done in public, i.e. others are looking at how we treat those who do come forward and submit code to some bite size issue. So while @agnosticdev may have enough skin on his nose, onlookers that are considering whether they should contribute may not. On Tue, 17 Sep 2019 09:04:21 +0200, Dr. Matthias St. Pierre wrote: > > I appreciate your concerns Richard, but I believe they are unwarranted in this > case fortunately. > > First, my impression is that the discussion between was objective all the time > and far from being heated up with emotions. > > Second, looking at the profile of the contributor, one can assert that he might > be relatively new to our project, but he is certainly experienced in Open Source > development. So I wouldn't worry too much about his feelings ? > > Regards, > Matthias > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaishen.yy at alipay.com Tue Sep 17 09:01:53 2019 From: kaishen.yy at alipay.com (Paul Yang) Date: Tue, 17 Sep 2019 17:01:53 +0800 Subject: Being socially aware In-Reply-To: <87sgovgxzz.wl-levitte@openssl.org> References: <87zhj3h3pa.wl-levitte@openssl.org> <1e3637be864a4a268f3415366115f69e@Ex13.ncp.local> <87sgovgxzz.wl-levitte@openssl.org> Message-ID: <467AF830-AFD5-44BD-8843-449BBD2DBC10@alipay.com> I think this highly depends on a person?s character - sensitive or insensitive for instance. Communicating online makes it even harder to know one?s emotion behind the screens/comments. I am kinda agree with Richard that the issues with label "good first issue? could be treated a little more cautious to encourage more new contributors - suppose passing the regular review process of course. > On Sep 17, 2019, at 3:53 PM, Richard Levitte wrote: > > You forget that this is done in public, i.e. others are looking at how > we treat those who do come forward and submit code to some bite size > issue. So while @agnosticdev may have enough skin on his nose, > onlookers that are considering whether they should contribute may not. > > On Tue, 17 Sep 2019 09:04:21 +0200, > Dr. Matthias St. Pierre wrote: >> >> I appreciate your concerns Richard, but I believe they are unwarranted in this >> case fortunately. >> >> First, my impression is that the discussion between was objective all the time >> and far from being heated up with emotions. >> >> Second, looking at the profile of the contributor, one can assert that he might >> be relatively new to our project, but he is certainly experienced in Open Source >> development. So I wouldn't worry too much about his feelings ? >> >> Regards, >> Matthias >> > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ Regards, Paul Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Matthias.St.Pierre at ncp-e.com Tue Sep 17 10:20:54 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 17 Sep 2019 10:20:54 +0000 Subject: AW: Being socially aware In-Reply-To: References: <87zhj3h3pa.wl-levitte@openssl.org> Message-ID: <19ff6c415e8b458fa15a2f2de2656036@Ex13.ncp.local> > I agree, this shouldn?t have been a ?good first issue?. You might be right, but in hindsight it?s always easier to judge. In advance it was not at all obvious to me at all that this pull request would be discussed so controversially. For me, the task had all properties which in my view make it a good first issue: - There was an issue report about a missing feature https://github.com/openssl/openssl/issues/9880 - The task was straight forward and had the right size. Also, there was a precedence in the code. So instead of rushing towards an own solution, I took the time to describe an outline of a possible implementation, because I like the idea behind the [good first issue] tag, which is to lower the bar for new contributors. Personally, I don?t think that a lively discussion is discouraging per se. Discussing about solutions and convincing others is an important aspect of open source development, which one can start learning from the very first pull request. Criticism is only harmful if it is carried out with a negative attitude. But recalling my own experience as a beginner, I can say that this was never the case. I always experienced the OpenSSL community as very positive and welcoming to newcomers, and feedback was always constructive. Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Amit.Kliger at cyberark.com Thu Sep 19 13:51:23 2019 From: Amit.Kliger at cyberark.com (Amit Kliger) Date: Thu, 19 Sep 2019 13:51:23 +0000 Subject: OpenSSL version 3.0.0 release Message-ID: Hi all, I wanted to ask if the plan (mentioned here: https://www.openssl.org/blog/blog/2018/09/25/fips/) to release OpenSSL version 3.0 and its FIPS 140-2 validated module, before EOY 2019 is progressing as expected, or should we expect a delay for that release? As you probably all know, this is especially important for FIPS 140-2 compliance, as the 1.0.2 branch is currently still the newest branch that supports compilation with a compliant FIPS 140-2 module, but this branch will stop getting security patches by the end of the year, as far as I understand it. Regards, Amit ---------------------------------------------------------------------- _______________________________________________ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Sep 19 14:18:02 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 19 Sep 2019 15:18:02 +0100 Subject: OpenSSL version 3.0.0 release In-Reply-To: References: Message-ID: <37e1afbf-8c80-a061-9ae1-7e6001fb139c@openssl.org> On 19/09/2019 14:51, Amit Kliger wrote: > Hi all, > > ? > > I wanted to ask if the plan (mentioned here: > https://www.openssl.org/blog/blog/2018/09/25/fips/) to release OpenSSL version > 3.0 and its FIPS 140-2 validated module, before EOY 2019 is progressing as > expected, or should we expect a delay for that release? The last public timeline that we communicated on this was: - Code complete by the end of the year - Lab testing commences after that - Hoping to have an OpenSSL 3.0 release early Q2 2020 - FIPS validation of the 3.0 release (i.e. the paperwork) may happen sometime after that Matt > As you probably all know, this is especially important for FIPS 140-2 > compliance, as the 1.0.2 branch is currently still the newest branch that > supports compilation with a compliant FIPS 140-2 module, but this branch will > stop getting security patches by the end of the year, as far as I understand it. > > ? > > Regards, > > Amit > > -------------------------------------------------------------------------------- > _______________________________________________ > This e-mail may contain information that is confidential, privileged or > otherwise protected from disclosure. > If you are not an intended recipient of this e-mail, do not duplicate or > redistribute it by any means. Please delete it and any attachments and notify > the sender that you have received it in error. From paul.dale at oracle.com Tue Sep 24 00:17:47 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 24 Sep 2019 10:17:47 +1000 Subject: RAND, FIPS and providers Message-ID: This started in #9954, the topic of RAND being used by the legacy provider came up (in the context of DES). The abridged version is: * @levitte suggested the possibility of making RAND detachable. * I noted that this was desirable and in fact necessary for FIPS. * @mattcaswell added that the DRBGs and seeding is available inside the FIPS provider. That the FIPS provider includes a copy of the relevant RAND files, means it can satisfy internal requests for random numbers. However, external entities (TLS stack, user applications) won?t git FIPS approved random numbers. I can?t see currently an alternative to making the RAND functionality fetchable. I also suspect it will need to be per library context which might interfere with the per thread DRBGs we?re using. As for what to fetch: the DRBG instances and the seed material source would be ideal, although we don?t need the seed source for FIPS (so long as the DRBGs seed from inside their own provider). Thoughts or input anyone? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia From matt at openssl.org Tue Sep 24 08:32:32 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Sep 2019 09:32:32 +0100 Subject: RAND, FIPS and providers In-Reply-To: References: Message-ID: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> On 24/09/2019 01:17, Dr Paul Dale wrote: > This started in #9954, the topic of RAND being used by the legacy provider came up (in the context of DES). The abridged version is: > > * @levitte suggested the possibility of making RAND detachable. > * I noted that this was desirable and in fact necessary for FIPS. > * @mattcaswell added that the DRBGs and seeding is available inside the FIPS provider. > > > That the FIPS provider includes a copy of the relevant RAND files, means it can satisfy internal requests for random numbers. > However, external entities (TLS stack, user applications) won?t git FIPS approved random numbers. > > I can?t see currently an alternative to making the RAND functionality fetchable. I think making RAND fetchable is highly desirable and should be done (I had always assumed we would do this). > I also suspect it will need to be per library context which might interfere with the per thread DRBGs we?re using. I see no problems here. The RAND code is already library context aware. You get per thread DRBGs for each OPENSSL_CTX. For example calling OPENSSL_CTX_get0_private_drbg() will get you the private DRBG for the current thread in the specified OPENSSL_CTX. RAND_DRBG_get0_private() does the same thing for the default OPENSSL_CTX. > As for what to fetch: the DRBG instances and the seed material source would be ideal, although we don?t need the seed source for FIPS (so long as the DRBGs seed from inside their own provider). I had always assumed we would fetch DRBG instances. Matt > > > Thoughts or input anyone? > > > Pauli > From Matthias.St.Pierre at ncp-e.com Tue Sep 24 08:58:17 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 24 Sep 2019 10:58:17 +0200 Subject: RAND, FIPS and providers In-Reply-To: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> References: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> Message-ID: <6e2e69f6-a7f7-d45b-4d8d-c306e9d6970d@ncp-e.com> >> As for what to fetch: the DRBG instances and the seed material source would be ideal, although we don?t need the seed source for FIPS (so long as the DRBGs seed from inside their own provider). > I had always assumed we would fetch DRBG instances. > > Matt It would also make sense to make the entropy sources themselves fetchable and configurable.? This would enable us to - separate FIPS and non-FIPS entropy sources (using the 'fips' attribute) - make the entropy search policy configurable via config file (search order, blocking vs. non-blocking, ...) and it would also enable third party providers to plug in their (FIPS certified) hardware modules as entropy sources. In this context it might help to revisit Pauli's long standing and still unresolved issue #4394: - Multiple entropy source handling - https://github.com/openssl/openssl/issues/4394 Matthias From Matthias.St.Pierre at ncp-e.com Tue Sep 24 09:17:53 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 24 Sep 2019 11:17:53 +0200 Subject: RAND, FIPS and providers In-Reply-To: <6e2e69f6-a7f7-d45b-4d8d-c306e9d6970d@ncp-e.com> References: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> <6e2e69f6-a7f7-d45b-4d8d-c306e9d6970d@ncp-e.com> Message-ID: <890d3106-4aa0-a450-9cd7-2f2f2401cfaf@ncp-e.com> On 24.09.19 10:58, Matthias St. Pierre wrote: > It would also make sense to make the entropy sources themselves fetchable and configurable.? This would enable us to > > - separate FIPS and non-FIPS entropy sources (using the 'fips' attribute) This concept would also enable us to ensure that FIPS DRBGs can only seed from FIPS entropy sources, without having to hardcode the list of approved entropy sources. Matthias From matt at openssl.org Tue Sep 24 09:20:26 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Sep 2019 10:20:26 +0100 Subject: RAND, FIPS and providers In-Reply-To: <890d3106-4aa0-a450-9cd7-2f2f2401cfaf@ncp-e.com> References: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> <6e2e69f6-a7f7-d45b-4d8d-c306e9d6970d@ncp-e.com> <890d3106-4aa0-a450-9cd7-2f2f2401cfaf@ncp-e.com> Message-ID: <7372f54c-e86f-2224-6ac9-26b04691cd04@openssl.org> On 24/09/2019 10:17, Matthias St. Pierre wrote: > > On 24.09.19 10:58, Matthias St. Pierre wrote: >> It would also make sense to make the entropy sources themselves fetchable and >> configurable.? This would enable us to >> >> - separate FIPS and non-FIPS entropy sources (using the 'fips' attribute) > > This concept would also enable us to ensure that FIPS DRBGs can only seed from > FIPS entropy sources, without having to > hardcode the list of approved entropy sources. It's not quite as simple as that. Although allowed by FIPS standards, we made the simplifying assumption that our FIPS module would never fetch or use algorithms external to its own boundary. This is physically not possible in the FIPS module as it stands today. Matt From rsalz at akamai.com Tue Sep 24 11:43:17 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Sep 2019 11:43:17 +0000 Subject: RAND, FIPS and providers In-Reply-To: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> References: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> Message-ID: FWIW, I agree with Matt's points. From paul.dale at oracle.com Wed Sep 25 01:37:39 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 25 Sep 2019 11:37:39 +1000 Subject: RAND, FIPS and providers In-Reply-To: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> References: <83e84aca-3f15-cc88-4663-b23ad3e362dc@openssl.org> Message-ID: Matt, thanks for the clarification. I?ve looked at the DRBG setup code dozens of times and it never clicked. It seems we?re down to making the DRBGs and, perhaps, the seed source available using fetch. That doesn?t seem anything like as difficult. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Sep 2019, at 6:32 pm, Matt Caswell wrote: > > > > On 24/09/2019 01:17, Dr Paul Dale wrote: >> This started in #9954, the topic of RAND being used by the legacy provider came up (in the context of DES). The abridged version is: >> >> * @levitte suggested the possibility of making RAND detachable. >> * I noted that this was desirable and in fact necessary for FIPS. >> * @mattcaswell added that the DRBGs and seeding is available inside the FIPS provider. >> >> >> That the FIPS provider includes a copy of the relevant RAND files, means it can satisfy internal requests for random numbers. >> However, external entities (TLS stack, user applications) won?t git FIPS approved random numbers. >> >> I can?t see currently an alternative to making the RAND functionality fetchable. > > I think making RAND fetchable is highly desirable and should be done (I had > always assumed we would do this). > >> I also suspect it will need to be per library context which might interfere with the per thread DRBGs we?re using. > > I see no problems here. The RAND code is already library context aware. You get > per thread DRBGs for each OPENSSL_CTX. For example calling > OPENSSL_CTX_get0_private_drbg() will get you the private DRBG for the current > thread in the specified OPENSSL_CTX. RAND_DRBG_get0_private() does the same > thing for the default OPENSSL_CTX. > > >> As for what to fetch: the DRBG instances and the seed material source would be ideal, although we don?t need the seed source for FIPS (so long as the DRBGs seed from inside their own provider). > > I had always assumed we would fetch DRBG instances. > > Matt > >> >> >> Thoughts or input anyone? >> >> >> Pauli >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Sep 27 21:44:24 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 27 Sep 2019 21:44:24 +0000 Subject: Reorganization of the header files (GitHub #9333) Message-ID: <7ad20416b1b54a699fecc2d667aa6a21@Ex13.ncp.local> Hi, some of you might have loosely followed pull request #9333 (see [1]), where I am reorganizing the header files in a more consistent manner. Since I intend to do the reorganization both to master and the 1.1.1 stable branch (in order to facilitate conflict-free cherry-picking to the 1.1.1 LTS branch), I decided to automate the changes. This decision turned out to be very convenient, because the heavy rearchitecturing on master frequently conflicted with my changes. Instead of resolving conflicts, I could just rerun the script after rebasing. When this pull request finally gets merged, it might happen that you in turn encounter more merge conflicts as usual, in particular if you are one of the 'replumbers' involved in the FIPS rearchitecturing. It might also happen if you are working on some long running pull request like the CMP integration. To check the impact of my changes on your work, I did some rebasing experiments, and as a result I wrote down some guidance about possible rebasing strategies in [2]. The reason I write this mail is because I'd like to hear your opinion about how to proceed with this pull request. There are two possibilities: Variant I): Merge early in to get the reorganization integrated as soon as possible and not wait until shortly before the next release. Variant II): Wait a little bit more until the heavy rearchitecturing has settled down a little bit. What is your opinion? What are your preferences? Regards, Matthias [1] https://github.com/openssl/openssl/pull/9333 [2] https://github.com/openssl/openssl/pull/9333#issuecomment-536105158 From tjh at cryptsoft.com Fri Sep 27 21:51:51 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 28 Sep 2019 07:51:51 +1000 Subject: Reorganization of the header files (GitHub #9333) In-Reply-To: <7ad20416b1b54a699fecc2d667aa6a21@Ex13.ncp.local> References: <7ad20416b1b54a699fecc2d667aa6a21@Ex13.ncp.local> Message-ID: Merge early is pretty much my default position ... and that applies to this context in my view. Tim. On Sat, 28 Sep. 2019, 7:44 am Dr. Matthias St. Pierre, < Matthias.St.Pierre at ncp-e.com> wrote: > Hi, > > some of you might have loosely followed pull request #9333 (see [1]), > where I am reorganizing the header files in a more consistent manner. > > Since I intend to do the reorganization both to master and the 1.1.1 > stable branch (in order to facilitate conflict-free cherry-picking to > the 1.1.1 LTS branch), I decided to automate the changes. This decision > turned out to be very convenient, because the heavy rearchitecturing on > master frequently conflicted with my changes. Instead of resolving > conflicts, I could just rerun the script after rebasing. > > When this pull request finally gets merged, it might happen that you > in turn encounter more merge conflicts as usual, in particular if you > are one of the 'replumbers' involved in the FIPS rearchitecturing. > It might also happen if you are working on some long running pull > request like the CMP integration. > > To check the impact of my changes on your work, I did some rebasing > experiments, and as a result I wrote down some guidance about possible > rebasing strategies in [2]. > > The reason I write this mail is because I'd like to hear your opinion > about how to proceed with this pull request. There are two possibilities: > > Variant I): > Merge early in to get the reorganization integrated as soon > as possible and not wait until shortly before the next release. > > Variant II): > Wait a little bit more until the heavy rearchitecturing > has settled down a little bit. > > What is your opinion? What are your preferences? > > > Regards, > > Matthias > > > [1] https://github.com/openssl/openssl/pull/9333 > [2] https://github.com/openssl/openssl/pull/9333#issuecomment-536105158 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sat Sep 28 07:05:53 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 28 Sep 2019 07:05:53 +0000 Subject: AW: Reorganization of the header files (GitHub #9333) In-Reply-To: References: <7ad20416b1b54a699fecc2d667aa6a21@Ex13.ncp.local> Message-ID: > Merge early is pretty much my default position ... and that applies to this context in my view. Thank you Tim for your quick and clear consent. Meanwhile, pull request #9333 and its counterpart #9681 for the 1.1.1 stable branch have been approved by Richard. Unless I hear any protest until Sunday afternoon (CEST), I would like to merge in the evening, just in time before the Australian plumbers start their weekly shift again. Matthias From paul.dale at oracle.com Sat Sep 28 09:58:27 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 28 Sep 2019 19:58:27 +1000 Subject: Reorganization of the header files (GitHub #9333) In-Reply-To: References: <7ad20416b1b54a699fecc2d667aa6a21@Ex13.ncp.local> Message-ID: <05CD7E4D-CBF3-4966-9DDF-CF486B77BB2D@oracle.com> Go for it, the antipodean contingent aren?t busy this weekend. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 28 Sep 2019, at 5:05 pm, Dr. Matthias St. Pierre wrote: > >> Merge early is pretty much my default position ... and that applies to this context in my view. > > Thank you Tim for your quick and clear consent. > > Meanwhile, pull request #9333 and its counterpart #9681 for the 1.1.1 stable > branch have been approved by Richard. Unless I hear any protest until Sunday > afternoon (CEST), I would like to merge in the evening, just in time before the > Australian plumbers start their weekly shift again. > > Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sat Sep 28 17:01:51 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 28 Sep 2019 17:01:51 +0000 Subject: AW: Reorganization of the header files (GitHub #9333) In-Reply-To: <05CD7E4D-CBF3-4966-9DDF-CF486B77BB2D@oracle.com> References: <7ad20416b1b54a699fecc2d667aa6a21@Ex13.ncp.local> <05CD7E4D-CBF3-4966-9DDF-CF486B77BB2D@oracle.com> Message-ID: > Go for it, the antipodean contingent aren?t busy this weekend. Ok, since I have green light from three OMC members now, I think there is no need to wait until tomorrow. I'll merge later this evening. Matthias From Matthias.St.Pierre at ncp-e.com Sat Sep 28 19:09:25 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 28 Sep 2019 19:09:25 +0000 Subject: AW: Reorganization of the header files (GitHub #9333) In-Reply-To: References: <7ad20416b1b54a699fecc2d667aa6a21@Ex13.ncp.local> <05CD7E4D-CBF3-4966-9DDF-CF486B77BB2D@oracle.com> Message-ID: It's merged to master. If you encounter merge problems while rebasing, please consult https://github.com/openssl/openssl/pull/9333#issuecomment-536105158 Matthias From Matthias.St.Pierre at ncp-e.com Sat Sep 28 20:25:04 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 28 Sep 2019 20:25:04 +0000 Subject: Build failures on master Message-ID: <73b1aa9466c540c3a51345c097cdebe9@Ex13.ncp.local> Hi, since my last commit on master did not build successfully, I checked the CIs. It turned out that a lot of tests are failing, and they have been for quite a while now. https://travis-ci.org/openssl/openssl/builds/590874649?utm_source=github_status&utm_medium=notification Apart from the well known trio boringssl, krb5, and pyca, there are some new failing tests. It would be nice if we could put some effort into fixing them in order to get back to having stable successful builds on master again. The build failures on master also affect the pull request CI builds and if the failure persists, people stop checking their red crosses. Matthias -- https://travis-ci.org/openssl/openssl/jobs/590874663 80-test_ssl_old.t (Wstat: 256 Tests: 6 Failed: 1) Failed test: 3 Non-zero exit status: 1 https://travis-ci.org/openssl/openssl/jobs/590874664 Test Summary Report ------------------- 95-test_external_boringssl.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 https://travis-ci.org/openssl/openssl/jobs/590874669 Test Summary Report ------------------- 30-test_evp.t (Wstat: 256 Tests: 19 Failed: 1) Failed test: 1 Non-zero exit status: 1 30-test_evp_fetch_prov.t (Wstat: 5376 Tests: 34 Failed: 21) Failed tests: 1, 9-18, 25-34 Non-zero exit status: 21 https://travis-ci.org/openssl/openssl/jobs/590874670 Test Summary Report ------------------- 30-test_evp.t (Wstat: 256 Tests: 19 Failed: 1) Failed test: 1 Non-zero exit status: 1 30-test_evp_fetch_prov.t (Wstat: 5376 Tests: 34 Failed: 21) Failed tests: 1, 9-18, 25-34 Non-zero exit status: 21 From levitte at openssl.org Sun Sep 29 06:45:23 2019 From: levitte at openssl.org (Richard Levitte) Date: Sun, 29 Sep 2019 08:45:23 +0200 Subject: Build failures on master In-Reply-To: <73b1aa9466c540c3a51345c097cdebe9@Ex13.ncp.local> References: <73b1aa9466c540c3a51345c097cdebe9@Ex13.ncp.local> Message-ID: <8736gf61oc.wl-levitte@openssl.org> This keeps happening because the standard tests don't include no-fips or no-pic or no-module (the latter two will disable fips too), so we keep not hitting this hurdle in PRs unless we have extended tests run (done by having '[extended tests]' in the commit message). We should add a configuration with 'no-fips' among our standard tests, so this becomes automatically visible in PRs. The issue with the tests? Doing FIPS tests without checking if 'fips' is disabled or not. Cheers, Richard On Sat, 28 Sep 2019 22:25:04 +0200, Dr. Matthias St. Pierre wrote: > > Hi, > > since my last commit on master did not build successfully, I checked the CIs. > It turned out that a lot of tests are failing, and they have been for quite a while now. > > https://travis-ci.org/openssl/openssl/builds/590874649?utm_source=github_status&utm_medium=notification > > Apart from the well known trio boringssl, krb5, and pyca, there are some new failing tests. > It would be nice if we could put some effort into fixing them in order to get back to having > stable successful builds on master again. The build failures on master also affect the > pull request CI builds and if the failure persists, people stop checking their red crosses. > > Matthias > > > -- > > https://travis-ci.org/openssl/openssl/jobs/590874663 > > 80-test_ssl_old.t (Wstat: 256 Tests: 6 Failed: 1) > Failed test: 3 > Non-zero exit status: 1 > > > https://travis-ci.org/openssl/openssl/jobs/590874664 > > Test Summary Report > ------------------- > 95-test_external_boringssl.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > 95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > 95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > > https://travis-ci.org/openssl/openssl/jobs/590874669 > > Test Summary Report > ------------------- > 30-test_evp.t (Wstat: 256 Tests: 19 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > 30-test_evp_fetch_prov.t (Wstat: 5376 Tests: 34 Failed: 21) > Failed tests: 1, 9-18, 25-34 > Non-zero exit status: 21 > > https://travis-ci.org/openssl/openssl/jobs/590874670 > > Test Summary Report > ------------------- > 30-test_evp.t (Wstat: 256 Tests: 19 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > 30-test_evp_fetch_prov.t (Wstat: 5376 Tests: 34 Failed: 21) > Failed tests: 1, 9-18, 25-34 > Non-zero exit status: 21 > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/