From pauli at openssl.org Sun Aug 1 23:58:21 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Mon, 2 Aug 2021 09:58:21 +1000 Subject: Monthly Status: July Message-ID: Significant activities throughout June were: * Added a -fips command line option to util/wrap.pl * Wrote provider side PBKDF1 documentation that was missed earlier. * Document config_diagnostics option more widely. * Added other documentation that was missed. * Add config_diagnostics option to all of our configuration files (pending). * Moved the PVK KDF to providers for post 3.0. * Fix a problem with BN_div getting the remainder's sign incorrect in some circumstances. * Addressed the last old Coverity issue -- Coverity is now clean. * Update auto DH so that it honours the security level rather than picking something inappropriate and erroring. * Remove ERR_GET_FUNC() from the codebase. * Investigation Solaris failure. * Fix Windows makefile * Streamline the apps so they know more about the command line options given and don't search for algorithms inappropriately. Use libctx and propq more pervasively when specified and don't fall back to legacy if provider options have been specified. * Reallow short IVs for AES and ARIA GCM modes. * Fix a no-posix-io build problem. * Add demo code for PBKDF2, SCRYPT and GMAC. * Investigation into non-caching build running the test machine out of memory. * Add cross compiles to our CI loops including execution via QEMU where reasonable. * Investigation of possible problem in wrap cipher mode and multiple calls to update. * Modified CTR DRBG to allow operation without a derivation function in FIPS mode * Investigate TLS 1.3 FIPS self test requirements. * Investigated, compiled and run lab's test suite. * Review vendor evidence document. In addition were minor pull requests, reviewing, OMC and OTC business, et al. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Mon Aug 2 16:11:43 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 02 Aug 2021 18:11:43 +0200 Subject: Monthly Status Report (July 2021) Message-ID: My key activities this month were: - triage of newly reported issues and responding to questions - re-triage of issues/PRs without triaged labels with closing obsolete issues - participation on the meetings - studied the OpenSSL sysadmin documentation - started studying the Buildbot documentation - reviews of various PRs: ? - I've reviewed about 50 PRs this month ? - Notable PRs reviewed: - PROV & STORE: Don't decode keys in the 'file:' store loader #15981 - Avoid calling EVP_get_XXXbyname when legacy isn't relevant #16022 - ASN.1: Refuse to encode to DER if non-optional items are missing [3.0] #16036 - EVP: Add EVP_PKEY_get0_provider() and EVP_PKEY_CTX_get0_provider() #16063 - Fix custom EVP_PKEY_METHODs #16118 - submitted 15 PRs: ? - In particular: - fips module header inclusion fine-tunning #15974 - Split bignum code out of the sparcv9cap.c #16019 - Allow RSA signature operations with RSA_NO_PADDING #16068 - Signature algos: allow having identical digest in params #16076 - Fix potential problems with EVP_PKEY_CTX_new() with engine set #16137 I had also 1 full week time off. -- 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 pauli at openssl.org Tue Aug 3 09:02:50 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 3 Aug 2021 19:02:50 +1000 Subject: OTC vote on accepting #16171: config_diagnostic Message-ID: <5b2b6736-3c12-b224-3f24-fb6c200e4960@openssl.org> Accept PR 16171 in 3.0 subject to our normal review process. Pauli -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Tue Aug 3 09:03:00 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 3 Aug 2021 19:03:00 +1000 Subject: OTC vote on accepting #16203: TLS 1.3 KDF Message-ID: <0c43723d-2c05-ba70-5f3b-ad185cb1edd6@openssl.org> Accept PR 16203 in 3.0 subject to our normal review process. This one is still undergoing early review. Pauli -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Tue Aug 3 19:26:27 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 3 Aug 2021 19:26:27 +0000 Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] Message-ID: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> > I'm starting to vote -1 on anything has a vote text that looks like that, so -1. I perfectly understand Kurt's dislike of this kind of votes. The text is not very informative for OTC members who weren't able to participate at the weekly video meetings. IMHO it proves that the current voting mechanism does not scale well with the number of decisions that have to be made. The rate of those decision has increased heavily during the final phase of the 3.0 development and the weekly video meetings were an attempt to improve agility and get those decisions made. On the other side, the voting scheme has remained unchanged, mailing '+-1' replies to the mailing list within a certain time interval and recording them arduously in a GitHub repository. Maybe we need to overthink the online voting rules and optimize them slightly. For example, we could require an online quota in which case the online votes can be held immediately, but they would need to be documented properly with a meaningful subject line and ideally also a rationale. We could switch to publishing meeting protocols which document all online votes properly, including the rationale. Maybe those online votes could be excluded from the official participation count mentioned in the bylaws as indicator for OTC activity. These are just some wild thoughts for the moment. I doubt we will have time to discuss it in detail before the final 3.0 release. But maybe it would be a good subject for the next OTC face-to-face meeting. Matthias > -----Original Message----- > From: otc On Behalf Of Kurt Roeckx > Sent: Tuesday, August 3, 2021 6:36 PM > To: Dr Paul Dale > Cc: otc at openssl.org > Subject: Re: OTC vote PR #16171: config_diagnostic > > On Tue, Aug 03, 2021 at 07:03:14PM +1000, Dr Paul Dale wrote: > > topic: Accept PR 16171 in 3.0 subject to our normal review process. > > I'm starting to vote -1 on anything has a vote text that looks > like that, so -1. > > This is also send to the wrong list. > > > Kurt > > _______________________________________________ > otc mailing list > otc at openssl.org > https://mta.openssl.org/mailman/listinfo/otc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Tue Aug 3 19:31:27 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 3 Aug 2021 19:31:27 +0000 Subject: OTC vote on accepting #16171: config_diagnostic In-Reply-To: <5b2b6736-3c12-b224-3f24-fb6c200e4960@openssl.org> References: <5b2b6736-3c12-b224-3f24-fb6c200e4960@openssl.org> Message-ID: 0 From: openssl-project On Behalf Of Dr Paul Dale Sent: Tuesday, August 3, 2021 11:03 AM To: openssl-project at openssl.org Subject: OTC vote on accepting #16171: config_diagnostic Accept PR 16171 in 3.0 subject to our normal review process. Pauli -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Tue Aug 3 19:31:40 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 3 Aug 2021 19:31:40 +0000 Subject: OTC vote on accepting #16203: TLS 1.3 KDF In-Reply-To: <0c43723d-2c05-ba70-5f3b-ad185cb1edd6@openssl.org> References: <0c43723d-2c05-ba70-5f3b-ad185cb1edd6@openssl.org> Message-ID: <53bb3bd361de4cccb04b138af464f862@ncp-e.com> 0 From: openssl-project On Behalf Of Dr Paul Dale Sent: Tuesday, August 3, 2021 11:03 AM To: openssl-project at openssl.org Subject: OTC vote on accepting #16203: TLS 1.3 KDF Accept PR 16203 in 3.0 subject to our normal review process. This one is still undergoing early review. Pauli -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Tue Aug 3 19:58:55 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 3 Aug 2021 19:58:55 +0000 Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] In-Reply-To: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> References: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> Message-ID: You probably all noticed my mistake: I meant to say 'quorum', not 'quota'. Matthias > -----Original Message----- > From: openssl-project On Behalf Of Dr. Matthias St. Pierre > Sent: Tuesday, August 3, 2021 9:26 PM > To: Kurt Roeckx ; Dr Paul Dale > Cc: openssl-project at openssl.org > Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] > > > I'm starting to vote -1 on anything has a vote text that looks like that, so -1. > > I perfectly understand Kurt's dislike of this kind of votes. The text is not very informative for OTC members who > weren't able to participate at the weekly video meetings. > > IMHO it proves that the current voting mechanism does not scale well with the number of decisions that have to be made. > The rate of those decision has increased heavily during the final phase of the 3.0 development and the weekly video meetings > were an attempt to improve agility and get those decisions made. On the other side, the voting scheme has remained unchanged, > mailing '+-1' replies to the mailing list within a certain time interval and recording them arduously in a GitHub repository. > > Maybe we need to overthink the online voting rules and optimize them slightly. For example, we could require an online > quota in which case the online votes can be held immediately, but they would need to be documented properly with > a meaningful subject line and ideally also a rationale. We could switch to publishing meeting protocols which document all > online votes properly, including the rationale. Maybe those online votes could be excluded from the official participation count > mentioned in the bylaws as indicator for OTC activity. > > These are just some wild thoughts for the moment. I doubt we will have time to discuss it in detail before the final 3.0 release. > But maybe it would be a good subject for the next OTC face-to-face meeting. > > Matthias > > > > -----Original Message----- > > From: otc On Behalf Of Kurt Roeckx > > Sent: Tuesday, August 3, 2021 6:36 PM > > To: Dr Paul Dale > > Cc: otc at openssl.org > > Subject: Re: OTC vote PR #16171: config_diagnostic > > > > On Tue, Aug 03, 2021 at 07:03:14PM +1000, Dr Paul Dale wrote: > > > topic: Accept PR 16171 in 3.0 subject to our normal review process. > > > > I'm starting to vote -1 on anything has a vote text that looks > > like that, so -1. > > > > This is also send to the wrong list. > > > > > > Kurt > > > > _______________________________________________ > > otc mailing list > > otc at openssl.org > > https://mta.openssl.org/mailman/listinfo/otc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From tjh at cryptsoft.com Tue Aug 3 21:21:57 2021 From: tjh at cryptsoft.com (Tim Hudson) Date: Wed, 4 Aug 2021 07:21:57 +1000 Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] In-Reply-To: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> References: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> Message-ID: On Wed, Aug 4, 2021 at 5:26 AM Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > > I'm starting to vote -1 on anything has a vote text that looks like > that, so -1. > > I perfectly understand Kurt's dislike of this kind of votes. The text is > not very informative for OTC members who > weren't able to participate at the weekly video meetings. > This isn't about the OTC meeting itself - this is about the details of the topic actually being captured within the PR. You need to actually look at the PR to form a view. And we do add to the PRs during the discussion if things come up and we review the PR details. So the vote isn't about an OTC discussion - the vote is precisely about the PR itself. One of the things we have explicitly discussed on multiple calls is that in order to be informed of the details, you need to consult the PR which has a record of the discussion and often viewpoints that offer rather different positions on a topic - and those viewpoints are what should be being considered. If you wanted to form a view on the basis of vote text without a reference to the PR, then you would require replication of the issue, the PR code changes, and the PR comment discussion. Such an approach would be a complete waste of time and resources. We want the discussion in terms of an issue to be in the PR itself. Often during OTC meetings additional comments (separate from the consensus viewpoint) are added capturing an relevant point from the OTC discussions (which can be quite free flowing). The email based voting mechanism is a separate topic and one I've expressed views on multiple times - as I do think we should have an online mechanism for voting and tallying and communicating about votes - but that isn't this specific issue Kurt is raising here. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Aug 3 22:07:06 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 4 Aug 2021 00:07:06 +0200 Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] In-Reply-To: References: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> Message-ID: On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote: > > This isn't about the OTC meeting itself - this is about the details of the > topic actually being captured within the PR. > You need to actually look at the PR to form a view. And we do add to the > PRs during the discussion if things come up and we review the PR details. > So the vote isn't about an OTC discussion - the vote is precisely about the > PR itself. > > One of the things we have explicitly discussed on multiple calls is that in > order to be informed of the details, you need to consult the PR which has a > record of the discussion and often viewpoints that offer rather different > positions on a topic - and those viewpoints are what should be being > considered. I am happy to read the issue/PR to see the different view points. But different viewpoints is exactly the problem, which of those am I voting for? During a meeting, there probably was a consensus about what you're actually voting for, but that information is lost. In general, I want a vote to be about what is going to change, the how isn't important most of the time. Kurt From pauli at openssl.org Tue Aug 3 22:12:15 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 4 Aug 2021 08:12:15 +1000 Subject: OTC vote on accepting #16171: config_diagnostic In-Reply-To: <5b2b6736-3c12-b224-3f24-fb6c200e4960@openssl.org> References: <5b2b6736-3c12-b224-3f24-fb6c200e4960@openssl.org> Message-ID: This vote has now passed: topic: Accept PR 16171 in 3.0 subject to our normal review process. Proposed by Pauli. Public: yes opened: 2021-08-03 closed: 2021-08-04 accepted:? yes? (for: 6, against: 1, abstained:1, not voted: 2) ONE WEEK VOTE ? Dmitry???? [+1] ? Matt?????? [? ] ? Pauli????? [+1] ? Tim??????? [+1] ? Richard??? [? ] ? Shane????? [+1] ? Tomas????? [+1] ? Kurt?????? [-1] ? Matthias?? [ 0] ? Nicola???? [+1] Pauli On 3/8/21 7:02 pm, Dr Paul Dale wrote: > Accept PR 16171 in 3.0 > subject to our normal review process. > > Pauli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Tue Aug 3 22:25:59 2021 From: tjh at cryptsoft.com (Tim Hudson) Date: Wed, 4 Aug 2021 08:25:59 +1000 Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] In-Reply-To: References: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> Message-ID: The votes on the PR are precisely that - to vote to proceed with the PR via the normal review process - and that means looking at the varying viewpoints. If we reached a consensus that overall we didn't think the PR made sense then we wouldn't form a vote of that form. What you are voting for is that what the PR holds is what makes sense to proceed with - subject to the normal review process - i.e. this isn't a push-the-PR-in-right-now vote - it is a "proceed" vote. A PR has a discussion in the PR comments, and generally an associated issue, and always (as it is a PR) the suggested code change. That is what is being voted on - to proceed with the PR - via the normal review process. As otherwise the PR remains blocked on an OTC decision - and the OTC decision is to not continue to block the PR (blocked on an OTC decision). Repeating again - the PR itself is what is being voted about - not a set of different unstated viewpoints - it is what is in the PR - fix this problem - and generally there is nothing critical seen in the code approach - but our normal review processes still apply to handle it. Which means the PR simply needs the two approvals. The majority of the time in the OTC discussions we are actually looking at the PR details in terms of the code changes - we aren't reviewing it as such (although that does sometimes happen on the call) - we are looking at the PR code changes providing the additional detail to help in the decision making. There are very few PRs which describe what is going to change in a useful form independent of the code changes - they don't usually state things like what is going to be changed - they are focused on what is wrong and the PR is going to fix it - there isn't usually anything meaningful about what is going to be changed in order to fix what is wrong. A PR doesn't hold a range of code fixes to choose between - it holds a discussion (comments) and a specific code fix - and perhaps that specific code fix is the result of a sequence of code fixes that have evolved through the discussion. So the precise viewpoint you are voting for in those PRs is to proceed to include that PR in the work for the current release while continuing to use our normal review and approval processes - that is the vote text - and it makes the intent of the vote. Where there is a view that we should not take a particular approach represented in a PR and should take an alternate approach then we don't form a vote that way - we actually allocate someone to produce an alternate PR. Often we leave the initial PR and alternate PR open until such time as we can compare the approaches in concrete form and then we can make a decision - but that would be accepting one PR over another PR. We have had "competing" PRs regularly - and we then vote on the alternatives - where it is clear what the alternatives are. A single PR vote is about that PR. Tim. On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx wrote: > On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote: > > > > This isn't about the OTC meeting itself - this is about the details of > the > > topic actually being captured within the PR. > > You need to actually look at the PR to form a view. And we do add to the > > PRs during the discussion if things come up and we review the PR details. > > So the vote isn't about an OTC discussion - the vote is precisely about > the > > PR itself. > > > > One of the things we have explicitly discussed on multiple calls is that > in > > order to be informed of the details, you need to consult the PR which > has a > > record of the discussion and often viewpoints that offer rather different > > positions on a topic - and those viewpoints are what should be being > > considered. > > I am happy to read the issue/PR to see the different view points. > But different viewpoints is exactly the problem, which of those am > I voting for? > > During a meeting, there probably was a consensus about what you're > actually voting for, but that information is lost. > > In general, I want a vote to be about what is going to change, the > how isn't important most of the time. > > > Kurt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Aug 4 23:37:14 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 5 Aug 2021 00:37:14 +0100 Subject: OTC vote on accepting #16203: TLS 1.3 KDF In-Reply-To: <0c43723d-2c05-ba70-5f3b-ad185cb1edd6@openssl.org> References: <0c43723d-2c05-ba70-5f3b-ad185cb1edd6@openssl.org> Message-ID: <3ae70c43-4f01-8c08-e0ba-b68382a5844d@openssl.org> +1 On 03/08/2021 10:03, Dr Paul Dale wrote: > Accept PR 16203 in 3.0 > subject to our normal review process. > > This one is still undergoing early review. > > > Pauli > From pauli at openssl.org Wed Aug 4 23:51:42 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Thu, 5 Aug 2021 09:51:42 +1000 Subject: OTC vote on accepting #16203: TLS 1.3 KDF In-Reply-To: <0c43723d-2c05-ba70-5f3b-ad185cb1edd6@openssl.org> References: <0c43723d-2c05-ba70-5f3b-ad185cb1edd6@openssl.org> Message-ID: <301c536c-5685-0e0a-fba6-f95b4aca0b2f@openssl.org> This vote has now passed: topic: Accept PR 16203 in 3.0 subject to our normal review process. Proposed by Pauli. Public: yes opened: 2021-08-03 closed: 2021-08-05 accepted:? yes? (for: 4, against: 1, abstained: 4, not voted: 1) ONE WEEK VOTE ? Dmitry???? [+1] ? Matt?????? [+1] ? Pauli????? [+1] ? Tim??????? [ 0] ? Richard??? [? ] ? Shane????? [ 0] ? Tomas????? [+1] ? Kurt?????? [-1] ? Matthias?? [ 0] ? Nicola???? [+0] Pauli On 3/8/21 7:03 pm, Dr Paul Dale wrote: > Accept PR 16203 in 3.0 > subject to our normal review process. > > This one is still undergoing early review. > > > Pauli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 10 10:45:58 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Aug 2021 11:45:58 +0100 Subject: 3.0 final release status Message-ID: <8b10ffe3-079b-8806-cf80-0e20efeb6e35@openssl.org> OTC have met today to review outstanding 3.0 related issues. The final 3.0 release will not be this week. OTC will review again next week. Matt From matt at openssl.org Tue Aug 10 10:53:23 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Aug 2021 11:53:23 +0100 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 Message-ID: topic: Revert the commits merged from PR #16027 in 1.1.1 Comment: Refer to issue #16266 for background Proposed by Tomas Mraz Public: yes opened: 2021-08-10 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Dmitry [+1] Matt [+1] Pauli [ ] Tim [-1] Richard [ ] Shane [-1] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [-1] From matt at openssl.org Tue Aug 10 10:54:19 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Aug 2021 11:54:19 +0100 Subject: OTC VOTE: RSA public exponent validation in 3.0 Message-ID: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> topic: RSA public exponent validation in 3.0 for the default provider should be consistent with 1.1.1 Comment: See issue #16255 for background Proposed by Matt Caswell Public: yes opened: 2021-08-10 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Dmitry [ 0] Matt [+1] Pauli [ ] Tim [+1] Richard [ ] Shane [+1] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [-0] From matt at openssl.org Tue Aug 10 11:00:33 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Aug 2021 12:00:33 +0100 Subject: OTC vote on accepting #16171: config_diagnostic In-Reply-To: <5b2b6736-3c12-b224-3f24-fb6c200e4960@openssl.org> References: <5b2b6736-3c12-b224-3f24-fb6c200e4960@openssl.org> Message-ID: <1a81a901-ef66-5fa0-1399-e07248282a02@openssl.org> For the record: +1 Matt On 03/08/2021 10:02, Dr Paul Dale wrote: > Accept PR 16171 in 3.0 > subject to our normal review process. > > Pauli > From Matthias.St.Pierre at ncp-e.com Tue Aug 10 15:47:42 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 10 Aug 2021 15:47:42 +0000 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: Message-ID: <1472fda04b1242499bea5822f84a30de@ncp-e.com> +1 > -----Original Message----- > From: openssl-project On Behalf Of Matt Caswell > Sent: Tuesday, August 10, 2021 12:53 PM > To: openssl-project at openssl.org > Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 > > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [+1] > Matt [+1] > Pauli [ ] > Tim [-1] > Richard [ ] > Shane [-1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Tue Aug 10 15:47:56 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 10 Aug 2021 15:47:56 +0000 Subject: OTC VOTE: RSA public exponent validation in 3.0 In-Reply-To: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> References: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> Message-ID: <4f9afc906ad240c1bc6398ada4708bf0@ncp-e.com> -1 > -----Original Message----- > From: openssl-project On Behalf Of Matt Caswell > Sent: Tuesday, August 10, 2021 12:54 PM > To: openssl-project at openssl.org > Subject: OTC VOTE: RSA public exponent validation in 3.0 > > topic: RSA public exponent validation in 3.0 for the default provider > should be > consistent with 1.1.1 > Comment: See issue #16255 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [ 0] > Matt [+1] > Pauli [ ] > Tim [+1] > Richard [ ] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-0] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From pauli at openssl.org Wed Aug 11 03:09:16 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 11 Aug 2021 13:09:16 +1000 Subject: OTC VOTE: RSA public exponent validation in 3.0 In-Reply-To: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> References: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> Message-ID: <8f782845-420a-5be2-3fc4-283901602da7@openssl.org> 0 Pauli On 10/8/21 8:54 pm, Matt Caswell wrote: > topic: RSA public exponent validation in 3.0 for the default provider > should be > consistent with 1.1.1 > Comment: See issue #16255 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ? Dmitry???? [ 0] > ? Matt?????? [+1] > ? Pauli????? [? ] > ? Tim??????? [+1] > ? Richard??? [? ] > ? Shane????? [+1] > ? Tomas????? [+1] > ? Kurt?????? [? ] > ? Matthias?? [? ] > ? Nicola???? [-0] > From pauli at openssl.org Wed Aug 11 03:18:34 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 11 Aug 2021 13:18:34 +1000 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: Message-ID: <9880dae1-cef7-598e-bd92-06474ee6e30d@openssl.org> +0 Pauli On 10/8/21 8:53 pm, Matt Caswell wrote: > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ? Dmitry???? [+1] > ? Matt?????? [+1] > ? Pauli????? [? ] > ? Tim??????? [-1] > ? Richard??? [? ] > ? Shane????? [-1] > ? Tomas????? [+1] > ? Kurt?????? [? ] > ? Matthias?? [? ] > ? Nicola???? [-1] > From kurt at roeckx.be Wed Aug 11 06:32:34 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 11 Aug 2021 08:32:34 +0200 Subject: OTC VOTE: RSA public exponent validation in 3.0 In-Reply-To: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> References: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> Message-ID: On Tue, Aug 10, 2021 at 11:54:19AM +0100, Matt Caswell wrote: > topic: RSA public exponent validation in 3.0 for the default provider should > be > consistent with 1.1.1 I think this is one of those conflicts between providing a general crypto library, and providing something that is secure by default. As far as I know, at least NIST recommends it to be bigger, and it's been adopted CA/Browser forum as requirement too. The vote is also about the default provider, I assume that the FIPS provider will enforce this both at creation and use time. I think that we should follow the recommendations, and at least enforce this by default for the creation of new keys. But it's not clear if this vote is just about creation, or also about using such a key. So I'm voting -1. Kurt From matt at openssl.org Wed Aug 11 07:36:18 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Aug 2021 08:36:18 +0100 Subject: OTC VOTE: RSA public exponent validation in 3.0 In-Reply-To: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> References: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> Message-ID: This vote is now closed. accepted: yes (for: 4, against: 2, abstained: 3, not voted: 1) On 10/08/2021 11:54, Matt Caswell wrote: > topic: RSA public exponent validation in 3.0 for the default provider > should be > consistent with 1.1.1 > Comment: See issue #16255 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ? Dmitry???? [ 0] > ? Matt?????? [+1] > ? Pauli????? [? ] > ? Tim??????? [+1] > ? Richard??? [? ] > ? Shane????? [+1] > ? Tomas????? [+1] > ? Kurt?????? [? ] > ? Matthias?? [? ] > ? Nicola???? [-0] From tomas at openssl.org Wed Aug 11 07:59:59 2021 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 11 Aug 2021 09:59:59 +0200 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: Message-ID: <28afcf4093624f8559a4a58a36083e122e0455a1.camel@openssl.org> As this vote is still ongoing I am going to somewhat promote its case. I really suspect that many applications albeit somewhat special ones will be broken by this change. So although the change can be surely viewed as a bug fix it is IMO wrong that it was merged to the 1.1.1 branch. Although there might be security implications of exporting an incomplete/broken DER encoding, no concrete security issue was presented that exists unless this bug is fixed. On Tue, 2021-08-10 at 11:53 +0100, Matt Caswell wrote: > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ?? Dmitry???? [+1] > ?? Matt?????? [+1] > ?? Pauli????? [? ] > ?? Tim??????? [-1] > ?? Richard??? [? ] > ?? Shane????? [-1] > ?? Tomas????? [+1] > ?? 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 matt at openssl.org Wed Aug 11 11:11:49 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Aug 2021 12:11:49 +0100 Subject: Monthly Status Report (July) Message-ID: <040e13a1-e863-c735-4046-b092e7cc77d1@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, support customer issues, CLA submissions, handling security reports, etc., key activities this month: - Continued to work on mingw test failures. Isolated a strange problem relating to our use of the gmtime/mktime functions - Fixed a regression in the pkcs12 app where we were adding the first certificate multiple times - Fixed a bug in s_server PSK handling - Fixed 2 SSL_key_update() problems (master and 1.1.1) - Fixed some minor record layer issues - Fixed some signed/unsigned comparison warnings in sslapitest - Fixed custom EVP_PKEY_METHODs where no engine is present - Reviewed FIPS lab documents - Fixed EVP_MD_meth_dup and EVP_CIPHER_meth_dup - Fixed 3 separate FIPS related config issues - Performed the 3.0 beta 2 release - Updated fingerprints.txt to add Paul Matt From kurt at roeckx.be Wed Aug 11 18:37:47 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 11 Aug 2021 20:37:47 +0200 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: Message-ID: On Tue, Aug 10, 2021 at 11:53:23AM +0100, Matt Caswell wrote: > topic: Revert the commits merged from PR #16027 in 1.1.1 +1 Kurt From nic.tuv at gmail.com Wed Aug 11 18:53:14 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 11 Aug 2021 21:53:14 +0300 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: <28afcf4093624f8559a4a58a36083e122e0455a1.camel@openssl.org> References: <28afcf4093624f8559a4a58a36083e122e0455a1.camel@openssl.org> Message-ID: On the other hand, 1.1.1 is not in its last year of support so it is not limited to security fixes only. The commits which this vote proposes to revert fixed a bug that produced invalid output from functions with a clear intent. This might have security repercussions, as the user might end up signing something which is unexpectedly invalid. But even without concrete security vulnerabilities on record, if we classify invalid output as a bug this should be fixed in 1.1.1. There are applications that might be broken, because they relied on the buggy behavior for producing invalid output as intermediate data, but, as mentioned in #16266, there are ways of producing the required non-x509 data without abusing functions meant to produce valid x509. It is unfortunate for existing applications to break upon a patch release, but given that patch releases for 1.1.1 are meant to fix security defects and bugs, this is inevitable for any application relying on buggy behavior (especially as in the case that triggered this discussion, which configures a clear abuse of the API, while alternative non-abusive ways of achieving the intended result exist). Nicola On Wed, Aug 11, 2021, 11:00 Tomas Mraz wrote: > As this vote is still ongoing I am going to somewhat promote its case. > I really suspect that many applications albeit somewhat special ones > will be broken by this change. So although the change can be surely > viewed as a bug fix it is IMO wrong that it was merged to the 1.1.1 > branch. > > Although there might be security implications of exporting an > incomplete/broken DER encoding, no concrete security issue was > presented that exists unless this bug is fixed. > > On Tue, 2021-08-10 at 11:53 +0100, Matt Caswell wrote: > > topic: Revert the commits merged from PR #16027 in 1.1.1 > > Comment: Refer to issue #16266 for background > > Proposed by Tomas Mraz > > Public: yes > > opened: 2021-08-10 > > closed: 2021-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Dmitry [+1] > > Matt [+1] > > Pauli [ ] > > Tim [-1] > > Richard [ ] > > Shane [-1] > > Tomas [+1] > > 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.] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Aug 11 19:20:42 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 11 Aug 2021 21:20:42 +0200 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: <28afcf4093624f8559a4a58a36083e122e0455a1.camel@openssl.org> Message-ID: On Wed, Aug 11, 2021 at 09:53:14PM +0300, Nicola Tuveri wrote: > On the other hand, 1.1.1 is not in its last year of support so it is not > limited to security fixes only. > > The commits which this vote proposes to revert fixed a bug that produced > invalid output from functions with a clear intent. > This might have security repercussions, as the user might end up signing > something which is unexpectedly invalid. > But even without concrete security vulnerabilities on record, if we > classify invalid output as a bug this should be fixed in 1.1.1. > > There are applications that might be broken, because they relied on the > buggy behavior for producing invalid output as intermediate data, but, as > mentioned in #16266, there are ways of producing the required non-x509 data > without abusing functions meant to produce valid x509. > > It is unfortunate for existing applications to break upon a patch release, > but given that patch releases for 1.1.1 are meant to fix security defects > and bugs, this is inevitable for any application relying on buggy behavior > (especially as in the case that triggered this discussion, which configures > a clear abuse of the API, while alternative non-abusive ways of achieving > the intended result exist). There are a lot of things we accept in a certificate we shouldn't. And I would like to fix all of them. But fixing them in stable branches is going to cause people problems and prevent them from upgrading to a newer version and getting other security fixes. I prefer to only do breaking changes in a minor version. Kurt From matt at openssl.org Thu Aug 12 09:20:00 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Aug 2021 10:20:00 +0100 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: <28afcf4093624f8559a4a58a36083e122e0455a1.camel@openssl.org> Message-ID: <5966d25a-3aa7-784f-be00-c84c3d05ef94@openssl.org> On 11/08/2021 20:20, Kurt Roeckx wrote: > But fixing them in stable > branches is going to cause people problems and prevent them from > upgrading to a newer version and getting other security fixes. This is actually an important point. We *want* people to upgrade to the latest patch release of a stable branch to ensure they get the latest security fixes. If we introduce "fixes" that actually break people's applications then their response will be to *not* upgrade at all. Therefore, even though such a breaking fix might have been introduced with the best of intentions (to fix a possible (unspecified) security risk), it might actually have the opposite effect and make our users *more* vulnerable to security risks. Matt From tomas at openssl.org Fri Aug 13 10:56:07 2021 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 13 Aug 2021 12:56:07 +0200 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: Message-ID: <4877b61f1e8daf0aa92d8e0a903a8cbb9a351207.camel@openssl.org> This vote is now closed: closed: 2021-08-13 accepted: yes (for: 5, against: 3, abstained: 1, not voted: 1) Tomas On Tue, 2021-08-10 at 11:53 +0100, Matt Caswell wrote: > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ?? Dmitry???? [+1] > ?? Matt?????? [+1] > ?? Pauli????? [? ] > ?? Tim??????? [-1] > ?? Richard??? [? ] > ?? Shane????? [-1] > ?? Tomas????? [+1] > ?? 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 levitte at openssl.org Sun Aug 15 17:29:25 2021 From: levitte at openssl.org (Richard Levitte) Date: Sun, 15 Aug 2021 19:29:25 +0200 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: <28afcf4093624f8559a4a58a36083e122e0455a1.camel@openssl.org> Message-ID: <87im06sjka.wl-levitte@openssl.org> On Wed, 11 Aug 2021 21:20:42 +0200, Kurt Roeckx wrote: > > There are a lot of things we accept in a certificate we shouldn't. PR #16027 isn't about what our code accepts, but about what it *produces*. At the very least, I see an interop problem, because when certain necessary structure values are missing, the DER (and PEM) encoding will be invalid for the declared content type. Just take the program from issue openssl/openssl#16026, but change the i2d_RSAPrivateKey() call to a PEM_write_RSAPrivateKey() call. This is a run again OpenSSL 1.1.1k (which is the version before this patch): : ; ./foo -----BEGIN RSA PRIVATE KEY----- MA0CAQACAwHiQAIDAQAB -----END RSA PRIVATE KEY----- Failed 'PEM_write_RSAPrivateKey(stdout, rsa, NULL, NULL, 0, NULL, NULL) <= 0' : levitte at lapdog:~/gitwrk/openssl.net/official/1.1.1 : ; ./foo | openssl asn1parse -i Failed 'PEM_write_RSAPrivateKey(stdout, rsa, NULL, NULL, 0, NULL, NULL) <= 0' 0:d=0 hl=2 l= 13 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 3 prim: INTEGER :01E240 10:d=1 hl=2 l= 3 prim: INTEGER :010001 That's a badly formatted RSAPrivateKey (it looks like a RSAPublicKey). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sun Aug 15 17:29:57 2021 From: levitte at openssl.org (Richard Levitte) Date: Sun, 15 Aug 2021 19:29:57 +0200 Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1 In-Reply-To: References: Message-ID: <87h7fqsjje.wl-levitte@openssl.org> -1 On Tue, 10 Aug 2021 12:53:23 +0200, Matt Caswell wrote: > > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [+1] > Matt [+1] > Pauli [ ] > Tim [-1] > Richard [ ] > Shane [-1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sun Aug 15 17:34:00 2021 From: levitte at openssl.org (Richard Levitte) Date: Sun, 15 Aug 2021 19:34:00 +0200 Subject: OTC VOTE: RSA public exponent validation in 3.0 In-Reply-To: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> References: <0cd90c6b-3ff9-101e-5870-d1e7bb9962f5@openssl.org> Message-ID: <87fsvasjcn.wl-levitte@openssl.org> 0 On Tue, 10 Aug 2021 12:54:19 +0200, Matt Caswell wrote: > > topic: RSA public exponent validation in 3.0 for the default provider > should be > consistent with 1.1.1 > Comment: See issue #16255 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [ 0] > Matt [+1] > Pauli [ ] > Tim [+1] > Richard [ ] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-0] > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Aug 17 13:19:08 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Aug 2021 14:19:08 +0100 Subject: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process Message-ID: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> topic: Accept PR#16286 into 3.0 subject to the normal review process Proposed by Shane Lontis Public: yes opened: 2021-08-17 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Dmitry [ ] Matt [-1] Pauli [+1] Tim [ 0] Richard [+1] Shane [+1] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [+1] From beldmit at gmail.com Tue Aug 17 13:20:54 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 17 Aug 2021 15:20:54 +0200 Subject: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process In-Reply-To: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> References: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> Message-ID: +1 On Tue, Aug 17, 2021 at 3:19 PM Matt Caswell wrote: > topic: Accept PR#16286 into 3.0 subject to the normal review process > Proposed by Shane Lontis > Public: yes > opened: 2021-08-17 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [ ] > Matt [-1] > Pauli [+1] > Tim [ 0] > Richard [+1] > Shane [+1] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 17 15:31:21 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Aug 2021 16:31:21 +0100 Subject: Forthcoming OpenSSL release Message-ID: <16741599-8f3a-555b-582c-1b68b3571bd7@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1l. This release will be made available on Tuesday 24th August 2021 between 1200-1600 UTC. OpenSSL 1.1.1l is a security-fix release. The highest severity issue fixed in this release is HIGH: https://www.openssl.org/policies/secpolicy.html#high Note that due to this also affecting OpenSSL 3.0 beta releases, OpenSSL 3.0 final will not be occurring this week. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From pauli at openssl.org Tue Aug 17 22:37:31 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 18 Aug 2021 08:37:31 +1000 Subject: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process In-Reply-To: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> References: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> Message-ID: <0001ce26-0889-8fa1-6464-b9911c73c121@openssl.org> The vote has closed and passed. Pauli topic: Accept PR#16286 into 3.0 subject to the normal review process Proposed by Shane Lontis Public: yes opened: 2021-08-17 closed: 2021-08-18 accepted:? yes? (for: 5, against: 1, abstained: 1, not voted: 3) ? Dmitry???? [+1] ? Matt?????? [-1] ? Pauli????? [+1] ? Tim??????? [ 0] ? Richard??? [+1] ? Shane????? [+1] ? Tomas????? [? ] ? Kurt?????? [? ] ? Matthias?? [? ] ? Nicola???? [+1] On 17/8/21 11:19 pm, Matt Caswell wrote: > topic: Accept PR#16286 into 3.0 subject to the normal review process > Proposed by Shane Lontis > Public: yes > opened: 2021-08-17 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ? Dmitry???? [? ] > ? Matt?????? [-1] > ? Pauli????? [+1] > ? Tim??????? [ 0] > ? Richard??? [+1] > ? Shane????? [+1] > ? Tomas????? [? ] > ? Kurt?????? [? ] > ? Matthias?? [? ] > ? Nicola???? [+1] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Mon Aug 23 12:07:07 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 23 Aug 2021 14:07:07 +0200 Subject: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process In-Reply-To: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> References: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> Message-ID: <4d1f68df0a332ae4575d3e1f06062ca69a171ba0.camel@openssl.org> -1 post closing of the vote for the record Tomas On Tue, 2021-08-17 at 14:19 +0100, Matt Caswell wrote: > topic: Accept PR#16286 into 3.0 subject to the normal review process > Proposed by Shane Lontis > Public: yes > opened: 2021-08-17 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ?? Dmitry???? [? ] > ?? Matt?????? [-1] > ?? Pauli????? [+1] > ?? Tim??????? [ 0] > ?? Richard??? [+1] > ?? Shane????? [+1] > ?? 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 matt at openssl.org Tue Aug 24 10:47:42 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Aug 2021 11:47:42 +0100 Subject: Update on 3.0 release Message-ID: <98d67dce-f30b-7b36-f6ef-807433026e90@openssl.org> FYI, OTC met today to discuss the 3.0 final release. Due to the security release taking place later today they decided that 3.0 final will not be released this week. Matt From matt at openssl.org Tue Aug 24 14:08:28 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Aug 2021 14:08:28 +0000 Subject: OpenSSL version 1.1.1l published Message-ID: <20210824140828.GA24741@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1l released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1l of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1l is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1l.tar.gz Size: 9834044 SHA1 checksum: f8819dd31642eebea6cc1fa5c256fc9a4f40809b SHA256 checksum: 0b7a3e5e59c34827fe0c3a74b7ec8baef302b98fa80088d7f9153aa16fa76bd1 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1l.tar.gz openssl sha256 openssl-1.1.1l.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmEk9nQACgkQ2cTSbQ5g RJFk2QgAr9NfJzaDqFFDnjCS7bCGyOf77I4P7IFKfD2Ip4BFYUAS//x7rHjyBs/+ LvbXGm1uht8QWvqA+j6jgq/FwHJS0NhYiw8JPh9E/ATqjhx0K3Pe133u8oy4KOWL /yZvc7bm99Fh9kTb+41hYRYqDcnnLvTyjhMT8zTtuZiva3/152zXgSSfbglF9/A5 nnvWRqJMtGX058EuGNpprHT+1HMN/yUr9lkpKR4iHqHTPm/Y+UgQFnwyJnEUDIy3 1yEFiU6FRGyqZL+lLWmv0mORwJRbgFyk1016xMtvR3NsPWITyt9XlkWwExC9mDlG reN5SLCrLyA9mUVzED6ARSMQNINDbg== =hKcH -----END PGP SIGNATURE----- From matt at openssl.org Tue Aug 24 14:16:11 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Aug 2021 14:16:11 +0000 Subject: OpenSSL Security Advisory Message-ID: <20210824141611.GA18839@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [24 August 2021] ========================================== SM2 Decryption Buffer Overflow (CVE-2021-3711) ============================================== Severity: High In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL value for the "out" parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to EVP_PKEY_decrypt() can be smaller than the actual size required by the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated. OpenSSL versions 1.1.1k and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1l. OpenSSL 1.0.2 is not impacted by this issue. OpenSSL 3.0 alpha/beta releases are also affected but this issue will be addressed before the final release. This issue was reported to OpenSSL on 12th August 2021 by John Ouyang. The fix was developed by Matt Caswell. Read buffer overruns processing ASN.1 strings (CVE-2021-3712) ============================================================= Severity: Moderate ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). OpenSSL versions 1.1.1k and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1l. OpenSSL versions 1.0.2y and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2za. Other users should upgrade to 1.1.1l. An initial instance of this issue in the X509_aux_print() function was reported to OpenSSL on 18th July 2021 by Ingo Schwarze. The bugfix was developed by Ingo Schwarze and first publicly released in OpenBSD-current on 10th July 2021 and subsequently in OpenSSL on 20th July 2021 (commit d9d838ddc). Subsequent analysis by David Benjamin on 17th August 2021 identified more instances of the same bug. Additional analysis was performed by Matt Caswell. Fixes for the additional instances of this issue were developed by Matt Caswell. Note ==== OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20210824.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmEk/mUACgkQ2cTSbQ5g RJFqwgf+JbgzTg6LoHNHCIAHkCwHHq2+bZO4ziGbxNxiSv5+37x3jV2iDxdjUeK6 IY87VG0AvjKCD5gN3eMpgOTspO9S2F5fq/q2HE0iIVc8bmR0w3TBvUtFceiBaW2X GyEPxtvG5IG5cMT7vEguk1yq3CgKfXqCz88/gya2YvC/9E7idoyi2UQbEYx+VHRU j5LDGPqYvqaUhWg7FfSCNZ5grdv9pl0A9Kx+HeoIYAi5LZgrcGScm7JpiU7dRa+L 3y1597g6uHOKuGORXkvR9Q61xnNSvOqfV6KLWkMR4PU1a3+Qklpofzub0SZwUIlr bgQ+i2Jm0IMrYHOmG8A9UDzNEqnEjA== =8QGT -----END PGP SIGNATURE----- From kurt at roeckx.be Sun Aug 29 11:36:29 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 29 Aug 2021 13:36:29 +0200 Subject: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process In-Reply-To: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> References: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> Message-ID: On Tue, Aug 17, 2021 at 02:19:08PM +0100, Matt Caswell wrote: > topic: Accept PR#16286 into 3.0 subject to the normal review process -1 Do we need some general policy for such changes after the 3.0 release? Kurt From kurt at roeckx.be Sun Aug 29 12:35:14 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 29 Aug 2021 14:35:14 +0200 Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] In-Reply-To: References: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> Message-ID: I currently fail to see why you can't describe in words what you intend to fix. The PR itself has a subject, so have the commits. One of the reasons we have this vote is public is so that people reading this list can comment on it. Just some number doesn't tell them anything without having to go and look it up and spend time trying to understand. A simple summary of what we intend to vote on will help them understand if they want to look at this or not. If you feel that it should not be part of the vote text, can we at least have some introduction text? For instance PR 16203 was about adding the TLS 1.3 KDF. I can see several vote text for that: - Add the TLS 1.3 KDF to the provider in 3.0. - Add the TLS 1.3 KDF to the provider, and use it in the ssl library in 3.0 so that TLS 1.3 can be used in FIPS mode. - Add support for using TLS 1.3 in FIPS mode in 3.0 Most of our votes are not about how it's implemented, but really a general direction. As you say yourself, it's about proceeding in that direction. I don't see why you can't describe that direction with words. Some of the PR and issues we vote on have different view points based on the comments. Am I voting on the last comment made in the PR or issue? With a PR you can argue it's not the comments but the code, but what happens in case the PR is changed before I can vote? We have also voted on issue, were several things were mentioned in the issue, some things I agree we should do, others I don't. Kurt On Wed, Aug 04, 2021 at 08:25:59AM +1000, Tim Hudson wrote: > The votes on the PR are precisely that - to vote to proceed with the PR via > the normal review process - and that means looking at the varying > viewpoints. > If we reached a consensus that overall we didn't think the PR made sense > then we wouldn't form a vote of that form. > > What you are voting for is that what the PR holds is what makes sense to > proceed with - subject to the normal review process - i.e. this isn't a > push-the-PR-in-right-now vote - it is a "proceed" vote. > > A PR has a discussion in the PR comments, and generally an associated > issue, and always (as it is a PR) the suggested code change. > That is what is being voted on - to proceed with the PR - via the normal > review process. > > As otherwise the PR remains blocked on an OTC decision - and the OTC > decision is to not continue to block the PR (blocked on an OTC decision). > > Repeating again - the PR itself is what is being voted about - not a set of > different unstated viewpoints - it is what is in the PR - fix this problem > - and generally there is nothing critical seen in the code approach - but > our normal review processes still apply to handle it. Which means the PR > simply needs the two approvals. > > The majority of the time in the OTC discussions we are actually looking at > the PR details in terms of the code changes - we aren't reviewing it as > such (although that does sometimes happen on the call) - we are looking at > the PR code changes providing the additional detail to help in the decision > making. > > There are very few PRs which describe what is going to change in a useful > form independent of the code changes - they don't usually state things like > what is going to be changed - they are focused on what is wrong and the PR > is going to fix it - there isn't usually anything meaningful about what is > going to be changed in order to fix what is wrong. > > A PR doesn't hold a range of code fixes to choose between - it holds a > discussion (comments) and a specific code fix - and perhaps that specific > code fix is the result of a sequence of code fixes that have evolved > through the discussion. > > So the precise viewpoint you are voting for in those PRs is to proceed to > include that PR in the work for the current release while continuing to use > our normal review and approval processes - that is the vote text - and it > makes the intent of the vote. > > Where there is a view that we should not take a particular approach > represented in a PR and should take an alternate approach then we don't > form a vote that way - we actually allocate someone to produce an alternate > PR. Often we leave the initial PR and alternate PR open until such time as > we can compare the approaches in concrete form and then we can make a > decision - but that would be accepting one PR over another PR. We have had > "competing" PRs regularly - and we then vote on the alternatives - where it > is clear what the alternatives are. A single PR vote is about that PR. > On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx wrote: > > > On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote: > > > > > > This isn't about the OTC meeting itself - this is about the details of > > the > > > topic actually being captured within the PR. > > > You need to actually look at the PR to form a view. And we do add to the > > > PRs during the discussion if things come up and we review the PR details. > > > So the vote isn't about an OTC discussion - the vote is precisely about > > the > > > PR itself. > > > > > > One of the things we have explicitly discussed on multiple calls is that > > in > > > order to be informed of the details, you need to consult the PR which > > has a > > > record of the discussion and often viewpoints that offer rather different > > > positions on a topic - and those viewpoints are what should be being > > > considered. > > > > I am happy to read the issue/PR to see the different view points. > > But different viewpoints is exactly the problem, which of those am > > I voting for? > > > > During a meeting, there probably was a consensus about what you're > > actually voting for, but that information is lost. > > > > In general, I want a vote to be about what is going to change, the > > how isn't important most of the time. > > > > > > Kurt > > > > From beldmit at gmail.com Sun Aug 29 17:02:33 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 29 Aug 2021 19:02:33 +0200 Subject: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process In-Reply-To: References: <1a40fcd8-3217-0253-1f61-80f7b8f4faae@openssl.org> Message-ID: On Sun, Aug 29, 2021 at 1:36 PM Kurt Roeckx wrote: > On Tue, Aug 17, 2021 at 02:19:08PM +0100, Matt Caswell wrote: > > topic: Accept PR#16286 into 3.0 subject to the normal review process > > -1 > > Do we need some general policy for such changes after the 3.0 > release? > > I think we need some sort of definition of missing features. Some features (e.g. SRP) were deliberately excluded from 3.0, but I tend to treat all the other features available in 1.1.1 and missing in 3.0 as bugs. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Sun Aug 29 19:53:42 2021 From: tjh at cryptsoft.com (Tim Hudson) Date: Mon, 30 Aug 2021 05:53:42 +1000 Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] In-Reply-To: References: <0bbc53cd21d64e82b4022bebe0a8923f@ncp-e.com> Message-ID: You cannot meaningfully vote on the PR without reviewing it. It is that simple. There is zero point in providing details beyond that as the PR is the details. The subject of the PR doesn't remove the need to read the details to form a view. The commentary on the PR and the code itself is what needs to be reviewed in order to form a view point - and that journey needs to be gone through if you want to offer a meaningful opinion on a PR. Any attempt to make a decision based on any form of summary of a PR is completely missing the point of participation in the review process - you might as well toss a coin to form your vote if you aren't going to look at the actual details. Reviewing the code changes and the comments is what is necessary for that purpose and the PR itself is where we want any additional comments to be made. Remember that this context is where and OTC member has placed a hold on a PR for a discussion and decision to be made and there is no clear consensus in the OTC meeting on the path forward or any OTC member wants a formal decision made for whatever reason. There is always a discussion prior to the vote being called. A substantial portion of the PRs result in one or more OTC member acknowledging that the didn't realise the PR meant what it means from having seen its title or summary description - and actually having to read the full commentary *and* the code to understand the context was absolutely necessary. Remember that someone has gone to the effort generally of raising and issue and the creating a proposed solution in a PR and multiple people have looked at it and provided feedback and one or more of them decided that we need a decision made for some reason (and those reasons widely vary). To make an informed decision reasonably requires reviewing all that information to form a view. There is no short cut to reading the PR itself and the vote text reflects that reality. In our OTC meetings we review the issues and review the PRs and we do that by going through the details - not by working off the title of the issue or PR. If you want to only comment on PRs off a summary list then go to GitHub and use its summary views to get that. We could perhaps even add another label with OTC vote pending which might get close to what you want in a single GitHub view. It won't avoid the need to actually read the details to be able to form a view prior to voting. Tim. On Sun, 29 Aug 2021, 22:35 Kurt Roeckx, wrote: > I currently fail to see why you can't describe in words what you > intend to fix. The PR itself has a subject, so have the commits. > > One of the reasons we have this vote is public is so that people > reading this list can comment on it. Just some number doesn't tell > them anything without having to go and look it up and spend time > trying to understand. A simple summary of what we intend to vote > on will help them understand if they want to look at this or not. > > If you feel that it should not be part of the vote text, can we at > least have some introduction text? > > For instance PR 16203 was about adding the TLS 1.3 KDF. I can see > several vote text for that: > - Add the TLS 1.3 KDF to the provider in 3.0. > - Add the TLS 1.3 KDF to the provider, and use it in the ssl library > in 3.0 so that TLS 1.3 can be used in FIPS mode. > - Add support for using TLS 1.3 in FIPS mode in 3.0 > > Most of our votes are not about how it's implemented, but really > a general direction. As you say yourself, it's about proceeding in > that direction. I don't see why you can't describe that direction > with words. > > Some of the PR and issues we vote on have different view > points based on the comments. Am I voting on the last comment > made in the PR or issue? With a PR you can argue it's not the > comments but the code, but what happens in case the PR is changed > before I can vote? We have also voted on issue, were several > things were mentioned in the issue, some things I agree we should > do, others I don't. > > > Kurt > > On Wed, Aug 04, 2021 at 08:25:59AM +1000, Tim Hudson wrote: > > The votes on the PR are precisely that - to vote to proceed with the PR > via > > the normal review process - and that means looking at the varying > > viewpoints. > > If we reached a consensus that overall we didn't think the PR made sense > > then we wouldn't form a vote of that form. > > > > What you are voting for is that what the PR holds is what makes sense to > > proceed with - subject to the normal review process - i.e. this isn't a > > push-the-PR-in-right-now vote - it is a "proceed" vote. > > > > A PR has a discussion in the PR comments, and generally an associated > > issue, and always (as it is a PR) the suggested code change. > > That is what is being voted on - to proceed with the PR - via the normal > > review process. > > > > As otherwise the PR remains blocked on an OTC decision - and the OTC > > decision is to not continue to block the PR (blocked on an OTC decision). > > > > Repeating again - the PR itself is what is being voted about - not a set > of > > different unstated viewpoints - it is what is in the PR - fix this > problem > > - and generally there is nothing critical seen in the code approach - but > > our normal review processes still apply to handle it. Which means the PR > > simply needs the two approvals. > > > > The majority of the time in the OTC discussions we are actually looking > at > > the PR details in terms of the code changes - we aren't reviewing it as > > such (although that does sometimes happen on the call) - we are looking > at > > the PR code changes providing the additional detail to help in the > decision > > making. > > > > There are very few PRs which describe what is going to change in a useful > > form independent of the code changes - they don't usually state things > like > > what is going to be changed - they are focused on what is wrong and the > PR > > is going to fix it - there isn't usually anything meaningful about what > is > > going to be changed in order to fix what is wrong. > > > > A PR doesn't hold a range of code fixes to choose between - it holds a > > discussion (comments) and a specific code fix - and perhaps that specific > > code fix is the result of a sequence of code fixes that have evolved > > through the discussion. > > > > So the precise viewpoint you are voting for in those PRs is to proceed to > > include that PR in the work for the current release while continuing to > use > > our normal review and approval processes - that is the vote text - and it > > makes the intent of the vote. > > > > Where there is a view that we should not take a particular approach > > represented in a PR and should take an alternate approach then we don't > > form a vote that way - we actually allocate someone to produce an > alternate > > PR. Often we leave the initial PR and alternate PR open until such time > as > > we can compare the approaches in concrete form and then we can make a > > decision - but that would be accepting one PR over another PR. We have > had > > "competing" PRs regularly - and we then vote on the alternatives - where > it > > is clear what the alternatives are. A single PR vote is about that PR. > > > On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx wrote: > > > > > On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote: > > > > > > > > This isn't about the OTC meeting itself - this is about the details > of > > > the > > > > topic actually being captured within the PR. > > > > You need to actually look at the PR to form a view. And we do add to > the > > > > PRs during the discussion if things come up and we review the PR > details. > > > > So the vote isn't about an OTC discussion - the vote is precisely > about > > > the > > > > PR itself. > > > > > > > > One of the things we have explicitly discussed on multiple calls is > that > > > in > > > > order to be informed of the details, you need to consult the PR which > > > has a > > > > record of the discussion and often viewpoints that offer rather > different > > > > positions on a topic - and those viewpoints are what should be being > > > > considered. > > > > > > I am happy to read the issue/PR to see the different view points. > > > But different viewpoints is exactly the problem, which of those am > > > I voting for? > > > > > > During a meeting, there probably was a consensus about what you're > > > actually voting for, but that information is lost. > > > > > > In general, I want a vote to be about what is going to change, the > > > how isn't important most of the time. > > > > > > > > > Kurt > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Tue Aug 31 08:47:20 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 31 Aug 2021 18:47:20 +1000 Subject: OTC vote: release of 3.0.0 Message-ID: <5a77051a-27bf-d923-eaf8-86fd3210765c@openssl.org> topic: /Release 3.0.0 final on Tuesday the 7th of September 2021 if run-checker and CI builds have been clean for two days./ Proposed by Pauli. Public: yes opened: 2021-08-31 closed: 2021-08-31 accepted:? yes? (for: 8, against: 0, abstained: 0, not voted: 2) ? Dmitry???? [+1] ? Matt?????? [? ] ? Pauli????? [+1] ? Tim??????? [+1] ? Richard??? [+1] ? Shane????? [+1] ? Tomas????? [+1] ? Kurt?????? [? ] ? Matthias?? [+1] ? Nicola???? [+1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Tue Aug 31 09:15:40 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 31 Aug 2021 19:15:40 +1000 Subject: OTC vote: branching 3.0 Message-ID: <82376700-68f5-3fbf-1da0-973bc48c76cd@openssl.org> topic: Create `openssl-3.0' git branch today. comment: This cascades to other names/version information on GitHub. ???????? For example, change the release version information in the ???????? master branch to 3.1.0-dev Proposed by Pauli. Public: yes opened: 2021-08-31 closed: 2021-08-31 accepted:? yes? (for: 7, against: 0, abstained: 0, not voted: 3) ? Dmitry???? [+1] ? Matt?????? [? ] ? Pauli????? [+1] ? Tim??????? [+1] ? Richard??? [+1] ? Shane????? [+1] ? Tomas????? [+1] ? Kurt?????? [? ] ? Matthias?? [+1] ? Nicola???? [? ] This is to create a git branch and related activities. From matt at openssl.org Tue Aug 31 19:16:55 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Aug 2021 20:16:55 +0100 Subject: OTC vote: release of 3.0.0 In-Reply-To: <5a77051a-27bf-d923-eaf8-86fd3210765c@openssl.org> References: <5a77051a-27bf-d923-eaf8-86fd3210765c@openssl.org> Message-ID: <5226b884-ccfb-c07c-d171-bd9e60a1d036@openssl.org> +1 On 31/08/2021 09:47, Dr Paul Dale wrote: > topic: > > /Release 3.0.0 final on Tuesday the 7th of September 2021 if > run-checker and CI builds have been clean for two days./ > > > Proposed by Pauli. > Public: yes > opened: 2021-08-31 > closed: 2021-08-31 > accepted:? yes? (for: 8, against: 0, abstained: 0, not voted: 2) > > ? Dmitry???? [+1] > ? Matt?????? [? ] > ? Pauli????? [+1] > ? Tim??????? [+1] > ? Richard??? [+1] > ? Shane????? [+1] > ? Tomas????? [+1] > ? Kurt?????? [? ] > ? Matthias?? [+1] > ? Nicola???? [+1] > From matt at openssl.org Tue Aug 31 19:21:16 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Aug 2021 20:21:16 +0100 Subject: OTC vote: branching 3.0 In-Reply-To: <82376700-68f5-3fbf-1da0-973bc48c76cd@openssl.org> References: <82376700-68f5-3fbf-1da0-973bc48c76cd@openssl.org> Message-ID: <0c3168cc-9576-e3fa-8a83-d12e4050d29a@openssl.org> +1 On 31/08/2021 10:15, Dr Paul Dale wrote: > topic: Create `openssl-3.0' git branch today. > comment: This cascades to other names/version information on GitHub. > ???????? For example, change the release version information in the > ???????? master branch to 3.1.0-dev > Proposed by Pauli. > Public: yes > opened: 2021-08-31 > closed: 2021-08-31 > accepted:? yes? (for: 7, against: 0, abstained: 0, not voted: 3) > > ? Dmitry???? [+1] > ? Matt?????? [? ] > ? Pauli????? [+1] > ? Tim??????? [+1] > ? Richard??? [+1] > ? Shane????? [+1] > ? Tomas????? [+1] > ? Kurt?????? [? ] > ? Matthias?? [+1] > ? Nicola???? [? ] > > > This is to create a git branch and related activities. > >