From mark at openssl.org Mon Jun 1 09:15:35 2020 From: mark at openssl.org (Mark J Cox) Date: Mon, 1 Jun 2020 10:15:35 +0100 Subject: Stale PR stats @Jun01 Message-ID: In April I started a script to ping stale PRs that were in certain states. The script has also been collecting statistics (trending and snapshot). I intend to post this monthly and after a few months with trends and commentary. PRs that have not had any updates in the last 30 days and are not WIP: all ( 158 issues, median 219 days) of which: failed CI ( 28 issues, median 114.0 days) deferred after 1.1.1 ( 40 issues, median 219.0 days) cla required ( 18 issues, median 442.0 days) waiting for reporter ( 16 issues, median 299.5 days) waiting for review ( 2 issues, median 40.5 days) waiting for OMC ( 3 issues, median 83 days) waiting for OTC ( 3 issues, median 55 days) all other ( 48 issues, median 215.0 days) So, ignoring deferred issues too you could summarise this as: Stale PRs waiting for us to do something: 36 (last months: 27,29) Stale PRs waiting for the reporter to do something: 34 (last months: 34,37) Stale PRs with unclear next action: 48 (last months: 46,42) There really shouldn't be anything "waiting for OMC/OTC/review" that is over 30 days; many of these did get a decision and the state just isn't updated. Over time I hope we can triage the "all other" PRs with labels so we know what the next action is on each one. Details: waiting for reporter ( 16 issues, median 299.5 days) 11530 branch: 1.1.1, branch: master, cla: trivial, reviewed:changes_requested days:46 11514 reviewed:changes_requested days:50 11310 reviewed:changes_requested days:74 10724 reviewed:changes_requested days:37 10590 reviewed:changes_requested days:146 9575 reviewed:changes_requested days:293 9461 reviewed:changes_requested days:306 9427 reviewed:changes_requested days:313 9243 reviewed:changes_requested days:315 9240 reviewed:changes_requested days:340 8992 reviewed:changes_requested days:257 8962 reviewed:changes_requested days:75 8730 reviewed:changes_requested days:354 8674 reviewed:changes_requested days:409 7961 reviewed:changes_requested days:511 7432 reviewed:changes_requested days:590 waiting for OMC ( 3 issues, median 83 days) 10786 approval: done, branch: 1.1.1, branch: master, hold: need omc decision, reviewed:approved days:83 10195 branch: master, hold: need omc decision, reviewed:commented days:203 5909 hold: need omc decision, milestone:Assessed, reviewed:changes_requested days:34 waiting for OTC ( 3 issues, median 55 days) 9654 approval: otc review pending, branch: master, triaged: feature, reviewed:changes_requested days:55 9537 approval: otc review pending, hold: cla required, reviewed:commented days:47 8300 approval: otc review pending, branch: 1.1.1, branch: master, hold: need otc decision, reviewed:approved days:115 waiting for review ( 2 issues, median 40.5 days) 11526 approval: review pending, branch: 1.1.1, branch: master, reviewed:approved days:32 11278 approval: review pending, branch: master, reviewed:commented days:49 all other ( 48 issues, median 215.0 days) 11679 days:87 11545 days:47 11421 days:41 11398 approval: done, branch: master, reviewed:approved days:66 11359 days:46 11341 days:44 11312 days:78 11277 resolved: not a bug, days:81 11260 reviewed:commented days:86 11116 days:48 11115 days:87 11057 days:111 10884 days:133 10818 days:139 10570 reviewed:commented days:155 10541 days:170 10338 reviewed:commented days:210 10320 branch: 1.1.1, branch: master, reviewed:commented days:201 10298 days:214 10268 days:216 9655 days:188 9554 days:297 9444 branch: master, reviewed:commented days:41 9421 branch: 1.1.1, branch: master, reviewed:approved days:152 9223 branch: master, reviewed:commented days:114 9206 days:345 9051 reviewed:commented days:208 8956 days:367 8920 days:244 8908 days:382 8862 days:361 8835 days:401 8743 branch: master, days:412 8668 days:423 8455 days:425 8420 days:426 8333 days:461 8309 branch: master, reviewed:commented days:347 7688 days:547 7615 days:551 7454 reviewed:commented days:502 7274 reviewed:approved days:353 7225 reviewed:commented days:618 6725 milestone:Assessed, reviewed:approved days:361 6518 milestone:Assessed, reviewed:approved days:712 6448 milestone:Assessed, days:219 6219 milestone:Assessed, reviewed:approved days:750 4487 milestone:Assessed, days:689 From matt at openssl.org Tue Jun 2 14:29:32 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 2 Jun 2020 15:29:32 +0100 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: On 29/04/2020 14:28, Dr. Matthias St. Pierre wrote: > - First, a pull request needs to be opened against the master branch for > discussion. > > ? Only after that pull request has received the necessary amount of > approvals, > > ? a separate pull request can be opened? against the > OpenSSL_1_1_1-stable branch. > > ? > > - A separate pull request against the OpenSSL_1_1_1-stable branch is > required. > > ? This holds - contrary to common practice - even if the change can be > cherry-picked > > ? without conflicts from the master branch. The only exception from this > rule are > > ? changes which are considered 'CLA: trivial', like e.g. typographical > fixes. > There's been no further discussion on this for quite a while, so I will start an OTC vote based on the vote text proposed by Matthias and report back the results here. Matt From mark at openssl.org Tue Jun 2 14:34:49 2020 From: mark at openssl.org (Mark J Cox) Date: Tue, 2 Jun 2020 15:34:49 +0100 Subject: Stale PR stats @Jun01 In-Reply-To: References: Message-ID: Rich Salz mailed me about the issues that were in the "waiting for reporter" state in my summary noting that some of them shouldn't be in that state. I investigated just now and made some changes to my script, so if you are a reviewer or reporter you may get some extra pings today as things moved to the right state. The script looked at the github timeline 'reviewed' events, however those events only happen when changes are requested or the review is approved or rejected. So if a reporter does an update and re-requests a review, it still shows up for the script in state "changes_requested" which isn't true. So now the script also looks at "review_requested" events, and a "review_requested" will change the state from "changes_requested". When looking through the list one by one I spotted quite a few PRs which had changes_requested but where the reporter had made some changes or commented about the changes but had not re-requested a review. I manually did that re-request. I'll also add a OpenSSL Machine comment to stale "changes_requested" state issues to remind the reporter to do that action (and to be sure to re-request a review once they have done so). So here was the state before: > waiting for reporter ( 16 issues, median 299.5 days) > > 11530 branch: 1.1.1, branch: master, cla: trivial, > reviewed:changes_requested days:46 > 11514 reviewed:changes_requested days:50 > 11310 reviewed:changes_requested days:74 > 10724 reviewed:changes_requested days:37 > 10590 reviewed:changes_requested days:146 > 9575 reviewed:changes_requested days:293 > 9461 reviewed:changes_requested days:306 > 9427 reviewed:changes_requested days:313 > 9243 reviewed:changes_requested days:315 > 9240 reviewed:changes_requested days:340 > 8992 reviewed:changes_requested days:257 > 8962 reviewed:changes_requested days:75 > 8730 reviewed:changes_requested days:354 > 8674 reviewed:changes_requested days:409 > 7961 reviewed:changes_requested days:511 > 7432 reviewed:changes_requested days:590 > > waiting for review ( 2 issues, median 40.5 days) > > 11526 approval: review pending, branch: 1.1.1, branch: master, > reviewed:approved days:32 > 11278 approval: review pending, branch: master, reviewed:commented days:49 And now it is: waiting for reporter ( 9 issues, median 308 days) 11530 branch: 1.1.1, branch: master, cla: trivial, reviewed:changes_requested days:48 10590 reviewed:changes_requested days:148 9575 reviewed:changes_requested days:294 9461 reviewed:changes_requested days:308 9427 reviewed:changes_requested days:315 8962 reviewed:changes_requested days:76 8674 reviewed:changes_requested days:411 7961 reviewed:changes_requested days:513 7432 reviewed:changes_requested days:592 waiting for review ( 8 issues, median 51.5 days) 11526 approval: review pending, branch: 1.1.1, branch: master, reviewed:approved days:34 11514 reviewed:review pending days:52 11278 approval: review pending, branch: master, reviewed:commented days:51 10724 reviewed:review pending days:38 10632 reviewed:review pending days:35 8992 reviewed:review pending days:258 8730 reviewed:review pending days:356 6725 milestone:Assessed, reviewed:review pending days:363 From paul.dale at oracle.com Wed Jun 3 07:47:35 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 3 Jun 2020 17:47:35 +1000 Subject: Vote re: #11577 Message-ID: <15AB041F-8365-4870-AA3E-7F6D3FF23FBE@oracle.com> topic: Accept and merge #11577. comment: #11577 reduces the maximum length of TLS labels. It also breaks standards compliance. 8 against, none for, no abstentions, 3 not yet voted. The vote failed, the PR will be closed. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Jun 3 07:53:37 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 3 Jun 2020 17:53:37 +1000 Subject: Seeking assistance Message-ID: <11F28B3A-3209-437D-94C8-5301595E03ED@oracle.com> The OMC has approved working with the FIPS lab to include a number of additional algorithms in the upcoming FIPS validation. One slated for inclusion turns out to be beyond the time available for the fellows and the two others working on 3.0. This is the X9.42 KDF. What it needs is the X509 and CMS calls removed from the KDF and the various structures constructed piecemeal using calls that already exist within the FIPS provider. If somebody is willing to take this work on, it will likely be included in the FIPS validation for 3.0. If not, it won?t be. 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 Wed Jun 3 10:46:41 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 03 Jun 2020 12:46:41 +0200 Subject: OMC VOTE: Drop the 'openssl' interactive mode as per GH #12023 Message-ID: <87367cs9ym.wl-levitte@openssl.org> topic: Drop the 'openssl' interactive mode as per GH #12023 comment: It is undocumented, pretty much unused, and hard to keep stable. Proposed by Richard Levitte Public: yes -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl at openssl.org Thu Jun 4 14:32:20 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 4 Jun 2020 14:32:20 +0000 Subject: OpenSSL version 3.0.0-alpha3 published Message-ID: <20200604143220.GA30351@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 3 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 3 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-alpha3.tar.gz Size: 9622261 SHA1 checksum: 4e5856fb85b1383d309d38874795043a787891ea SHA256 checksum: 354f25ff6c7ed90271e2f0718054ecab253cc4252942aa0e89b265e2795ae040 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha3.tar.gz openssl sha256 openssl-3.0.0-alpha3.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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl7Y/ZwACgkQ2cTSbQ5g RJH5+QgAi8M5sH+m8xnDTV+i9NFc9EAyzs1NMVY2B1/Yhzn+tSbKfR9tocKjFEB/ RV3cAjB1RBHtMxK9sI+O4PyE7Bkk81JB64RjAawY3Dy1kETWEJsulnzgkrpKtrM2 FbyCubL2sZgFevWVB4fDbUIr983o9Dg7idZehvq0zvVzg++bKm6edDDTaIBgisA3 gr+rA00bD++bddmqG7vm31HhN2/fYa+g719trXdfIcsyHhY+bsFtFqMOnO1D0N6f d6dWBNIP8SjuYQ8GJPdPU+Ryro8uJpIUd1DlP7xDg1y21vUoWrzIStbUTIeZh+51 0Qy2tWa52xSBgYQN3tu11MN17rLEPQ== =w062 -----END PGP SIGNATURE----- From levitte at openssl.org Fri Jun 5 07:59:10 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 05 Jun 2020 09:59:10 +0200 Subject: OMC VOTE: Drop the 'openssl' interactive mode as per GH #12023 In-Reply-To: <87367cs9ym.wl-levitte@openssl.org> References: <87367cs9ym.wl-levitte@openssl.org> Message-ID: <87y2p2q6y9.wl-levitte@openssl.org> 4 voted for, none against, no abstencions, 3 have not yet voted. This PR will be merged. Cheers, Richard On Wed, 03 Jun 2020 12:46:41 +0200, Richard Levitte wrote: > > topic: Drop the 'openssl' interactive mode as per GH #12023 > comment: It is undocumented, pretty much unused, and hard to keep > stable. > Proposed by Richard Levitte > Public: yes > > -- > 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 matt at openssl.org Fri Jun 5 10:49:35 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 5 Jun 2020 11:49:35 +0100 Subject: Alpha 3 Blog post Message-ID: <4ec256b8-a03e-05ac-4a27-fe64c6d79c3f@openssl.org> Nicola's latest blog post on the Alpha 3 release has just been published. You can read it here: https://www.openssl.org/blog/blog/2020/06/05/OpenSSL3.0Alpha3/ Matt From tmraz at redhat.com Fri Jun 5 11:27:20 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 05 Jun 2020 13:27:20 +0200 Subject: Travis jobs not getting started Message-ID: Apparently the travis jobs are not getting started anymore for some reason. It happened to me on the GitHub linux-pam project and the solution (or workaround) was to migrate the project to the travis-ci.com. I just did it by following the instructions in this document: https://docs.travis-ci.com/user/migrate/open-source-repository-migration/ -- 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 Fri Jun 5 22:22:11 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 6 Jun 2020 00:22:11 +0200 Subject: Travis jobs not getting started In-Reply-To: References: Message-ID: <20200605222211.GA432047@roeckx.be> On Fri, Jun 05, 2020 at 01:27:20PM +0200, Tomas Mraz wrote: > Apparently the travis jobs are not getting started anymore for some > reason. > > It happened to me on the GitHub linux-pam project and the solution (or > workaround) was to migrate the project to the travis-ci.com. > > I just did it by following the instructions in this document: > https://docs.travis-ci.com/user/migrate/open-source-repository-migration/ I've tried to do it, but it doesn't seem to be working, it says it can't find the repository. Kurt From levitte at openssl.org Sat Jun 6 08:21:09 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 06 Jun 2020 10:21:09 +0200 Subject: Travis jobs not getting started In-Reply-To: References: Message-ID: <87tuzor4ei.wl-levitte@openssl.org> This is something that has been ongoing for a while... it was in the back of my mind a while ago, but then I got distracted. Thanks for finding that document... I failed to when I looked a couple of weeks ago. Migration is now done. It won't show on existing PRs, but does show on new ones. The new Travis is a Github App, which means that it's much more integrated into Github; among others, that shows when you press "details", and it's also available via the new per-PR "Checks" tab. Cheers, Richard On Fri, 05 Jun 2020 13:27:20 +0200, Tomas Mraz wrote: > > Apparently the travis jobs are not getting started anymore for some > reason. > > It happened to me on the GitHub linux-pam project and the solution (or > workaround) was to migrate the project to the travis-ci.com. > > I just did it by following the instructions in this document: > https://docs.travis-ci.com/user/migrate/open-source-repository-migration/ > > -- > 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 matt at openssl.org Mon Jun 8 10:16:40 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Jun 2020 11:16:40 +0100 Subject: addrev warning Message-ID: <422cd054-3bca-b7a4-e2bf-9c601b860191@openssl.org> After upgrading Ubuntu over the weekend I'm suddenly seeing this warning from addrev. Is anyone else getting this? WARNING: git-filter-branch has a glut of gotchas generating mangled history rewrites. Hit Ctrl-C before proceeding to abort, then use an alternative filtering tool such as 'git filter-repo' (https://github.com/newren/git-filter-repo/) instead. See the filter-branch manual page for more details; to squelch this warning, set FILTER_BRANCH_SQUELCH_WARNING=1. Proceeding with filter-branch... MMatt From nic.tuv at gmail.com Mon Jun 8 10:32:06 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 8 Jun 2020 12:32:06 +0200 Subject: addrev warning In-Reply-To: <422cd054-3bca-b7a4-e2bf-9c601b860191@openssl.org> References: <422cd054-3bca-b7a4-e2bf-9c601b860191@openssl.org> Message-ID: Yes, I also got that since I updated my git installation from the upstream source tarball. With recent versions of git this warning has been showing for months already, but I don't know enough about it to propose a fix! Nicola On Mon, Jun 8, 2020, 12:16 Matt Caswell wrote: > After upgrading Ubuntu over the weekend I'm suddenly seeing this warning > from addrev. Is anyone else getting this? > > WARNING: git-filter-branch has a glut of gotchas generating mangled history > rewrites. Hit Ctrl-C before proceeding to abort, then use an > alternative filtering tool such as 'git filter-repo' > (https://github.com/newren/git-filter-repo/) instead. See the > filter-branch manual page for more details; to squelch this > warning, > set FILTER_BRANCH_SQUELCH_WARNING=1. > Proceeding with filter-branch... > > > MMatt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Jun 8 10:38:57 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 08 Jun 2020 12:38:57 +0200 Subject: addrev warning In-Reply-To: <422cd054-3bca-b7a4-e2bf-9c601b860191@openssl.org> References: <422cd054-3bca-b7a4-e2bf-9c601b860191@openssl.org> Message-ID: <877dwhrge6.wl-levitte@openssl.org> Yes. I propose telling git to shut up, i.e. FILTER_BRANCH_SQUELCH_WARNING=1 Our use of git-filter-branch isn't one that will generate a gotcha, or we would have seen that a long time ago... in other words, we treat it gently. I was looking at git-filter-repo, but realised that it's not a standard git thing, so if we changed addrev to use that instead, we'd have addrev starting to fail completely for everyone that hasn't installed that one yet. I'm not prepared to spring that surprise on anyone. Cheers, Richard On Mon, 08 Jun 2020 12:16:40 +0200, Matt Caswell wrote: > > After upgrading Ubuntu over the weekend I'm suddenly seeing this warning > from addrev. Is anyone else getting this? > > WARNING: git-filter-branch has a glut of gotchas generating mangled history > rewrites. Hit Ctrl-C before proceeding to abort, then use an > alternative filtering tool such as 'git filter-repo' > (https://github.com/newren/git-filter-repo/) instead. See the > filter-branch manual page for more details; to squelch this warning, > set FILTER_BRANCH_SQUELCH_WARNING=1. > Proceeding with filter-branch... > > > MMatt > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaduk at mit.edu Mon Jun 8 22:55:39 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Mon, 8 Jun 2020 15:55:39 -0700 Subject: addrev warning In-Reply-To: <877dwhrge6.wl-levitte@openssl.org> References: <422cd054-3bca-b7a4-e2bf-9c601b860191@openssl.org> <877dwhrge6.wl-levitte@openssl.org> Message-ID: <20200608225539.GC58497@mit.edu> On Mon, Jun 08, 2020 at 12:38:57PM +0200, Richard Levitte wrote: > Yes. > > I propose telling git to shut up, i.e. FILTER_BRANCH_SQUELCH_WARNING=1 > Our use of git-filter-branch isn't one that will generate a gotcha, or > we would have seen that a long time ago... in other words, we treat > it gently. I just patched around it locally (in this manner) when it showed up in debian unstable. I agree that we're not using filter-branch in a way that is likely to cause problems. -Ben From rsalz at akamai.com Tue Jun 9 23:40:46 2020 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 9 Jun 2020 23:40:46 +0000 Subject: The hold on PR 12089 Message-ID: <9D99030C-F013-4B66-85F6-968432C1FFE6@akamai.com> What is the timetable for resolving https://github.com/openssl/openssl/pull/12089 ? The Beta is planned for a July 16 release. There is a massive RAND/DRBG PR (https://github.com/openssl/openssl/pull/11682, the provider-friendly random) that is in the pipeline, and 12089 and 11682 will undoubtedly cause merge issues whichever gets merged first. That means extra time will be needed to reconcile. An OMC vote, once started, can be resolved in as quickly as 24 hours, but often take one or two weeks if most people abstain. Being conservative, then, the OMC needs to discuss and vote, before the end of this month. An additional complication is around the question of who votes: the OMC or the OTC. It is hard to justify this as requiring OMC action, unless the project is committing to avoiding such language in the future as a policy. But if the project wants to decide that, it can do so. Regardless of the policy, PR 12089 could be seen as purely an OTC issue, and OMC involvement is over-reach ? what in https://www.openssl.org/policies/omc-bylaws.html justifies OMC involvement?. Nothing changes but some names; is the naming of things within OMC perview? I would love to know what OTC members think. So, what is the timetable, and what is the plan? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Wed Jun 10 08:55:36 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 10 Jun 2020 10:55:36 +0200 Subject: The hold on PR 12089 In-Reply-To: <9D99030C-F013-4B66-85F6-968432C1FFE6@akamai.com> References: <9D99030C-F013-4B66-85F6-968432C1FFE6@akamai.com> Message-ID: I believe the OMC is called into action as some name changes might be seen as breaking API or ABI compatibility and that has been considered so far as part of the first item in the OMC prerogatives list. The matter of OMC Vs OTC vote also depends on what kind of hold Tim is applying with his - 1: is it a OMC or a OTC hold? Of course OMC can always override what OTC decides, but the discussion/vote should happen in OTC/OMC depending on which hat Tim was wearing when placing the hold. Cheers, Nicola On Wed, Jun 10, 2020, 10:43 Salz, Rich wrote: > What is the timetable for resolving > https://github.com/openssl/openssl/pull/12089 ? > > > > The Beta is planned for a July 16 release. There is a massive RAND/DRBG > PR (https://github.com/openssl/openssl/pull/11682, the provider-friendly > random) that is in the pipeline, and 12089 and 11682 will undoubtedly cause > merge issues whichever gets merged first. That means extra time will be > needed to reconcile. An OMC vote, once started, can be resolved in as > quickly as 24 hours, but often take one or two weeks if most people > abstain. > > > > Being conservative, then, the OMC needs to discuss and vote, before the > end of this month. > > > > An additional complication is around the question of who votes: the OMC or > the OTC. It is hard to justify this as requiring OMC action, unless the > project is committing to avoiding such language in the future as a policy. > But if the project wants to decide that, it can do so. Regardless of the > policy, PR 12089 could be seen as purely an OTC issue, and OMC involvement > is over-reach ? what in https://www.openssl.org/policies/omc-bylaws.html > justifies OMC involvement?. Nothing changes but some names; is the naming > of things within OMC perview? I would love to know what OTC members think. > > > > So, what is the timetable, and what is the plan? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Jun 10 09:21:52 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 10 Jun 2020 11:21:52 +0200 Subject: The hold on PR 12089 In-Reply-To: References: <9D99030C-F013-4B66-85F6-968432C1FFE6@akamai.com> Message-ID: <87ftb3p973.wl-levitte@openssl.org> On Wed, 10 Jun 2020 10:55:36 +0200, Nicola Tuveri wrote: > The matter of OMC Vs OTC vote also depends on what kind of hold Tim > is applying with his - 1: is it a OMC or a OTC hold? The label that Tim added should make it clear: "hold: need omc decision" I've started a discussion within the OMC. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu Jun 11 14:20:18 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 11 Jun 2020 15:20:18 +0100 Subject: Monthly Status Report (May) Message-ID: <590d86e4-b59b-acf3-7fc4-130da2614960@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Investigated a mysterious perl crash during Configure on some platforms - Attended regular weekly dev team calls, and fortnightly FIPS sponsor calls - Created PR to ensure we don't offer accept ciphersuites that we don't support - Continued work on PR to centralise environment variables in the tests - Created PR to document some missing s_server options - Completed PR fixing raw provider keys - Published OpenSSL 1.0.2v for premium support customers - Implemented stricter type discipline in the provider<->libcrypto interface - Performed the OpenSSL 3.0 alpha 2 release - Fixed the alignment calculation in ssl3_setup_write - Continued review work on the CMP submission - Fixed an issue where we were incorrectly falling back to legacy if a fetch of the EVP_KEYMGMT failed. - Deleted the redundant sslprovidertest - Ensured that we check the availability of sigalgs before we offer or accept them - Removed some deliberate downgrading of keys in libssl - Investigated and fixed issues in the CMAC implementation Matt From matt at openssl.org Tue Jun 16 13:03:58 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jun 2020 14:03:58 +0100 Subject: Backports to 1.1.1 and what is allowed Message-ID: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> PR 11188 proposes to backport a series of s390x patches to the 1.1.1 branch. IIUC it includes performance improvements as well as support for new hardware instructions. I think we need to have a much clearer and more explicit policy about exactly what is allowed to be backported to a stable branch. For example PR #11968 was a significant recent PR that backported AES CTR-DRBG performance improvements to the 1.1.1 branch and was allowed (should it have been?). We have always said that the stable releases should only receive bug and security fixes. Performance improvements have been a bit of a grey area, e.g. a few lines of code that significantly improves the performance of a particular algorithm or codepath could reasonably be justified as "fixing a performance bug". OTOH bringing in whole new files of assembler seems to go way beyond that definition. However, when I tried to find a reference to the policy which says exactly what we are allowed to backport I could find one. Do we have such a thing? In any case I think we should develop a much more explicit policy that will enable us to decide whether PRs such as 11188 are reasonable or not. See for example Ubuntu's Stable Release Updates policy: https://wiki.ubuntu.com/StableReleaseUpdates Matt From levitte at openssl.org Tue Jun 16 20:51:50 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Jun 2020 22:51:50 +0200 Subject: Late Monthly Status Report (January 2020) Message-ID: <87o8piohsp.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 - [not_yet_merged] WIP: OSSL_STORE for providers (PR openssl/openssl#9389) - CORE & EVP: Adapt KEYEXCH, SIGNATURE and ASYM_CIPHER to handle key types better (PR openssl/openssl#10647) - Configuration: synchronise the variables on the build file templates (PR openssl/openssl#10753) - EVP: Fix method to determine if a PKEY is legacy or not (PR openssl/openssl#10758) - DOCS: The interpretation of OPENSSL_API_COMPAT has changed, update docs (PR openssl/openssl#10765) - Add missing inclusion of "internal/deprecated.h" (PR openssl/openssl#10766) - EVP: If a key can't be exported to provider, fallback to legacy (PR openssl/openssl#10771) - Add the DSA serializers to the default provider tools (PR openssl/openssl#10772) - EVP: make EVP_PKEY_{bits,security_bits,size} work with provider only keys (PR openssl/openssl#10778) - PROV: Fix mixup between general and specialized GCM implementations (PR openssl/openssl#10783) - Configure: use $list_separator_re only for defines and includes (PR openssl/openssl#10793) - Eliminate some EVP_PKEY_size() uses (PR openssl/openssl#10798) - EVP: clear error when falling back from failed EVP_KEYMGMT_fetch() (PR openssl/openssl#10803) - CORE: renumber OSSL_FUNC_KEYMGMT macros (PR openssl/openssl#10804) - Fix documentation for EVP_DigestSign* and EVP_DigestVerify* (PR openssl/openssl#10805) - Fix EVP_Digest{Sign,Verify}Final() and EVP_Digest{Sign,Verify}() for provider only keys (PR openssl/openssl#10806) - EVP: Adapt EVP_PKEY Seal and Open for provider keys (PR openssl/openssl#10808) - Move the definition of OPENSSL_BUILDING_OPENSSL (PR openssl/openssl#10813) - Change returned -2 to 0 in EVP_Digest{Sign,Verify}Init() (PR openssl/openssl#10815) - Add EVP_PKEY_get_default_digest_name() (PR openssl/openssl#10824) - CRYPTO: Remove support for ex_data fields when building the FIPS module (PR openssl/openssl#10837) - Modify EVP_CIPHER_is_a() and EVP_MD_is_a() to handle legacy methods too (PR openssl/openssl#10845) - Move the stored namemap pre-population to namemap construction (PR openssl/openssl#10846) - [1.1.1] Fix documentation of return value for EVP_Digest{Sign,Verify}Init() (PR openssl/openssl#10847) - Build file templates: Use explicit files instead of $< or $? for pods (PR openssl/openssl#10849) - EVP: Add evp_pkey_make_provided() and refactor around it (PR openssl/openssl#10850) - Adapt X509_PUBKEY_set() for use with provided implementations (PR openssl/openssl#10851) - For all assembler scripts where it matters, recognise clang > 9.x (PR openssl/openssl#10855) - Add GNU properties note for Intel CET in x86_64-xlate.pl (PR openssl/openssl#10875) - Configure: Better detection of '-static' in @{$config{LDFLAGS}} (PR openssl/openssl#10878) - PROV: Fix bignum printout in text serializers (PR openssl/openssl#10891) - OpenSSL::Test: bring back the relative paths (PR openssl/openssl#10913) - Adapt ASN1_item_sign_ctx() for use with provided keypairs (PR openssl/openssl#10920) - Add internal maxsize macros (PR openssl/openssl#10928) - test/recipes/30-test_evp.t: Fix multiple definition of @bffiles (PR openssl/openssl#10944) * Administration - Stop making snaps for 1.1.0 and 1.0.2, and make 3.0-dev snaps - Switch final review to be for OTC rather than OMC -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Jun 16 20:52:36 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Jun 2020 22:52:36 +0200 Subject: Late Monthly Status Report (February 2020) Message-ID: <87mu52ohrf.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 - PROV: add RSA signature implementation (PR openssl/openssl#10557) - Disable devcryptoeng on newer OpenBSD versions [1.1.1] (PR openssl/openssl#10565) - EVP: Adapt EVP_PKEY checking, comparing and copying for provider keys (PR openssl/openssl#10807) - DOC: document in more detail what a BIO_read_ex() via BIO_f_buffer() does (PR openssl/openssl#10890) - Refactor SM2 (PR openssl/openssl#10942) - Decentralize legacy_ctrl_str_to_param() (PR openssl/openssl#10947) - config: ensure the perl Configure run is the last statement (PR openssl/openssl#10953) - EVP: Small refactor of keymgmt library code (PR openssl/openssl#10963) - DOC: Add documentation related to X509_LOOKUPs (PR openssl/openssl#10986) - Redesign the KEYMGMT libcrypto <-> provider interface (PR openssl/openssl#11006) - EVP: Adapt EVP_PKEY checking, comparing and copying for provider keys, take 2 (PR openssl/openssl#11025) - Configure: Add easy to use disabled deprecated functionality indicators (PR openssl/openssl#11027) - PROV: Ensure the AlgorithmIdentifier registers in DSA signature impl (PR openssl/openssl#11037) - X509_PUBKEY_set(): Fix memory leak (PR openssl/openssl#11038) - test/recipes/80-test_ssl_old.t: use 'openssl genpkey' (PR openssl/openssl#11041) - Make util/find-doc-nits runnable from the build tree (PR openssl/openssl#11045) - Refactor OSSL_PARAM_allocate_from_text() for better flexibility (PR openssl/openssl#11046) - Add OSSL_SERIALIZER_PUBKEY_TO_DER_PQ and friends (PR openssl/openssl#11055) - Adapt i2d_PrivateKey for provider only keys (PR openssl/openssl#11056) - Document OSSL_SERIALIZER_PUBKEY_TO_DER_PQ and friends (PR openssl/openssl#11071) - Refactor evp_pkey_make_provided() to do legacy to provider export (PR openssl/openssl#11074) - Adapt i2d_PUBKEY for provider only keys (PR openssl/openssl#11078) - TEST: Create test specific output directories (PR openssl/openssl#11080) - include/openssl/whrlpool.h: correct unbalanced deprecation guards (PR openssl/openssl#11087) - Fix VMS build [1.1.1 only] (PR openssl/openssl#11088) - PROV: Build the main FIPS module code with FIPS_MODE defined (PR openssl/openssl#11090) - TEST: add util/wrap.pl and use it #11110 (PR openssl/openssl#11110) - Rethink the EVP_PKEY cache of provider side keys (PR openssl/openssl#11148) - VMS: mitigate for the C++ compiler that doesn't understand certain pragmas (PR openssl/openssl#11159) - Deprecate ASN1_sign(), ASN1_verify() and ASN1_digest() (PR openssl/openssl#11161) - Fix util/mktar.sh to use the new VERSION information (PR openssl/openssl#11190) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Jun 16 20:53:40 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Jun 2020 22:53:40 +0200 Subject: Late Monthly Status Report (March 2020) Message-ID: <87lfkmohpn.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 - [not_yet_merged] WIP: apps: Switch to using OSSL_STORE for loading keys, certs, ... (PR openssl/openssl#7390) - Implement domparam and key generation (PR openssl/openssl#10289) - DOC: Add documentation related to X509_LOOKUPs [1.1.1] (PR openssl/openssl#11120) - Refactor CRMF_poposigningkey_init() to work with provider keys (PR openssl/openssl#11126) - Configuration: Add post module building check (PR openssl/openssl#11170) - build.info extensions: variable value substitutions and multi-item statements (PR openssl/openssl#11185) - .travis.yml: where it matters, have build and source nesting levels differ (PR openssl/openssl#11186) - crypto/perlasm/x86_64-xlate.pl: detect GNU as to deal with quirks (PR openssl/openssl#11191) - EVP: Check that key methods aren't foreign when exporting (PR openssl/openssl#11193) - Andoid cross compile: change ANDROID_NDK_HOME to ANDROID_NDK_ROOT (PR openssl/openssl#11206) - config, Configure: move the check of removed crypto/ sub-systems (PR openssl/openssl#11217) - Configurations: Fix "android" configuration target (PR openssl/openssl#11238) - util/wrap.pl: do not look at EXE_SHELL (PR openssl/openssl#11258) - Restructure documentation of implementations in providers (PR openssl/openssl#11270) - DOCS: Fix documentation on asymmetric keydata types (PR openssl/openssl#11275) - DOCS: Fix the description of OSSL_PARAM_allocate_from_text() (PR openssl/openssl#11279) - Refactor sm2_id (PR openssl/openssl#11302) - Fix RSA structure (PR openssl/openssl#11315) - Fix legacy_ctrl_to_param() to pay better attention to keytype (PR openssl/openssl#11329) - Refactor sm2_id - addendum (PR openssl/openssl#11335) - EVP: fetch the EVP_KEYMGMT earlier (PR openssl/openssl#11343) - [WIP] EVP: Fix EVP_PKEY_copy_parameters() for a newly allocated |to| (PR openssl/openssl#11368) - DH, DSA, EC_KEY: Fix exporters to allow domain parameter keys (PR openssl/openssl#11374) - EVP: Downgrade keys rather than upgrade (PR openssl/openssl#11375) - util/wrap.pl: Correct exit code when signalled (PR openssl/openssl#11379) - EC: Refactor ec_curve_name2nid() to accept NIST curve names (PR openssl/openssl#11391) - PROV: Fix EC_KEY exporters to allow domain parameter keys (PR openssl/openssl#11394) * Web - Fix 'make relupd' -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Jun 16 20:56:20 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Jun 2020 22:56:20 +0200 Subject: Late Monthly Status Report (April 2020) Message-ID: <87k106ohl7.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 - EXPERIMENTAL: remove all the legacy bits from a EVP_PKEY (PR openssl/openssl#10797) - DOC: Add more description of EVP_PKEY_fromdata(), and examples (PR openssl/openssl#11220) - [not_yet_merged] [WIP] Incorporate system guessing in Configure (PR openssl/openssl#11230) - EC param / key generation (PR openssl/openssl#11328) - EVP & TLS: Add necessary EC_KEY data extraction functions, and use them (PR openssl/openssl#11358) - [not_yet_merged] [WIP] PKCS#7 and CMS with provider side keys (PR openssl/openssl#11422) - PROV: DER writer (PR openssl/openssl#11450) - CMS KARI: Temporarly downgrade newly generated EVP_PKEYs to legacy (PR openssl/openssl#11501) - OpenSSL::OID: Don't use List::Util (PR openssl/openssl#11503) - [URGENT] Add common internal crypto/ modules in liblegacy.a (PR openssl/openssl#11504) - PROV: Remove duplicate in .../ciphers/build.info (PR openssl/openssl#11513) - Rename FIPS_MODE to FIPS_MODULE (PR openssl/openssl#11539) - DOC: Refactor provider-keymgmt(7) to give the keytypes their own pages (PR openssl/openssl#11546) - EVP: Fix calls to evp_pkey_export_to_provider() (PR openssl/openssl#11550) - INSTALL: document 'no-ui-console' rather than 'no-ui' (PR openssl/openssl#11553) - TEST: make and use a fipsinstall script (PR openssl/openssl#11565) - Build files: add module installation targets (PR openssl/openssl#11566) - EVP: Fix EVP_Digest{Sign,Verify}Init() to handle no default digest (PR openssl/openssl#11576) - Make test/fipsinstall.pl when running via the test harness (PR openssl/openssl#11591) - Fix dev/release-aux-openssl-announce-pre-release.tmpl (PR openssl/openssl#11617) - Configure: Allow quoted values in VERSION (PR openssl/openssl#11624) - Configurations/windows-makefile.tmpl: Fix template code for INSTALL_MODULES (PR openssl/openssl#11629) - fuzz/asn1.c: Add missing #include (PR openssl/openssl#11640) - Configurations/unix-Makefile.tmpl: fix typo (PR openssl/openssl#11654) - include/openssl/x509v3.h: restore previous stack definition arrangement (PR openssl/openssl#11655) - crypto/x509/v3_alt.c: make 'othername' a bit bigger (PR openssl/openssl#11656) - Configure: change all references to INSTALL to INSTALL.md (PR openssl/openssl#11657) - EVP: Fix evp_keymgmt_util_copy() for to->keymgmt == NULL (PR openssl/openssl#11668) * Administration - Create the omc-tools repo, as per vote concluded 2020-03-04 - Move a set of directories to omc-tools, as per vote concluded 2020-03-04 - Move release-tools/do-release.pl to omc-tools - Give OTC push access to tools - mediawiki: add the NumberHeadings extension -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Jun 16 20:57:03 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Jun 2020 22:57:03 +0200 Subject: Monthly Status Report (May 2020) Message-ID: <87imfqohk0.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 - [not_yet_merged] [WIP] Refactor CPUID code (PR openssl/openssl#11311) - EVP: Only use the engine when one is defined, in pkey_mac_ctrl() (PR openssl/openssl#11674) - WPACKET: don't write DER length when we don't want to (PR openssl/openssl#11703) - util/perl/OpenSSL/OID.pm: remove the included unit test (PR openssl/openssl#11704) - Fix reason code clash (PR openssl/openssl#11708) - PSS pack: Add provider support for PSS parameters (PR openssl/openssl#11710) - Configure: avoid perl regexp bugs (PR openssl/openssl#11737) - EVP: when setting the operation to EVP_PKEY_OP_UNDEFINED, clean up! (PR openssl/openssl#11750) - Warn that objects with opaque types must never be passed on. (PR openssl/openssl#11754) - OSSL_STORE additions (PR openssl/openssl#11756) - Fix some misunderstandings in our providers' main modules (PR openssl/openssl#11777) - Fix d2i_PrivateKey_ex() to work as documented (PR openssl/openssl#11787) - Fix CHANGES.md issues reported by markdownlint (PR openssl/openssl#11788) - Remove explicit dependency on configdata.pm when processing .in files (PR openssl/openssl#11790) - PROV: Add a proper provider context structure for OpenSSL providers (PR openssl/openssl#11803) - SSL: refactor ssl_cert_lookup_by_pkey() to work with provider side keys (PR openssl/openssl#11828) - test/evp_extra_test.c: Add OPENSSL_NO_CMAC around CMAC test (PR openssl/openssl#11833) - CORE: Fix a couple of bugs in algorithm_do_this() (PR openssl/openssl#11837) - CORE: query for operations only once per provider (unless no_store is true) (PR openssl/openssl#11842) - Add OSSL_PROVIDER_do_all() (PR openssl/openssl#11858) - Refactor the provider side DER constants and writers (PR openssl/openssl#11868) - rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx(): fix check of |md| (PR openssl/openssl#11869) - STORE: Make try_decode_PrivateKey() ENGINE aware (PR openssl/openssl#11872) - Fix d2i_PrivateKey() to work as documented [1.1.1] (PR openssl/openssl#11888) - PROV: Fix RSA-OAEP memory leak (PR openssl/openssl#11927) - Add header file docs for openssl/core_numbers.h and openssl/core_names.h (PR openssl/openssl#11963) - util/mkpod2html.pl: Fix unbalanced quotes (PR openssl/openssl#11969) - Fix EVP_CIPHER_fetch race condition (PR openssl/openssl#11977) - [not_yet_merged] [WIP] EVP: retrieve EVP_CIPHER constants in the evp_cipher_from_dispatch() (PR openssl/openssl#11980) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaduk at mit.edu Wed Jun 17 03:43:35 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 16 Jun 2020 20:43:35 -0700 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> Message-ID: <20200617034335.GD11992@kduck.mit.edu> On Tue, Jun 16, 2020 at 02:03:58PM +0100, Matt Caswell wrote: > PR 11188 proposes to backport a series of s390x patches to the 1.1.1 > branch. IIUC it includes performance improvements as well as support for > new hardware instructions. > > I think we need to have a much clearer and more explicit policy about > exactly what is allowed to be backported to a stable branch. For example > PR #11968 was a significant recent PR that backported AES CTR-DRBG > performance improvements to the 1.1.1 branch and was allowed (should it > have been?). I am happy to see 11968 landed; some informal testing that I hope to make more formal soon seems to show a ~20% slowdown/regression for large RNG requests going from 1.1.1d to 1.1.g, and 11968 provided substantially more significant of a speedup (again, very informal testing, though). In this case you could say that the "bug" is that we're only calling AES on a block at a time despite having much more effective backends available for multi-block calls. > We have always said that the stable releases should only receive bug and > security fixes. Performance improvements have been a bit of a grey area, > e.g. a few lines of code that significantly improves the performance of > a particular algorithm or codepath could reasonably be justified as > "fixing a performance bug". OTOH bringing in whole new files of > assembler seems to go way beyond that definition. There's probably some semi-subtle distinction to make along the lines of "making the algorithm more efficient" vs "using a new algorithm, that happens to run faster", with the latter counting as a feature. > However, when I tried to find a reference to the policy which says > exactly what we are allowed to backport I could find one. Do we have > such a thing? > > In any case I think we should develop a much more explicit policy that > will enable us to decide whether PRs such as 11188 are reasonable or > not. See for example Ubuntu's Stable Release Updates policy: I agree that having something written down will be very useful, even if just as a fixed benchmark against which to think about how exceptional any given "exception case" is where we want to deviate from it. -Ben > https://wiki.ubuntu.com/StableReleaseUpdates > > > Matt From paul.dale at oracle.com Wed Jun 17 05:47:53 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 17 Jun 2020 15:47:53 +1000 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <20200617034335.GD11992@kduck.mit.edu> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200617034335.GD11992@kduck.mit.edu> Message-ID: I?d also support 11968 being merged. I find the recent discussion and the likelihood of all major distros (supporting the S390x) picking up the patches fairly compelling, especially since the same people will be maintaining it. I would need to go and double check the non-S390x specific parts for possible breakage but the bulk of the changes are S390x specific. I support formalising the rules better than we have at the moment. Even if this is in conflict with the above. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 17 Jun 2020, at 1:43 pm, Benjamin Kaduk wrote: > > On Tue, Jun 16, 2020 at 02:03:58PM +0100, Matt Caswell wrote: >> PR 11188 proposes to backport a series of s390x patches to the 1.1.1 >> branch. IIUC it includes performance improvements as well as support for >> new hardware instructions. >> >> I think we need to have a much clearer and more explicit policy about >> exactly what is allowed to be backported to a stable branch. For example >> PR #11968 was a significant recent PR that backported AES CTR-DRBG >> performance improvements to the 1.1.1 branch and was allowed (should it >> have been?). > > I am happy to see 11968 landed; some informal testing that I hope to make > more formal soon seems to show a ~20% slowdown/regression for large RNG > requests going from 1.1.1d to 1.1.g, and 11968 provided substantially more > significant of a speedup (again, very informal testing, though). > > In this case you could say that the "bug" is that we're only calling AES on > a block at a time despite having much more effective backends available for > multi-block calls. > >> We have always said that the stable releases should only receive bug and >> security fixes. Performance improvements have been a bit of a grey area, >> e.g. a few lines of code that significantly improves the performance of >> a particular algorithm or codepath could reasonably be justified as >> "fixing a performance bug". OTOH bringing in whole new files of >> assembler seems to go way beyond that definition. > > There's probably some semi-subtle distinction to make along the lines of > "making the algorithm more efficient" vs "using a new algorithm, that > happens to run faster", with the latter counting as a feature. > >> However, when I tried to find a reference to the policy which says >> exactly what we are allowed to backport I could find one. Do we have >> such a thing? >> >> In any case I think we should develop a much more explicit policy that >> will enable us to decide whether PRs such as 11188 are reasonable or >> not. See for example Ubuntu's Stable Release Updates policy: > > I agree that having something written down will be very useful, even if > just as a fixed benchmark against which to think about how exceptional any > given "exception case" is where we want to deviate from it. > > -Ben > >> https://wiki.ubuntu.com/StableReleaseUpdates >> >> >> Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Jun 17 19:57:31 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 17 Jun 2020 21:57:31 +0200 Subject: Reducing the security bits for MD5 and SHA1 in TLS In-Reply-To: <38fdd617-86ca-0440-e259-964863989e43@openssl.org> References: <38fdd617-86ca-0440-e259-964863989e43@openssl.org> Message-ID: <20200617195731.GA365490@roeckx.be> On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote: > PR 10787 proposed to reduce the number of security bits for MD5 and SHA1 > in TLS (master branch only, i.e. OpenSSL 3.0): > > https://github.com/openssl/openssl/pull/10787 > > This would have the impact of meaning that TLS < 1.2 would not be > available in the default security level of 1. You would have to set the > security level to 0. > > In my mind this feels like the right thing to do. The security bit > calculations should reflect reality, and if that means that TLS < 1.2 no > longer meets the policy for security level 1, then that is just the > security level doing its job. However this *is* a significant breaking > change and worthy of discussion. Since OpenSSL 3.0 is a major release it > seems that now is the right time to make such changes. > > IMO it seems appropriate to have an OMC vote on this topic (or should it > be OTC?). Possible wording: So should that be an OMC or OTC vote, or does it not need a vote? Kurt From tjh at cryptsoft.com Thu Jun 18 02:20:07 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Thu, 18 Jun 2020 12:20:07 +1000 Subject: Reducing the security bits for MD5 and SHA1 in TLS In-Reply-To: <20200617195731.GA365490@roeckx.be> References: <38fdd617-86ca-0440-e259-964863989e43@openssl.org> <20200617195731.GA365490@roeckx.be> Message-ID: Given that this change impacts interoperability in a major way it should be a policy vote of the OMC IMHO. Tim. On Thu, 18 Jun 2020, 5:57 am Kurt Roeckx, wrote: > On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote: > > PR 10787 proposed to reduce the number of security bits for MD5 and SHA1 > > in TLS (master branch only, i.e. OpenSSL 3.0): > > > > https://github.com/openssl/openssl/pull/10787 > > > > This would have the impact of meaning that TLS < 1.2 would not be > > available in the default security level of 1. You would have to set the > > security level to 0. > > > > In my mind this feels like the right thing to do. The security bit > > calculations should reflect reality, and if that means that TLS < 1.2 no > > longer meets the policy for security level 1, then that is just the > > security level doing its job. However this *is* a significant breaking > > change and worthy of discussion. Since OpenSSL 3.0 is a major release it > > seems that now is the right time to make such changes. > > > > IMO it seems appropriate to have an OMC vote on this topic (or should it > > be OTC?). Possible wording: > > So should that be an OMC or OTC vote, or does it not need a vote? > > > Kurt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Jun 18 04:04:02 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 18 Jun 2020 14:04:02 +1000 Subject: Reducing the security bits for MD5 and SHA1 in TLS In-Reply-To: References: <38fdd617-86ca-0440-e259-964863989e43@openssl.org> <20200617195731.GA365490@roeckx.be> Message-ID: <50DD7A5C-A6E3-458E-B3E4-C97A67EE90EB@oracle.com> I?d agree it?s major for for SHA1 but not for MD5. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 18 Jun 2020, at 12:20 pm, Tim Hudson wrote: > > Given that this change impacts interoperability in a major way it should be a policy vote of the OMC IMHO. > > Tim. > > > On Thu, 18 Jun 2020, 5:57 am Kurt Roeckx, > wrote: > On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote: > > PR 10787 proposed to reduce the number of security bits for MD5 and SHA1 > > in TLS (master branch only, i.e. OpenSSL 3.0): > > > > https://github.com/openssl/openssl/pull/10787 > > > > This would have the impact of meaning that TLS < 1.2 would not be > > available in the default security level of 1. You would have to set the > > security level to 0. > > > > In my mind this feels like the right thing to do. The security bit > > calculations should reflect reality, and if that means that TLS < 1.2 no > > longer meets the policy for security level 1, then that is just the > > security level doing its job. However this *is* a significant breaking > > change and worthy of discussion. Since OpenSSL 3.0 is a major release it > > seems that now is the right time to make such changes. > > > > IMO it seems appropriate to have an OMC vote on this topic (or should it > > be OTC?). Possible wording: > > So should that be an OMC or OTC vote, or does it not need a vote? > > > Kurt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 18 09:11:49 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 18 Jun 2020 10:11:49 +0100 Subject: Reducing the security bits for MD5 and SHA1 in TLS In-Reply-To: References: <38fdd617-86ca-0440-e259-964863989e43@openssl.org> <20200617195731.GA365490@roeckx.be> Message-ID: <3ff9154a-f6c5-73dd-acf9-9fb3ba268871@openssl.org> I will start the OMC vote using the text as previously proposed. Matt On 18/06/2020 03:20, Tim Hudson wrote: > Given that this change impacts interoperability in a major way it should > be a policy vote of the OMC IMHO. > > Tim. > > > On Thu, 18 Jun 2020, 5:57 am Kurt Roeckx, > wrote: > > On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote: > > PR 10787 proposed to reduce the number of security bits for MD5 > and SHA1 > > in TLS (master branch only, i.e. OpenSSL 3.0): > > > > https://github.com/openssl/openssl/pull/10787 > > > > This would have the impact of meaning that TLS < 1.2 would not be > > available in the default security level of 1. You would have to > set the > > security level to 0. > > > > In my mind this feels like the right thing to do. The security bit > > calculations should reflect reality, and if that means that TLS < > 1.2 no > > longer meets the policy for security level 1, then that is just the > > security level doing its job. However this *is* a significant breaking > > change and worthy of discussion. Since OpenSSL 3.0 is a major > release it > > seems that now is the right time to make such changes. > > > > IMO it seems appropriate to have an OMC vote on this topic (or > should it > > be OTC?). Possible wording: > > So should that be an OMC or OTC vote, or does it not need a vote? > > > Kurt > From matt at openssl.org Thu Jun 18 10:36:52 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 18 Jun 2020 11:36:52 +0100 Subject: Naming conventions Message-ID: PRs #11996 and #11997 made some changes to the EVP_MAC and EVP_KDF API naming conventions. Specifically (in the MAC case) renaming: EVP_MAC_CTX_new -> EVP_MAC_new_ctx EVP_MAC_CTX_free -> EVP_MAC_free_ctx EVP_MAC_CTX_dup -> EVP_MAC_dup_ctx EVP_MAC_CTX_mac -> EVP_MAC_get_ctx_mac EVP_MAC_CTX_get_params -> EVP_MAC_get_ctx_params EVP_MAC_CTX_set_params -> EVP_MAC_set_ctx_params There are similar renamings for the KDF APIs. I am opposed to this renaming on the basis that it is inconsistent with what we do elsewhere. For example, except for the MAC/KDF APIs I see there are 26 functions of the form: FOO_CTX_new The case is similar for FOO_CTX_free. Aside from the newly introduced MAC/KDF names there are no other instances of FOO_new_ctx or FOO_free_ctx. This is totally inconsistent and, IMO, will cause significant confusion for our users. I will let others describe the rationale and arguments in favour of the change, because I wasn't involved in those discussions. I have proposed a PR to revert the changes (12186) which has an OTC hold on it pending the discussion that I hope to kick off in this thread. As I wrote in that PR: "If we want to change the naming conventions then we should do so only after agreeing what those conventions should be, and agreeing a strategy for how we are going to apply them. It should not be done piecemeal (and hidden away in a PR that supposedly made things more consistent but in reality did the opposite)." There *are* inconsistencies and quirks in our current naming conventions. I am skeptical that now is the time to resolve them given the number of other changes we are already introducing into 3.0. I'm also skeptical about introducing changes to well established APIs that have been used for many years out of some purist sense of order. However, I'm willing to listen to the arguments on that. Thoughts please? Matt From levitte at openssl.org Thu Jun 18 12:03:42 2020 From: levitte at openssl.org (Richard Levitte) Date: Thu, 18 Jun 2020 14:03:42 +0200 Subject: Naming conventions In-Reply-To: References: Message-ID: <87tuz8mvhd.wl-levitte@openssl.org> On Thu, 18 Jun 2020 12:36:52 +0200, Matt Caswell wrote: > > EVP_MAC_CTX_new -> EVP_MAC_new_ctx > EVP_MAC_CTX_free -> EVP_MAC_free_ctx > EVP_MAC_CTX_dup -> EVP_MAC_dup_ctx > EVP_MAC_CTX_mac -> EVP_MAC_get_ctx_mac > EVP_MAC_CTX_get_params -> EVP_MAC_get_ctx_params > EVP_MAC_CTX_set_params -> EVP_MAC_set_ctx_params > > There are similar renamings for the KDF APIs. > > I am opposed to this renaming on the basis that it is inconsistent with > what we do elsewhere. Okie, if we're going to start this discussion with taking a stand, I guess I'll declare that while I initially had the exact same concern, I now see this change in a positive light. This comment from #11997 got me to change my mind: The already established patterns is a furphy. I'll reword it more precisely: we've done things badly in the past, thus we should do them badly moving forwards. We've always been at war with Eurasia.....oh wrong context, it's Eastasia. Ref: https://github.com/openssl/openssl/pull/11997#issuecomment-636658901 For historical background, changing the function name pattern isn't a new discussion, it's even been brought up on this list more than a year ago: https://mta.openssl.org/pipermail/openssl-project/2019-March/001280.html Unfortunately, those discussion never got much traction. I'm not at all surprised that #11996 and #11997 came to be, it follows a fairly human pattern that when talking leads nowhere and someone is still engaged enough, action will happen. When it comes to EVP_MAC and EVP_KDF, those sub-APIs already break with existing patterns, albeit more subtly. They have a _dup function, where previous sub-APIs have a _copy function. But that's perhaps small enough to be acceptable. > For example, except for the MAC/KDF APIs I see > there are 26 functions of the form: > > FOO_CTX_new > > The case is similar for FOO_CTX_free. Aside from the newly introduced > MAC/KDF names there are no other instances of FOO_new_ctx or > FOO_free_ctx. This is totally inconsistent and, IMO, will cause > significant confusion for our users. Sure, but it counters the confusion with when to use FOO and when to use FOO_CTX as a prefix. You and I seem to be pretty clear on this, but I've seen enough questions on the matter to see the benefit with this change, even though it breaks the old pattern. > "If we want to change the naming conventions then we should do so only > after agreeing what those conventions should be, and agreeing a strategy > for how we are going to apply them. It should not be done piecemeal (and > hidden away in a PR that supposedly made things more consistent but in > reality did the opposite)." I agree that it would have been good to discuss it further first. However, those discussion have been met with utter silence before, so that wasn't very fruitful. I guess that #11996 and #11997 was enough of a slap to wake us up. As for not doing something piecemeal, I actually disagree, I see benefit in more than just one person getting their hands dirty (plus changing everything in one go may be overwhelming, and would make for another huge PR that takes overly much time to get through). However, as strategies go, and if we agree on making the change, we could very well create an issue for each affected sub-API and have it point at a common page that describes what we agreed upon... this could be a good use of the github wiki tab, for example. > There *are* inconsistencies and quirks in our current naming > conventions. I am skeptical that now is the time to resolve them given > the number of other changes we are already introducing into 3.0. When do you see that time being, then? 3.1 (we've talked about it being a "cleanup" release)? 4.0? Each choice has its pros and cons: - Pros for 3.1: we get the added API variants out fairly early. - Cons for 3.1: because of ABI compatibility concerns, the old functions will have to be preserved as is and the new will have to be implemented as macros or new functions, making for a bigger libcrypto.num. - Pros for 4.0: ABI concerns aren't a factor, so the old functions can be renamed, and we can preserve the old names as macros. No need for double entries in libcrypto.num. - Cons for 4.0: Booooy that's far away, which means that we solidify the old pattern even more before remaking it. Side note: if we get through a rename fest, can we get rid of CamelCase? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu Jun 18 14:36:30 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 18 Jun 2020 15:36:30 +0100 Subject: Naming conventions In-Reply-To: <87tuz8mvhd.wl-levitte@openssl.org> References: <87tuz8mvhd.wl-levitte@openssl.org> Message-ID: On 18/06/2020 13:03, Richard Levitte wrote: > > Okie, if we're going to start this discussion with taking a stand, I > guess I'll declare that while I initially had the exact same concern, > I now see this change in a positive light. This comment from #11997 > got me to change my mind: > > The already established patterns is a furphy. I'll reword it more > precisely: we've done things badly in the past, thus we should do > them badly moving forwards. We've always been at war with > Eurasia.....oh wrong context, it's Eastasia. > While I can agree with the sentiment here I disagree with the conclusion that the answer is to change the APIs piecemeal to introduce even more quirkiness and inconsistency in the APIs. I'm also not convinced that the currently slightly strange inconsistencies are worth fixing. Yes, if we were to design it again we would do it differently. But that does not mean that we have to change everything to fit into our ideal picture of the way things should be. To fix it necessarily involves changing the names of a lot of different functions (how many depends on exactly what convention we eventually decided upon). Yes, we can lessen the impact by providing backwards compat macros - but that doesn't mean that a change of name is without cost. Either applications must change all of the names in their code to the new form OR they keep the old form and start using the new form for new code. This pushes the complexity of the name change onto our downstream application maintainers. They will have all the confusion of different naming conventions within their application. It adds further complexity to our documentation. Either we only document the new forms (which is confusing when application maintainers and authors see all the old forms being used "out there") - or we have to ensure all the synonyms are documented everywhere - which is itself confusing to our users. And our documentation will be at odds with all the examples and samples and unofficial documentation that our users undoubtedly use. I think a wholesale name change can only really be considered if it brings significant benefits. At the moment I'm struggling to see that the benefits outweigh the costs. Even if we decided that we would want to do this, we should also think twice about doing it in the 3.0 timeframe. We are already pushing a lot of change onto our users with the change to our architecture. Pushing more change for dubious benefit doesn't seem like a great idea. > As for not doing something piecemeal, I actually disagree, I see > benefit in more than just one person getting their hands dirty (plus > changing everything in one go may be overwhelming, and would make for > another huge PR that takes overly much time to get through). However, > as strategies go, and if we agree on making the change, we could very > well create an issue for each affected sub-API and have it point at a > common page that describes what we agreed upon... this could be a > good use of the github wiki tab, for example. I don't mean piecemeal in the sense of doing it spread over a number of PRs. I mean piecemeal in the sense of doing it spread over a number of releases. As far as I can tell #11996 and #11997 were one offs without any long term strategy in mind to convert the whole API in this way. In the absence of a strategy we shouldn't be making one off changes like this. >> There *are* inconsistencies and quirks in our current naming >> conventions. I am skeptical that now is the time to resolve them given >> the number of other changes we are already introducing into 3.0. > > When do you see that time being, then? 3.1 (we've talked about it > being a "cleanup" release)? 4.0? Perhaps never. But if we do it then either 3.1 or 4.0 could be considered. I am yet to be convinced that its worth it. Matt From tjh at cryptsoft.com Thu Jun 18 15:48:29 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 19 Jun 2020 01:48:29 +1000 Subject: Naming conventions In-Reply-To: References: <87tuz8mvhd.wl-levitte@openssl.org> Message-ID: We have a convention that we mostly follow. Adding new stuff with variations in the convention offers no benefit without also adjusting the rest of the API. Inconsistencies really do not assist any developer. Where APIs have been added that don't follow the conventions they should be changed. It really is that simple - each developer may have a different set of personal preferences and if we simply allow any two people to pick their own API pattern effectively at whim we end up with a real mess over time. This example is a clear cut case where we should fix the unnecessary variation in the pattern. It serves no benefit whatsoever to have such a mix of API patterns. We do have some variations that we should adjust - and for APIs that have been in official releases dropping in backwards compatibility macros is appropriate. The argument that we aren't completely consistent is specious - it is saying because we have a few mistakes that have slipped through the cracks we have open season on API patterns. It also would not hurt to have an automated check of API deviations on commits to catch such things in future. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Jun 18 16:58:56 2020 From: levitte at openssl.org (Richard Levitte) Date: Thu, 18 Jun 2020 18:58:56 +0200 Subject: Naming conventions In-Reply-To: References: <87tuz8mvhd.wl-levitte@openssl.org> Message-ID: <87r1ucmhtb.wl-levitte@openssl.org> On Thu, 18 Jun 2020 16:36:30 +0200, Matt Caswell wrote: > On 18/06/2020 13:03, Richard Levitte wrote: > > As for not doing something piecemeal, I actually disagree, I see > > benefit in more than just one person getting their hands dirty (plus > > changing everything in one go may be overwhelming, and would make for > > another huge PR that takes overly much time to get through). However, > > as strategies go, and if we agree on making the change, we could very > > well create an issue for each affected sub-API and have it point at a > > common page that describes what we agreed upon... this could be a > > good use of the github wiki tab, for example. > > I don't mean piecemeal in the sense of doing it spread over a number of > PRs. I mean piecemeal in the sense of doing it spread over a number of > releases. As far as I can tell #11996 and #11997 were one offs without > any long term strategy in mind to convert the whole API in this way. Ah, ok. I agree with you there, if we're doing this, we should do it consistently for the same release. > > When do you see that time being, then? 3.1 (we've talked about it > > being a "cleanup" release)? 4.0? > > Perhaps never. But if we do it then either 3.1 or 4.0 could be > considered. I am yet to be convinced that its worth it. I actually have a different idea, but that's much more further in the future: a consistent libcrypto API across the board, where all libcrypto functions are in the "namespaces" (i.e. are prefixed with) OSSL or OPENSSL. No exception. That idea would be a fairly complete API remake, and I do think it would be worth the while. So uhm, "never" isn't a line of thinking that I'm ready to accept. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tmraz at redhat.com Fri Jun 19 07:15:22 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 19 Jun 2020 09:15:22 +0200 Subject: Naming conventions In-Reply-To: References: <87tuz8mvhd.wl-levitte@openssl.org> Message-ID: On Fri, 2020-06-19 at 01:48 +1000, Tim Hudson wrote: > We have a convention that we mostly follow. Adding new stuff with > variations in the convention offers no benefit without also adjusting > the rest of the API. Inconsistencies really do not assist any > developer. > > Where APIs have been added that don't follow the conventions they > should be changed. > > It really is that simple - each developer may have a different set of > personal preferences and if we simply allow any two people to pick > their own API pattern effectively at whim we end up with a real mess > over time. > > This example is a clear cut case where we should fix the unnecessary > variation in the pattern. It serves no benefit whatsoever to have > such a mix of API patterns. > > We do have some variations that we should adjust - and for APIs that > have been in official releases dropping in backwards compatibility > macros is appropriate. > > The argument that we aren't completely consistent is specious - it is > saying because we have a few mistakes that have slipped through the > cracks we have open season on API patterns. > > It also would not hurt to have an automated check of API deviations > on commits to catch such things in future. The problem is that there is not really fully consistent convention followed currently (even in 1.1.1, not counting the API additions in 3.0). For example if we would like to follow the convention _fully_ we would have to rename these new EVP_MAC functions: int EVP_MAC_init(EVP_MAC_CTX *ctx); int EVP_MAC_update(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); int EVP_MAC_final(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); to something like: int EVP_MacInit(EVP_MAC_CTX *ctx); int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); or at least int EVP_MACInit(EVP_MAC_CTX *ctx); int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); Should we do that? I hope for the sheer ugliness of the supposedly consistent names that we do not. Fortunately or unfortunately depending on personal opinons we have already diverged from that pattern with EVP_PKEY API. And I actually hope we could add at least non-CamelCase aliases to the existing (non-deprecated) CamelCase functions because they were always the worst offender of the API consistency. -- 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 Fri Jun 19 09:17:05 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 19 Jun 2020 11:17:05 +0200 Subject: Naming conventions In-Reply-To: References: <87tuz8mvhd.wl-levitte@openssl.org> Message-ID: <875zbnmn3i.wl-levitte@openssl.org> On Fri, 19 Jun 2020 09:15:22 +0200, Tomas Mraz wrote: > The problem is that there is not really fully consistent convention > followed currently (even in 1.1.1, not counting the API additions in > 3.0). > > For example if we would like to follow the convention _fully_ we would > have to rename these new EVP_MAC functions: > > int EVP_MAC_init(EVP_MAC_CTX *ctx); > > int EVP_MAC_update(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); > > int EVP_MAC_final(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); > > to something like: > > int EVP_MacInit(EVP_MAC_CTX *ctx); > > int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); > > int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); > > or at least > > int EVP_MACInit(EVP_MAC_CTX *ctx); > > int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); > > int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); Someone's walking memory lane ;-) I had to look back at OpenSSL_0_9_1c to remind myself, 'cause today, we're quite mixed up, what with the slightly lower level functions EVP_PKEY_sign_init, EVP_PKEY_sign, etc etc etc... I would say, thought, that if you want to do the higher level function thing (which are all CamelCase as far as I can see), there's another naming convention going on, at least with EVP_PKEY, it seems to be done according to the higher level operation you want to perform, not the type of data used to do it... what do you normally to with a MAC? So: int EVP_AuthenticateInit(EVP_MAC_CTX *ctx); int EVP_AUthenticateUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen); int EVP_AUthenticateFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t outsize); ... or something like that. Quite frankly, a naming convention that is about the operation rather than the type of any type is something I could play along with. > And I actually hope we could add at least non-CamelCase aliases to the > existing (non-deprecated) CamelCase functions because they were always > the worst offender of the API consistency. I agree with you... but we have to recognise that would be a bigger remake, and if we do look at just the CamelCase API, it's actually fairly consistent (turning a blind eye at DigestSign quirkiness when I say that). (I suppose that CamelCase was inspired by the time, it was quite popular in certain circles in the 90's, and got especially popularised by Microsoft... and well, there are quite a few Microsoft ideas that have infiltrated OpenSSL... need I mention '_ex'?) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Fri Jun 19 20:39:57 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 19 Jun 2020 22:39:57 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> Message-ID: <20200619203957.GA498222@roeckx.be> So we currently also have PR #12201 that adds a new constant time P-384 implementation. Do you think we should backport that to the 1.1.1 branch? If the answer is different than for the assembler, why? Does 1.1.1 being an LTS release have any effect on the answer? For instance, if we add some assembler during the 3.1 development, and 3.0 is not an LTS release, but 1.1.1 is, and is still supported, do we backport it to 1.1.1 and not 3.0? We've at least talked about not adding a feature to the stable branch. At least one way of looking at that is that we don't add new functionality. You could argue that new assembler is not a new feature, just a new implementation of an existing feature. Kurt From kurt at roeckx.be Fri Jun 19 20:42:03 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 19 Jun 2020 22:42:03 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> Message-ID: <20200619204203.GB498222@roeckx.be> I think one other thing that has come up is adding support for a new target, which can just be some small change to configuration files. Is that something we want to accept? Kurt From matt at openssl.org Fri Jun 19 21:29:24 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 19 Jun 2020 22:29:24 +0100 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <20200619204203.GB498222@roeckx.be> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> Message-ID: <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> On 19/06/2020 21:42, Kurt Roeckx wrote: > I think one other thing that has come up is adding support for a > new target, which can just be some small change to configuration > files. Is that something we want to accept? I think previously we have said that a new target is a new feature and therefore haven't allowed it. But even this I think is a grey area. If a target could be added simply by adding some lines to Configure, probably the risk to our existing users is very low. OTOH, if adding a platform means adding lots of ifdef hackery throughout the codebase then the risk of something going wrong is significantly higher. > So we currently also have PR #12201 that adds a new constant time > P-384 implementation. Do you think we should backport that to the > 1.1.1 branch? If the answer is different than for the assembler, > why? My immediate reaction to that is no - it shouldn't go to 1.1.1. That would impact a very high proportion of our user base. Matt From kurt at roeckx.be Fri Jun 19 21:58:28 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 19 Jun 2020 23:58:28 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> Message-ID: <20200619215828.GA501508@roeckx.be> On Fri, Jun 19, 2020 at 10:29:24PM +0100, Matt Caswell wrote: > > My immediate reaction to that is no - it shouldn't go to 1.1.1. That > would impact a very high proportion of our user base. So is risk an important factor? How do you judge the risk? By the size of the change? Kurt From tjh at cryptsoft.com Fri Jun 19 22:11:16 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 20 Jun 2020 08:11:16 +1000 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <20200619215828.GA501508@roeckx.be> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> Message-ID: The general concept is to only fix serious bugs in stable releases. Increasing performance is not fixing a bug - it is a feature. Swapping out one implementation of algorithm for another is a significant change and isn't something that should go into an LTS in my view. It would be less of an issue for users if our release cadence was more frequent - but the principal applies - stability is what an LTS is aimed at. We should be fixing significant bugs only. Arguing that slower performance is a bug is specious - it works - and performance is not something that we document and guarantee. You don't find our release notes stating performance=X for a release - because such a statement makes little sense for the vast majority of users. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Fri Jun 19 22:13:56 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 19 Jun 2020 15:13:56 -0700 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> Message-ID: <20200619221356.GY11992@kduck.mit.edu> On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > The general concept is to only fix serious bugs in stable releases. > Increasing performance is not fixing a bug - it is a feature. Is remediating a significant performance regression fixing a bug? -Ben From tjh at cryptsoft.com Fri Jun 19 22:34:33 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 20 Jun 2020 08:34:33 +1000 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <20200619221356.GY11992@kduck.mit.edu> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> Message-ID: On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, wrote: > On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > > The general concept is to only fix serious bugs in stable releases. > > Increasing performance is not fixing a bug - it is a feature. > > Is remediating a significant performance regression fixing a bug? > It would be a bug - but not a serious bug. So no. It works. It was released. Wholesale replacement of implementations of algorithms should not be happening in LTS releases. We make no performance guarantees or statements in our releases (in general). And performance isn't an issue for the vast majority of our users. Those for whom performance is critical also tend to be building their own releases in my experience. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 19 22:46:15 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 19 Jun 2020 23:46:15 +0100 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> Message-ID: On 19/06/2020 23:34, Tim Hudson wrote: > > > On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, > wrote: > > On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > > The general concept is to only fix serious bugs in stable releases. > > Increasing performance is not fixing a bug - it is a feature. > > Is remediating a significant performance regression fixing a bug? > > > It would be a bug - but not a serious bug. So no. > It works. It was released. I don't recall us ever saying that we would only fix serious bugs. AFAIK, if its a bug then we will fix it. IMO a serious performance regression would qualify, within reason (e.g. major rewrites of the assembler would not be ok). > Wholesale replacement of implementations of algorithms should not be > happening in LTS releases. This I agree with. Matt From matt at openssl.org Fri Jun 19 22:47:47 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 19 Jun 2020 23:47:47 +0100 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <20200619215828.GA501508@roeckx.be> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> Message-ID: <3e2f78ab-eab0-9fcc-ccc3-0c79e7405e52@openssl.org> On 19/06/2020 22:58, Kurt Roeckx wrote: > On Fri, Jun 19, 2020 at 10:29:24PM +0100, Matt Caswell wrote: >> >> My immediate reaction to that is no - it shouldn't go to 1.1.1. That >> would impact a very high proportion of our user base. > > So is risk an important factor? How do you judge the risk? By the > size of the change? Yes, I do believe risk is an important factor although putting hard rules around it is very difficult. There are bound to be some fuzzy lines here between what is and isn't acceptable. Matt From kaduk at mit.edu Fri Jun 19 22:52:57 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 19 Jun 2020 15:52:57 -0700 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> Message-ID: <20200619225257.GZ11992@kduck.mit.edu> On Fri, Jun 19, 2020 at 11:46:15PM +0100, Matt Caswell wrote: > > > On 19/06/2020 23:34, Tim Hudson wrote: > > > > > > On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, > > wrote: > > > > On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > > > The general concept is to only fix serious bugs in stable releases. > > > Increasing performance is not fixing a bug - it is a feature. > > > > Is remediating a significant performance regression fixing a bug? > > > > > > It would be a bug - but not a serious bug. So no. > > It works. It was released. > > I don't recall us ever saying that we would only fix serious bugs. > AFAIK, if its a bug then we will fix it. IMO a serious performance > regression would qualify, within reason (e.g. major rewrites of the > assembler would not be ok). > > > Wholesale replacement of implementations of algorithms should not be > > happening in LTS releases. > > This I agree with. Both of Matt's paragraphs match up with my understanding/sentiment. -Ben From tjh at cryptsoft.com Sat Jun 20 00:11:04 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Sat, 20 Jun 2020 10:11:04 +1000 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <20200619225257.GZ11992@kduck.mit.edu> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> <20200619225257.GZ11992@kduck.mit.edu> Message-ID: I suggest everyone takes a read through https://en.wikipedia.org/wiki/Long-term_support as to what LTS is actually meant to be focused on. What you (Ben and Matt) are both describing is not LTS but STS ... these are different concepts. For LTS the focus is *stability *and *reduced risk of disruption *which alters the judgement on what is appropriate to put into a release. It then becomes a test of "is this bug fix worth the risk" with the general focus on lowest possible risk which stops this sort of thing happening unless a critical feature is broken. All of the "edge case" examples presented all involve substantial changes to implementations and carry an inherent risk of breaking something else - and that is the issue. It would be different if we had a full regression test suite across all the platforms and variations on platforms that our users are operating on - but we don't. We don't compare performance between releases or for any updates in our test suite so it isn't part of our scope for release readiness - if this is such a critical thing that must be fixed then it is something that we should be measuring and checking as a release condition - but we don't - because it actually isn't that critical. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Sun Jun 21 21:34:32 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Sun, 21 Jun 2020 14:34:32 -0700 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> <20200619225257.GZ11992@kduck.mit.edu> Message-ID: <20200621213432.GA11992@kduck.mit.edu> Hi Tim, On Sat, Jun 20, 2020 at 10:11:04AM +1000, Tim Hudson wrote: > I suggest everyone takes a read through > https://en.wikipedia.org/wiki/Long-term_support as to what LTS is actually > meant to be focused on. You may have hit on a key aspect of how we are disconnected, here. I was under the impression that (as is the case for many OSS projects), the fact that 1.1.1 is an LTS release means that we enter a separate "LTS mode" at the "beginning of a long-term support period" (as Wikipedia puts it) but that there is some period prior to the start of the long-term support period for which the STS policies apply. So, are you considering that 1.1.1 is now, and has always been, in LTS mode because it is marked as an "LTS release"? Or is there a separate STS period before it transitions to "LTS mode"? > What you (Ben and Matt) are both describing is not LTS but STS ... these > are different concepts. AFAICT the thread started with just talk of merging to stable release branches; LTS didn't come up until Kurt's note. I certainly was not considering the LTS policy in my earlier comments. > For LTS the focus is *stability *and *reduced risk of disruption *which > alters the judgement on what is appropriate to put into a release. > It then becomes a test of "is this bug fix worth the risk" with the general > focus on lowest possible risk which stops this sort of thing happening > unless a critical feature is broken. > > All of the "edge case" examples presented all involve substantial changes > to implementations and carry an inherent risk of breaking something else - > and that is the issue. IMO, if we're in LTS mode, if any of the proposed edge cases came up that would indicate that we failed at the LTS policy in the first place. > It would be different if we had a full regression test suite across all the > platforms and variations on platforms that our users are operating on - but > we don't. > > We don't compare performance between releases or for any updates in our > test suite so it isn't part of our scope for release readiness - if this is > such a critical thing that must be fixed then it is something that we > should be measuring and checking as a release condition - but we don't - > because it actually isn't that critical. It can translate to real monetary impact in some cases (e.g., at scale). But I can't directly refute your point, it is true. -Ben From tmraz at redhat.com Mon Jun 22 06:11:12 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 22 Jun 2020 08:11:12 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <20200621213432.GA11992@kduck.mit.edu> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> <20200619225257.GZ11992@kduck.mit.edu> <20200621213432.GA11992@kduck.mit.edu> Message-ID: <613fa463d8582ed24b4bb39b75a1f40b1351399d.camel@redhat.com> On Sun, 2020-06-21 at 14:34 -0700, Benjamin Kaduk wrote: > Hi Tim, > > On Sat, Jun 20, 2020 at 10:11:04AM +1000, Tim Hudson wrote: > > I suggest everyone takes a read through > > https://en.wikipedia.org/wiki/Long-term_support as to what LTS is > > actually > > meant to be focused on. > > You may have hit on a key aspect of how we are disconnected, here. > > I was under the impression that (as is the case for many OSS > projects), the > fact that 1.1.1 is an LTS release means that we enter a separate "LTS > mode" > at the "beginning of a long-term support period" (as Wikipedia puts > it) but > that there is some period prior to the start of the long-term support > period for which the STS policies apply. > > So, are you considering that 1.1.1 is now, and has always been, in > LTS mode > because it is marked as an "LTS release"? Or is there a separate STS > period before it transitions to "LTS mode"? In my opinion the 1.1.1 should not enter such strongly restricted phase earlier than after the 3.0 is released. Ideally, if we had releases based on some predictable cadence and not rather feature based ones, we should have 3 active branches - master for development of new features, one branch with bug fixes and even non-invasive performance fixes, and one branch for LTS where only security fixes with above than low severity and severe bug fixes would be applied. -- 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 Jun 22 08:37:32 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 22 Jun 2020 09:37:32 +0100 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> <20200619225257.GZ11992@kduck.mit.edu> Message-ID: <7bd05840-68bf-4601-3331-2634378df798@openssl.org> On 20/06/2020 01:11, Tim Hudson wrote: > I suggest?everyone takes a read through? > https://en.wikipedia.org/wiki/Long-term_support?as to what LTS is > actually meant to be focused on. > > What you (Ben and Matt) are both describing is not LTS but STS ... these > are different concepts. > > For LTS the focus is *stability?*and *reduced risk of disruption?*which > alters the judgement on what is appropriate to put into a release. > It then becomes a test of "is this bug fix worth the risk" with the > general focus on lowest possible risk which stops this sort of thing > happening unless a critical feature is broken. > > All of the "edge case" examples presented all involve substantial > changes to implementations and carry an inherent risk of breaking > something else - and that is the issue. > It would be different if we had a full regression?test suite across all > the platforms and variations on platforms that our users are operating > on - but we don't. > > We don't compare performance between releases or for any updates in our > test suite so it isn't part of our scope for release readiness - if this > is such a critical thing that must be fixed then it is something that we > should be measuring and checking as a release condition - but we don't - > because it actually isn't that critical.? > I read the page and I don't think it is contrary to anything that I said. From the characteristics section: "At the beginning of a long-term support period, the software developers impose a feature freeze: They make patches to correct software bugs and vulnerabilities, but do not introduce new features that may cause regression. The software maintainer either distributes patches individually, or packages them in maintenance releases, point releases, or service packs. At the conclusion of the support period, the product either reaches end-of-life, or receives a reduced level of support for a period of time (e.g., high-priority security patches only).[2]" AFAIK this is exactly what we do. We fix bugs and don't add new features. After 4 years we transition to security fixes only. Later, in the Rational section, it says this: "Long-term support addresses this by assuring users and administrators that the software will be maintained for a specific period of time, and that updates selected for publication will carry a significantly reduced risk of regression.[2] The maintainers of LTS software only publish updates that either have low IT risk or that reduce IT risk (such as security patches). Patches for LTS software are published with the understanding that installing them is less risky than not installing them." This, IMO, is exactly what we do. In none of this does it say that we shouldn't fix less serious bugs or performance regressions. It talks about risk - but that does not preclude those kinds of fixes. In fact as I said in my answer to Kurt earlier in this thread I do believe that risk is an important factor in deciding what things get backported. However I don't believe that, generally speaking, most minor bug fixes represent a significant source of risk. I also think the same *might* be true of *some* types of performance regressions. Matt From rsalz at akamai.com Sat Jun 20 16:20:36 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 20 Jun 2020 16:20:36 +0000 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> <20200619225257.GZ11992@kduck.mit.edu> Message-ID: * I suggest everyone takes a read through https://en.wikipedia.org/wiki/Long-term_support as to what LTS is actually meant to be focused on. For what it?s worth, I think Tim?s comments are spot-on. An LTS release should not change unless there are serious bugs or new security flaws. It is tempting to add new hardware support, nor improved performance. ?Hey, everyone will get this in their long-term offering.? But you?re thinking the wrong way. Imagine that each new patch to an LTS release requires massive effort, such as changing the firmware on a plane. Does the change justify that? Almost always, the answer is no. -------------- next part -------------- An HTML attachment was scrubbed... URL: From psteuer9 at gmail.com Mon Jun 22 10:28:25 2020 From: psteuer9 at gmail.com (Patrick Steuer) Date: Mon, 22 Jun 2020 12:28:25 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <613fa463d8582ed24b4bb39b75a1f40b1351399d.camel@redhat.com> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <20200619204203.GB498222@roeckx.be> <4368f400-16c2-46c2-aa75-f104357e7dd1@openssl.org> <20200619215828.GA501508@roeckx.be> <20200619221356.GY11992@kduck.mit.edu> <20200619225257.GZ11992@kduck.mit.edu> <20200621213432.GA11992@kduck.mit.edu> <613fa463d8582ed24b4bb39b75a1f40b1351399d.camel@redhat.com> Message-ID: From the view of an application dev .. 1 the reasons to chose OpenSSL over other crypto libraries are its rich feature set and wide portability paired with good performance across a wide range of platforms plus having a customizable backend (engines/providers). 2 the reasons to not move away from OpenSSL trusting in LTS releases actually being stable i.e., not causing any disruptions. (For both 1 and 2, a good security record is a matter of course.) IMO the current release policy of infrequent "big bang" releases serves 2 well, but largely neglects 1 (think e.g., about time-to-market for new processor features). That doesnt mean that we should take all features into LTS but i think performance improvements is an area where you should think about it, at least in individual cases. Patrick From openssl at openssl.org Thu Jun 25 14:26:01 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 Jun 2020 14:26:01 +0000 Subject: OpenSSL version 3.0.0-alpha4 published Message-ID: <20200625142601.GA29824@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 4 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 4 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-alpha4.tar.gz Size: 13884897 SHA1 checksum: 056194ea4ec57234ce3cb16b944d99c4d2a8b650 SHA256 checksum: d930b650e0899f5baca8b80c50e7401620c129fef6c50198400999776a39bd37 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha4.tar.gz openssl sha256 openssl-3.0.0-alpha4.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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl70rYcACgkQ2cTSbQ5g RJFWeAf/ZOGaHZbcAUy9Xm/R8x56qPJWD+3D8qGOgjNgKc/5r3kXII3I7NH7lc1j zFSt/FA9NhqU7dIh/8/SlyZaBbFW/XZBRiczDqRSqAkAfsxhlj5tOq8xZoXuTqlN it3DICC96jgh2xGo3LJUPgY1o0evsPLX98L/BtRZcZMcZed0ImZEEmJra3vEDr7H C+Hu4/+gNDlAISDENSDygAE8vDB5hBDmk0YCySPKZpDbWPdV2/WF8oBlgRpNBjY+ zbk/V32xZkhf/x/nhRGNs44CJI8ymsDtp6UyV2e7ZW6LZNMGX7l0M8ZuJvLTFJJM ZqQo7Xhn1EFdIRwTd+B2CvY2k73Pzw== =khAk -----END PGP SIGNATURE----- From nic.tuv at gmail.com Thu Jun 25 14:33:35 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 25 Jun 2020 16:33:35 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> Message-ID: In light of how the discussion evolved I would say that not only there is consensus on supporting the definition of a detailed policy on backports and the definitions of what are the requirements for regular releases vs LTS releases (other than the longer support timeframe), but also highlights a need to do it sooner rather than later! This seems a job for the OMC, as it falls under: > makes all decisions regarding management and strategic direction of the project; including: > - business requirements; > - feature requirements; > - platform requirements; > - roadmap requirements and priority; > - end-of-life decisions; > - release timing and requirement decisions; My contribution to the discussion is to ask if the OMC has plans for addressing this in the very short term. If working on a policy is going to be a medium-term effort, maybe it would be opportune to call an OTC vote specific to #11968 under the current release requirements defined by the OMC (or lack thereof). We already saw a few comments in favor of evaluating backporting #11968 as an exception, in light of the supporting arguments, even if it was in conflict with the current policy understanding or the upcoming policy formulation. So if we could swiftly agree on this being an OTC or OMC vote, I would urge to have a dedicated discussion/vote specific to #11968, while more detailed policies and definitions are in the process of being formulated. - What is the consensus on splitting the 2 discussions? - If splitting the discussions, is deciding on #11968 an OTC or OMC matter? Cheers, Nicola From Matthias.St.Pierre at ncp-e.com Thu Jun 25 14:49:47 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 25 Jun 2020 14:49:47 +0000 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> Message-ID: <57e047d32ad24446b7e06f2d4f8517a9@Ex13.ncp.local> Since already a few backporting requests to 1.1.1 have accumulated which are controversial or not allowed for an LTS release, would it make sense to consider creating a new 1.1.2 STS branch which could then receive such changes? Matthias From tmraz at redhat.com Thu Jun 25 14:56:40 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 25 Jun 2020 16:56:40 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: <57e047d32ad24446b7e06f2d4f8517a9@Ex13.ncp.local> References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> <57e047d32ad24446b7e06f2d4f8517a9@Ex13.ncp.local> Message-ID: <84862d5737e84832dcb9debe4081bcb8d24651df.camel@redhat.com> On Thu, 2020-06-25 at 14:49 +0000, Dr. Matthias St. Pierre wrote: > Since already a few backporting requests to 1.1.1 have accumulated > which are controversial > or not allowed for an LTS release, would it make sense to consider > creating a new 1.1.2 STS > branch which could then receive such changes? In my opinion that would open a can of worms. Such branch would inevitably mean there will be request for the 1.1.2 release and I do not think it would be a good idea to have it. It would seriously stretch the team resources IMHO. It would be much better to have the rules not tightened for 1.1.1 right now (i.e. still allow for example the performance improvements and support for newer hardware) and tighten them only after the 3.0 release is final. Still, I do not think allowing any truly new features other than the performance and HW support on 1.1.1 is worth it. -- 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 Jun 25 15:54:13 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 25 Jun 2020 16:54:13 +0100 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> Message-ID: On 25/06/2020 15:33, Nicola Tuveri wrote: > In light of how the discussion evolved I would say that not only there > is consensus on supporting the definition of a detailed policy on > backports and the definitions of what are the requirements for regular > releases vs LTS releases (other than the longer support timeframe), > but also highlights a need to do it sooner rather than later! > > This seems a job for the OMC, as it falls under: > >> makes all decisions regarding management and strategic direction of the project; including: >> - business requirements; >> - feature requirements; >> - platform requirements; >> - roadmap requirements and priority; >> - end-of-life decisions; >> - release timing and requirement decisions; > > My contribution to the discussion is to ask if the OMC has plans for > addressing this in the very short term. I think its unlikely we are going to get to a policy in the short term. It seems to me we are still some way away from a consensus here. > If working on a policy is going to be a medium-term effort, maybe it > would be opportune to call an OTC vote specific to #11968 under the > current release requirements defined by the OMC (or lack thereof). 11968 is already merged and, AFAIK, no one has proposed reverting it. If such a PR was raised then a vote might be a way forward for it. 11188 is the more pressing problem because that is currently unmerged and stuck. That has an OTC hold on it (placed there by me), so an OTC vote seems appropriate. If a vote is held it should be to decide whether backporting it is consistent with our current understanding of the policy such as it is. It is for the OMC to decide whether a different policy should be introduced at some point in the future. Matt > > We already saw a few comments in favor of evaluating backporting > #11968 as an exception, in light of the supporting arguments, even if > it was in conflict with the current policy understanding or the > upcoming policy formulation. > So if we could swiftly agree on this being an OTC or OMC vote, I would > urge to have a dedicated discussion/vote specific to #11968, while > more detailed policies and definitions are in the process of being > formulated. > > - What is the consensus on splitting the 2 discussions? > - If splitting the discussions, is deciding on #11968 an OTC or OMC matter? > > > > Cheers, > > Nicola > From nic.tuv at gmail.com Thu Jun 25 16:26:43 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 25 Jun 2020 18:26:43 +0200 Subject: Backports to 1.1.1 and what is allowed In-Reply-To: References: <17776a7e-eed5-8926-8340-5ca8c9058272@openssl.org> Message-ID: Sorry yes, I meant to refer to the open PR with the s390 support, I picked the wrong number! On Thu, Jun 25, 2020, 17:54 Matt Caswell wrote: > > > On 25/06/2020 15:33, Nicola Tuveri wrote: > > In light of how the discussion evolved I would say that not only there > > is consensus on supporting the definition of a detailed policy on > > backports and the definitions of what are the requirements for regular > > releases vs LTS releases (other than the longer support timeframe), > > but also highlights a need to do it sooner rather than later! > > > > This seems a job for the OMC, as it falls under: > > > >> makes all decisions regarding management and strategic direction of the > project; including: > >> - business requirements; > >> - feature requirements; > >> - platform requirements; > >> - roadmap requirements and priority; > >> - end-of-life decisions; > >> - release timing and requirement decisions; > > > > My contribution to the discussion is to ask if the OMC has plans for > > addressing this in the very short term. > > I think its unlikely we are going to get to a policy in the short term. > It seems to me we are still some way away from a consensus here. > > > If working on a policy is going to be a medium-term effort, maybe it > > would be opportune to call an OTC vote specific to #11968 under the > > current release requirements defined by the OMC (or lack thereof). > > 11968 is already merged and, AFAIK, no one has proposed reverting it. If > such a PR was raised then a vote might be a way forward for it. > > 11188 is the more pressing problem because that is currently unmerged > and stuck. That has an OTC hold on it (placed there by me), so an OTC > vote seems appropriate. If a vote is held it should be to decide whether > backporting it is consistent with our current understanding of the > policy such as it is. It is for the OMC to decide whether a different > policy should be introduced at some point in the future. > > Matt > > > > > > We already saw a few comments in favor of evaluating backporting > > #11968 as an exception, in light of the supporting arguments, even if > > it was in conflict with the current policy understanding or the > > upcoming policy formulation. > > So if we could swiftly agree on this being an OTC or OMC vote, I would > > urge to have a dedicated discussion/vote specific to #11968, while > > more detailed policies and definitions are in the process of being > > formulated. > > > > - What is the consensus on splitting the 2 discussions? > > - If splitting the discussions, is deciding on #11968 an OTC or OMC > matter? > > > > > > > > Cheers, > > > > Nicola > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Fri Jun 26 06:00:45 2020 From: mark at openssl.org (Mark J Cox) Date: Fri, 26 Jun 2020 07:00:45 +0100 Subject: OMC Vote: Change some words by accepting PR#12089 Message-ID: topic: Change some words by accepting PR#12089 Proposed by Mark Cox Public: yes opened: 2020-06-25 From mhkelley2017 at gmail.com Thu Jun 25 16:28:21 2020 From: mhkelley2017 at gmail.com (mhkelley2017 at gmail.com) Date: Thu, 25 Jun 2020 10:28:21 -0600 Subject: Error building OpenSSL-1.1.1g Message-ID: <01f901d64b0d$a4d35660$ee7a0320$@gmail.com> Error: 'ml64' is not recognized as an internal or external command, operable program or batch file. Platform: Windows 10 Intended context for use: Mingw-64, Qt 5.15 Building with Visual Studio 2019 Community Perl: ActivePerl 5.24.3 Build_2404 (64-bit) Configuration commands: perl Configure VC-WIN64A-masm --prefix=%PREFIX% Error output: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "." /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix- seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"OPENSSL_USE_APPLINK" -D"NDEBUG" /Zs /showIncludes "crypto\aes\aes_wrap.c" 2>&1 > crypto\aes\aes_wrap.d set ASM=ml64 "C:\Perl64\bin\perl.exe" "crypto\aes\asm\aesni-mb-x86_64.pl" masm crypto\aes\aesni-mb-x86_64.asm ml64 /c /Cp /Cx /nologo /Zi /Focrypto\aes\aesni-mb-x86_64.obj "crypto\aes\aesni-mb-x86_64.asm" 'ml64' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml64' : return code '0x1' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"' : return code '0x2' Stop. Initial build output: Configuring OpenSSL version 1.1.1g (0x1010107fL) for VC-WIN64A-masm Using os-specific seed configuration Creating configdata.pm Creating makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g>nmake Microsoft (R) Program Maintenance Utility Version 14.26.28806.0 Copyright (C) Microsoft Corporation. All rights reserved. "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "include\crypto\bn_conf.h.in" > include\crypto\bn_conf.h "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "include\crypto\dso_conf.h.in" > include\crypto\dso_conf.h "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "include\openssl\opensslconf.h.in" > include\openssl\opensslconf.h "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" / depend && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" / _all Microsoft (R) Program Maintenance Utility Version 14.26.28806.0 Copyright (C) Microsoft Corporation. All rights reserved. Microsoft (R) Program Maintenance Utility Version 14.26.28806.0 Copyright (C) Microsoft Corporation. All rights reserved. cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "." /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix- seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"OPENSSL_USE_APPLINK" -D"NDEBUG" -c /Foapps\app_rand.obj "apps\app_rand.c" app_rand.c *** lots of similar output before fatal error -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Jun 30 05:49:19 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 30 Jun 2020 07:49:19 +0200 Subject: Naming conventions In-Reply-To: References: Message-ID: <87pn9hhzmo.wl-levitte@openssl.org> This discussion seems to have gone stale. As far as I can read the thread, there are three lines of thought at play (in no special order): - the API put forth in #11996 and #11997 - the API exemplified with EVP_MAC and EVP_KDF before #11996 and #11997 - the API exemplified by functions in CamelCase I'm uncertain if we mean to say that only new EVP features (sometimes called sub-APIs) should be affected by whatever we decide, or if we should make appropriate aliases for older EVP features as well (one might argue that the CamelCase functions pave a way that avoids such aliases). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Jun 30 12:09:13 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 30 Jun 2020 13:09:13 +0100 Subject: New blog post Message-ID: <12e46e44-047a-8ce7-b1a3-098a2087115c@openssl.org> I've just published a new blog post by Nicola on the alpha 4 release. You can read it here: https://www.openssl.org/blog/blog/2020/06/25/OpenSSL3.0Alpha4/ Thanks Nicola! Matt From mark at openssl.org Tue Jun 30 22:59:00 2020 From: mark at openssl.org (Mark J Cox) Date: Tue, 30 Jun 2020 23:59:00 +0100 Subject: Stale PR stats @Jul 2020 Message-ID: During June I updated the stale PR script to start to ping reporters where issues were in the "changes requested" state. I corrected some issues that were incorrectly in this state where changes had been supplied. I also got the script to close the issues still "waiting for CLA" that had had no response for several months of automated reminders. Finally, there were a few issues in "waiting for review" state that were given reviews or otherwise updated. PRs that have not had any updates in the last 30 days and are not WIP: all ( 132 issues, median 248 days) of which: failed CI ( 22 issues, median 183 days) deferred after 1.1.1 ( 46 issues) cla required ( 0 issues) waiting for reporter ( 8 issues, median 255 days) waiting for review ( 0 issues) waiting for OMC ( 1 issue) waiting for OTC ( 4 issues, median 44 days) all other ( 51 issues, median 239 days) So, ignoring deferred issues too you could summarise this as: Stale PRs waiting for us to do something: 27 (last months: 36, 27, 29) Stale PRs waiting for the reporter to do something: 8 (last months: 34, 34, 37) Stale PRs with unclear next action: 51 (last months: 48, 46, 42) Total Stale PRs: 86 (last months: 118, 107, 108) There really shouldn't be anything "waiting for OMC/OTC/review" that is over 30 days; many of these did get a decision and the state just isn't updated. Over time I hope we can triage the "all other" PRs with labels so we know what the next action is on each one. Details: waiting for reporter: 10590 reviewed:changes_requested days:175 10063 branch: master, reviewed:changes_requested days:35 9461 reviewed:changes_requested days:335 9427 reviewed:changes_requested days:342 8962 reviewed:changes_requested days:104 8706 branch: master, reviewed:changes_requested days:36 7961 reviewed:changes_requested days:540 7432 reviewed:changes_requested days:619 waiting for OMC: 10195 branch: master, hold: need omc decision, reviewed:commented days:232 waiting for OTC: 11757 hold: cla required, hold: need otc decision, days:48 8916 approval: review pending, branch: 1.1.1, branch: master, hold: need otc decision, reviewed:changes_requested days:41 8300 approval: otc review pending, branch: 1.1.1, branch: master, hold: need otc decision, reviewed:review pending days:144 8024 approval: otc review pending, branch: master, reviewed:commented days:33 all other: 11779 cla: trivial, days:48 11744 days:62 11712 branch: master, reviewed:commented days:57 11679 days:116 11481 branch: 1.1.1, branch: master, days:81 11421 days:70 11398 approval: done, branch: master, reviewed:approved days:95 11359 days:75 11341 days:73 11312 days:107 11260 reviewed:commented days:115 11248 reviewed:commented days:33 11116 days:77 11115 days:116 11082 branch: master, days:67 11057 days:140 10884 days:162 10818 days:168 10570 reviewed:commented days:184 10541 days:199 10338 reviewed:commented days:239 10320 branch: 1.1.1, branch: master, reviewed:commented days:230 10298 days:243 10268 days:245 9655 days:217 9554 days:326 9421 branch: 1.1.1, branch: master, reviewed:approved days:181 9223 branch: master, reviewed:commented days:143 9206 days:374 9051 reviewed:commented days:237 8956 days:396 8920 days:273 8908 days:411 8862 days:390 8835 days:430 8743 branch: master, days:441 8668 days:452 8455 days:454 8420 days:455 8333 days:490 8309 branch: master, reviewed:commented days:376 7688 days:576 7615 days:580 7454 reviewed:commented days:531 7274 reviewed:approved days:382 7225 reviewed:commented days:647 6518 milestone:Assessed, reviewed:approved days:741 6448 milestone:Assessed, days:248 6219 milestone:Assessed, reviewed:approved days:779 4487 milestone:Assessed, days:718 4486 milestone:Assessed, days:718