From paul.dale at oracle.com Thu Oct 1 08:36:09 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 1 Oct 2020 18:36:09 +1000 Subject: Would this be interesting to the project? Message-ID: https://github.blog/2020-09-30-code-scanning-is-now-available/ Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Oct 2 12:50:31 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 2 Oct 2020 15:50:31 +0300 Subject: Would this be interesting to the project? In-Reply-To: References: Message-ID: Do you have ideas on how to properly set it up? On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale wrote: > https://github.blog/2020-09-30-code-scanning-is-now-available/ > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Oct 2 13:29:42 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 2 Oct 2020 13:29:42 +0000 Subject: Would this be interesting to the project? In-Reply-To: References: Message-ID: > Do you have ideas on how to properly set it up? Congratulations, Dmitry! You just won the price of being assigned the job to figure it out. ;-) Matthias From: openssl-project On Behalf Of Dmitry Belyavsky Sent: Friday, October 2, 2020 2:51 PM To: Dr Paul Dale Cc: openssl-project at openssl.org Subject: Re: Would this be interesting to the project? Do you have ideas on how to properly set it up? On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale > wrote: https://github.blog/2020-09-30-code-scanning-is-now-available/ Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Oct 2 15:30:31 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 2 Oct 2020 18:30:31 +0300 Subject: Would this be interesting to the project? In-Reply-To: References: Message-ID: As setting up openssl master is required to build gost-engine, I'll have to. On Fri, Oct 2, 2020 at 4:29 PM Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > > Do you have ideas on how to properly set it up? > > > > Congratulations, Dmitry! You just won the price of being assigned the job > to figure it out. ;-) > > > > Matthias > > > > > > *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre* > > Senior Software Engineer > matthias.st.pierre at ncp-e.com > Phone: +49 911 9968-0 > www.ncp-e.com > > > * Follow us on:* Facebook | > Twitter | Xing > | YouTube > | LinkedIn > > > *Headquarters Germany: *NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 > ? Nuremberg > *North American HQ:* NCP engineering Inc. ? 601 Cleveland Str., Suite > 501-25 ? Clearwater, FL 33755 > > Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate > Dietrich > Registry Court: Lower District Court of Nuremberg > Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE > 133557619 > > This e-mail message including any attachments is for the sole use of the > intended recipient(s) and may contain privileged or confidential > information. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please immediately > contact the sender by reply e-mail and delete the original message and > destroy all copies thereof. > > > > > *From**:* openssl-project *On > Behalf Of *Dmitry Belyavsky > *Sent:* Friday, October 2, 2020 2:51 PM > *To:* Dr Paul Dale > *Cc:* openssl-project at openssl.org > *Subject:* Re: Would this be interesting to the project? > > > > Do you have ideas on how to properly set it up? > > > > On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale wrote: > > https://github.blog/2020-09-30-code-scanning-is-now-available/ > > > > Pauli > > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > > > > > > > > > -- > > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NCP_logo_2f45208a-c14d-4000-bcd3-1ab400c0e48c.gif Type: image/gif Size: 2815 bytes Desc: not available URL: From nic.tuv at gmail.com Fri Oct 2 20:55:51 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 2 Oct 2020 23:55:51 +0300 Subject: [OTC] Agenda proposal for OTC meeting on 2020-10-06 Message-ID: I am writing this on behalf of the OTC, as an update on the latest OTC developments. This week we had three days of virtual face to face meetings (two OTC sessions with one Committers session in the middle) and we scheduled the next OTC meeting already next week, on Tuesday 2020-10-06. This email presents some of the points already under discussion since last week, and an agenda proposal for the next OTC meeting. This is done in the interest of transparency and so that the community can give us feedback during the discussion. Background ---------- Understandably, it doesn't come as a surprise that this week we mostly discussed about the upcoming beta release and associated items. According to our [Release Schedule][], among our pre-releases, the transition from _alpha_ releases to _beta_ releases is defined by the following definitions: - an _alpha_ release means: - Not (necessarily) feature complete - Not necessarily all new APIs in place yet - a _beta_ release means: - Feature complete/Feature freeze - Bug fixes only >From the discussion, it transpired that the OTC needs to better formalize, in technical terms, how to assess its level of confidence on beta readiness, and to collectively agree on which technical tasks still need to be completed before the transition to beta to ensure feature completeness, and which remaining tasks would count as bug fixes that can be planned for the beta stage. At the next OTC meeting, we plan to discuss mainly two items in our agenda: - discuss, refine and vote on the "Beta Release Readiness Checklist" - discuss, refine and vote on the "Technical items still to be done" list The "Beta Release Readiness Checklist" aims at establishing the technical checks to be performed to assess the OTC degree of confidence on the state of the development branch before calling the OTC "Ready for beta" vote. The "Technical items still to be done" list aims at collecting a number of technical items that we still need to meet in order to qualify for feature completeness against the release requirements provided by the OMC (mainly via the [3.0 design document][] and the [Release Strategy][]). This list requires further review to check if there are missing items that were overlooked, to refine and compare different interpretations of how the OTC should deduce technical items out of the OMC provided requirements, or to improve the description of how to technically meet those requirements. On the prerogatives of OTC and OMC ---------------------------------- To better frame the community discussion following this announcement, it is worth to recall here an excerpt (listing only the items that are relevant in the context of these drafts) from the [OpenSSL Bylaws][], according to which - the OpenSSL Technical Committee (OTC) - makes all technical decision of the code and documentation for OpenSSL; - produces releases according to OMC requirements; - establishes and maintains technical policies and technical procedures; - the OpenSSL Management Committee (OMC) - makes all decisions regarding management and strategic direction of the project, including: * business requirements; * feature requirements; * platform requirements; * roadmap requirements and priority; * release timing and requirement decisions; - sets and maintains all non-technical policies and non-technical procedures; - schedules releases and determines future release plans and the development roadmap and priorities. It follows that the scope of the OTC discussion regarding both lists, and the feedback we can invite from the community, is limited to technical policies and procedures to produce releases according to the requirements provided by the OMC, and should not include items that belong only to the OMC prerogatives. --- The rest of this email provides the **drafts** of the two lists as the result of our preliminary discussions, to collect feedback from the wider community for consideration in the decision process. **NOTE**: I must reiterate that the following lists are both in a **draft** state, with some items deliberately in the form of discussion points. At the end of the process it is likely for some items to be rephrased, altered in scope, or dropped, as it is likely that entirely new items might be added. Both drafts are just **proposals**: they have not been adopted by the OTC yet, they might still not be adopted at the end of the decision process, and their scopes, goals and titles might still be changed. --- Proposed "Beta Release Readiness Checklist" ------------------------------------------- 01. Functionally complete 02. Public API freeze. An application that works with beta1 should work with all subsequent versions. 03. Triage all open issues and decide: not an issue, won?t fix, fix for beta or fix after beta for each. 04. Triage all TODO(current release) items: done, won?t fix, fix for beta or fix after beta for each. 05. Triage all Coverity issues and close either: by marking it as false positive or by fixing it. 06. Coveralls coverage has not decreased overall from the previous release. 07. Have a pass through all new/changed APIs to ensure consistency, fixing those that aren't. 08. Confirm that all new public APIs are documented. 09. Check that new exported symbols (in the static build) are named correctly (`OSSL_` resp. `ossl_` prefix). 10. Run the previous (all relevant supported) release test suites against the beta version. 11. Clean builds in Travis and Appveyor for two days. 12. run-checker.sh succeeds on 2 consecutive days before release. 13. A passing OTC "ready for beta" vote. Proposed "Technical items still to be done" list ------------------------------------------------ 1. The `EVP` interface is the recommended API, it must be feature-complete compared with the functionality available using lower-level APIs. - Anything that isn't available must be put to an OTC vote to exclude. - The `apps/` are the minimum bar for this, they should not use internal nor deprecated functions (except `speed`, `engine` and the code to handle the `-engine` CLI option). - Deprecated functions used by `libssl` should be moved to an independent file. 2. Deprecation List Proposal: The entire `DH_`, `DSA_`, `ECDH_`, `ECDSA_`, `EC_KEY_`, `RSA_`, and `RAND_METHOD_` interfaces. - Does not include macros defining useful values (e.g. DH maximum size). - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. - There might be some others. - Review for exceptions. - Rewrite apps to use non-deprecated interfaces as far as possible. - Transfer old apps to test cases (either directly or via 1.1.1). 3. Compile a list of things we know are not present - including things we have removed. 4. We need to have a mapping table from ?old names? for things into the 5. We need to have mapping tables for various `d2i`/`i2d` functions. `OSSL_PARAMS` names. 6. We need to rewrite the apps to use only the non-deprecated interfaces (except for the list, speed and engine apps and the engine parameter in various places). 7. All the legacy interfaces need to have their documentation pointing to the replacement interfaces. --- Best regards, Nicola Tuveri [Release Strategy]: https://www.openssl.org/policies/releasestrat.html [OpenSSL Bylaws]: https://www.openssl.org/policies/omc-bylaws.html [3.0 design document]: https://www.openssl.org/docs/OpenSSL300Design.html From nic.tuv at gmail.com Fri Oct 2 21:18:54 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sat, 3 Oct 2020 00:18:54 +0300 Subject: [OTC] Agenda proposal for OTC meeting on 2020-10-06 In-Reply-To: References: Message-ID: [Resending this, to incorporate an errata in the second list, at points 4 and 5] I am writing this on behalf of the OTC, as an update on the latest OTC developments. This week we had three days of virtual face to face meetings (two OTC sessions with one Committers session in the middle) and we scheduled the next OTC meeting already next week, on Tuesday 2020-10-06. This email presents some of the points already under discussion since last week, and an agenda proposal for the next OTC meeting. This is done in the interest of transparency and so that the community can give us feedback during the discussion. Background ---------- Understandably, it doesn't come as a surprise that this week we mostly discussed about the upcoming beta release and associated items. According to our [Release Schedule][], among our pre-releases, the transition from _alpha_ releases to _beta_ releases is defined by the following definitions: - an _alpha_ release means: - Not (necessarily) feature complete - Not necessarily all new APIs in place yet - a _beta_ release means: - Feature complete/Feature freeze - Bug fixes only >From the discussion, it transpired that the OTC needs to better formalize, in technical terms, how to assess its level of confidence on beta readiness, and to collectively agree on which technical tasks still need to be completed before the transition to beta to ensure feature completeness, and which remaining tasks would count as bug fixes that can be planned for the beta stage. At the next OTC meeting, we plan to discuss mainly two items in our agenda: - discuss, refine and vote on the "Beta Release Readiness Checklist" - discuss, refine and vote on the "Technical items still to be done" list The "Beta Release Readiness Checklist" aims at establishing the technical checks to be performed to assess the OTC degree of confidence on the state of the development branch before calling the OTC "Ready for beta" vote. The "Technical items still to be done" list aims at collecting a number of technical items that we still need to meet in order to qualify for feature completeness against the release requirements provided by the OMC (mainly via the [3.0 design document][] and the [Release Strategy][]). This list requires further review to check if there are missing items that were overlooked, to refine and compare different interpretations of how the OTC should deduce technical items out of the OMC provided requirements, or to improve the description of how to technically meet those requirements. On the prerogatives of OTC and OMC ---------------------------------- To better frame the community discussion following this announcement, it is worth to recall here an excerpt (listing only the items that are relevant in the context of these drafts) from the [OpenSSL Bylaws][], according to which - the OpenSSL Technical Committee (OTC) - makes all technical decision of the code and documentation for OpenSSL; - produces releases according to OMC requirements; - establishes and maintains technical policies and technical procedures; - the OpenSSL Management Committee (OMC) - makes all decisions regarding management and strategic direction of the project, including: * business requirements; * feature requirements; * platform requirements; * roadmap requirements and priority; * release timing and requirement decisions; - sets and maintains all non-technical policies and non-technical procedures; - schedules releases and determines future release plans and the development roadmap and priorities. It follows that the scope of the OTC discussion regarding both lists, and the feedback we can invite from the community, is limited to technical policies and procedures to produce releases according to the requirements provided by the OMC, and should not include items that belong only to the OMC prerogatives. --- The rest of this email provides the **drafts** of the two lists as the result of our preliminary discussions, to collect feedback from the wider community for consideration in the decision process. **NOTE**: I must reiterate that the following lists are both in a **draft** state, with some items deliberately in the form of discussion points. At the end of the process it is likely for some items to be rephrased, altered in scope, or dropped, as it is likely that entirely new items might be added. Both drafts are just **proposals**: they have not been adopted by the OTC yet, they might still not be adopted at the end of the decision process, and their scopes, goals and titles might still be changed. --- Proposed "Beta Release Readiness Checklist" ------------------------------------------- 01. Functionally complete 02. Public API freeze. An application that works with beta1 should work with all subsequent versions. 03. Triage all open issues and decide: not an issue, won?t fix, fix for beta or fix after beta for each. 04. Triage all TODO(current release) items: done, won?t fix, fix for beta or fix after beta for each. 05. Triage all Coverity issues and close either: by marking it as false positive or by fixing it. 06. Coveralls coverage has not decreased overall from the previous release. 07. Have a pass through all new/changed APIs to ensure consistency, fixing those that aren't. 08. Confirm that all new public APIs are documented. 09. Check that new exported symbols (in the static build) are named correctly (`OSSL_` resp. `ossl_` prefix). 10. Run the previous (all relevant supported) release test suites against the beta version. 11. Clean builds in Travis and Appveyor for two days. 12. run-checker.sh succeeds on 2 consecutive days before release. 13. A passing OTC "ready for beta" vote. Proposed "Technical items still to be done" list ------------------------------------------------ 1. The `EVP` interface is the recommended API, it must be feature-complete compared with the functionality available using lower-level APIs. - Anything that isn't available must be put to an OTC vote to exclude. - The `apps/` are the minimum bar for this, they should not use internal nor deprecated functions (except `speed`, `engine` and the code to handle the `-engine` CLI option). - Deprecated functions used by `libssl` should be moved to an independent file. 2. Deprecation List Proposal: The entire `DH_`, `DSA_`, `ECDH_`, `ECDSA_`, `EC_KEY_`, `RSA_`, and `RAND_METHOD_` interfaces. - Does not include macros defining useful values (e.g. DH maximum size). - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. - There might be some others. - Review for exceptions. - Rewrite apps to use non-deprecated interfaces as far as possible. - Transfer old apps to test cases (either directly or via 1.1.1). 3. Compile a list of things we know are not present - including things we have removed. 4. We need to have a mapping table from ?old names? for things into the `OSSL_PARAMS` names. 5. We need to have mapping tables for various `d2i`/`i2d` functions. 6. We need to rewrite the apps to use only the non-deprecated interfaces (except for the list, speed and engine apps and the engine parameter in various places). 7. All the legacy interfaces need to have their documentation pointing to the replacement interfaces. --- Best regards, Nicola Tuveri [Release Strategy]: https://www.openssl.org/policies/releasestrat.html [OpenSSL Bylaws]: https://www.openssl.org/policies/omc-bylaws.html [3.0 design document]: https://www.openssl.org/docs/OpenSSL300Design.html On Fri, 2 Oct 2020 at 23:55, Nicola Tuveri wrote: > > I am writing this on behalf of the OTC, as an update on the latest OTC > developments. > This week we had three days of virtual face to face meetings (two OTC > sessions with one Committers session in the middle) and we scheduled the > next OTC meeting already next week, on Tuesday 2020-10-06. > > This email presents some of the points already under discussion since > last week, and an agenda proposal for the next OTC meeting. > This is done in the interest of transparency and so that the community > can give us feedback during the discussion. > > > Background > ---------- > > Understandably, it doesn't come as a surprise that this week we mostly > discussed about the upcoming beta release and associated items. > According to our [Release Schedule][], among our pre-releases, the > transition from _alpha_ releases to _beta_ releases is defined by the > following definitions: > > - an _alpha_ release means: > - Not (necessarily) feature complete > - Not necessarily all new APIs in place yet > - a _beta_ release means: > - Feature complete/Feature freeze > - Bug fixes only > > From the discussion, it transpired that the OTC needs to better > formalize, in technical terms, how to assess its level of confidence on > beta readiness, and to collectively agree on which technical tasks still > need to be completed before the transition to beta to ensure feature > completeness, and which remaining tasks would count as bug fixes that > can be planned for the beta stage. > > At the next OTC meeting, we plan to discuss mainly two items in our > agenda: > > - discuss, refine and vote on the "Beta Release Readiness Checklist" > - discuss, refine and vote on the "Technical items still to be done" > list > > The "Beta Release Readiness Checklist" aims at establishing the > technical checks to be performed to assess the OTC degree of confidence > on the state of the development branch before calling the OTC "Ready for > beta" vote. > > The "Technical items still to be done" list aims at collecting a number > of technical items that we still need to meet in order to qualify for > feature completeness against the release requirements provided by the > OMC (mainly via the [3.0 design document][] and the > [Release Strategy][]). > This list requires further review to check if there are missing items > that were overlooked, to refine and compare different interpretations of > how the OTC should deduce technical items out of the OMC provided > requirements, or to improve the description of how to technically meet > those requirements. > > > On the prerogatives of OTC and OMC > ---------------------------------- > > To better frame the community discussion following this announcement, it > is worth to recall here an excerpt (listing only the items that are > relevant in the context of these drafts) from the [OpenSSL Bylaws][], > according to which > > - the OpenSSL Technical Committee (OTC) > - makes all technical decision of the code and documentation for > OpenSSL; > - produces releases according to OMC requirements; > - establishes and maintains technical policies and technical > procedures; > - the OpenSSL Management Committee (OMC) > - makes all decisions regarding management and strategic direction of > the project, including: > * business requirements; > * feature requirements; > * platform requirements; > * roadmap requirements and priority; > * release timing and requirement decisions; > - sets and maintains all non-technical policies and non-technical > procedures; > - schedules releases and determines future release plans and the > development roadmap and priorities. > > It follows that the scope of the OTC discussion regarding both lists, > and the feedback we can invite from the community, is limited to > technical policies and procedures to produce releases according to the > requirements provided by the OMC, and should not include items that > belong only to the OMC prerogatives. > > --- > > The rest of this email provides the **drafts** of the two lists as the > result of our preliminary discussions, to collect feedback from the > wider community for consideration in the decision process. > > **NOTE**: I must reiterate that the following lists are both in a > **draft** state, with some items deliberately in the form of > discussion points. > At the end of the process it is likely for some items to be > rephrased, altered in scope, or dropped, as it is likely that > entirely new items might be added. > Both drafts are just **proposals**: they have not been adopted > by the OTC yet, they might still not be adopted at the end of > the decision process, and their scopes, goals and titles might > still be changed. > > --- > > > Proposed "Beta Release Readiness Checklist" > ------------------------------------------- > > 01. Functionally complete > 02. Public API freeze. An application that works with beta1 should work > with all subsequent versions. > 03. Triage all open issues and decide: > not an issue, won?t fix, fix for beta or fix after beta for each. > 04. Triage all TODO(current release) items: > done, won?t fix, fix for beta or fix after beta for each. > 05. Triage all Coverity issues and close either: > by marking it as false positive or by fixing it. > 06. Coveralls coverage has not decreased overall from the previous > release. > 07. Have a pass through all new/changed APIs to ensure consistency, > fixing those that aren't. > 08. Confirm that all new public APIs are documented. > 09. Check that new exported symbols (in the static build) are named > correctly (`OSSL_` resp. `ossl_` prefix). > 10. Run the previous (all relevant supported) release test suites > against the beta version. > 11. Clean builds in Travis and Appveyor for two days. > 12. run-checker.sh succeeds on 2 consecutive days before release. > 13. A passing OTC "ready for beta" vote. > > > Proposed "Technical items still to be done" list > ------------------------------------------------ > > 1. The `EVP` interface is the recommended API, it must be > feature-complete compared with the functionality available using > lower-level APIs. > - Anything that isn't available must be put to an OTC vote to > exclude. > - The `apps/` are the minimum bar for this, they should not use > internal nor deprecated functions (except `speed`, `engine` and > the code to handle the `-engine` CLI option). > - Deprecated functions used by `libssl` should be moved to an > independent file. > 2. Deprecation List Proposal: The entire `DH_`, `DSA_`, `ECDH_`, > `ECDSA_`, `EC_KEY_`, `RSA_`, and `RAND_METHOD_` interfaces. > - Does not include macros defining useful values (e.g. DH maximum > size). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - Rewrite apps to use non-deprecated interfaces as far as possible. > - Transfer old apps to test cases (either directly or via 1.1.1). > 3. Compile a list of things we know are not present - including things > we have removed. > 4. We need to have a mapping table from ?old names? for things into the > 5. We need to have mapping tables for various `d2i`/`i2d` functions. > `OSSL_PARAMS` names. > 6. We need to rewrite the apps to use only the non-deprecated interfaces > (except for the list, speed and engine apps and the engine parameter > in various places). > 7. All the legacy interfaces need to have their documentation pointing > to the replacement interfaces. > > > --- > > Best regards, > > Nicola Tuveri > > [Release Strategy]: https://www.openssl.org/policies/releasestrat.html > [OpenSSL Bylaws]: https://www.openssl.org/policies/omc-bylaws.html > [3.0 design document]: https://www.openssl.org/docs/OpenSSL300Design.html From beldmit at gmail.com Sat Oct 3 17:52:58 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 3 Oct 2020 20:52:58 +0300 Subject: Would this be interesting to the project? In-Reply-To: References: Message-ID: Hello, I was able to setup CodeQL for the GOST engine. As it fetches OpenSSL alpha 6, I got able to see the results. ====== openssl/test/cmp_hdr_test.c#L181 Call to gmtime is potentially dangerous openssl/test/cmp_hdr_test.c#L171 Call to gmtime is potentially dangerous ? openssl/test/asn1_time_test.c#L398 Call to localtime is potentially dangerous ? openssl/crypto/ec/curve448/curve448.c#L583 Multiplication result may overflow 'int' before it is converted to 'unsigned long'. ? openssl/crypto/asn1/a_time.c#L250 Multiplication result may overflow 'int' before it is converted to 'long'. ====== I can submit a PR providing the CodeQL scan for the master branch if the Team thinks it is useful. But I strongly suppose that someone will have to configure the OpenSSL github project to enable it. On Fri, Oct 2, 2020 at 6:30 PM Dmitry Belyavsky wrote: > As setting up openssl master is required to build gost-engine, I'll have > to. > > On Fri, Oct 2, 2020 at 4:29 PM Dr. Matthias St. Pierre < > Matthias.St.Pierre at ncp-e.com> wrote: > >> > Do you have ideas on how to properly set it up? >> >> >> >> Congratulations, Dmitry! You just won the price of being assigned the job >> to figure it out. ;-) >> >> >> >> Matthias >> >> >> >> >> >> *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre* >> >> Senior Software Engineer >> matthias.st.pierre at ncp-e.com >> Phone: +49 911 9968-0 >> www.ncp-e.com >> >> >> * Follow us on:* Facebook | >> Twitter | Xing >> | YouTube >> | LinkedIn >> >> >> *Headquarters Germany: *NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 >> ? Nuremberg >> *North American HQ:* NCP engineering Inc. ? 601 Cleveland Str., Suite >> 501-25 ? Clearwater, FL 33755 >> >> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate >> Dietrich >> Registry Court: Lower District Court of Nuremberg >> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE >> 133557619 >> >> This e-mail message including any attachments is for the sole use of the >> intended recipient(s) and may contain privileged or confidential >> information. Any unauthorized review, use, disclosure or distribution is >> prohibited. If you are not the intended recipient, please immediately >> contact the sender by reply e-mail and delete the original message and >> destroy all copies thereof. >> >> >> >> >> *From**:* openssl-project *On >> Behalf Of *Dmitry Belyavsky >> *Sent:* Friday, October 2, 2020 2:51 PM >> *To:* Dr Paul Dale >> *Cc:* openssl-project at openssl.org >> *Subject:* Re: Would this be interesting to the project? >> >> >> >> Do you have ideas on how to properly set it up? >> >> >> >> On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale >> wrote: >> >> https://github.blog/2020-09-30-code-scanning-is-now-available/ >> >> >> >> Pauli >> >> -- >> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations >> Phone +61 7 3031 7217 >> Oracle Australia >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> SY, Dmitry Belyavsky >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NCP_logo_2f45208a-c14d-4000-bcd3-1ab400c0e48c.gif Type: image/gif Size: 2815 bytes Desc: not available URL: From kurt at roeckx.be Sun Oct 4 14:22:09 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 4 Oct 2020 16:22:09 +0200 Subject: Tracking important issues In-Reply-To: <20200923185128.GA1669330@roeckx.be> References: <20200923185128.GA1669330@roeckx.be> Message-ID: <20201004142209.GA2319050@roeckx.be> On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote: > Hi, > > I would like to have a system so that we can tag issues as > important. But I think they fall in a few categories: > - Features for the next minor/major release (so 3.1 or 4.0) > that we find important. I've created a new milestone for that: > https://github.com/openssl/openssl/milestone/18 (Post 3.0.0) > > We've also had a Post 1.1.1 milestone, but that seems to be just > things that didn't block the 1.1.1 release, maybe some more > things can be moved over. > > I suggest we do not add all feature requests to the new > milestone, so that we can have some kind of overview. > - Features we want in before beta 1: The 3.0.0 beta1 milestone > - Bugs that need to get fixed before the 3.0.0 release: > currently using the 3.0.0 milestone > - Important bugs that affect the stable releases. I've started > tagging bugs that have "triaged: bug" also with the branches > that are affected. But that doesn't say how important it is. > I have 2 proposals for that: > - Create a milestone for them, like 1.1.1-stable. In cases we > have multiple supported branches, we can add for instance a > 3.0-stable and use the oldest branches that's a affected > as the target. This would at least match what we do now > with the "3.0.0" milestone. > - Create a label for the severity. I'm not sure we need things > like "severity: minor", but it might be useful too. So I've created the "severity: important" label, and started tagging some issues with it. Kurt From matt at openssl.org Mon Oct 5 09:00:14 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 5 Oct 2020 10:00:14 +0100 Subject: Tracking important issues In-Reply-To: <20201004142209.GA2319050@roeckx.be> References: <20200923185128.GA1669330@roeckx.be> <20201004142209.GA2319050@roeckx.be> Message-ID: On 04/10/2020 15:22, Kurt Roeckx wrote: > On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote: >> Hi, >> >> I would like to have a system so that we can tag issues as >> important. But I think they fall in a few categories: >> - Features for the next minor/major release (so 3.1 or 4.0) >> that we find important. I've created a new milestone for that: >> https://github.com/openssl/openssl/milestone/18 (Post 3.0.0) >> >> We've also had a Post 1.1.1 milestone, but that seems to be just >> things that didn't block the 1.1.1 release, maybe some more >> things can be moved over. >> >> I suggest we do not add all feature requests to the new >> milestone, so that we can have some kind of overview. >> - Features we want in before beta 1: The 3.0.0 beta1 milestone >> - Bugs that need to get fixed before the 3.0.0 release: >> currently using the 3.0.0 milestone >> - Important bugs that affect the stable releases. I've started >> tagging bugs that have "triaged: bug" also with the branches >> that are affected. But that doesn't say how important it is. >> I have 2 proposals for that: >> - Create a milestone for them, like 1.1.1-stable. In cases we >> have multiple supported branches, we can add for instance a >> 3.0-stable and use the oldest branches that's a affected >> as the target. This would at least match what we do now >> with the "3.0.0" milestone. >> - Create a label for the severity. I'm not sure we need things >> like "severity: minor", but it might be useful too. > > So I've created the "severity: important" label, and started > tagging some issues with it. We should define some criteria for what constitutes an important bug. Everyone always thinks the bug they found is important because it impacts *them*. But what makes something important for the project?. Perhaps something about the number of users likely to be affected, or likely to cause interoperability issues, etc. Matt From tmraz at redhat.com Mon Oct 5 10:41:51 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 05 Oct 2020 12:41:51 +0200 Subject: Tracking important issues In-Reply-To: References: <20200923185128.GA1669330@roeckx.be> <20201004142209.GA2319050@roeckx.be> Message-ID: <05be0c477e25935f37e4da621379866089018d23.camel@redhat.com> On Mon, 2020-10-05 at 10:00 +0100, Matt Caswell wrote: > > On 04/10/2020 15:22, Kurt Roeckx wrote: > > On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote: > > > Hi, > > > > > > I would like to have a system so that we can tag issues as > > > important. But I think they fall in a few categories: > > > - Features for the next minor/major release (so 3.1 or 4.0) > > > that we find important. I've created a new milestone for that: > > > https://github.com/openssl/openssl/milestone/18 (Post 3.0.0) > > > > > > We've also had a Post 1.1.1 milestone, but that seems to be > > > just > > > things that didn't block the 1.1.1 release, maybe some more > > > things can be moved over. > > > > > > I suggest we do not add all feature requests to the new > > > milestone, so that we can have some kind of overview. > > > - Features we want in before beta 1: The 3.0.0 beta1 milestone > > > - Bugs that need to get fixed before the 3.0.0 release: > > > currently using the 3.0.0 milestone > > > - Important bugs that affect the stable releases. I've started > > > tagging bugs that have "triaged: bug" also with the branches > > > that are affected. But that doesn't say how important it is. > > > I have 2 proposals for that: > > > - Create a milestone for them, like 1.1.1-stable. In cases we > > > have multiple supported branches, we can add for instance a > > > 3.0-stable and use the oldest branches that's a affected > > > as the target. This would at least match what we do now > > > with the "3.0.0" milestone. > > > - Create a label for the severity. I'm not sure we need things > > > like "severity: minor", but it might be useful too. > > > > So I've created the "severity: important" label, and started > > tagging some issues with it. > > We should define some criteria for what constitutes an important bug. > Everyone always thinks the bug they found is important because it > impacts *them*. But what makes something important for the project?. > Perhaps something about the number of users likely to be affected, or > likely to cause interoperability issues, etc. IMO whether interoperability is affected is not really criteria on its own. What should matter is: 1. pervasiveness - i.e. how many users are affected 2. the actual severity - i.e. is the bug breaking affected functionality completely or it is just an intermittent problem 3. availability of workarounds Unfortunately it is hard to evaluate the first criterion in our case as it will also be a subjective matter - I do not think we have a database of all our users with the functionality they use. :D -- 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 Tue Oct 6 12:12:53 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Oct 2020 13:12:53 +0100 Subject: Alpha releases Message-ID: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> The OTC meeting today discussed making further alpha releases while we continue to work towards getting to beta 1. It was proposed that we release alpha 7 on Thursday 15h October and then regularly on a 3 weekly basis thereafter until such time as beta 1 is ready. This will need to be an OMC decision so this is my suggested vote wording: "OpenSSL 3.0 Alpha 7 shouuld be released on Thursday 15th October and subsequent alpha releases should be performed on a 3 weekly basis until beta 1 is ready" I'd like to give an opportunity for feedback on the above before I call this vote. Note that the OTC discussions on beta 1 (looking at the proposal that Nicola posted to this list last Friday) are still ongoing. There will be a further meeting tomorrow. Matt From rsalz at akamai.com Tue Oct 6 14:53:44 2020 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Oct 2020 14:53:44 +0000 Subject: Alpha releases In-Reply-To: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> References: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> Message-ID: <7E3714EB-05A7-4172-A51B-6DCE9E6C2F87@akamai.com> Is it the project's understanding that Alpha and Beta releases are, in fact, capital-R releases and therefore subject to OMC? That seems weird to me. From matt at openssl.org Tue Oct 6 14:56:23 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Oct 2020 15:56:23 +0100 Subject: Alpha releases In-Reply-To: <7E3714EB-05A7-4172-A51B-6DCE9E6C2F87@akamai.com> References: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> <7E3714EB-05A7-4172-A51B-6DCE9E6C2F87@akamai.com> Message-ID: <7be2d44a-708b-a9f9-6ea2-15c102ecbf1c@openssl.org> On 06/10/2020 15:53, Salz, Rich wrote: > Is it the project's understanding that Alpha and Beta releases are, in fact, capital-R releases and therefore subject to OMC? > That seems weird to me. Yes - that is the case at the moment. Matt From rsalz at akamai.com Tue Oct 6 15:11:48 2020 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Oct 2020 15:11:48 +0000 Subject: Alpha releases In-Reply-To: <7be2d44a-708b-a9f9-6ea2-15c102ecbf1c@openssl.org> References: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> <7E3714EB-05A7-4172-A51B-6DCE9E6C2F87@akamai.com> <7be2d44a-708b-a9f9-6ea2-15c102ecbf1c@openssl.org> Message-ID: On 06/10/2020 15:53, Salz, Rich wrote: > Is it the project's understanding that Alpha and Beta releases are, in fact, capital-R releases and therefore subject to OMC? > That seems weird to me. Yes - that is the case at the moment. Looking at the release strategy [1] it points to the wiki 3.0 schedule page [2] which is says Beta 1 was to be in June; someone should update that. I think you should have a new vote to change the bylaws [3] to change this line: release timing and requirement decisions; to be release timing (not counting internal test releases and such) and requirement decisions; Finally, was there an OMC vote on the 3.0 release contents, or is it just the 3.0 design [4]? Thanks. (Note that this isn't directedly specifically at Matt) [1] https://www.openssl.org/policies/releasestrat.html [2] https://wiki.openssl.org/index.php/OpenSSL_3.0_Release_Schedule [3] https://www.openssl.org/policies/omc-bylaws.html [4] https://www.openssl.org/docs/OpenSSL300Design.html From matt at openssl.org Wed Oct 7 11:21:13 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2020 12:21:13 +0100 Subject: Vote proposal: Accept the Fully Pluggable TLSv1.3 KEM into 3.0 Message-ID: <018e39b0-3b58-f6a3-6ed8-fe04d66ba676@openssl.org> I'm proposing the following vote text: We should accept the Fully Pluggable TLSv1.3 KEM functionality as shown in PR #13018 into the 3.0 release Feedback please on the vote proposal before I start the vote. Matt From matt at openssl.org Wed Oct 7 11:29:10 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2020 12:29:10 +0100 Subject: Vote proposal: Private keys can exist independently of public keys Message-ID: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> Issue #12612 exposes a problem with how we handle keys that contain private components but not public components. There is a widespread assumption in the code that keys with private components must have public components. There is text in our public documentation that states this (and that text dates back to 2006). OTOH, the code has not always enforced this. Issue #12612 describes a scenario where this has not historically been enforced, and it now is in the current 3.0 code causing a regression. There are differences of opinion on how this should be handled. Some have the opinion that we should change the model so that we explicitly allow private keys to exists without the public components. Others feel that we should continue with the old model. It seems we need a vote to decide this. Here is my proposed vote text: We should change the 3.0 code to explicitly allow private components to exist in keys without the public components also being present. Feedback please on the proposed vote text. Matt From matt at openssl.org Wed Oct 7 11:35:28 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2020 12:35:28 +0100 Subject: Vote proposal: Technical items still to be done Message-ID: I had an action from the OTC meeting today to raise a vote on the OTC list of technical items still to be done. Here is my proposed vote text. There will be a subsequent vote on the "beta readiness checklist" which is a separate list. Feedback please on the proposed vote text below. The following items are required prerequisites for the first beta release: * EVP is the recommended API, it must be feature-complete compared with the functionality available using lower-level APIs. - Anything that isn?t available must be put to an OTC vote to exclude. - The apps are the minimum bar for this, subject to exceptions noted below. * Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, RAND_METHOD_. - Does not include macros defining useful constants (e.g. SHA512_DIGEST_LENGTH). - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. - There might be some others. - Review for exceptions. - The apps are the minimum bar to measure feature completeness for the EVP interface: rewrite them so they do not use internal nor deprecated functions (except speed, engine, list, passwd -crypt and the code to handle the -engine CLI option). That is, remove the suppression of deprecated define. - Proposal: drop passwd -crypt (OMC vote required) - Compile and link 1.1.1 command line app against the master headers and library. Run 1.1.1 app test cases against the chimera. Treat this as an external test using a special 1.1.1 branch. Deprecated functions used by libssl should be moved to independent file(s), to limit the suppression of deprecated defines to the absolute minimum scope. * Draft documentation (contents but not pretty) - Need a list of things we know are not present - including things we have removed. - We need to have mapping tables for various d2i/i2d functions. - We need to have a mapping table from ?old names? for things into the OSSL_PARAMS names. - Documentation addition to old APIs to refer to new ones (man7). - Documentation needs to reference name mapping. - All the legacy interfaces need to have their documentation pointing to the replacement interfaces. * Review (and maybe clean up) legacy bridge code. * Review TODO(3.0) items #12224. * Source checksum script. * Review of functions previously named _with_libctx. * Encoder fixers (PKCS#8, PKCS#1, etc). * Encoder DER to PEM refactor. * Builds and passes tests on all primary, secondary and FIPS platforms. * Query provider parameters (name, version, ?) from the command line. * Setup buildbot infrastructure and associated instructions. * Complete make fipsinstall. * More specific decoding selection (e.g. params or keys). * Example code covering replacements for deprecated APIs. * Drop C code output options from the apps (OMC approval required). * Address 3.0beta1 milestones. Matt From paul.dale at oracle.com Wed Oct 7 11:54:15 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 7 Oct 2020 21:54:15 +1000 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> Message-ID: <015FBCCC-C032-4286-A0BA-9179BDA2FB8E@oracle.com> Would it be feasible to change code that does ->pub_key to call a function that null checks the field and generates the public key if it is absent? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 7 Oct 2020, at 9:29 pm, Matt Caswell wrote: > > Issue #12612 exposes a problem with how we handle keys that contain > private components but not public components. > > There is a widespread assumption in the code that keys with private > components must have public components. There is text in our public > documentation that states this (and that text dates back to 2006). > > OTOH, the code has not always enforced this. Issue #12612 describes a > scenario where this has not historically been enforced, and it now is in > the current 3.0 code causing a regression. > > There are differences of opinion on how this should be handled. Some > have the opinion that we should change the model so that we explicitly > allow private keys to exists without the public components. Others feel > that we should continue with the old model. > > It seems we need a vote to decide this. Here is my proposed vote text: > > We should change the 3.0 code to explicitly allow private components to > exist in keys without the public components also being present. > > Feedback please on the proposed vote text. > > Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Wed Oct 7 11:58:15 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 07 Oct 2020 13:58:15 +0200 Subject: Vote proposal: Technical items still to be done In-Reply-To: References: Message-ID: <2ff2a124709f7e13407b60058d0e2770947d4bf2.camel@redhat.com> On Wed, 2020-10-07 at 12:35 +0100, Matt Caswell wrote: > I had an action from the OTC meeting today to raise a vote on the OTC > list of technical items still to be done. Here is my proposed vote > text. > There will be a subsequent vote on the "beta readiness checklist" > which > is a separate list. > > Feedback please on the proposed vote text below. > > The following items are required prerequisites for the first beta > release: > * EVP is the recommended API, it must be feature-complete compared > with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to > exclude. > - The apps are the minimum bar for this, subject to exceptions > noted > below. > * Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the > EVP interface: rewrite them so they do not use internal nor > deprecated > functions (except speed, engine, list, passwd -crypt and the code to > handle the -engine CLI option). That is, remove the suppression of > deprecated define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master > headers > and library. Run 1.1.1 app test cases against the chimera. Treat > this > as an external test using a special 1.1.1 branch. > Deprecated functions used by libssl should be moved to independent > file(s), to limit the suppression of deprecated defines to the > absolute > minimum scope. > * Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things > we > have removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into > the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to the replacement interfaces. > * Review (and maybe clean up) legacy bridge code. > * Review TODO(3.0) items #12224. > * Source checksum script. > * Review of functions previously named _with_libctx. > * Encoder fixers (PKCS#8, PKCS#1, etc). > * Encoder DER to PEM refactor. > * Builds and passes tests on all primary, secondary and FIPS > platforms. > * Query provider parameters (name, version, ?) from the command line. > * Setup buildbot infrastructure and associated instructions. > * Complete make fipsinstall. > * More specific decoding selection (e.g. params or keys). > * Example code covering replacements for deprecated APIs. > * Drop C code output options from the apps (OMC approval required). > * Address 3.0beta1 milestones. Address issues and PRs in the 3.0beta1 milestone. -- 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 nic.tuv at gmail.com Wed Oct 7 13:53:02 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 7 Oct 2020 16:53:02 +0300 Subject: [VOTE PROPOSAL] Weekly OTC meeting until 3.0 beta1 is released Message-ID: Background ---------- Since the two virtual face-to-face OTC meetings of last week, and again in the two OTC meetings this week, we repeatedly discussed replacing the weekly "developer meetings" with official OTC meetings. The "developer meetings" have so far seen frequent participation from a subset of OTC members heavily involved in day to day tasks for the [`3.0 New Core + FIPS` project][new_core+FIPS], and have been open and advertised to all OTC members since the end of January, but they were not qualified as official OTC meetings: they were meant to assess the weekly progress within the project, and determine the coming week's priorities, discussing and resolving any difficulties encountered. Rationale --------- At this point in the development process, in which we are refining the state of development branch to finally qualify for the transition into the beta release stage, upgrading these meetings to proper OTC meetings seems appropriate and desirable, as discussion and assessment of the remaining technical tasks increasingly requires discussion within the OTC and OTC decisions, and additionally provides OTC steering on the preferred way of completing some of the allocated tasks before the work is done, rather than after the fact. Personally, I also expect that upgrading the developer meetings into full-fledged OTC meetings will increase attendance by the wider OTC audience: this would provide the OTC as a whole with better oversight on the progress towards the upcoming release, and would further improve the quality of the release process by leveraging the plurality of OTC perspectives and insights. Meeting Schedule ---------------- So far, the "developer meetings" have been regularly scheduled each Tuesday from 08:00 to 09:30 (UTC, 24h format), with a tendency to spill into the next half-hour. There have been cases in which we had to hit the 3h mark, but I wouldn't describe 3h as the norm. My proposal for the OTC meeting is to adopt the same 1h30m (+30m buffer) approach. Tuesday, 08:00 UTC as the starting time, has been so far a good compromise between folks working in European and Australian timezone, and keeping it is the current proposal, but is admittedly not the best time for attendance from the American continents. Vote: why and when? ------------------- We are proposing a vote, rather than agreeing on it during the last call, to invite discussion from the OTC members that could not participate in the meetings during these two weeks, for example regarding alternative time slots to improve overall attendance. I plan to wait until Friday to open the actual vote: please provide feedback before then if you would like to amend the letter of the vote topic. One item on which I'd like to ask for feedback is if the actual vote text should include the specifics of the timeslot or not. Proposed vote text ------------------ Hold online weekly OTC meetings starting on Tuesday 2020-10-13 and until 3.0 beta1 is released, in lieu of the weekly "developer meetings". Refs ---- [new_core+FIPS]: https://github.com/openssl/openssl/projects/2 From nic.tuv at gmail.com Wed Oct 7 14:23:25 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 7 Oct 2020 17:23:25 +0300 Subject: Vote proposal: Technical items still to be done In-Reply-To: <2ff2a124709f7e13407b60058d0e2770947d4bf2.camel@redhat.com> References: <2ff2a124709f7e13407b60058d0e2770947d4bf2.camel@redhat.com> Message-ID: I support the edit proposed by Tomas. First comment that I have is that I'd prefer the first-level items to be actually numbered, as done in the drafts: we might put a disclaimer that the numbers are not indicative of priority and just meant to be used to address (equally important) tasks by index. The second comment is just a quirk of mine: I prefer plain text emails and Markdown formatting. If others shared the feeling (and nobody objected to Markdown for our records) I'd volunteer to reformat the draft of this vote text using Markdown syntax. Nicola On Wed, 7 Oct 2020 at 14:58, Tomas Mraz wrote: > > On Wed, 2020-10-07 at 12:35 +0100, Matt Caswell wrote: > > I had an action from the OTC meeting today to raise a vote on the OTC > > list of technical items still to be done. Here is my proposed vote > > text. > > There will be a subsequent vote on the "beta readiness checklist" > > which > > is a separate list. > > > > Feedback please on the proposed vote text below. > > > > The following items are required prerequisites for the first beta > > release: > > * EVP is the recommended API, it must be feature-complete compared > > with > > the functionality available using lower-level APIs. > > - Anything that isn?t available must be put to an OTC vote to > > exclude. > > - The apps are the minimum bar for this, subject to exceptions > > noted > > below. > > * Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > > RAND_METHOD_. > > - Does not include macros defining useful constants (e.g. > > SHA512_DIGEST_LENGTH). > > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > > - There might be some others. > > - Review for exceptions. > > - The apps are the minimum bar to measure feature completeness for > > the > > EVP interface: rewrite them so they do not use internal nor > > deprecated > > functions (except speed, engine, list, passwd -crypt and the code to > > handle the -engine CLI option). That is, remove the suppression of > > deprecated define. > > - Proposal: drop passwd -crypt (OMC vote required) > > - Compile and link 1.1.1 command line app against the master > > headers > > and library. Run 1.1.1 app test cases against the chimera. Treat > > this > > as an external test using a special 1.1.1 branch. > > Deprecated functions used by libssl should be moved to independent > > file(s), to limit the suppression of deprecated defines to the > > absolute > > minimum scope. > > * Draft documentation (contents but not pretty) > > - Need a list of things we know are not present - including things > > we > > have removed. > > - We need to have mapping tables for various d2i/i2d functions. > > - We need to have a mapping table from ?old names? for things into > > the > > OSSL_PARAMS names. > > - Documentation addition to old APIs to refer to new ones (man7). > > - Documentation needs to reference name mapping. > > - All the legacy interfaces need to have their documentation > > pointing to the replacement interfaces. > > * Review (and maybe clean up) legacy bridge code. > > * Review TODO(3.0) items #12224. > > * Source checksum script. > > * Review of functions previously named _with_libctx. > > * Encoder fixers (PKCS#8, PKCS#1, etc). > > * Encoder DER to PEM refactor. > > * Builds and passes tests on all primary, secondary and FIPS > > platforms. > > * Query provider parameters (name, version, ?) from the command line. > > * Setup buildbot infrastructure and associated instructions. > > * Complete make fipsinstall. > > * More specific decoding selection (e.g. params or keys). > > * Example code covering replacements for deprecated APIs. > > * Drop C code output options from the apps (OMC approval required). > > * Address 3.0beta1 milestones. > > Address issues and PRs in the 3.0beta1 milestone. > > -- > 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 nic.tuv at gmail.com Wed Oct 7 15:34:25 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 7 Oct 2020 18:34:25 +0300 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> Message-ID: I believe the current formulation is slightly concealing part of the problem. The way I see it, the intention if the vote passes is to do more than stated: 1. change the long-documented assumption 2. fix "regressions" in 3.0 limited to things that worked in a certain way in 1.1.1 (and maybe before), _despite_ the documented assumption 3. test all existing functions that access the public key component of `EVP_PKEY` (or lower level) objects to ensure they don't rely on the long-documented assumption 4. fix all the places that intentionally relied on the long-documented assumption and that were required to avoid "useless NULL checks" I believe that to change a widely and longed-enforced assumption like this, we can't rely on a single case or a list of single cases that worked _despite_ the documented assumption as proof that things can (and should) work a certain way or another, and that before taking the decision this late in the development process the results of thorough testing are a prerequisite to assess the extent of code changes required by changing the assumption and the potential for instability and disruption that this can cause for our direct and indirect users if segfaults slip through our currently limited coverage as a consequence of this change. I feel that we are currently underestimating the potential impact of this change, and currently motivated by a handful of isolated cases in which under a very specific set of conditions things aligned in a way that allowed certain usage patterns to succeed despite the documented assumption. I also feel that the "burden of the proof" of improving the test coverage to exhaustively cover all kinds of keys (both in their legacy form and in provider-native form), under all possible operations at different abstraction levels (e.g. limiting this example to sign/verify as the operation, testing should not be limited to `EVP_DigestSign/Verify()`, but also through `EVP_DigestSign/Verify{Init,Update,Final}()`, `EVP_PKEY_sign/verify*()`, `(EC)DSA_(do_)sign/verify()`, etc., external testing with ENGINEs that might rely on the long-documented assumption), should fall on who is proposing this change, rather than committing that we will be able to increase our coverage to prevent unforeseen consequences of changing the assumption, before we can decide to commit to alter the assumption. So, to better capture the extent of work required to apply the change and the risks associated with it I would rephrase the text vote as follows: > We should change the 3.0 code to explicitly allow private components > to exist in keys without the public components also being present, > ensuring that, in `EVP` and in the lower abstraction layers, both in > legacy and in provider-native codepaths, _every_ instance in which any > public key component is dereferenced it is preceded by a NULL pointer > check or guaranteed non-NULL from any caller. > To change the long documented assumption, we commit to improve test > coverage of all public functions directly or indirectly triggering > potential access to public key components, to prevent the risk of user > facing crashes. Nicola On Wed, 7 Oct 2020 at 14:29, Matt Caswell wrote: > > Issue #12612 exposes a problem with how we handle keys that contain > private components but not public components. > > There is a widespread assumption in the code that keys with private > components must have public components. There is text in our public > documentation that states this (and that text dates back to 2006). > > OTOH, the code has not always enforced this. Issue #12612 describes a > scenario where this has not historically been enforced, and it now is in > the current 3.0 code causing a regression. > > There are differences of opinion on how this should be handled. Some > have the opinion that we should change the model so that we explicitly > allow private keys to exists without the public components. Others feel > that we should continue with the old model. > > It seems we need a vote to decide this. Here is my proposed vote text: > > We should change the 3.0 code to explicitly allow private components to > exist in keys without the public components also being present. > > Feedback please on the proposed vote text. > > Matt From matt at openssl.org Wed Oct 7 16:15:36 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2020 17:15:36 +0100 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> Message-ID: <97c3c8f3-2019-d20e-38b0-f591f424c9ff@openssl.org> I would also be ok with this vote text formulation. Lets see what others say. Matt On 07/10/2020 16:34, Nicola Tuveri wrote: > I believe the current formulation is slightly concealing part of the problem. > > The way I see it, the intention if the vote passes is to do more than stated: > 1. change the long-documented assumption > 2. fix "regressions" in 3.0 limited to things that worked in a certain > way in 1.1.1 (and maybe before), _despite_ the documented assumption > 3. test all existing functions that access the public key component of > `EVP_PKEY` (or lower level) objects to ensure they don't rely on the > long-documented assumption > 4. fix all the places that intentionally relied on the long-documented > assumption and that were required to avoid "useless NULL checks" > > I believe that to change a widely and longed-enforced assumption like > this, we can't rely on a single case or a list of single cases that > worked _despite_ the documented assumption as proof that things can > (and should) work a certain way or another, and that before taking the > decision this late in the development process the results of thorough > testing are a prerequisite to assess the extent of code changes > required by changing the assumption and the potential for instability > and disruption that this can cause for our direct and indirect users > if segfaults slip through our currently limited coverage as a > consequence of this change. > > I feel that we are currently underestimating the potential impact of > this change, and currently motivated by a handful of isolated cases in > which under a very specific set of conditions things aligned in a way > that allowed certain usage patterns to succeed despite the documented > assumption. > I also feel that the "burden of the proof" of improving the test > coverage to exhaustively cover all kinds of keys (both in their legacy > form and in provider-native form), under all possible operations at > different abstraction levels (e.g. limiting this example to > sign/verify as the operation, testing should not be limited to > `EVP_DigestSign/Verify()`, but also through > `EVP_DigestSign/Verify{Init,Update,Final}()`, > `EVP_PKEY_sign/verify*()`, `(EC)DSA_(do_)sign/verify()`, etc., > external testing with ENGINEs that might rely on the long-documented > assumption), should fall on who is proposing this change, rather than > committing that we will be able to increase our coverage to prevent > unforeseen consequences of changing the assumption, before we can > decide to commit to alter the assumption. > > So, to better capture the extent of work required to apply the change > and the risks associated with it I would rephrase the text vote as > follows: > >> We should change the 3.0 code to explicitly allow private components >> to exist in keys without the public components also being present, >> ensuring that, in `EVP` and in the lower abstraction layers, both in >> legacy and in provider-native codepaths, _every_ instance in which any >> public key component is dereferenced it is preceded by a NULL pointer >> check or guaranteed non-NULL from any caller. >> To change the long documented assumption, we commit to improve test >> coverage of all public functions directly or indirectly triggering >> potential access to public key components, to prevent the risk of user >> facing crashes. > > > Nicola > > > > > On Wed, 7 Oct 2020 at 14:29, Matt Caswell wrote: >> >> Issue #12612 exposes a problem with how we handle keys that contain >> private components but not public components. >> >> There is a widespread assumption in the code that keys with private >> components must have public components. There is text in our public >> documentation that states this (and that text dates back to 2006). >> >> OTOH, the code has not always enforced this. Issue #12612 describes a >> scenario where this has not historically been enforced, and it now is in >> the current 3.0 code causing a regression. >> >> There are differences of opinion on how this should be handled. Some >> have the opinion that we should change the model so that we explicitly >> allow private keys to exists without the public components. Others feel >> that we should continue with the old model. >> >> It seems we need a vote to decide this. Here is my proposed vote text: >> >> We should change the 3.0 code to explicitly allow private components to >> exist in keys without the public components also being present. >> >> Feedback please on the proposed vote text. >> >> Matt > From matt at openssl.org Wed Oct 7 16:36:28 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2020 17:36:28 +0100 Subject: Alpha releases In-Reply-To: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> References: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> Message-ID: This vote has now started. I'll post here with the results once its complete. Matt On 06/10/2020 13:12, Matt Caswell wrote: > The OTC meeting today discussed making further alpha releases while we > continue to work towards getting to beta 1. It was proposed that we > release alpha 7 on Thursday 15h October and then regularly on a 3 weekly > basis thereafter until such time as beta 1 is ready. > > This will need to be an OMC decision so this is my suggested vote wording: > > "OpenSSL 3.0 Alpha 7 shouuld be released on Thursday 15th October and > subsequent alpha releases should be performed on a 3 weekly basis until > beta 1 is ready" > > I'd like to give an opportunity for feedback on the above before I call > this vote. > > Note that the OTC discussions on beta 1 (looking at the proposal that > Nicola posted to this list last Friday) are still ongoing. There will be > a further meeting tomorrow. > > Matt > From levitte at openssl.org Wed Oct 7 16:52:48 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 07 Oct 2020 18:52:48 +0200 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> Message-ID: <875z7m2d27.wl-levitte@openssl.org> As far as I can tell, the existing "enforcement" is in the algorithm implementations. I had a look through the following files in OpenSSL 1.1.1: crypto/rsa/rsa_ossl.c crypto/dsa/dsa_ossl.c crypto/dh/dh_key.c crypto/ec/ecdsa_ossl.c crypto/ec/ecdh_ossl.c I first had a look at the key computing functions in dh_key.c and ecdh_ossl.c, because I was told that the public key is looked at there. This turns out to be somewhat false; they do look at a public key, the public key of the peer key that they get passed, which isn't quite the same. However, when it comes to the DH or EC_KEY they work with, only the private half is looked at, Looking at dsa_ossl.c and ecdsa_ossl.c, I can see that the signing functions do NOT look a |pub_key|, and the verification functions do NOT look at |priv_key|. This seems perfectly normal to me. Similarly, the signing functions in rsa_ossl.c do NOT seem to look at |d|, and the verification functions do NOT seem to look at |e|. I took a moment to search through the corresponding *meth.c files to see if I could quickly grep for some kind of check, and found none. Mind you, that was a *quick* grep, someone more thorough might want to confirm or contradict. So, having looked through that code, my sense is that the "enforcement" that's talked about is non-existent, or at least very unclear, and I suspect that if there is some sort of "enforcement" at that level, it's more accidental than by design... I'm not sure what to make of the documentation from 2006. Considering the level of involvement there was from diverse people (2006 wasn't exactly the most eventful time), there's a possibility that it was a precaution ("don't touch that can of worms!") than a firm decision. Cheers, Richard On Wed, 07 Oct 2020 17:34:25 +0200, Nicola Tuveri wrote: > > I believe the current formulation is slightly concealing part of the problem. > > The way I see it, the intention if the vote passes is to do more than stated: > 1. change the long-documented assumption > 2. fix "regressions" in 3.0 limited to things that worked in a certain > way in 1.1.1 (and maybe before), _despite_ the documented assumption > 3. test all existing functions that access the public key component of > `EVP_PKEY` (or lower level) objects to ensure they don't rely on the > long-documented assumption > 4. fix all the places that intentionally relied on the long-documented > assumption and that were required to avoid "useless NULL checks" > > I believe that to change a widely and longed-enforced assumption like > this, we can't rely on a single case or a list of single cases that > worked _despite_ the documented assumption as proof that things can > (and should) work a certain way or another, and that before taking the > decision this late in the development process the results of thorough > testing are a prerequisite to assess the extent of code changes > required by changing the assumption and the potential for instability > and disruption that this can cause for our direct and indirect users > if segfaults slip through our currently limited coverage as a > consequence of this change. > > I feel that we are currently underestimating the potential impact of > this change, and currently motivated by a handful of isolated cases in > which under a very specific set of conditions things aligned in a way > that allowed certain usage patterns to succeed despite the documented > assumption. > I also feel that the "burden of the proof" of improving the test > coverage to exhaustively cover all kinds of keys (both in their legacy > form and in provider-native form), under all possible operations at > different abstraction levels (e.g. limiting this example to > sign/verify as the operation, testing should not be limited to > `EVP_DigestSign/Verify()`, but also through > `EVP_DigestSign/Verify{Init,Update,Final}()`, > `EVP_PKEY_sign/verify*()`, `(EC)DSA_(do_)sign/verify()`, etc., > external testing with ENGINEs that might rely on the long-documented > assumption), should fall on who is proposing this change, rather than > committing that we will be able to increase our coverage to prevent > unforeseen consequences of changing the assumption, before we can > decide to commit to alter the assumption. > > So, to better capture the extent of work required to apply the change > and the risks associated with it I would rephrase the text vote as > follows: > > > We should change the 3.0 code to explicitly allow private components > > to exist in keys without the public components also being present, > > ensuring that, in `EVP` and in the lower abstraction layers, both in > > legacy and in provider-native codepaths, _every_ instance in which any > > public key component is dereferenced it is preceded by a NULL pointer > > check or guaranteed non-NULL from any caller. > > To change the long documented assumption, we commit to improve test > > coverage of all public functions directly or indirectly triggering > > potential access to public key components, to prevent the risk of user > > facing crashes. > > > Nicola > > > > > On Wed, 7 Oct 2020 at 14:29, Matt Caswell wrote: > > > > Issue #12612 exposes a problem with how we handle keys that contain > > private components but not public components. > > > > There is a widespread assumption in the code that keys with private > > components must have public components. There is text in our public > > documentation that states this (and that text dates back to 2006). > > > > OTOH, the code has not always enforced this. Issue #12612 describes a > > scenario where this has not historically been enforced, and it now is in > > the current 3.0 code causing a regression. > > > > There are differences of opinion on how this should be handled. Some > > have the opinion that we should change the model so that we explicitly > > allow private keys to exists without the public components. Others feel > > that we should continue with the old model. > > > > It seems we need a vote to decide this. Here is my proposed vote text: > > > > We should change the 3.0 code to explicitly allow private components to > > exist in keys without the public components also being present. > > > > Feedback please on the proposed vote text. > > > > Matt > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Wed Oct 7 17:17:58 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 07 Oct 2020 19:17:58 +0200 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> Message-ID: <87362q2bw9.wl-levitte@openssl.org> There's no reason for the EVP layer to check for the presence or the absence or the public key, for one very simple reason: it doesn't have access to the backend key structure and therefore has no possibility to make any such checks. Such checks should be made in the backend. That part of your proposed vote text that mentions checks in EVP doesn't make any sense with that in mind, and I fear that it would lead us into a rabbit hole that's not really necessary. Also, this contradicts the intentions of the design for libcrypto vs providers, which was that libcrypto (and therefore EVP) would be a rather thin layer that simply passes stuff to the providers and gets results back (there are things that complicate this a bit, but this is essentially what we do), and leave it to the provider to decide what to do and how to do it. Cheers, Richard On Wed, 07 Oct 2020 17:34:25 +0200, Nicola Tuveri wrote: > > I believe the current formulation is slightly concealing part of the problem. > > The way I see it, the intention if the vote passes is to do more than stated: > 1. change the long-documented assumption > 2. fix "regressions" in 3.0 limited to things that worked in a certain > way in 1.1.1 (and maybe before), _despite_ the documented assumption > 3. test all existing functions that access the public key component of > `EVP_PKEY` (or lower level) objects to ensure they don't rely on the > long-documented assumption > 4. fix all the places that intentionally relied on the long-documented > assumption and that were required to avoid "useless NULL checks" > > I believe that to change a widely and longed-enforced assumption like > this, we can't rely on a single case or a list of single cases that > worked _despite_ the documented assumption as proof that things can > (and should) work a certain way or another, and that before taking the > decision this late in the development process the results of thorough > testing are a prerequisite to assess the extent of code changes > required by changing the assumption and the potential for instability > and disruption that this can cause for our direct and indirect users > if segfaults slip through our currently limited coverage as a > consequence of this change. > > I feel that we are currently underestimating the potential impact of > this change, and currently motivated by a handful of isolated cases in > which under a very specific set of conditions things aligned in a way > that allowed certain usage patterns to succeed despite the documented > assumption. > I also feel that the "burden of the proof" of improving the test > coverage to exhaustively cover all kinds of keys (both in their legacy > form and in provider-native form), under all possible operations at > different abstraction levels (e.g. limiting this example to > sign/verify as the operation, testing should not be limited to > `EVP_DigestSign/Verify()`, but also through > `EVP_DigestSign/Verify{Init,Update,Final}()`, > `EVP_PKEY_sign/verify*()`, `(EC)DSA_(do_)sign/verify()`, etc., > external testing with ENGINEs that might rely on the long-documented > assumption), should fall on who is proposing this change, rather than > committing that we will be able to increase our coverage to prevent > unforeseen consequences of changing the assumption, before we can > decide to commit to alter the assumption. > > So, to better capture the extent of work required to apply the change > and the risks associated with it I would rephrase the text vote as > follows: > > > We should change the 3.0 code to explicitly allow private components > > to exist in keys without the public components also being present, > > ensuring that, in `EVP` and in the lower abstraction layers, both in > > legacy and in provider-native codepaths, _every_ instance in which any > > public key component is dereferenced it is preceded by a NULL pointer > > check or guaranteed non-NULL from any caller. > > To change the long documented assumption, we commit to improve test > > coverage of all public functions directly or indirectly triggering > > potential access to public key components, to prevent the risk of user > > facing crashes. > > > Nicola > > > > > On Wed, 7 Oct 2020 at 14:29, Matt Caswell wrote: > > > > Issue #12612 exposes a problem with how we handle keys that contain > > private components but not public components. > > > > There is a widespread assumption in the code that keys with private > > components must have public components. There is text in our public > > documentation that states this (and that text dates back to 2006). > > > > OTOH, the code has not always enforced this. Issue #12612 describes a > > scenario where this has not historically been enforced, and it now is in > > the current 3.0 code causing a regression. > > > > There are differences of opinion on how this should be handled. Some > > have the opinion that we should change the model so that we explicitly > > allow private keys to exists without the public components. Others feel > > that we should continue with the old model. > > > > It seems we need a vote to decide this. Here is my proposed vote text: > > > > We should change the 3.0 code to explicitly allow private components to > > exist in keys without the public components also being present. > > > > Feedback please on the proposed vote text. > > > > Matt > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From nic.tuv at gmail.com Wed Oct 7 17:20:45 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 7 Oct 2020 20:20:45 +0300 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <875z7m2d27.wl-levitte@openssl.org> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <875z7m2d27.wl-levitte@openssl.org> Message-ID: Re; "enforcement" My impression is that there is no such enforcement, because the project has (had?) a stance on "avoid NULL checks" and "consider things that break our documented assumptions as programmer errors". The natural result of these two principles may very well be the deliberate reason why "enforcement" cannot be found and we might perceive documentation written in 2006 as not current. I can say that in the past 4 years within PR I authored or co-authored, even before becoming a Committer, I can recall reviews requesting to amend the code to avoid NULL checks on the public key component because it is our convention that an EVP_PKEY with key material is either a public key or a key pair. Nicola On Wed, 7 Oct 2020 at 19:52, Richard Levitte wrote: > > As far as I can tell, the existing "enforcement" is in the algorithm > implementations. I had a look through the following files in OpenSSL > 1.1.1: > > crypto/rsa/rsa_ossl.c > crypto/dsa/dsa_ossl.c > crypto/dh/dh_key.c > crypto/ec/ecdsa_ossl.c > crypto/ec/ecdh_ossl.c > > I first had a look at the key computing functions in dh_key.c and > ecdh_ossl.c, because I was told that the public key is looked at > there. This turns out to be somewhat false; they do look at a public > key, the public key of the peer key that they get passed, which isn't > quite the same. However, when it comes to the DH or EC_KEY they work > with, only the private half is looked at, > > Looking at dsa_ossl.c and ecdsa_ossl.c, I can see that the signing > functions do NOT look a |pub_key|, and the verification functions do > NOT look at |priv_key|. This seems perfectly normal to me. > > Similarly, the signing functions in rsa_ossl.c do NOT seem to look at > |d|, and the verification functions do NOT seem to look at |e|. > > I took a moment to search through the corresponding *meth.c files to > see if I could quickly grep for some kind of check, and found none. > Mind you, that was a *quick* grep, someone more thorough might want to > confirm or contradict. > > So, having looked through that code, my sense is that the "enforcement" > that's talked about is non-existent, or at least very unclear, and I > suspect that if there is some sort of "enforcement" at that level, > it's more accidental than by design... > > I'm not sure what to make of the documentation from 2006. Considering > the level of involvement there was from diverse people (2006 wasn't > exactly the most eventful time), there's a possibility that it was a > precaution ("don't touch that can of worms!") than a firm decision. > > Cheers, > Richard > > On Wed, 07 Oct 2020 17:34:25 +0200, > Nicola Tuveri wrote: > > > > I believe the current formulation is slightly concealing part of the problem. > > > > The way I see it, the intention if the vote passes is to do more than stated: > > 1. change the long-documented assumption > > 2. fix "regressions" in 3.0 limited to things that worked in a certain > > way in 1.1.1 (and maybe before), _despite_ the documented assumption > > 3. test all existing functions that access the public key component of > > `EVP_PKEY` (or lower level) objects to ensure they don't rely on the > > long-documented assumption > > 4. fix all the places that intentionally relied on the long-documented > > assumption and that were required to avoid "useless NULL checks" > > > > I believe that to change a widely and longed-enforced assumption like > > this, we can't rely on a single case or a list of single cases that > > worked _despite_ the documented assumption as proof that things can > > (and should) work a certain way or another, and that before taking the > > decision this late in the development process the results of thorough > > testing are a prerequisite to assess the extent of code changes > > required by changing the assumption and the potential for instability > > and disruption that this can cause for our direct and indirect users > > if segfaults slip through our currently limited coverage as a > > consequence of this change. > > > > I feel that we are currently underestimating the potential impact of > > this change, and currently motivated by a handful of isolated cases in > > which under a very specific set of conditions things aligned in a way > > that allowed certain usage patterns to succeed despite the documented > > assumption. > > I also feel that the "burden of the proof" of improving the test > > coverage to exhaustively cover all kinds of keys (both in their legacy > > form and in provider-native form), under all possible operations at > > different abstraction levels (e.g. limiting this example to > > sign/verify as the operation, testing should not be limited to > > `EVP_DigestSign/Verify()`, but also through > > `EVP_DigestSign/Verify{Init,Update,Final}()`, > > `EVP_PKEY_sign/verify*()`, `(EC)DSA_(do_)sign/verify()`, etc., > > external testing with ENGINEs that might rely on the long-documented > > assumption), should fall on who is proposing this change, rather than > > committing that we will be able to increase our coverage to prevent > > unforeseen consequences of changing the assumption, before we can > > decide to commit to alter the assumption. > > > > So, to better capture the extent of work required to apply the change > > and the risks associated with it I would rephrase the text vote as > > follows: > > > > > We should change the 3.0 code to explicitly allow private components > > > to exist in keys without the public components also being present, > > > ensuring that, in `EVP` and in the lower abstraction layers, both in > > > legacy and in provider-native codepaths, _every_ instance in which any > > > public key component is dereferenced it is preceded by a NULL pointer > > > check or guaranteed non-NULL from any caller. > > > To change the long documented assumption, we commit to improve test > > > coverage of all public functions directly or indirectly triggering > > > potential access to public key components, to prevent the risk of user > > > facing crashes. > > > > > > Nicola > > > > > > > > > > On Wed, 7 Oct 2020 at 14:29, Matt Caswell wrote: > > > > > > Issue #12612 exposes a problem with how we handle keys that contain > > > private components but not public components. > > > > > > There is a widespread assumption in the code that keys with private > > > components must have public components. There is text in our public > > > documentation that states this (and that text dates back to 2006). > > > > > > OTOH, the code has not always enforced this. Issue #12612 describes a > > > scenario where this has not historically been enforced, and it now is in > > > the current 3.0 code causing a regression. > > > > > > There are differences of opinion on how this should be handled. Some > > > have the opinion that we should change the model so that we explicitly > > > allow private keys to exists without the public components. Others feel > > > that we should continue with the old model. > > > > > > It seems we need a vote to decide this. Here is my proposed vote text: > > > > > > We should change the 3.0 code to explicitly allow private components to > > > exist in keys without the public components also being present. > > > > > > Feedback please on the proposed vote text. > > > > > > Matt > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Wed Oct 7 17:29:38 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 7 Oct 2020 19:29:38 +0200 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> Message-ID: <20201007172938.GA45463@roeckx.be> On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote: > Issue #12612 exposes a problem with how we handle keys that contain > private components but not public components. > > There is a widespread assumption in the code that keys with private > components must have public components. There is text in our public > documentation that states this (and that text dates back to 2006). > > OTOH, the code has not always enforced this. Issue #12612 describes a > scenario where this has not historically been enforced, and it now is in > the current 3.0 code causing a regression. > > There are differences of opinion on how this should be handled. Some > have the opinion that we should change the model so that we explicitly > allow private keys to exists without the public components. Others feel > that we should continue with the old model. It seems to me that we have various ways forward: 1) Enforce that a private key requires the public key 2) Don't enforce it, just give an error when you try to use the public key and it's not available. 3) Make it work for the same cases that worked with 1.1.1 4) Generate the public key from the private key 5) Have some kind of transition where we do 2), 3) or 4) in 3.0, but will move to 1) at some later point. 6) do 2), but enforce it in the fips provider I don't know if we do any any kind of consistency checks on the key now when it's loaded. But 2) would then imply that the check is skipped instead of returning an error. Kurt From beldmit at gmail.com Wed Oct 7 17:31:54 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 7 Oct 2020 20:31:54 +0300 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <20201007172938.GA45463@roeckx.be> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <20201007172938.GA45463@roeckx.be> Message-ID: On Wed, Oct 7, 2020 at 8:29 PM Kurt Roeckx wrote: > On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote: > > Issue #12612 exposes a problem with how we handle keys that contain > > private components but not public components. > > > > There is a widespread assumption in the code that keys with private > > components must have public components. There is text in our public > > documentation that states this (and that text dates back to 2006). > > > > OTOH, the code has not always enforced this. Issue #12612 describes a > > scenario where this has not historically been enforced, and it now is in > > the current 3.0 code causing a regression. > > > > There are differences of opinion on how this should be handled. Some > > have the opinion that we should change the model so that we explicitly > > allow private keys to exists without the public components. Others feel > > that we should continue with the old model. > > It seems to me that we have various ways forward: > 1) Enforce that a private key requires the public key > 2) Don't enforce it, just give an error when you try to use the > public key and it's not available. > 3) Make it work for the same cases that worked with 1.1.1 > 4) Generate the public key from the private key > 5) Have some kind of transition where we do 2), 3) > or 4) in 3.0, but will move to 1) at some later point. > 6) do 2), but enforce it in the fips provider > > I don't know if we do any any kind of consistency checks on the key > now when it's loaded. But 2) would then imply that the check is > skipped instead of returning an error. > 4) maybe not applicable when a private key is on the hardware token. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Oct 7 17:45:44 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 07 Oct 2020 19:45:44 +0200 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <875z7m2d27.wl-levitte@openssl.org> Message-ID: <871ria2alz.wl-levitte@openssl.org> I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY with a private key should have a public key. I was incorrect. Regarding avoiding NULL checks, that's actually a separate story, evem though it overlaps conveniently. There was the idea, for a while, that we should avoid NULL checks everywhere (unless it's valid input), and indeed make it a programmer error if they happened to pass NULL where they shouldn't. One can see that as an hard assertion, and that has indeed produced crashes that uncovered bugs we might otherwise have missed. The tide has changed though, and it seem like the fashion du jour is to check NULLs and error with an ERR_R_PASSED_NULL_PARAMETER. I'm not sure that we've made an actual hard decision in either direction, though. However, I'm not sure where the NULL check problem comes in. Operations that don't use the public key parts don't need to look at the public key parts, so a NULL check there is simply not necessary. Cheers, Richard On Wed, 07 Oct 2020 19:20:45 +0200, Nicola Tuveri wrote: > > Re; "enforcement" > > My impression is that there is no such enforcement, because the > project has (had?) a stance on "avoid NULL checks" and "consider > things that break our documented assumptions as programmer errors". > > The natural result of these two principles may very well be the > deliberate reason why "enforcement" cannot be found and we might > perceive documentation written in 2006 as not current. > > I can say that in the past 4 years within PR I authored or > co-authored, even before becoming a Committer, I can recall reviews > requesting to amend the code to avoid NULL checks on the public key > component because it is our convention that an EVP_PKEY with key > material is either a public key or a key pair. > > > Nicola > > On Wed, 7 Oct 2020 at 19:52, Richard Levitte wrote: > > > > As far as I can tell, the existing "enforcement" is in the algorithm > > implementations. I had a look through the following files in OpenSSL > > 1.1.1: > > > > crypto/rsa/rsa_ossl.c > > crypto/dsa/dsa_ossl.c > > crypto/dh/dh_key.c > > crypto/ec/ecdsa_ossl.c > > crypto/ec/ecdh_ossl.c > > > > I first had a look at the key computing functions in dh_key.c and > > ecdh_ossl.c, because I was told that the public key is looked at > > there. This turns out to be somewhat false; they do look at a public > > key, the public key of the peer key that they get passed, which isn't > > quite the same. However, when it comes to the DH or EC_KEY they work > > with, only the private half is looked at, > > > > Looking at dsa_ossl.c and ecdsa_ossl.c, I can see that the signing > > functions do NOT look a |pub_key|, and the verification functions do > > NOT look at |priv_key|. This seems perfectly normal to me. > > > > Similarly, the signing functions in rsa_ossl.c do NOT seem to look at > > |d|, and the verification functions do NOT seem to look at |e|. > > > > I took a moment to search through the corresponding *meth.c files to > > see if I could quickly grep for some kind of check, and found none. > > Mind you, that was a *quick* grep, someone more thorough might want to > > confirm or contradict. > > > > So, having looked through that code, my sense is that the "enforcement" > > that's talked about is non-existent, or at least very unclear, and I > > suspect that if there is some sort of "enforcement" at that level, > > it's more accidental than by design... > > > > I'm not sure what to make of the documentation from 2006. Considering > > the level of involvement there was from diverse people (2006 wasn't > > exactly the most eventful time), there's a possibility that it was a > > precaution ("don't touch that can of worms!") than a firm decision. > > > > Cheers, > > Richard > > > > On Wed, 07 Oct 2020 17:34:25 +0200, > > Nicola Tuveri wrote: > > > > > > I believe the current formulation is slightly concealing part of the problem. > > > > > > The way I see it, the intention if the vote passes is to do more than stated: > > > 1. change the long-documented assumption > > > 2. fix "regressions" in 3.0 limited to things that worked in a certain > > > way in 1.1.1 (and maybe before), _despite_ the documented assumption > > > 3. test all existing functions that access the public key component of > > > `EVP_PKEY` (or lower level) objects to ensure they don't rely on the > > > long-documented assumption > > > 4. fix all the places that intentionally relied on the long-documented > > > assumption and that were required to avoid "useless NULL checks" > > > > > > I believe that to change a widely and longed-enforced assumption like > > > this, we can't rely on a single case or a list of single cases that > > > worked _despite_ the documented assumption as proof that things can > > > (and should) work a certain way or another, and that before taking the > > > decision this late in the development process the results of thorough > > > testing are a prerequisite to assess the extent of code changes > > > required by changing the assumption and the potential for instability > > > and disruption that this can cause for our direct and indirect users > > > if segfaults slip through our currently limited coverage as a > > > consequence of this change. > > > > > > I feel that we are currently underestimating the potential impact of > > > this change, and currently motivated by a handful of isolated cases in > > > which under a very specific set of conditions things aligned in a way > > > that allowed certain usage patterns to succeed despite the documented > > > assumption. > > > I also feel that the "burden of the proof" of improving the test > > > coverage to exhaustively cover all kinds of keys (both in their legacy > > > form and in provider-native form), under all possible operations at > > > different abstraction levels (e.g. limiting this example to > > > sign/verify as the operation, testing should not be limited to > > > `EVP_DigestSign/Verify()`, but also through > > > `EVP_DigestSign/Verify{Init,Update,Final}()`, > > > `EVP_PKEY_sign/verify*()`, `(EC)DSA_(do_)sign/verify()`, etc., > > > external testing with ENGINEs that might rely on the long-documented > > > assumption), should fall on who is proposing this change, rather than > > > committing that we will be able to increase our coverage to prevent > > > unforeseen consequences of changing the assumption, before we can > > > decide to commit to alter the assumption. > > > > > > So, to better capture the extent of work required to apply the change > > > and the risks associated with it I would rephrase the text vote as > > > follows: > > > > > > > We should change the 3.0 code to explicitly allow private components > > > > to exist in keys without the public components also being present, > > > > ensuring that, in `EVP` and in the lower abstraction layers, both in > > > > legacy and in provider-native codepaths, _every_ instance in which any > > > > public key component is dereferenced it is preceded by a NULL pointer > > > > check or guaranteed non-NULL from any caller. > > > > To change the long documented assumption, we commit to improve test > > > > coverage of all public functions directly or indirectly triggering > > > > potential access to public key components, to prevent the risk of user > > > > facing crashes. > > > > > > > > > Nicola > > > > > > > > > > > > > > > On Wed, 7 Oct 2020 at 14:29, Matt Caswell wrote: > > > > > > > > Issue #12612 exposes a problem with how we handle keys that contain > > > > private components but not public components. > > > > > > > > There is a widespread assumption in the code that keys with private > > > > components must have public components. There is text in our public > > > > documentation that states this (and that text dates back to 2006). > > > > > > > > OTOH, the code has not always enforced this. Issue #12612 describes a > > > > scenario where this has not historically been enforced, and it now is in > > > > the current 3.0 code causing a regression. > > > > > > > > There are differences of opinion on how this should be handled. Some > > > > have the opinion that we should change the model so that we explicitly > > > > allow private keys to exists without the public components. Others feel > > > > that we should continue with the old model. > > > > > > > > It seems we need a vote to decide this. Here is my proposed vote text: > > > > > > > > We should change the 3.0 code to explicitly allow private components to > > > > exist in keys without the public components also being present. > > > > > > > > Feedback please on the proposed vote text. > > > > > > > > Matt > > > > > -- > > Richard Levitte levitte at openssl.org > > OpenSSL Project http://www.openssl.org/~levitte/ > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From nic.tuv at gmail.com Wed Oct 7 17:57:20 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 7 Oct 2020 20:57:20 +0300 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <87362q2bw9.wl-levitte@openssl.org> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <87362q2bw9.wl-levitte@openssl.org> Message-ID: On Wed, 7 Oct 2020 at 20:17, Richard Levitte wrote: > > There's no reason for the EVP layer to check for the presence or the > absence or the public key, for one very simple reason: it doesn't have > access to the backend key structure and therefore has no possibility > to make any such checks. Such checks should be made in the backend. The very case that triggered this discussion happens because the provider backend is doing the tests that libcrypto is not doing, and upholding the core&users to the documented assumption. On import/export the backend is enforcing that privkey alone is never imported/exported without its public counterpart. > That part of your proposed vote text that mentions checks in EVP > doesn't make any sense with that in mind, and I fear that it would > lead us into a rabbit hole that's not really necessary. Also, this > contradicts the intentions of the design for libcrypto vs providers, > which was that libcrypto (and therefore EVP) would be a rather thin > layer that simply passes stuff to the providers and gets results back > (there are things that complicate this a bit, but this is essentially > what we do), and leave it to the provider to decide what to do and how > to do it. Re: contradicting design principles I would also remark here that pushing quirkiness into providers to satisfy "weird" requirements that only serve the purpose of dealing with the legacy promises of libcrypto (or anyway the extra constraints enforced by libcrypto surface that is not directly facing the providers) also contradicts designs of libcrypto vs providers: libcrypto takes care of libcrypto user-facing and provider-facing API, the provider only should care about the new and well defined core-provider API. Re: why test at EVP layer? In my proposal the test at the EVP (and lower) layers is because that is part of taking care of libcrypto user-facing API: the long-standing (locally betrayed) assumption is established for `EVP_PKEY` objects, so `EVP` is the natural layer to have a first layer of testing to ensure that pervasively we can guarantee that the current documented assumption can be safely disregarded because not relevant anymore. That assumption, for which we have long-standing documentation at the EVP layer has at some point (even in the past 4 years in my limited experience) been enforced also on lower levels (it is not particularly relevant if chronologically it percolated down to the lower levels or conversely was already there all along undocumented and was put in writing only when documenting `EVP_PKEY`): that is why I included in my proposal to also build coverage for this change not only in EVP but also in the other layers. I can agree with you that some of this testing at different layers can appear quite redundant, especially in terms of which "security critical" or "potentially failing" code is tested in the current snapshot of the code: but my counter argument is that if we were less worried about redundant tests and were more rigorous in always including both positive and negative tests for all the things we put in our documentation, maybe we would have already had the tests that asserted that the code reflects our documented assumption (and in which layers) and we wouldn't have ended up violating our documented assumption by accident creating something that works in 1.1.1 by (partial) accident and that we are now considering as a potential regression in 3.0. Nicola From kurt at roeckx.be Wed Oct 7 18:07:44 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 7 Oct 2020 20:07:44 +0200 Subject: Vote proposal: Technical items still to be done In-Reply-To: References: Message-ID: <20201007180744.GB45463@roeckx.be> On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > The following items are required prerequisites for the first beta release: [...] > * Address 3.0beta1 milestones. So we now have a list here, with the last item pointing to a different list. I suggest that we only have 1 list, and that we make github issues for anything that doesn't have an issue yet, and it to the milestone. It would at least be easier to track the progress. We also talked about freezing the milestone at some point. We intend to go over the 3.0.0 milestone PRs/issues, and see if any of those need to be moved to the 3.0.0 beta1 milestone. I assume that if we have done that, that we'll freeze it. We can then try to estimate how long it will take before beta1. Kurt From nic.tuv at gmail.com Wed Oct 7 19:25:57 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 7 Oct 2020 22:25:57 +0300 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <871ria2alz.wl-levitte@openssl.org> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <875z7m2d27.wl-levitte@openssl.org> <871ria2alz.wl-levitte@openssl.org> Message-ID: On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote: > > I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY > with a private key should have a public key. I was incorrect. Sure, my example was not about pointing fingers! It's just to give recent data points on how the documentation written in 2006 is probably not something as stale as one can think, because until recently we were leveraging that assumption at least in some sections of the lower layers. > Regarding avoiding NULL checks, that's actually a separate story, > evem though it overlaps conveniently. There was the idea, for a > while, that we should avoid NULL checks everywhere (unless it's valid > input), and indeed make it a programmer error if they happened to pass > NULL where they shouldn't. > One can see that as an hard assertion, and that has indeed produced > crashes that uncovered bugs we might otherwise have missed. The tide > has changed though, and it seem like the fashion du jour is to check > NULLs and error with an ERR_R_PASSED_NULL_PARAMETER. I'm not sure > that we've made an actual hard decision in either direction, though. > > However, I'm not sure where the NULL check problem comes in. > Operations that don't use the public key parts don't need to look at > the public key parts, so a NULL check there is simply not necessary. I think the lack of NULL checks is intertwined with this problem as long as in some code that does access the public key component we ensured we dereference without making the NULL check because of the assumption. The problem I see with spot checking rather than writing a comprehensive suite of tests, is that given our wide API surface and the compromises taken in the transition from non-opaque stack allocated objects in 1.0.2 to opaque objects in 1.1.1+, we might have non-obvious places where dereferencing the public key without checking for NULL can bite us. I would add, although it's feedback for the vote, not the proposal, that I am not opposed to changing the documented assumption in principle, but with changing it this late in the development of 3.0. I am giving feedback for the text proposal to ensure that during the voting we don't underestimate the high risk of critical bugs coming with adopting this change at this stage, and that it does call for vastly extending our current test coverage beyond what we were currently planning as acceptable. We all feel quite under pressure due to the time constraints, and I feel that in general we have privileged working on implementing the required features (with sufficient level of tests as per our policy) rather than spending major resources in further developing our test coverage with exhaustive positive and negative tests for regular and far-fetched cases, this should probably also have a weight on the decision of committing to this change at this point. Nicola From levitte at openssl.org Wed Oct 7 21:10:39 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 07 Oct 2020 23:10:39 +0200 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <875z7m2d27.wl-levitte@openssl.org> <871ria2alz.wl-levitte@openssl.org> Message-ID: <87y2kh214g.wl-levitte@openssl.org> On Wed, 07 Oct 2020 21:25:57 +0200, Nicola Tuveri wrote: > > On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote: > > > > I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY > > with a private key should have a public key. I was incorrect. > > Sure, my example was not about pointing fingers! I didn't try to imply that you did, just wanted to own up to my part in it. > It's just to give recent data points on how the documentation written > in 2006 is probably not something as stale as one can think, because > until recently we were leveraging that assumption at least in some > sections of the lower layers. Were we? Not in the operations... however, this picked my curiousity and got me to look at this from a different angle. See, it seems that what we're mostly disputing is the behaviour of the keymgmt import function, which is related to loading keys from file, among others. When loading private keys from PEM files in 1.1.1, we do rely entirely on the related i2d functions, which do implement the ASN.1 structures quite failthfully, so our basis of deciding what's ok or not is at influenced by associated standardised ASN.1 key formats. I did just now look up the ASN.1 key format for ECC keys, and it seems that our EC keymgmt ends up violating that standard. I've commented further on that in the issue: https://github.com/openssl/openssl/issues/12612#issuecomment-705162303 > I think the lack of NULL checks is intertwined with this problem as > long as in some code that does access the public key component we > ensured we dereference without making the NULL check because of the > assumption. Looking again at #12612, I don't quite see where the conclusion that we're missning NULL checks comes from. EVP_DigestSignInit() fails, quite correctly, because it's been given a key that couldn't be (automatically) exported to a provider, because the keymgmt import refused it for the lack of a public key. Had the import accepted this key material, the signature operation would have worked with no issues whatsoever as far as I can see, because it doesn't use the public key. And the code we use for the actual computation does a NULL check on the private key. I can't see that the issue was a lack of NULL check, rather the contrary in this case. > The problem I see with spot checking rather than writing a > comprehensive suite of tests, is that given our wide API surface and > the compromises taken in the transition from non-opaque stack > allocated objects in 1.0.2 to opaque objects in 1.1.1+, we might have > non-obvious places where dereferencing the public key without checking > for NULL can bite us. The current ECC private keys embedded in test/recipes/30-test_evp_data/evppkey_ecc.txt (both in 1.1.1 and 3.0) currently all have a public key present. It should be possible to change some of them to have the public key removed, or add test stanza with private keys that don't have the public part. I agree that we should add such stanzas, and probably test them on 1.1.1 as well as on 3.0, to ensure that we don't have the dormant bug that you fear that we might have. Mind you, there's another possible answer for ECC keys. If you look at crypto/dh/dh_ameth.c and crypto/dsa/dsa_ameth.c, and look up dh_priv_decode() and dsa_priv_decode()... well, you only need to read the comment, really. See, a PKCS#8 structure with a DH or DSA key only has the private key. No public key whatsoever, so DSA and DH keys can be said to be in the same situation as ECC keys... it's just that our legacy code to decode such PKCS#8 structures will recalculate the public key from the private key and the parameters. I'm not terribly keen on that idea, and specially not on the idea to possibly have to reproduce it in the provided decoders, which means that we're putting that pressure on other provider authors as well. However, if that suites everyone better, we have a precedent. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From shane.lontis at oracle.com Wed Oct 7 21:22:23 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Thu, 8 Oct 2020 07:22:23 +1000 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <015FBCCC-C032-4286-A0BA-9179BDA2FB8E@oracle.com> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <015FBCCC-C032-4286-A0BA-9179BDA2FB8E@oracle.com> Message-ID: <0C660DAE-CCA7-4532-8B81-093F8D7D08F5@oracle.com> I assume you are just talking about the ec key? If the public key is not present then that could be seen as an error for operations that require the public key. Shane > On 7 Oct 2020, at 9:54 pm, Dr Paul Dale wrote: > > Would it be feasible to change code that does ->pub_key to call a function that null checks the field and generates the public key if it is absent? > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 7 Oct 2020, at 9:29 pm, Matt Caswell > wrote: >> >> Issue #12612 exposes a problem with how we handle keys that contain >> private components but not public components. >> >> There is a widespread assumption in the code that keys with private >> components must have public components. There is text in our public >> documentation that states this (and that text dates back to 2006). >> >> OTOH, the code has not always enforced this. Issue #12612 describes a >> scenario where this has not historically been enforced, and it now is in >> the current 3.0 code causing a regression. >> >> There are differences of opinion on how this should be handled. Some >> have the opinion that we should change the model so that we explicitly >> allow private keys to exists without the public components. Others feel >> that we should continue with the old model. >> >> It seems we need a vote to decide this. Here is my proposed vote text: >> >> We should change the 3.0 code to explicitly allow private components to >> exist in keys without the public components also being present. >> >> Feedback please on the proposed vote text. >> >> Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Thu Oct 8 04:57:36 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Wed, 7 Oct 2020 21:57:36 -0700 Subject: Vote proposal: Technical items still to be done In-Reply-To: References: Message-ID: <20201008045736.GX89563@kduck.mit.edu> On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > I had an action from the OTC meeting today to raise a vote on the OTC > list of technical items still to be done. Here is my proposed vote text. > There will be a subsequent vote on the "beta readiness checklist" which > is a separate list. Thanks, Matt; this is a fine list of desirable things. (I tried to resist commenting on specific items, but building the 1.1.1 apps+tests against 3.0 libraries is a solid way to help meet our stability goals, and should arguably be something that run-checker just does, all the time.) I've trimmed the list, though, to make a broader point, which could be summarized as "the perfect is the enemy of the good". It's a natural consequence for a software project that has long-term supported releases, strong API stability guarantees, and infrequent releases, to feel that each major release is a critical threshold and that we need to do a bunch of tidying before the release to wrap it up nicely. Paying off technical debt is often a bit part of the tidying that is perceived necessary, as is attempting to be future looking -- missing the release, after all, is the difference between needing to support some bad/annoying thing for (say) 8 years instead of "only" 5. There is value in doing this fixup, yes, but there is also cost in keeping all the good things (and other fixup) that is already done out of the hands of those who wish to consume it. I've seen this phenomenon bite various projects over time with effects of different magnitude, varying from FreeBSD 5.0+SMP that had nearly existential consequences on the project, to OpenAFS 1.6.0 where release delays produced enough frustration to lead to a bit of a rush-job final release that was a bit unstable; I was lucky enough to have missed the worst of this effect for krb5, and managed to do a little better (but still not great) for OpenAFS 1.8.0. Projects that get hit really badly by this phenomenon tend to correct for it and end up on a fixed time-based cadence of releases, and in order to stick to that cadence end up having to get comfortable shipping releases without a desired feature or that are known to have incomplete parts of one feature or another. It also requires discipline to keep the main development branch always (or nearly so) in a releasable state, but in my opinion we are already doing a pretty good job of that with our policies for code review and unit tests. (We could, of course, do better about monitoring the extended tests, run checker, and the like, but when we do have regressions getting them fixed is not an invasive mess.) To list some examples: FreeBSD aims for new major ("dot zero") releases every two years. MIT krb5 puts out new releases annually. Google Chrome puts out releases every 6 weeks. [Okay, I haven't exactly moved OpenAFS over to this schedule yet, but I did just today cut a 1.9.0 and am going to try to put out regular 1.9.x versions.] I would urge the OTC (and OMC) to be careful around the pitfalls of making the perfect the enemy of the good, and be willing to accept some level of "uncleanliness" in the interest of getting all the good things we have already done out there in production releases. (And also trying to not slip the published schedule too much.) It is unpleasant, yes, but sometimes it is the best choice overall. Thanks, Ben From tmraz at redhat.com Thu Oct 8 06:47:21 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Oct 2020 08:47:21 +0200 Subject: Vote proposal: Technical items still to be done In-Reply-To: <20201008045736.GX89563@kduck.mit.edu> References: <20201008045736.GX89563@kduck.mit.edu> Message-ID: <5ad4db61c1463524e45ceed3c21c8cb5af73d271.camel@redhat.com> +1 to that. There is a reason why almost all the major projects switched over to doing time based releases instead of feature completeness based ones. Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it stable for many years to come. Any bugs in the API design for providers will have to live with us at least until the 4.0 release and so it is reasonable goal to avoid them if at all possible. But yes, I am also feeling that the release requirements as defined in the proposal are a little bit too much on the side of the perfect, the enemy of the good and it would not be a major problem if some of them were not there. Unfortunately the release requirements as defined in the proposal for OTC vote come fairly naturally from the feature requirements set by OMC so if we would like to avoid some of them I think that OMC would have to first amend the feature requirements for the 3.0 release. On Wed, 2020-10-07 at 21:57 -0700, Benjamin Kaduk wrote: > On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > > I had an action from the OTC meeting today to raise a vote on the > > OTC > > list of technical items still to be done. Here is my proposed vote > > text. > > There will be a subsequent vote on the "beta readiness checklist" > > which > > is a separate list. > > Thanks, Matt; this is a fine list of desirable things. (I tried to > resist > commenting on specific items, but building the 1.1.1 apps+tests > against 3.0 > libraries is a solid way to help meet our stability goals, and should > arguably be something that run-checker just does, all the time.) > > I've trimmed the list, though, to make a broader point, which could > be > summarized as "the perfect is the enemy of the good". > > It's a natural consequence for a software project that has long-term > supported releases, strong API stability guarantees, and infrequent > releases, to feel that each major release is a critical threshold and > that > we need to do a bunch of tidying before the release to wrap it up > nicely. > Paying off technical debt is often a bit part of the tidying that is > perceived necessary, as is attempting to be future looking -- missing > the > release, after all, is the difference between needing to support some > bad/annoying thing for (say) 8 years instead of "only" 5. > > There is value in doing this fixup, yes, but there is also cost in > keeping > all the good things (and other fixup) that is already done out of the > hands > of those who wish to consume it. I've seen this phenomenon bite > various > projects over time with effects of different magnitude, varying from > FreeBSD 5.0+SMP that had nearly existential consequences on the > project, to > OpenAFS 1.6.0 where release delays produced enough frustration to > lead to a > bit of a rush-job final release that was a bit unstable; I was lucky > enough > to have missed the worst of this effect for krb5, and managed to do a > little better (but still not great) for OpenAFS 1.8.0. > > Projects that get hit really badly by this phenomenon tend to correct > for > it and end up on a fixed time-based cadence of releases, and in order > to > stick to that cadence end up having to get comfortable shipping > releases > without a desired feature or that are known to have incomplete parts > of one > feature or another. It also requires discipline to keep the main > development branch always (or nearly so) in a releasable state, but > in my > opinion we are already doing a pretty good job of that with our > policies > for code review and unit tests. (We could, of course, do better > about > monitoring the extended tests, run checker, and the like, but when we > do > have regressions getting them fixed is not an invasive mess.) > > To list some examples: > > FreeBSD aims for new major ("dot zero") releases every two years. > MIT krb5 puts out new releases annually. > Google Chrome puts out releases every 6 weeks. > [Okay, I haven't exactly moved OpenAFS over to this schedule yet, but > I did > just today cut a 1.9.0 and am going to try to put out regular 1.9.x > versions.] > > I would urge the OTC (and OMC) to be careful around the pitfalls of > making > the perfect the enemy of the good, and be willing to accept some > level of > "uncleanliness" in the interest of getting all the good things we > have > already done out there in production releases. (And also trying to > not > slip the published schedule too much.) It is unpleasant, yes, but > sometimes it is the best choice overall. > > Thanks, > > Ben -- 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 Thu Oct 8 08:47:12 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2020 09:47:12 +0100 Subject: Vote proposal: Technical items still to be done In-Reply-To: <20201007180744.GB45463@roeckx.be> References: <20201007180744.GB45463@roeckx.be> Message-ID: <44ae5021-e3af-a130-d502-91245dcd1dc7@openssl.org> On 07/10/2020 19:07, Kurt Roeckx wrote: > On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: >> The following items are required prerequisites for the first beta release: > [...] >> * Address 3.0beta1 milestones. > > So we now have a list here, with the last item pointing to a > different list. I suggest that we only have 1 list, and that we > make github issues for anything that doesn't have an issue yet, > and it to the milestone. It would at least be easier to track the > progress. I agree, although its bit of a chicken-and-egg problem. I'd suggest voting on the list as is, and then if the vote passes converting all of those things into issues. > > We also talked about freezing the milestone at some point. We > intend to go over the 3.0.0 milestone PRs/issues, and see if any of > those need to be moved to the 3.0.0 beta1 milestone. I assume that > if we have done that, that we'll freeze it. We can then try to > estimate how long it will take before beta1. Yes. Matt From tmraz at redhat.com Thu Oct 8 09:51:48 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Oct 2020 11:51:48 +0200 Subject: Vote proposal: Technical items still to be done In-Reply-To: <44ae5021-e3af-a130-d502-91245dcd1dc7@openssl.org> References: <20201007180744.GB45463@roeckx.be> <44ae5021-e3af-a130-d502-91245dcd1dc7@openssl.org> Message-ID: On Thu, 2020-10-08 at 09:47 +0100, Matt Caswell wrote: > > On 07/10/2020 19:07, Kurt Roeckx wrote: > > On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > > > The following items are required prerequisites for the first beta > > > release: > > [...] > > > * Address 3.0beta1 milestones. > > > > So we now have a list here, with the last item pointing to a > > different list. I suggest that we only have 1 list, and that we > > make github issues for anything that doesn't have an issue yet, > > and it to the milestone. It would at least be easier to track the > > progress. > > I agree, although its bit of a chicken-and-egg problem. I'd suggest > voting on the list as is, and then if the vote passes converting all > of > those things into issues. +1 > > We also talked about freezing the milestone at some point. We > > intend to go over the 3.0.0 milestone PRs/issues, and see if any of > > those need to be moved to the 3.0.0 beta1 milestone. I assume that > > if we have done that, that we'll freeze it. We can then try to > > estimate how long it will take before beta1. > > Yes. > > Matt > -- 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 rsalz at akamai.com Thu Oct 8 12:00:46 2020 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 8 Oct 2020 12:00:46 +0000 Subject: Vote proposal: Technical items still to be done In-Reply-To: <5ad4db61c1463524e45ceed3c21c8cb5af73d271.camel@redhat.com> References: <20201008045736.GX89563@kduck.mit.edu> <5ad4db61c1463524e45ceed3c21c8cb5af73d271.camel@redhat.com> Message-ID: <4F33BABA-A553-46F6-B315-E882D69F2B15@akamai.com> > Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it stable for many years to come. Any bugs in the API design for providers will have to live with us at least until the 4.0 release and so it is reasonable goal to avoid them if at all possible. There's two parts to this, bugs within the API, and errors in the API definition itself. You're talking about the latter, which is the more important thing. Nowhere in this thread, or elsewhere, has there been any mention of how to test that the provider API is correct. We have the existence proof of OpenSSL, but that's it. There are beliefs that it works, concerns about things missing, but no other running code. If the provider API is paramount, then perhaps additional proof-points are needed? > Unfortunately the release requirements as defined in the proposal for OTC vote come fairly naturally from the feature requirements set by OMC Where can I find those? If they were posted I missed it. If it's the 3.0 design document [1] then, for example, I would say that the deprecation requirements are met because it doesn't mandate "remove from the code" style of deprecation. But maybe there is another list of 3.0 requirements that I am missing. Any help [1] https://www.openssl.org/docs/OpenSSL300Design.html From nic.tuv at gmail.com Thu Oct 8 14:06:57 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 8 Oct 2020 17:06:57 +0300 Subject: Vote proposal: Private keys can exist independently of public keys In-Reply-To: <87y2kh214g.wl-levitte@openssl.org> References: <108b27f3-b7b8-41fc-4548-f3a0771463f1@openssl.org> <875z7m2d27.wl-levitte@openssl.org> <871ria2alz.wl-levitte@openssl.org> <87y2kh214g.wl-levitte@openssl.org> Message-ID: An update to keep this thread in sync: we moved the discussion between me and Richard partially offline and partially on (the issue that triggered this vote proposal). Part of the discussion was on our positions and rationales regarding the actual vote and not the vote proposal, so they did not belong here, but I feel like it would be better to include in this thread a point I made in the issue discussion in support of amending the vote text to be more explicit regarding the amount of work required to change the "keypair assumption" in a way that is safe for all of our users. The full details are at but the relevant part that I think is worth including in this thread is the following: > Regardless of the fact that, in this particular instance, arguments > are checked and we don't fail with a segfault, my point in the > discussion about the vote proposal is exactly that to propose to > change the underlying assumption first we should build test coverage > to catch the segfaults where they could happen and fix them! > > Currently our test coverage for "incomplete keys" is 0% or very close > to it, because we rely greatly on data driven tests (and PEM in > particular), and while we do exercise encodings that omit the optional > public key components, this still means we are not covering the > codepaths that a user could hit if using the API to intentionally > violate the "keypair assumption" as in the description of this issue. To be fair, when I say close to 0%, I am aware we have tests specific to provider-native keys, that feed the raw data, and are offering some level of assurance for this test. What I feel is gravely undertested to undertake this change in the timeframe of 3.0 is exhaustive unit testing of our wide API and integration/system tests to ensure that by removing this assumption we do not impact established patterns in the existing user codebase. Yes, as #12612 shows also being strict about this introduces breaking changes for the users that used the API to programmatically create patterns that work in 1.1.1 even if they defied the documented "keypair assumption", but I see a big difference in breaking leaning towards hardening and breaking leaning towards potential run-time exceptions! I am not saying we should never change the "keypair assumption", but that on voting to change this assumption in the 3.0 timeframe, we should remind ourselves of the current poor coverage on some details, the risk that could emerge out of this change and the amount of work required to reach exhaustive testing to be able to quantify these risks and the work required to make all the existing codebase robust to this change. -- Nicola On Thu, 8 Oct 2020 at 00:10, Richard Levitte wrote: > > On Wed, 07 Oct 2020 21:25:57 +0200, > Nicola Tuveri wrote: > > > > On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote: > > > > > > I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY > > > with a private key should have a public key. I was incorrect. > > > > Sure, my example was not about pointing fingers! > > I didn't try to imply that you did, just wanted to own up to my part > in it. > > > It's just to give recent data points on how the documentation written > > in 2006 is probably not something as stale as one can think, because > > until recently we were leveraging that assumption at least in some > > sections of the lower layers. > > Were we? Not in the operations... however, this picked my curiousity > and got me to look at this from a different angle. See, it seems that > what we're mostly disputing is the behaviour of the keymgmt import > function, which is related to loading keys from file, among others. > > When loading private keys from PEM files in 1.1.1, we do rely entirely > on the related i2d functions, which do implement the ASN.1 structures > quite failthfully, so our basis of deciding what's ok or not is at > influenced by associated standardised ASN.1 key formats. > > I did just now look up the ASN.1 key format for ECC keys, and it seems > that our EC keymgmt ends up violating that standard. I've commented > further on that in the issue: > https://github.com/openssl/openssl/issues/12612#issuecomment-705162303 > > > I think the lack of NULL checks is intertwined with this problem as > > long as in some code that does access the public key component we > > ensured we dereference without making the NULL check because of the > > assumption. > > Looking again at #12612, I don't quite see where the conclusion that > we're missning NULL checks comes from. EVP_DigestSignInit() fails, > quite correctly, because it's been given a key that couldn't be > (automatically) exported to a provider, because the keymgmt import > refused it for the lack of a public key. Had the import accepted this > key material, the signature operation would have worked with no issues > whatsoever as far as I can see, because it doesn't use the public key. > And the code we use for the actual computation does a NULL check on > the private key. > > I can't see that the issue was a lack of NULL check, rather the > contrary in this case. > > > The problem I see with spot checking rather than writing a > > comprehensive suite of tests, is that given our wide API surface and > > the compromises taken in the transition from non-opaque stack > > allocated objects in 1.0.2 to opaque objects in 1.1.1+, we might have > > non-obvious places where dereferencing the public key without checking > > for NULL can bite us. > > The current ECC private keys embedded in test/recipes/30-test_evp_data/evppkey_ecc.txt > (both in 1.1.1 and 3.0) currently all have a public key present. > It should be possible to change some of them to have the public key > removed, or add test stanza with private keys that don't have the > public part. > > I agree that we should add such stanzas, and probably test them on > 1.1.1 as well as on 3.0, to ensure that we don't have the dormant bug > that you fear that we might have. > > Mind you, there's another possible answer for ECC keys. If you look > at crypto/dh/dh_ameth.c and crypto/dsa/dsa_ameth.c, and look up > dh_priv_decode() and dsa_priv_decode()... well, you only need to read > the comment, really. > See, a PKCS#8 structure with a DH or DSA key only has the private > key. No public key whatsoever, so DSA and DH keys can be said to be > in the same situation as ECC keys... it's just that our legacy code > to decode such PKCS#8 structures will recalculate the public key from > the private key and the parameters. > I'm not terribly keen on that idea, and specially not on the idea to > possibly have to reproduce it in the provided decoders, which means > that we're putting that pressure on other provider authors as well. > However, if that suites everyone better, we have a precedent. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu Oct 8 14:27:18 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2020 15:27:18 +0100 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality Message-ID: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as shown in PR #13018 into the 3.0 release Proposed by Matt Caswell Public: yes opened: 2020-10-08 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [ ] From nic.tuv at gmail.com Thu Oct 8 14:30:36 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 8 Oct 2020 17:30:36 +0300 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: +1 On Thu, Oct 8, 2020, 17:27 Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Oct 8 14:44:11 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2020 15:44:11 +0100 Subject: Vote proposal: Technical items still to be done In-Reply-To: References: Message-ID: <8815249e-bdeb-5bc2-9eb3-7673b673d7d8@openssl.org> Thanks for the feedback on this thread. There was some feedback specifically on the vote text. I've made the amendment suggested by Tomas, and numbered the items as suggested by Nicola. I did not convert to markdown. The other discussions on this thread I think are useful things to think about when considering how to vote - but I don't think change the vote text itself - so I've not made any changes in response to those things. I'll shortly start this vote. Matt On 07/10/2020 12:35, Matt Caswell wrote: > I had an action from the OTC meeting today to raise a vote on the OTC > list of technical items still to be done. Here is my proposed vote text. > There will be a subsequent vote on the "beta readiness checklist" which > is a separate list. > > Feedback please on the proposed vote text below. > > The following items are required prerequisites for the first beta release: > * EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > * Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for the > EVP interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code to > handle the -engine CLI option). That is, remove the suppression of > deprecated define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers > and library. Run 1.1.1 app test cases against the chimera. Treat this > as an external test using a special 1.1.1 branch. > Deprecated functions used by libssl should be moved to independent > file(s), to limit the suppression of deprecated defines to the absolute > minimum scope. > * Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to the replacement interfaces. > * Review (and maybe clean up) legacy bridge code. > * Review TODO(3.0) items #12224. > * Source checksum script. > * Review of functions previously named _with_libctx. > * Encoder fixers (PKCS#8, PKCS#1, etc). > * Encoder DER to PEM refactor. > * Builds and passes tests on all primary, secondary and FIPS platforms. > * Query provider parameters (name, version, ?) from the command line. > * Setup buildbot infrastructure and associated instructions. > * Complete make fipsinstall. > * More specific decoding selection (e.g. params or keys). > * Example code covering replacements for deprecated APIs. > * Drop C code output options from the apps (OMC approval required). > * Address 3.0beta1 milestones. > > > Matt > From matt at openssl.org Thu Oct 8 14:47:18 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2020 15:47:18 +0100 Subject: VOTE: Technical Items still to be done Message-ID: topic: The following items are required prerequisites for the first beta release: 1) EVP is the recommended API, it must be feature-complete compared with the functionality available using lower-level APIs. - Anything that isn?t available must be put to an OTC vote to exclude. - The apps are the minimum bar for this, subject to exceptions noted below. 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, RAND_METHOD_. - Does not include macros defining useful constants (e.g. SHA512_DIGEST_LENGTH). - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. - There might be some others. - Review for exceptions. - The apps are the minimum bar to measure feature completeness for the EVP interface: rewrite them so they do not use internal nor deprecated functions (except speed, engine, list, passwd -crypt and the code to handle the -engine CLI option). That is, remove the suppression of deprecated define. - Proposal: drop passwd -crypt (OMC vote required) - Compile and link 1.1.1 command line app against the master headers and library. Run 1.1.1 app test cases against the chimera. Treat this as an external test using a special 1.1.1 branch. Deprecated functions used by libssl should be moved to independent file(s), to limit the suppression of deprecated defines to the absolute minimum scope. 3) Draft documentation (contents but not pretty) - Need a list of things we know are not present - including things we have removed. - We need to have mapping tables for various d2i/i2d functions. - We need to have a mapping table from ?old names? for things into the OSSL_PARAMS names. - Documentation addition to old APIs to refer to new ones (man7). - Documentation needs to reference name mapping. - All the legacy interfaces need to have their documentation pointing to the replacement interfaces. 4) Review (and maybe clean up) legacy bridge code. 5) Review TODO(3.0) items #12224. 6) Source checksum script. 7) Review of functions previously named _with_libctx. 8) Encoder fixes (PKCS#8, PKCS#1, etc). 9) Encoder DER to PEM refactor. 10) Builds and passes tests on all primary, secondary and FIPS platforms. 11) Query provider parameters (name, version, ...) from the command line. 12) Setup buildbot infrastructure and associated instructions. 13) Complete make fipsinstall. 14) More specific decoding selection (e.g. params or keys). 15) Example code covering replacements for deprecated APIs. 16) Drop C code output options from the apps (OMC approval required). 17) Address issues and PRs in the 3.0beta1 milestone. Proposed by . Public: yes opened: 2020-10-08 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [ ] From nic.tuv at gmail.com Thu Oct 8 14:57:00 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 8 Oct 2020 17:57:00 +0300 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: +1 On Thu, 8 Oct 2020 at 17:47, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] From matt at openssl.org Thu Oct 8 15:01:16 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2020 16:01:16 +0100 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: <766d8827-9b6a-31a0-8748-da6fa9730218@openssl.org> Note that Nicola pointed out a formatting error in the vote text. The last sub-bullet under point 2 is actually 2 different sub-bullets that got merged together, i.e. - Compile and link 1.1.1 command line app against the master headers and library. Run 1.1.1 app test cases against the chimera. Treat this as an external test using a special 1.1.1 branch. - Deprecated functions used by libssl should be moved to independent file(s), to limit the suppression of deprecated defines to the absolute minimum scope. Since this is formatting only I don't think it affects the vote. I've corrected it in votes.txt. Matt On 08/10/2020 15:47, Matt Caswell wrote: > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > From Matthias.St.Pierre at ncp-e.com Thu Oct 8 15:09:37 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 8 Oct 2020 15:09:37 +0000 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: <675e64f4f98845d381613ab79aac15d0@ncp-e.com> +1 > -----Original Message----- > From: openssl-project On Behalf Of Matt Caswell > Sent: Thursday, October 8, 2020 4:27 PM > To: openssl-project at openssl.org > Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality > > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] From tjh at cryptsoft.com Thu Oct 8 16:09:10 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 9 Oct 2020 02:09:10 +1000 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: +1 Tim. On Fri, Oct 9, 2020 at 12:47 AM Matt Caswell wrote: > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of > deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Thu Oct 8 16:09:30 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 9 Oct 2020 02:09:30 +1000 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: +1 Tim On Fri, Oct 9, 2020 at 12:27 AM Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Thu Oct 8 16:21:04 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Oct 2020 18:21:04 +0200 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: +1 On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote: > topic: The following items are required prerequisites for the first > beta > release: > 1) EVP is the recommended API, it must be feature-complete compared > with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to > exclude. > - The apps are the minimum bar for this, subject to exceptions > noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, > RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor > deprecated > functions (except speed, engine, list, passwd -crypt and the > code > to handle > the -engine CLI option). That is, remove the suppression of > deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master > headers and > library. Run 1.1.1 app test cases against the chimera. Treat > this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things > we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into > the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones > (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS > platforms. > 11) Query provider parameters (name, version, ...) from the command > line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] -- 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 tmraz at redhat.com Thu Oct 8 16:21:28 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Oct 2020 18:21:28 +0200 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: +1 On Thu, 2020-10-08 at 15:27 +0100, Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality > as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] -- 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 Thu Oct 8 16:51:40 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 8 Oct 2020 18:51:40 +0200 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: <20201008165140.GC45463@roeckx.be> On Thu, Oct 08, 2020 at 03:27:18PM +0100, Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release +1 Kurt From Matthias.St.Pierre at ncp-e.com Thu Oct 8 16:55:24 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 8 Oct 2020 16:55:24 +0000 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: +1 > -----Original Message----- > From: openssl-project On Behalf Of Tomas Mraz > Sent: Thursday, October 8, 2020 6:21 PM > To: Matt Caswell ; openssl-project at openssl.org > Subject: Re: VOTE: Technical Items still to be done > > +1 > > On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first > > beta > > release: > > 1) EVP is the recommended API, it must be feature-complete compared > > with > > the functionality available using lower-level APIs. > > - Anything that isn?t available must be put to an OTC vote to > > exclude. > > - The apps are the minimum bar for this, subject to exceptions > > noted > > below. > > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, > > RSA_, > > RAND_METHOD_. > > - Does not include macros defining useful constants (e.g. > > SHA512_DIGEST_LENGTH). > > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > > - There might be some others. > > - Review for exceptions. > > - The apps are the minimum bar to measure feature completeness for > > the EVP > > interface: rewrite them so they do not use internal nor > > deprecated > > functions (except speed, engine, list, passwd -crypt and the > > code > > to handle > > the -engine CLI option). That is, remove the suppression of > > deprecated > > define. > > - Proposal: drop passwd -crypt (OMC vote required) > > - Compile and link 1.1.1 command line app against the master > > headers and > > library. Run 1.1.1 app test cases against the chimera. Treat > > this > > as an > > external test using a special 1.1.1 branch. Deprecated functions > > used by > > libssl should be moved to independent file(s), to limit the > > suppression of > > deprecated defines to the absolute minimum scope. > > 3) Draft documentation (contents but not pretty) > > - Need a list of things we know are not present - including things > > we > > have > > removed. > > - We need to have mapping tables for various d2i/i2d functions. > > - We need to have a mapping table from ?old names? for things into > > the > > OSSL_PARAMS names. > > - Documentation addition to old APIs to refer to new ones > > (man7). > > - Documentation needs to reference name mapping. > > - All the legacy interfaces need to have their documentation > > pointing to > > the replacement interfaces. > > 4) Review (and maybe clean up) legacy bridge code. > > 5) Review TODO(3.0) items #12224. > > 6) Source checksum script. > > 7) Review of functions previously named _with_libctx. > > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > > 9) Encoder DER to PEM refactor. > > 10) Builds and passes tests on all primary, secondary and FIPS > > platforms. > > 11) Query provider parameters (name, version, ...) from the command > > line. > > 12) Setup buildbot infrastructure and associated instructions. > > 13) Complete make fipsinstall. > > 14) More specific decoding selection (e.g. params or keys). > > 15) Example code covering replacements for deprecated APIs. > > 16) Drop C code output options from the apps (OMC approval required). > > 17) Address issues and PRs in the 3.0beta1 milestone. > > Proposed by . > > Public: yes > > opened: 2020-10-08 > > closed: 2020-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [+1] > > Mark [ ] > > Pauli [ ] > > Viktor [ ] > > Tim [ ] > > Richard [ ] > > Shane [ ] > > Tomas [ ] > > Kurt [ ] > > Matthias [ ] > > Nicola [ ] > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] From paul.dale at oracle.com Thu Oct 8 21:40:43 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 9 Oct 2020 07:40:43 +1000 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: <8F8D6096-4F34-454E-9BD9-E654207A62BA@oracle.com> +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 12:27 am, Matt Caswell wrote: > > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Oct 8 21:41:44 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 9 Oct 2020 07:41:44 +1000 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: <37CBEFD6-CAB1-4345-A6FA-37D8EFB6D187@oracle.com> [to the project list this time] +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 12:47 am, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Thu Oct 8 21:45:52 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Fri, 9 Oct 2020 07:45:52 +1000 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8F8D6096-4F34-454E-9BD9-E654207A62BA@oracle.com> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> <8F8D6096-4F34-454E-9BD9-E654207A62BA@oracle.com> Message-ID: -1 > On 9 Oct 2020, at 7:40 am, Dr Paul Dale wrote: > > +1 > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 9 Oct 2020, at 12:27 am, Matt Caswell > wrote: >> >> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as >> shown in PR #13018 into the 3.0 release >> Proposed by Matt Caswell >> Public: yes >> opened: 2020-10-08 >> closed: 2020-mm-dd >> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) >> >> Matt [+1] >> Mark [ ] >> Pauli [ ] >> Viktor [ ] >> Tim [ ] >> Richard [ ] >> Shane [ ] >> Tomas [ ] >> Kurt [ ] >> Matthias [ ] >> Nicola [ ] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Thu Oct 8 22:21:29 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Fri, 9 Oct 2020 08:21:29 +1000 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: +1 > On 9 Oct 2020, at 12:47 am, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Fri Oct 9 06:39:08 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 09 Oct 2020 08:39:08 +0200 Subject: Vote proposal: Technical items still to be done In-Reply-To: <4F33BABA-A553-46F6-B315-E882D69F2B15@akamai.com> References: <20201008045736.GX89563@kduck.mit.edu> <5ad4db61c1463524e45ceed3c21c8cb5af73d271.camel@redhat.com> <4F33BABA-A553-46F6-B315-E882D69F2B15@akamai.com> Message-ID: <1283078ca82f385c457874925b687fafebdebd0e.camel@redhat.com> On Thu, 2020-10-08 at 12:00 +0000, Salz, Rich wrote: > > Of course the 3.0 release is kind of special because we are > > defining a > completely new API - the providers API - with the intention to > have it > stable for many years to come. Any bugs in the API design for > providers > will have to live with us at least until the 4.0 release and so > it is > reasonable goal to avoid them if at all possible. > > There's two parts to this, bugs within the API, and errors in the API > definition itself. You're talking about the latter, which is the > more important thing. > > Nowhere in this thread, or elsewhere, has there been any mention of > how to test that the provider API is correct. We have the existence > proof of OpenSSL, but that's it. There are beliefs that it works, > concerns about things missing, but no other running code. If the > provider API is paramount, then perhaps additional proof-points are > needed? > > > Unfortunately the release requirements as defined in the > > proposal for > OTC vote come fairly naturally from the feature requirements set > by OMC > > Where can I find those? If they were posted I missed it. If it's > the 3.0 design document [1] then, for example, I would say that the > deprecation requirements are met because it doesn't mandate "remove > from the code" style of deprecation. But maybe there is another list > of 3.0 requirements that I am missing. Any help Yes, we are talking here about the 3.0 design document. And no, there is no "remove from the code" deprecation kind of. There is no such thing on this list that we are voting upon either, except for two things - C code output and passwd -crypt - and both of them are explicitly mentioned to require OMC vote to drop completely. So this is misunderstanding. The problem is that the current state of the API does not deprecate (as in add deprecation warnings and disable in no- deprecated build) many low level API things that are supposed to be deprecated. And we list them here in this list as a requirement to be finished before the 3.0 can be declared feature complete. > [1] https://www.openssl.org/docs/OpenSSL300Design.html -- 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 nic.tuv at gmail.com Fri Oct 9 11:48:19 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 9 Oct 2020 14:48:19 +0300 Subject: [VOTE PROPOSAL] Weekly OTC meeting until 3.0 beta1 is released In-Reply-To: References: Message-ID: I received no feedback, so I am keeping the vote text as proposed and opening the vote shortly. Nicola On Wed, 7 Oct 2020 at 16:53, Nicola Tuveri wrote: > > Background > ---------- > > Since the two virtual face-to-face OTC meetings of last week, and again > in the two OTC meetings this week, we repeatedly discussed replacing the > weekly "developer meetings" with official OTC meetings. > > The "developer meetings" have so far seen frequent participation from a > subset of OTC members heavily involved in day to day tasks for the > [`3.0 New Core + FIPS` project][new_core+FIPS], and have been open and > advertised to all OTC members since the end of January, but they were > not qualified as official OTC meetings: they were meant to assess the > weekly progress within the project, and determine the coming week's > priorities, discussing and resolving any difficulties encountered. > > Rationale > --------- > > At this point in the development process, in which we are refining the > state of development branch to finally qualify for the transition into > the beta release stage, upgrading these meetings to proper OTC meetings > seems appropriate and desirable, as discussion and assessment of the > remaining technical tasks increasingly requires discussion within the > OTC and OTC decisions, and additionally provides OTC steering on the > preferred way of completing some of the allocated tasks before the work > is done, rather than after the fact. > > Personally, I also expect that upgrading the developer meetings into > full-fledged OTC meetings will increase attendance by the wider OTC > audience: this would provide the OTC as a whole with better oversight on > the progress towards the upcoming release, and would further improve the > quality of the release process by leveraging the plurality of OTC > perspectives and insights. > > Meeting Schedule > ---------------- > > So far, the "developer meetings" have been regularly scheduled each > Tuesday from 08:00 to 09:30 (UTC, 24h format), with a tendency to spill > into the next half-hour. > There have been cases in which we had to hit the 3h mark, but I wouldn't > describe 3h as the norm. > My proposal for the OTC meeting is to adopt the same 1h30m (+30m buffer) > approach. > Tuesday, 08:00 UTC as the starting time, has been so far a good > compromise between folks working in European and Australian timezone, > and keeping it is the current proposal, but is admittedly not the best > time for attendance from the American continents. > > Vote: why and when? > ------------------- > > We are proposing a vote, rather than agreeing on it during the last > call, to invite discussion from the OTC members that could not > participate in the meetings during these two weeks, for example > regarding alternative time slots to improve overall attendance. > > I plan to wait until Friday to open the actual vote: please provide > feedback before then if you would like to amend the letter of the vote > topic. > > One item on which I'd like to ask for feedback is if the actual vote > text should include the specifics of the timeslot or not. > > Proposed vote text > ------------------ > > Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly > "developer meetings". > > Refs > ---- > > [new_core+FIPS]: https://github.com/openssl/openssl/projects/2 From nic.tuv at gmail.com Fri Oct 9 12:00:00 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 9 Oct 2020 15:00:00 +0300 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released Message-ID: topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 and until 3.0 beta1 is released, in lieu of the weekly "developer meetings". Proposed by Nicola Tuveri Public: yes opened: 2020-10-09 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ ] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [+1] From tmraz at redhat.com Fri Oct 9 12:02:29 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 09 Oct 2020 14:02:29 +0200 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch Message-ID: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> topic: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch As the change is borderline on bug fix/behaviour change OTC needs to decide whether it is acceptable for 1.1.1 branch. Proposed by Tomas Mraz Public: yes opened: 2020-10-09 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ ] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] -- 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 tmraz at redhat.com Fri Oct 9 12:03:39 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 09 Oct 2020 14:03:39 +0200 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: +1 On Fri, 2020-10-09 at 15:00 +0300, Nicola Tuveri wrote: > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly > "developer > meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From paul.dale at oracle.com Fri Oct 9 12:14:45 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 9 Oct 2020 22:14:45 +1000 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: <79F1FADB-EC6D-4F91-9E84-E2734971A2EE@oracle.com> +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 10:00 pm, Nicola Tuveri wrote: > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly "developer > meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Oct 9 12:19:42 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 9 Oct 2020 13:19:42 +0100 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: +1 On 09/10/2020 13:00, Nicola Tuveri wrote: > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly "developer > meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > From kurt at roeckx.be Fri Oct 9 12:40:39 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 9 Oct 2020 14:40:39 +0200 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: <20201009124039.GD45463@roeckx.be> On Fri, Oct 09, 2020 at 03:00:00PM +0300, Nicola Tuveri wrote: > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly "developer > meetings". +1 Kurt From tjh at cryptsoft.com Fri Oct 9 19:20:34 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 10 Oct 2020 05:20:34 +1000 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: +1 Tim On Fri, 9 Oct 2020, 10:01 pm Nicola Tuveri, wrote: > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly "developer > meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Fri Oct 9 21:29:11 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Sat, 10 Oct 2020 07:29:11 +1000 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: [+1] (reluctantly committing to 3 hour meetings :)) > On 9 Oct 2020, at 10:00 pm, Nicola Tuveri wrote: > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly "developer > meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri Oct 9 23:44:04 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 10 Oct 2020 09:44:04 +1000 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: <77168EF0-9E37-4BA7-953F-1AB71A6360E6@oracle.com> Nowhere has it been said that the weekly meeting will be 3 hours. The existing 1.5 - 2 hour slot should be enough, although perhaps not for a few more weeks. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 10 Oct 2020, at 7:29 am, SHANE LONTIS wrote: > > [+1] (reluctantly committing to 3 hour meetings :)) > > >> On 9 Oct 2020, at 10:00 pm, Nicola Tuveri > wrote: >> >> topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 >> and until 3.0 beta1 is released, in lieu of the weekly "developer >> meetings". >> Proposed by Nicola Tuveri >> Public: yes >> opened: 2020-10-09 >> closed: 2020-mm-dd >> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) >> >> Matt [ ] >> Mark [ ] >> Pauli [ ] >> Viktor [ ] >> Tim [ ] >> Richard [ ] >> Shane [ ] >> Tomas [ ] >> Kurt [ ] >> Matthias [ ] >> Nicola [+1] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Sat Oct 10 00:52:29 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 10 Oct 2020 10:52:29 +1000 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 10:02 pm, Tomas Mraz wrote: > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > 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.] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Sat Oct 10 07:33:35 2020 From: mark at openssl.org (Mark J Cox) Date: Sat, 10 Oct 2020 08:33:35 +0100 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: +1 On Fri, Oct 9, 2020 at 1:03 PM Tomas Mraz wrote: > > +1 > > On Fri, 2020-10-09 at 15:00 +0300, Nicola Tuveri wrote: > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > > and until 3.0 beta1 is released, in lieu of the weekly > > "developer > > meetings". > > Proposed by Nicola Tuveri > > Public: yes > > opened: 2020-10-09 > > closed: 2020-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [ ] > > Mark [ ] > > Pauli [ ] > > Viktor [ ] > > Tim [ ] > > Richard [ ] > > Shane [ ] > > Tomas [ ] > > Kurt [ ] > > Matthias [ ] > > Nicola [+1] > -- > 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 Matthias.St.Pierre at ncp-e.com Sat Oct 10 21:44:00 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 10 Oct 2020 21:44:00 +0000 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: 0 > -----Original Message----- > From: openssl-project On Behalf Of Tomas Mraz > Sent: Friday, October 9, 2020 2:02 PM > To: openssl-project at openssl.org > Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for > 1.1.1 branch > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > 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 Matthias.St.Pierre at ncp-e.com Sat Oct 10 21:45:40 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 10 Oct 2020 21:45:40 +0000 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: <7fa30a0eed7144cda3863628d24b5476@ncp-e.com> +1 > -----Original Message----- > From: openssl-project On Behalf Of Mark J Cox > Sent: Saturday, October 10, 2020 9:34 AM > To: openssl-project at openssl.org > Subject: Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released > > +1 > > On Fri, Oct 9, 2020 at 1:03 PM Tomas Mraz wrote: > > > > +1 > > > > On Fri, 2020-10-09 at 15:00 +0300, Nicola Tuveri wrote: > > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > > > and until 3.0 beta1 is released, in lieu of the weekly > > > "developer > > > meetings". > > > Proposed by Nicola Tuveri > > > Public: yes > > > opened: 2020-10-09 > > > closed: 2020-mm-dd > > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > > > Matt [ ] > > > Mark [ ] > > > Pauli [ ] > > > Viktor [ ] > > > Tim [ ] > > > Richard [ ] > > > Shane [ ] > > > Tomas [ ] > > > Kurt [ ] > > > Matthias [ ] > > > Nicola [+1] > > -- > > 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 shane.lontis at oracle.com Sat Oct 10 23:16:58 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Sun, 11 Oct 2020 09:16:58 +1000 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: 0 > On 9 Oct 2020, at 10:02 pm, Tomas Mraz wrote: > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > 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.] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Sun Oct 11 10:34:13 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sun, 11 Oct 2020 13:34:13 +0300 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: +1 I am basing my vote on the feedback provided by @DDvO [0] and @t8m [1]. In particular I am convinced to vote in favor, as I can see this as a bug fix, fixing an undocumented inconsistency, and that it is very unlikely it would affect existing applications. Nicola [0]: https://github.com/openssl/openssl/pull/11359#issuecomment-706189632 [1]: https://github.com/openssl/openssl/pull/11359#issuecomment-706191205 On Fri, 9 Oct 2020 at 15:02, Tomas Mraz wrote: > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > 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 nic.tuv at gmail.com Sun Oct 11 10:49:05 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Sun, 11 Oct 2020 13:49:05 +0300 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: As defined by the [OTC Voting Procedures][0], I am declaring the vote closed, as the number of uncast votes cannot affect the outcome of the vote. The vote is accepted. topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 and until 3.0 beta1 is released, in lieu of the weekly "developer meetings". Proposed by Nicola Tuveri Public: yes opened: 2020-10-09 closed: 2020-10-11 accepted: yes (for: 9, against: 0, abstained: 0, not voted: 2) Matt [+1] Mark [+1] Pauli [+1] Viktor [ ] Tim [+1] Richard [ ] Shane [+1] Tomas [+1] Kurt [+1] Matthias [+1] Nicola [+1] Nicola Tuveri [0]: https://www.openssl.org/policies/omc-bylaws.html On Fri, 9 Oct 2020 at 15:00, Nicola Tuveri wrote: > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly "developer > meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] From matt at openssl.org Mon Oct 12 09:12:55 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Oct 2020 10:12:55 +0100 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: <5f8b3310-9f16-1e79-78b0-88ffd254fbd6@openssl.org> -1 On 09/10/2020 13:02, Tomas Mraz wrote: > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > From matt at openssl.org Mon Oct 12 09:15:36 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Oct 2020 10:15:36 +0100 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: <75008eef-899a-0aae-117e-0c43346a6944@openssl.org> On 11/10/2020 11:34, Nicola Tuveri wrote: > I am basing my vote on the feedback provided by @DDvO [0] and @t8m [1]. > In particular I am convinced to vote in favor, as I can see this as a > bug fix, fixing an undocumented inconsistency, and that it is very > unlikely it would affect existing applications. IMO this is not a bug fix. It does correct an undocumented inconsistency and so I have no problem with this being applied to master. But I think it is a stretch to describe it as a bug fix. Matt > > > Nicola > > > [0]: https://github.com/openssl/openssl/pull/11359#issuecomment-706189632 > [1]: https://github.com/openssl/openssl/pull/11359#issuecomment-706191205 > > > On Fri, 9 Oct 2020 at 15:02, Tomas Mraz wrote: >> >> topic: The PR #11359 (Allow to continue with further checks on >> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch >> As the change is borderline on bug fix/behaviour change OTC needs >> to decide whether it is acceptable for 1.1.1 branch. >> Proposed by Tomas Mraz >> Public: yes >> opened: 2020-10-09 >> closed: 2020-mm-dd >> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) >> >> Matt [ ] >> Mark [ ] >> Pauli [ ] >> Viktor [ ] >> Tim [ ] >> Richard [ ] >> Shane [ ] >> Tomas [+1] >> Kurt [ ] >> Matthias [ ] >> Nicola [ ] >> >> -- >> 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 tjh at cryptsoft.com Mon Oct 12 09:26:00 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Mon, 12 Oct 2020 19:26:00 +1000 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: -1 I don't see this as a bug fix. Tim On Fri, Oct 9, 2020 at 10:02 PM Tomas Mraz wrote: > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > 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.] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Mon Oct 12 09:32:55 2020 From: mark at openssl.org (Mark J Cox) Date: Mon, 12 Oct 2020 10:32:55 +0100 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: 0 On Fri, Oct 9, 2020 at 1:02 PM Tomas Mraz wrote: > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > 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 Oct 12 14:13:44 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Oct 2020 15:13:44 +0100 Subject: Monthly Status Report (September) Message-ID: <33efa045-3c92-4038-c1d2-ab1282ccc90d@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 and eventually merged a PR to add an HMAC implementation that was TLS aware - Managed the response to the Raccoon Attack and the associated 1.0.2w release - Fixed an EVP_MD_CTX related memory leak - Overhauled and fixed long standing issues with stafestack - Published a blog post on the OpenSSL Administrator and Manager position - Fixed the dgst app to not assume that it can send -1 for the length of a raw key - Implemented a fix for lhash along the same lines as the safestack fix - Drafted and attempted to get passed (only partially successfully) new coding style guidance about function arguments - Added support to the provider side EdDSA signature algorithm for AlgorithmIdentifiers. - Managed the release of 1.1.1h - Investigated and created a reproducer for an issue where EC based EVP_PKEYs fail to work in master where a private key is set but there is no public key, but the same code worked in 1.1.1 - Implemented provider side support for SM2 Asymmetric Encryption - Ongoing activity in the recruitment for the Administrator & Manager position - Renamed all *_with_libctx functions to *_ex() - Reviewed old issues for relevance to the beta1 milestone - Reviewed all the outstanding TODO(3.0) tags for relevance to the beta1 milestone - Attended 2 OTC vf2f meetings - Attended committer vf2f meeting - Ongoing attendance at regular developer meetings - Ongoing attendance at regular FIPS sponsor meetings Matt From levitte at openssl.org Tue Oct 13 08:09:12 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 13 Oct 2020 10:09:12 +0200 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: <87r1q2im3b.wl-levitte@openssl.org> +1 On Fri, 09 Oct 2020 14:02:29 +0200, Tomas Mraz wrote: > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > 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.] > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Oct 13 08:10:22 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 13 Oct 2020 10:10:22 +0200 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <87r1q2im3b.wl-levitte@openssl.org> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> <87r1q2im3b.wl-levitte@openssl.org> Message-ID: <87pn5mim1d.wl-levitte@openssl.org> Cancel that, wrong vote. For this, 0 On Tue, 13 Oct 2020 10:09:12 +0200, Richard Levitte wrote: > > +1 > > On Fri, 09 Oct 2020 14:02:29 +0200, > Tomas Mraz wrote: > > > > topic: The PR #11359 (Allow to continue with further checks on > > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > > As the change is borderline on bug fix/behaviour change OTC needs > > to decide whether it is acceptable for 1.1.1 branch. > > Proposed by Tomas Mraz > > Public: yes > > opened: 2020-10-09 > > closed: 2020-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [ ] > > Mark [ ] > > Pauli [ ] > > Viktor [ ] > > Tim [ ] > > Richard [ ] > > Shane [ ] > > Tomas [+1] > > Kurt [ ] > > Matthias [ ] > > Nicola [ ] > > > > -- > > 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.] > > > > > -- > 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 levitte at openssl.org Tue Oct 13 08:10:34 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 13 Oct 2020 10:10:34 +0200 Subject: VOTE: Weekly OTC meetings until 3.0 beta1 is released In-Reply-To: References: Message-ID: <87o8l6im11.wl-levitte@openssl.org> +1 On Fri, 09 Oct 2020 14:00:00 +0200, Nicola Tuveri wrote: > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 > and until 3.0 beta1 is released, in lieu of the weekly "developer > meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Oct 13 08:16:58 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 13 Oct 2020 10:16:58 +0200 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: <87mu0qilqd.wl-levitte@openssl.org> +1 As for "EVP is the recommended API", I hope that everyone understands this to be for crypto functionality (hash functions, cipher functions, EVP_PKEY functions, MAC functions, KDF functions), not *everything*. On Thu, 08 Oct 2020 16:47:18 +0200, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Oct 13 08:23:10 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Oct 2020 09:23:10 +0100 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: <1aebf41c-fba5-54c9-0ea1-72f603fab3f2@openssl.org> I have just close this vote. The final result was: accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3) Matt On 08/10/2020 15:47, Matt Caswell wrote: > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > From tjh at cryptsoft.com Tue Oct 13 09:40:37 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Tue, 13 Oct 2020 19:40:37 +1000 Subject: Additional things for deprecation Message-ID: In a 3.0 context, EVP_PKEY_ASN1_METHOD and all the associated functions should be marked deprecated in my view. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Oct 13 10:14:43 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 13 Oct 2020 12:14:43 +0200 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: <87k0vuiga4.wl-levitte@openssl.org> +1 On Thu, 08 Oct 2020 16:27:18 +0200, Matt Caswell wrote: > > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Oct 13 10:20:25 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Oct 2020 11:20:25 +0100 Subject: Alpha releases In-Reply-To: References: <7249628a-4cde-71b1-4aed-b8f712aaa8ea@openssl.org> Message-ID: <2b597f5f-eaf8-bac8-618e-92927f535fe0@openssl.org> On 07/10/2020 17:36, Matt Caswell wrote: > This vote has now started. I'll post here with the results once its > complete. This vote has now closed and was accepted: +1: 6: 0: 0 -1: 0 No vote: 1 Matt > > Matt > > On 06/10/2020 13:12, Matt Caswell wrote: >> The OTC meeting today discussed making further alpha releases while we >> continue to work towards getting to beta 1. It was proposed that we >> release alpha 7 on Thursday 15h October and then regularly on a 3 weekly >> basis thereafter until such time as beta 1 is ready. >> >> This will need to be an OMC decision so this is my suggested vote wording: >> >> "OpenSSL 3.0 Alpha 7 shouuld be released on Thursday 15th October and >> subsequent alpha releases should be performed on a 3 weekly basis until >> beta 1 is ready" >> >> I'd like to give an opportunity for feedback on the above before I call >> this vote. >> >> Note that the OTC discussions on beta 1 (looking at the proposal that >> Nicola posted to this list last Friday) are still ongoing. There will be >> a further meeting tomorrow. >> >> Matt >> > From nic.tuv at gmail.com Tue Oct 13 10:34:18 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 13 Oct 2020 13:34:18 +0300 Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality In-Reply-To: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> References: <8eb88410-9bc4-10cb-097e-91dce4715abe@openssl.org> Message-ID: As defined by the [OTC Voting Procedures][0], I am declaring the vote closed, as the number of uncast votes cannot affect the outcome of the vote. The vote is accepted. topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as shown in PR #13018 into the 3.0 release Proposed by Matt Caswell Public: yes opened: 2020-10-08 closed: 2020-10-13 accepted: yes (for: 8, against: 1, abstained: 1, not voted: 1) Matt [+1] Mark [ 0] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [-1] Tomas [+1] Kurt [+1] Matthias [+1] Nicola [+1] -- Nicola [0]: https://www.openssl.org/policies/omc-bylaws.html From levitte at openssl.org Tue Oct 13 12:25:03 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 13 Oct 2020 14:25:03 +0200 Subject: Additional things for deprecation In-Reply-To: References: Message-ID: <87imbeia8w.wl-levitte@openssl.org> Hmmm, are we going to start marking types for deprecation? I would advise against it on a general level, 'cause that's likely to cause an implosion. See for example marking ENGINE for deprecation, i.e. this: -------------- next part -------------- diff --git a/include/openssl/types.h b/include/openssl/types.h index ee024cef29..4e73c0dc0d 100644 --- a/include/openssl/types.h +++ b/include/openssl/types.h @@ -172,7 +172,9 @@ typedef struct ossl_init_settings_st OPENSSL_INIT_SETTINGS; typedef struct ui_st UI; typedef struct ui_method_st UI_METHOD; -typedef struct engine_st ENGINE; +# ifndef OPENSSL_NO_DEPRECATED_3_0 +OSSL_DEPRECATEDIN_3_0 typedef struct engine_st ENGINE; +# endif typedef struct ssl_st SSL; typedef struct ssl_ctx_st SSL_CTX; -------------- next part -------------- Try that and see your build become... interesting. Cheers, Richard On Tue, 13 Oct 2020 11:40:37 +0200, Tim Hudson wrote: > > In a 3.0 context,?EVP_PKEY_ASN1_METHOD and all the associated functions should be marked > deprecated in my view. > > Tim. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Oct 13 12:28:44 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Oct 2020 13:28:44 +0100 Subject: Proposed vote: Drop C code output options from the apps Message-ID: <13379281-0bca-b5e7-be63-9bb1c70c4e2c@openssl.org> The OTC recently adopted a list of technical items still to be done which included this item: Drop C code output options from the apps (OMC approval required). Examples of this include the "-C" options to dhparam, dsaparam and ecparam applications. This provides the ability to convert parameters into C code. Unfortunately this C code uses APIs that are due to be deprecated in 3.0. Therefore we either have to fix this or remove the option. The OTC recommendation is that the option should be removed. Since this is the removal of a feature OMC approval is required. This is my proposed vote text "Drop from 3.0 support for the C code output options from the applications where the use of deprecated APIs is required" Note: I notice that the x509 application also has such an option but does not appear to require the use of deprecated APIs. The above vote text as it is currently written would therefore not apply to that application. Feedback please on the proposed vote text before I raise this. Matt From matt at openssl.org Tue Oct 13 12:41:15 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Oct 2020 13:41:15 +0100 Subject: Proposed vote: Drop support for "passwd -crypt" Message-ID: The OTC recently adopted a list of technical items still to be done which included this item: - Proposal: drop passwd -crypt (OMC vote required) The passwd application contains the option "-crypt" which provides an implementation for the traditional UNIX password encryption scheme based on a modified version of DES. This is a default option for the passwd application. The OTC recommendation is to drop support for this option from 3.0. Since this is the removal of a feature OMC approval is required. This is my proposed vote text "Drop from 3.0 support for the '-crypt' option from the passwd application" Feedback please on the proposed vote text before I raise this. Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 13 20:43:08 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 13 Oct 2020 20:43:08 +0000 Subject: Assigning OpenSSL 3.0.0 beta1 issues Message-ID: A lot of GitHub issues were created by Nicola (@romen) today to keep track of the [Technical Items still to be done][tbd] list. On the same occasion, we assigned some of the tasks internally. For more transparency, I converted the assignments on the internal spreadsheet into GitHub assignments of the corresponding [beta1 issues]. Note that there remain a lot of [unassigned beta1 issues]. Matthias [tbd]: https://www.mail-archive.com/openssl-project at openssl.org/msg02141.html [beta1 issues]: https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.0.0+beta1%22 [unassigned beta1 issues]: https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.0.0+beta1%22+no%3Aassignee From kurt at roeckx.be Wed Oct 14 14:12:38 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 14 Oct 2020 16:12:38 +0200 Subject: VOTE: Technical Items still to be done In-Reply-To: References: Message-ID: <20201014141238.GA383636@roeckx.be> On Thu, Oct 08, 2020 at 03:47:18PM +0100, Matt Caswell wrote: > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. > - Anything that isn?t available must be put to an OTC vote to exclude. > - The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. > - Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). > - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. > - There might be some others. > - Review for exceptions. > - The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) > - Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) > - Need a list of things we know are not present - including things we > have > removed. > - We need to have mapping tables for various d2i/i2d functions. > - We need to have a mapping table from ?old names? for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to > the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 -1 I think we can delay some of that work until 3.1. Kurt From kurt at roeckx.be Wed Oct 14 14:15:25 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 14 Oct 2020 16:15:25 +0200 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: <20201014141525.GB383636@roeckx.be> On Fri, Oct 09, 2020 at 02:02:29PM +0200, Tomas Mraz wrote: > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd 0 Kurt From rsalz at akamai.com Wed Oct 14 16:08:26 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Oct 2020 16:08:26 +0000 Subject: Assigning OpenSSL 3.0.0 beta1 issues In-Reply-To: References: Message-ID: I am interested in helping out with the deprecation tasks. Should I assume that Richard's PR to change how it's done will be going in? From matt at openssl.org Wed Oct 14 16:22:25 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Oct 2020 17:22:25 +0100 Subject: Assigning OpenSSL 3.0.0 beta1 issues In-Reply-To: References: Message-ID: On 14/10/2020 17:08, Salz, Rich wrote: > I am interested in helping out with the deprecation tasks. Should I assume that Richard's PR to change how it's done will be going in? > I'm not sure which of Richard's PRs you're referring to? Matt From rsalz at akamai.com Wed Oct 14 16:36:39 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Oct 2020 16:36:39 +0000 Subject: Assigning OpenSSL 3.0.0 beta1 issues In-Reply-To: References: Message-ID: <753FC0A0-354A-4D4E-B44C-C3FB6A092000@akamai.com> On 14/10/2020 17:08, Salz, Rich wrote: > I am interested in helping out with the deprecation tasks. Should I assume that Richard's PR to change how it's done will be going in? > I'm not sure which of Richard's PRs you're referring to? I thought he had a "rethinking how we deprecate" PR or issue, but I can't find it now. From openssl at openssl.org Thu Oct 15 13:38:32 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 15 Oct 2020 13:38:32 +0000 Subject: OpenSSL version 3.0.0-alpha7 published Message-ID: <20201015133832.GA10055@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 7 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 7 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha7.tar.gz Size: 14005200 SHA1 checksum: 1d05682f62b34038a37b196c7c43a21013f5f507 SHA256 checksum: 2884219ad2fae614c0f0d57b77af2f0720f32ffa3a569ac70bbf506bd8732298 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha7.tar.gz openssl sha256 openssl-3.0.0-alpha7.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl+IS5sACgkQ2cTSbQ5g RJGBOAgAidOQVOhw5N3tLVOD1EqNvg+0FoEugGtM0lXSBFXXbcKc12jV/e1INyw6 iaZImtypZtlrEfIYFQUkTfEzfGAYXK8E9Xx6GTIV41tacd516MWz7NtMJkZlp3Fb D2DcEutqTO3Xi3XS+pPElLxSMzuSgGt8ZqqTv7ZqgseN+1uB/tdKUPZqDO+DTSpz n/0oMnpsqJsEXqv3N5sS/2ASa9paLkLsIoChDeJzc5j41aKnMTgwAPqF2r8vLBfo k851L5S/gsMw5Y9M3ljM4IYNiU0/lneGnT//uYOnLAKY/s1I9hNcWC/Q63xrOoqT zukZ2NoqTcCYC+a0Vg3yBpjwSYuaSA== =hL/2 -----END PGP SIGNATURE----- From kaduk at mit.edu Sat Oct 17 22:37:42 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Sat, 17 Oct 2020 15:37:42 -0700 Subject: Assigning OpenSSL 3.0.0 beta1 issues In-Reply-To: <753FC0A0-354A-4D4E-B44C-C3FB6A092000@akamai.com> References: <753FC0A0-354A-4D4E-B44C-C3FB6A092000@akamai.com> Message-ID: <20201017223742.GC39170@kduck.mit.edu> On Wed, Oct 14, 2020 at 04:36:39PM +0000, Salz, Rich wrote: > On 14/10/2020 17:08, Salz, Rich wrote: > > I am interested in helping out with the deprecation tasks. Should I assume that Richard's PR to change how it's done will be going in? > > > > I'm not sure which of Richard's PRs you're referring to? > > I thought he had a "rethinking how we deprecate" PR or issue, but I can't find it now. I think it was https://github.com/openssl/openssl/pull/13074 (now merged). -Ben From kurt at roeckx.be Sun Oct 18 07:33:11 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 18 Oct 2020 09:33:11 +0200 Subject: Meaning of no-xxx option Message-ID: <20201018073311.GA599267@roeckx.be> Hi, It seems that we might start to interprete the no-xxx options differently. In 1.1.1 it would completly disable the feature in libcrypto, the apps and libssl. It seems that now the interpretation changed to just disable the support for it in the provider. You might load a different provider that does support it, and so the apps and libssl can use it then. My interpretation was always that we want to completly disable the feature, for instance because we don't want to use it at all or we want to reduce the size of the binries. Kurt From beldmit at gmail.com Sun Oct 18 09:27:54 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 18 Oct 2020 12:27:54 +0300 Subject: Meaning of no-xxx option In-Reply-To: <20201018073311.GA599267@roeckx.be> References: <20201018073311.GA599267@roeckx.be> Message-ID: Dear Kurt, The situation in 1.1.1 was a bit fuzzier than you say. E.g., openssl built with no-gost in fact permits loading an engine for use in X.509/CMS, but GOST TLS support becomes unavailable. On Sun, Oct 18, 2020 at 10:33 AM Kurt Roeckx wrote: > Hi, > > It seems that we might start to interprete the no-xxx options > differently. In 1.1.1 it would completly disable the feature in > libcrypto, the apps and libssl. It seems that now the > interpretation changed to just disable the support for it in the > provider. You might load a different provider that does support > it, and so the apps and libssl can use it then. > > My interpretation was always that we want to completly disable the > feature, for instance because we don't want to use it at all or we > want to reduce the size of the binries. > > > Kurt > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sun Oct 18 10:19:36 2020 From: levitte at openssl.org (Richard Levitte) Date: Sun, 18 Oct 2020 12:19:36 +0200 Subject: Meaning of no-xxx option In-Reply-To: <20201018073311.GA599267@roeckx.be> References: <20201018073311.GA599267@roeckx.be> Message-ID: <87sgabeszr.wl-levitte@openssl.org> I'm afraid your interpretation isn't quite correct. The no-xxx options remove the actual code for the thing being disabled, but it doesn't turn off access to a compatible implementation. For example, you could conceptually have an ENGINE with an alternative DSA implementation that's perfectly usable through the EVP interface (keys will have to be loaded through that same engine, though), regardless of any no-dsa configuration. This is also reflect in the apps. Yes, the key type specific commands like 'openssl dsa' are disabled, but that's because in 1.1.1, they use the lower level APIs and can simply not build at all if the calls they depend on aren't there. However, if you look at apps/*pkey*.c, you will find very few uses of OPENSSL_NO_ macros. 1.1.1 only guards engine calls with OPENSSL_NO_ENGINE... master has some OPENSSL_NO_EC guards, for reasons I'm currently unaware of, I assume some kind of special case that should really be removed. So I guess this comes down to what's currently being done, where commands like 'openssl dsa' starts to use EVP functionality, and thereby become *more* available than before. If that's good or bad, only time will tell... In summary, the time where no-xxx truly meant that the algorithm xxx is completely unavailable is long gone. The addition of ENGINEs changed that... not immediately, but as soon as the ENGINE API got functionality to help implement EVP_PKEY_METHODs and EVP_PKEY_ASN1_METHODs. Cheers, Richard On Sun, 18 Oct 2020 09:33:11 +0200, Kurt Roeckx wrote: > > Hi, > > It seems that we might start to interprete the no-xxx options > differently. In 1.1.1 it would completly disable the feature in > libcrypto, the apps and libssl. It seems that now the > interpretation changed to just disable the support for it in the > provider. You might load a different provider that does support > it, and so the apps and libssl can use it then. > > My interpretation was always that we want to completly disable the > feature, for instance because we don't want to use it at all or we > want to reduce the size of the binries. > > > Kurt > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Oct 19 09:15:26 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 19 Oct 2020 10:15:26 +0100 Subject: Meaning of no-xxx option In-Reply-To: <87sgabeszr.wl-levitte@openssl.org> References: <20201018073311.GA599267@roeckx.be> <87sgabeszr.wl-levitte@openssl.org> Message-ID: <18990496-853b-8ae9-c942-c8fa0fe7af4e@openssl.org> On 18/10/2020 11:19, Richard Levitte wrote: > In summary, the time where no-xxx truly meant that the algorithm xxx > is completely unavailable is long gone. The addition of ENGINEs > changed that... not immediately, but as soon as the ENGINE API got > functionality to help implement EVP_PKEY_METHODs and > EVP_PKEY_ASN1_METHODs. Right. This is my opinion too. Historically no-dh (for example) meant that the low level implementation of "dh" was not compiled. Unfortunately the lack of the low level APIs was "viral" in the sense that it meant removal of all functions that used those APIs (because we had too - otherwise it wouldn't build). Due to the wholesale replacement of the low level APIs with high level ones we no longer need to do this. The low level API implementations are no longer there, but the functionality that was previously removed can remain. The "viral" nature of the removal has gone. To me this makes sense. We are moving to a model where the control of what algorithms are available depends on what providers are loaded. If you don't want support for DH, then don't load any providers that support it. The "no-dh" option restricts itself to controlling how the providers are built - but doesn't have impacts beyond that (except I suppose in the tests). Matt > > Cheers, > Richard > > On Sun, 18 Oct 2020 09:33:11 +0200, > Kurt Roeckx wrote: >> >> Hi, >> >> It seems that we might start to interprete the no-xxx options >> differently. In 1.1.1 it would completly disable the feature in >> libcrypto, the apps and libssl. It seems that now the >> interpretation changed to just disable the support for it in the >> provider. You might load a different provider that does support >> it, and so the apps and libssl can use it then. >> >> My interpretation was always that we want to completly disable the >> feature, for instance because we don't want to use it at all or we >> want to reduce the size of the binries. >> >> >> Kurt >> From matt at openssl.org Mon Oct 19 14:14:56 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 19 Oct 2020 15:14:56 +0100 Subject: LTS+ Message-ID: <07f8b061-741c-5342-4249-d76bd6356288@openssl.org> At the recent Committer and OTC meetings a proposal was discussed to add further clarity to what is allowed in stable releases, and to introduce a new "LTS+" type of release to go alongside the existing LTS release. The idea is that an LTS release is restricted to bug fixes and security fixes only (as now). However an LTS+ release would additionally be able to accept additional platforms as well as performance improvements. LTS and LTS+ releases would be issued simultaneously, have the same support period, and would have the same minor and patch version numbers. The LTS+ designation would be separate to the version number (e.g. in a text label). In order for this to happen an OMC vote would be required. My proposed vote text (which incorporates the proposal text discussed in the meeting) is as follows: "The OMC should include the following text in its release strategy: In order to maximise stability, Long Term Support (LTS) Releases are eligible to receive bug and security fixes only. Bug fixes are: - Fixes for defects that impact behaviour that do not impact the API or the ABI - Minor fixes to existing code to correct major performance regressions (e.g. larger than 10% performance regression compared to the previous release) - Inclusion of new API functions to correct missing accessor functions Security fixes are: - Fixes and changes as necessary as a result of a CVE - Minor amendments for security hardening purposes Security fixes should not change the API/ABI, although functional behaviour may be changed if strictly necessary (e.g. changing defaults). Following an LTS release additional releases may also occur in an LTS+ release. The LTS+ release support time will be aligned with the LTS release. Releases of the LTS+ version will be done at the same time as the LTS release. LTS+ releases may contain the following new features: - Support for additional platforms - Performance improvements The LTS+ release major and minor and patch version numbers will be the same as the LTS release. The designation of the LTS+ release will be separate from the version number." Feedback is appreciated on both the proposal, and the vote text. Matt From matt at openssl.org Mon Oct 19 16:28:54 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 19 Oct 2020 17:28:54 +0100 Subject: LTS+ In-Reply-To: <07f8b061-741c-5342-4249-d76bd6356288@openssl.org> References: <07f8b061-741c-5342-4249-d76bd6356288@openssl.org> Message-ID: <0c375f2e-092a-bbed-421f-b86ccd95e347@openssl.org> On 19/10/2020 15:14, Matt Caswell wrote: > LTS+ releases may contain the following new features: > - Support for additional platforms > - Performance improvements Based on the discussion in PR #13176, I'd like to add to this list: - Extending existing features to existing platforms where that feature does not yet exist Thoughts? Matt From rsalz at akamai.com Sun Oct 18 13:40:27 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 18 Oct 2020 13:40:27 +0000 Subject: Assigning OpenSSL 3.0.0 beta1 issues In-Reply-To: <20201017223742.GC39170@kduck.mit.edu> References: <753FC0A0-354A-4D4E-B44C-C3FB6A092000@akamai.com> <20201017223742.GC39170@kduck.mit.edu> Message-ID: <0365DBE5-FAE5-4009-A709-83760F3904E1@akamai.com> > I thought he had a "rethinking how we deprecate" PR or issue, but I can't find it now. I think it was [#13074] (now merged). Yes it was, thanks. From tm at t8m.info Mon Oct 19 19:07:19 2020 From: tm at t8m.info (Tomas Mraz) Date: Mon, 19 Oct 2020 21:07:19 +0200 Subject: LTS+ In-Reply-To: <0c375f2e-092a-bbed-421f-b86ccd95e347@openssl.org> References: <07f8b061-741c-5342-4249-d76bd6356288@openssl.org> <0c375f2e-092a-bbed-421f-b86ccd95e347@openssl.org> Message-ID: I wonder if something like adding a new entropy source on an existing platform especially on some that currently don't have adequate ones would be covered by this. ?Tom??? 19. 10. 2020 18:29, 18:29, Matt Caswell napsal/a: > > >On 19/10/2020 15:14, Matt Caswell wrote: >> LTS+ releases may contain the following new features: >> - Support for additional platforms >> - Performance improvements > >Based on the discussion in PR #13176, I'd like to add to this list: > >- Extending existing features to existing platforms where that feature >does not yet exist > >Thoughts? > >Matt From paul.dale at oracle.com Mon Oct 19 23:10:51 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 20 Oct 2020 09:10:51 +1000 Subject: LTS+ In-Reply-To: References: <07f8b061-741c-5342-4249-d76bd6356288@openssl.org> <0c375f2e-092a-bbed-421f-b86ccd95e347@openssl.org> Message-ID: <5981E67C-C536-4A3C-8D44-5ADE56B5BB07@oracle.com> Not with the wording used. The feature exists even if it?s rubbish. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 20 Oct 2020, at 5:07 am, Tomas Mraz wrote: > > I wonder if something like adding a new entropy source on an existing platform especially on some that currently don't have adequate ones would be covered by this. > > ?Tom??? > > 19. 10. 2020 18:29, 18:29, Matt Caswell napsal/a: >> >> >> On 19/10/2020 15:14, Matt Caswell wrote: >>> LTS+ releases may contain the following new features: >>> - Support for additional platforms >>> - Performance improvements >> >> Based on the discussion in PR #13176, I'd like to add to this list: >> >> - Extending existing features to existing platforms where that feature >> does not yet exist >> >> Thoughts? >> >> Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Oct 19 23:52:12 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 20 Oct 2020 09:52:12 +1000 Subject: LTS+ In-Reply-To: <5981E67C-C536-4A3C-8D44-5ADE56B5BB07@oracle.com> References: <07f8b061-741c-5342-4249-d76bd6356288@openssl.org> <0c375f2e-092a-bbed-421f-b86ccd95e347@openssl.org> <5981E67C-C536-4A3C-8D44-5ADE56B5BB07@oracle.com> Message-ID: <3307D92A-AAD5-4EBE-9227-D6316BA36D68@oracle.com> Unless the change can be argued to be security hardening ? an improved entropy source would be IMO. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 20 Oct 2020, at 9:10 am, Dr Paul Dale wrote: > > Not with the wording used. The feature exists even if it?s rubbish. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 20 Oct 2020, at 5:07 am, Tomas Mraz > wrote: >> >> I wonder if something like adding a new entropy source on an existing platform especially on some that currently don't have adequate ones would be covered by this. >> >> ?Tom??? >> >> 19. 10. 2020 18:29, 18:29, Matt Caswell > napsal/a: >>> >>> >>> On 19/10/2020 15:14, Matt Caswell wrote: >>>> LTS+ releases may contain the following new features: >>>> - Support for additional platforms >>>> - Performance improvements >>> >>> Based on the discussion in PR #13176, I'd like to add to this list: >>> >>> - Extending existing features to existing platforms where that feature >>> does not yet exist >>> >>> Thoughts? >>> >>> Matt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Oct 21 03:30:50 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 21 Oct 2020 13:30:50 +1000 Subject: Hacktoberfest Message-ID: There has been a request in #13172 to tag the PR for Hacktoberfest . There are two ways to do this: add a tag to the PR or a topic to the project. Is either something the project is interested in doing? Rather than polluting our already busy tags menu, the topic seems the easier path to me. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Wed Oct 21 05:33:23 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 21 Oct 2020 05:33:23 +0000 Subject: Hacktoberfest In-Reply-To: References: Message-ID: Given the fact that only one person asked for it and that only ten days are left in October, I think the label solution might be the simpler one for the moment. (Assuming that adding Topics to the project requires a vote?) The label has already been created and is ready to be applied, to make the person happy which asked for it. In November, the label can be removed again. [cid:image003.png at 01D6A77C.74236BB0] In general, I agree that GitHub Topics are a better solution. If we decide to participate officially next year, we should take the time to inform ourselves in advance and announce our participation in form of a blog post (I volunteer). Also, GitHub Topics should be discussed in more generality, i.e., what's our benefit of using GitHub Topics, and which topics we should add to the project. Up to yesterday, I didn't give GitHub Topics much thought. Matthias From: openssl-project On Behalf Of Dr Paul Dale Sent: Wednesday, October 21, 2020 5:31 AM To: openssl-project at openssl.org Subject: Hacktoberfest There has been a request in #13172 to tag the PR for Hacktoberfest. There are two ways to do this: add a tag to the PR or a topic to the project. Is either something the project is interested in doing? Rather than polluting our already busy tags menu, the topic seems the easier path to me. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 28479 bytes Desc: image003.png URL: From Matthias.St.Pierre at ncp-e.com Wed Oct 21 05:45:29 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 21 Oct 2020 05:45:29 +0000 Subject: Hacktoberfest In-Reply-To: References: Message-ID: <0c63fe389bda4a4ebb38477531b16cd7@ncp-e.com> > Rather than polluting our already busy tags menu, ... FWIW: the tags menu supports incremental search. Just type any fragment of the label name or its description, to narrow down the selection list. [cid:image001.png at 01D6A77E.24BF19F0] From: openssl-project On Behalf Of Dr Paul Dale Sent: Wednesday, October 21, 2020 5:31 AM To: openssl-project at openssl.org Subject: Hacktoberfest There has been a request in #13172 to tag the PR for Hacktoberfest. There are two ways to do this: add a tag to the PR or a topic to the project. Is either something the project is interested in doing? Rather than polluting our already busy tags menu, the topic seems the easier path to me. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 118069 bytes Desc: image001.png URL: From tmraz at redhat.com Mon Oct 26 13:04:21 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 26 Oct 2020 14:04:21 +0100 Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch In-Reply-To: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> References: <14bc92d7e784e5de2541033d03a29199f642bffc.camel@redhat.com> Message-ID: <6acc98fd938a51e74981d177162632db9618f0db.camel@redhat.com> I have closed the vote now. The vote was accepted, although with a very narrow margin. accepted: yes (for: 3, against: 2, abstained: 5, not voted: 1) Tomas On Fri, 2020-10-09 at 14:02 +0200, Tomas Mraz wrote: > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From paul.dale at oracle.com Thu Oct 29 23:43:13 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 30 Oct 2020 09:43:13 +1000 Subject: Project direction Message-ID: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> At the OTC call on Tuesday Tim raise a point about the future direction of the project. I was tasked with bringing this to the OMC for consideration. The question was should we design our APIs to ease the pain existing users of OpenSSL or should we be trying to attract new users. The idea being that supporting existing users means not changing the existing API, whereas catering to new users means working towards a new fresh consistent API. This is all in the context of function naming, argument ordering, cleanup for beta 1. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Oct 31 15:25:20 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 31 Oct 2020 16:25:20 +0100 Subject: Late Monthly Status Report (June 2020) Message-ID: <87v9eqto2n.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Incorporate system guessing in Configure (PR openssl/openssl#11230) - PEM: Make PKCS8 serializing functions aware of OSSL_SERIALIZERs (PR openssl/openssl#11855) - APPS: Make it possible to load_cert() from stdin again (PR openssl/openssl#11873) - CORE: make sure activated fallback providers stay activated (PR openssl/openssl#11926) - APPS: Create a library context in the main app, and pass it to commands (PR openssl/openssl#11982) - APPS: Drop interactive mode in the 'openssl' program (PR openssl/openssl#12023) - EVP: Let EVP_PKEY_gen() initialize ctx->keygen_info (PR openssl/openssl#12048) - TESTUTIL: Separate TAP output and other output by BIO filter (PR openssl/openssl#12057) - util/find-doc-nits: Do not read "missing" files when -u is given (PR openssl/openssl#12125) - EVP: allow empty strings to EVP_Decode* functions (PR openssl/openssl#12144) - DOCS: Add documentation for EVP_PKEY_CTX_set_rsa_pss_keygen_mgf1_md_name() (PR openssl/openssl#12188) - Build: Remove faulty DES assembler spec (PR openssl/openssl#12203) - CORE: Add OPENSSL_CTX_set0_default(), to set a default library context (PR openssl/openssl#12228) - INSTALL.md: Restore $ as command prompt indicator (PR openssl/openssl#12257) - apps/openssl: Fix buffer-overflow for command with no arguments (PR openssl/openssl#12259) - apps/openssl: clean-up of unused fallback code (PR openssl/openssl#12295) * Other: - Performed the transition from travis-ci.org to travis-ci.com. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Oct 31 15:26:37 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 31 Oct 2020 16:26:37 +0100 Subject: Late Monthly Status Report (July 2020) Message-ID: <87tuuato0i.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [closed in favor of #12512] WIP: OSSL_STORE for providers (PR openssl/openssl#9389) - Configure: Check source and build dir equality a little more thoroughly (PR openssl/openssl#12337) - util/perl/OpenSSL/config.pm: move misplaced Windows and VMS entries (PR openssl/openssl#12339) - Refactor ERR codes (PRs openssl/openssl#12314, openssl/openssl#12343) - Configure: fix handling of build.info attributes with value (PR openssl/openssl#12344) - Configuration and build: Fix solaris tags (PR openssl/openssl#12360) - CORE: perform post-condition in algorithm_do_this() under all circumstances (PR openssl/openssl#12365) - DOC: install documentation without execution permissions. (PR openssl/openssl#12373) - Makefile template: fix incorrect treatment of produced document files (PR openssl/openssl#12374) - BN: Check endianness in run-time, in BN_native2bn() and BN_bn2nativepad() (PR openssl/openssl#12390) - OSSL_DESERIALIZER: New API for provider based deserializers (PR openssl/openssl#12410) - util/find-doc-nits: read full declarations as one line in name_synopsis() (PR openssl/openssl#12452) - Fix typo for SSL_get_peer_certificate() (PR openssl/openssl#12468) - PROV: Move bio_prov.c from libcommon.a to libfips.a / libnonfips.a (PR openssl/openssl#12486) - PROV: Add a DER to RSA-PSS deserializer implementation (PR openssl/openssl#12492) - util/find-doc-nits: Relax check of function declarations in name_synopsis() (PR openssl/openssl#12494) * System Administration: - Performed operating system upgrade on our main machine * Other: - Performed the release of OpenSSL 3.0.0 alpha5 -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Oct 31 15:28:53 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 31 Oct 2020 16:28:53 +0100 Subject: Late Monthly Status Report (August 2020) Message-ID: <87sg9utnwq.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - OSSL_STORE for providers, take 2 (PR openssl/openssl#12512) - PROV: Make the DER to KEY deserializer decode parameters too (PR openssl/openssl#12569) - DESERIALIZER: Fix EVP_PKEY construction by export (PR openssl/openssl#12571) - Add MSBLOB and PVK deserializers (PR openssl/openssl#12574, openssl/openssl#12601) - RSA: Be less strict on PSS parameters when exporting to provider (PR openssl/openssl#12583) - EVP: Fix the returned value for ASN1_PKEY_CTRL_DEFAULT_MD_NID (PR openssl/openssl#12586) - EVP: Have evp_pkey_cmp_any() detect if export wasn't possible (PR openssl/openssl#12610) - Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODER / OSSL_DECODER (PR openssl/openssl#12659, openssl/openssl#12660) - X509: Add d2i_PUBKEY_ex(), which take a libctx and propq (PR openssl/openssl#12671) - TEST: separate out NIST ECC tests from non-NIST (PR openssl/openssl#12672) - PEM: Add more library context aware PEM readers (PR openssl/openssl#12673) - RSA: Fix rsa_todata() to only add params for existing data (PR openssl/openssl#12676) - PROV: Fix EC OSSL_FUNC_keymgmt_match() to work in the FIPS provider (PR openssl/openssl#12677) - PROV: Fix DSA and DH private key serializers (PR openssl/openssl#12679) - crypto/x509/v3_utl.c: Fix IPv6 output in ipaddr_to_asc() (PR openssl/openssl#12696) - TEST: Fix CMP tests so they load keys in the current library context (PR openssl/openssl#12705) - Fix PEM_write_bio_PrivateKey_traditional() to not output PKCS#8 (PR openssl/openssl#12728) - [1.1.1] Fix PEM_write_bio_PrivateKey_traditional() to not output PKCS#8 (PR openssl/openssl#12729) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Oct 31 15:29:44 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 31 Oct 2020 16:29:44 +0100 Subject: Late Monthly Status Report (September 2020) Message-ID: <87r1petnvb.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - [WIP] EVP: retrieve EVP_CIPHER constants in the evp_cipher_from_dispatch() (PR openssl/openssl#11980) - [not_yet_merged] [WIP] APPS: Refactoring dsaparam and dhparam (PR openssl/openssl#12072) - DOC: Modify one example in EVP_PKEY_fromdata(3) (PR openssl/openssl#12389) - CORE: Implement unconditional provider autoactivation (PR openssl/openssl#12497) - [reviewed] Add SM2 key management (PR openssl/openssl#12536 by InfoHunter) - OSSL_STORE: Move 'file:' scheme loader to provider (PR openssl/openssl#12587) - dev/release.sh: Rework to be smoother (PR openssl/openssl#12614) - Building: Build Unix static libraries a limited number of object files at a time (PR openssl/openssl#12706) - PEM: Make PEM_write_bio_PrivateKey_traditional() handle provider-native keys (PR openssl/openssl#12738) - EVP: Preserve the EVP_PKEY id in a few more spots (PR openssl/openssl#12785) - EVP: Add support for delayed EVP_PKEY operation parameters (PR openssl/openssl#12789) - TEST: skip POSIX errcode zero in test/recipes/02-test_errstr.t (PR openssl/openssl#12799) - [reviewed] NonStop port updates for 3.0.0. (PR openssl/openssl#12800 by rsbeckerca) - ENCODER: Refactor provider implementations, and some cleanup (PR openssl/openssl#12803) - Diverse build.info: Adjust paths (PR openssl/openssl#12816) - STORE: Fix OSSL_STORE_attach() to check |ui_method| before use (PR openssl/openssl#12831) - OSSL_DECODER 'decode' function must never be NULL. (PR openssl/openssl#12849) - EC: Reimplement EVP_PKEY_CTX_set_ec_param_enc() to support providers (PR openssl/openssl#12853) - EVP: Centralise fetching error reporting (PR openssl/openssl#12857) - ENCODER: Refactor the OSSL_ENCODER API to be more like OSSL_DECODER (PR openssl/openssl#12873) - OpenSSL::ParseC: recognise inline function bodies (PR openssl/openssl#12882) - util/mkerr.h: Restore header file rename (PR openssl/openssl#12910) - EVP: Enforce that EVP_PKEY_set_alias_type() only works with legacy keys (PR openssl/openssl#12920) - DOC: POD syntax fixes in doc/man1/openssl-cmp.pod.in (PR openssl/openssl#12924) - Streamline/Rationalize HPE NonStop Configuration (PR openssl/openssl#12933) - Configurations/unix-Makefile.tmpl: make cleanup kinder (PR openssl/openssl#12939) - Hide ECX_KEY again (PR openssl/openssl#12956) - Configuration: Make it possible to have an argument file (PR openssl/openssl#12960) - Build: Make NonStop shared libraries only export selected symbols (PR openssl/openssl#12962) - STORE: Clear a couple of TODOs that were there for the sake of SM2 (PR openssl/openssl#12986) - Configure: handle undefined shared_target. (PR openssl/openssl#13031) * Web: - [reviewed] Add a new section to the Coding Style about argument ordering (PR openssl/web#194 by mattcaswell) - [reviewed] Add a new section to the Coding Style about extending existing functions (PR openssl/web#195 by mattcaswell) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Oct 31 15:30:26 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 31 Oct 2020 16:30:26 +0100 Subject: Monthly Status Report (October 2020) Message-ID: <87pn4ytnu5.wl-levitte@openssl.org> Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, small fixes, etc., key activities this month: * Development: - Configuration: add initial NonStop values in OpenSSL::config (PR openssl/openssl#12973) - EVP: Take care of locks when downgrading an EVP_PKEY (PR openssl/openssl#12978) - [not_yet_merged] EVP: Adapt EVP_PKEY2PKCS8() to better handle provider-native keys (PR openssl/openssl#12995) - Make a build file target to install the FIPS module installation config file (PR openssl/openssl#13032) - EVP: use evp_pkey_ctx_is_legacy() to find what implementation to use (PR openssl/openssl#13043) - APPS: Reduce deprecation warning suppression - ENGINE (PR openssl/openssl#13044) - DECODER: Handle abstract object data type (PR openssl/openssl#13060) - DECODER: Allow precise result type for OSSL_DECODER_CTX_new_by_EVP_PKEY() (PR openssl/openssl#13061) - Refactor deprecation macros (PR openssl/openssl#13074) - Modify util/mknum.pl to drop new symbols that don't exist any more (PR openssl/openssl#13092) - Fix diverse ERR code conflicts (PR openssl/openssl#13093) - ENCODER / DECODER: Add functions to encode/decode to/from a buffer (PR openssl/openssl#13094) - [not_yet_merged] Add new provider encoders implementations for more output standards (PR openssl/openssl#13095, openssl/openssl#13167) - [not_yet_merged] Deprecate RSA harder (PR openssl/openssl#13096) - DH: stop setting the private key length arbitrarily (PR openssl/openssl#13140) - TEST: fix small logic error in test/evp_pkey_provided_test.c (PR openssl/openssl#13146) - TEST: modify tconversion.pl for forensics (PR openssl/openssl#13147) - ENCODER & DECODER: set params on all encoder/decoder instances, unconditionally (PR openssl/openssl#13156) - dev/release.sh: improve instruction for pushing the tag (PR openssl/openssl#13159) - DH: make the private key length importable / exportable (PR openssl/openssl#13166) - Add easy to digest selector macros for EVP_PKEYs (PR openssl/openssl#13189) - Work around Windows ftell() bug as per Microsoft engineering's suggestion (PR openssl/openssl#13190) - APPS: Implement load_keyparams() to load key parameters (PR openssl/openssl#13191) - Unexport internal MSBLOB and PVK functions (PR openssl/openssl#13196) - configdata.pm.in: Make a HERE document stricter. (PR openssl/openssl#13225) - APPS: Remove the format argument where it's not used (PR openssl/openssl#13236) - [not_yet_merged] util/fix-deprecation: DEPRECATEDIN conversion util for public headers (PR openssl/openssl#13239) - [not_yet_merged] Simplify and clarify doc/internal/man7/deprecation.pod (PR openssl/openssl#13240) - [not_yet_merged] Add new provider decoders implementations for more input standards (PR openssl/openssl#13248) - [not_yet_merged] test/endecoder_legacy_test.c: new test for legacy comparison (PR openssl/openssl#13262) - test/recipes/15-test_gendh.t: don't try DER params (PR openssl/openssl#13266) - [not_yet_merged] test/recipes/90-test_shlibload.t: Skip when address sanitizer enabled (PR openssl/openssl#13281) - [not_yet_published] Adapt OpenSSL 3.0 for VMS -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/