From mark at openssl.org Wed Apr 1 09:01:46 2020 From: mark at openssl.org (Mark J Cox) Date: Wed, 1 Apr 2020 10:01:46 +0100 Subject: Stale PR stats @Apr01 In-Reply-To: <1585699695.181394.1105.nullmailer@dev.openssl.org> References: <1585699695.181394.1105.nullmailer@dev.openssl.org> Message-ID: Earlier this month 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 ( 153 issues, median 158 days) of which: failed CI ( 21 issues, median 158 days) deferred after 1.1.1 ( 45 issues, median 158 days) cla required ( 24 issues, median 325.0 days) waiting for reporter ( 13 issues, median 252 days) waiting for review ( 3 issues, median 44 days) waiting for OMC ( 3 issues, median 142 days) waiting for OTC ( 2 issues, median 43.5 days) all other ( 42 issues, median 289.0 days) So, ignoring deferred issues too you could summarise this as: Stale PRs waiting for us to do something: 29 (27%) Stale PRs waiting for the reporter to do something: 37 (34%) Stale PRs with unclear next action: 42 (39%) Over time I hope we can triage the "all other" PRs with labels so we know what the next action is on each one. Detail: failed CI ( 21 issues, median 158 days) 11151 days:30 11136 reviewed:commented days:36 11116 days:42 10626 days:36 10556 days:117 10465 days:134 10344 branch: master, days:149 9926 days:196 9603 days:196 9155 reviewed:commented days:70 8955 branch: 1.1.1, branch: master, reviewed:dismissed days:145 8687 reviewed:commented days:180 8389 days:385 8024 reviewed:commented days:51 7921 reviewed:commented days:389 7914 reviewed:approved days:448 7380 reviewed:commented days:536 7051 milestone:Assessed, reviewed:commented days:585 6074 milestone:Assessed, reviewed:commented days:628 4992 milestone:Assessed, reviewed:commented days:158 4486 milestone:Assessed, days:628 waiting for reporter ( 13 issues, median 252 days) 10724 reviewed:changes_requested days:76 10590 reviewed:changes_requested days:85 9575 reviewed:changes_requested days:232 9461 reviewed:changes_requested days:245 9427 reviewed:changes_requested days:252 9243 reviewed:changes_requested days:254 9240 reviewed:changes_requested days:279 8992 reviewed:changes_requested days:196 8730 reviewed:changes_requested days:293 8674 reviewed:changes_requested days:348 7961 reviewed:changes_requested days:450 7432 reviewed:changes_requested days:529 2986 milestone:Assessed, reviewed:changes_requested days:158 waiting for review ( 3 issues, median 44 days) 10563 approval: review pending, branch: 1.1.1, branch: master, reviewed:approved days:44 10063 approval: review pending, reviewed:approved days:32 8916 approval: review pending, branch: 1.1.1, branch: master, reviewed:approved days:125 waiting for OMC ( 3 issues, median 142 days) 10195 branch: master, hold: need omc decision, reviewed:commented days:142 7285 hold: need omc decision, reviewed:changes_requested days:35 5909 hold: need omc decision, milestone:Assessed, reviewed:changes_requested days:643 waiting for OTC ( 2 issues, median 43.5 days) 9654 approval: otc review pending, branch: master, triaged: feature, reviewed:changes_requested days:33 8300 approval: otc review pending, branch: 1.1.1, branch: master, hold: need otc decision, reviewed:approved days:54 all other ( 42 issues, median 289.0 days) 11154 days:36 11057 days:50 10884 days:72 10818 days:78 10570 reviewed:commented days:94 10541 days:109 10338 reviewed:commented days:149 10320 branch: 1.1.1, branch: master, reviewed:commented days:140 10298 days:153 10268 days:155 10037 days:117 9655 days:127 9554 days:236 9421 branch: 1.1.1, branch: master, reviewed:approved days:91 9223 branch: master, reviewed:commented days:53 9206 days:284 9051 reviewed:commented days:147 8956 days:306 8920 days:183 8908 days:321 8862 days:300 8835 days:340 8743 branch: master, days:351 8668 days:362 8455 days:364 8420 days:365 8333 days:400 8309 branch: master, reviewed:commented days:286 7688 days:486 7615 days:490 7485 branch: 1.1.1, branch: master, reviewed:commented days:516 7454 reviewed:commented days:441 7274 reviewed:approved days:292 7225 reviewed:commented days:557 6725 milestone:Assessed, reviewed:approved days:300 6518 milestone:Assessed, reviewed:approved days:651 6516 branch: 1.1.1, branch: master, milestone:Assessed, days:651 6448 milestone:Assessed, days:158 6219 milestone:Assessed, reviewed:approved days:689 5860 branch: 1.1.1, branch: master, milestone:Assessed, reviewed:commented days:222 5427 branch: master, milestone:Assessed, reviewed:commented days:451 4487 milestone:Assessed, days:628 From matt at openssl.org Fri Apr 3 11:43:54 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Apr 2020 12:43:54 +0100 Subject: Monthly Status Report (March) Message-ID: <1e6cdfd1-edb5-3da5-b1c9-18e3cd9fe624@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Ongoing reviews of the CMP contribution - Clarified the docs around usage of EVP_PKEY_get_raw_*_key() - Provided some tweaks/fixes to the Serializer code - Completed implementation of Ed25519 and Ed448 in the default provider - Implemented serializers for Ed25519 and Ed448 - Performed and coordinated the release of both 1.1.1e and 1.1.1f - Fix to handle the case where there is no digest in an EVP_MD_CTX - Significant effort in getting a simple TLSv1.2 connection working with FIPS only crypto - Created PR to make various updates to provider.pod - Made it possible to easily specify a libctx from EVP_DigestSign* - Made sure we were using the correct libctx when fetching a MAC in one scenario - Ensured we were using RAND_bytes_ex in various calls in crypto/rsa - Ensured we were using fetched ciphers/digests for TLS tickets - Fixed a number of spots in libssl where we weren't using the libctx - Fixed EVP_PKEY_new_mac_key() so that it doesn't fail if the specified MAC is not available in the default provider - Wrote code to update libssl to use EVP_MAC for its MAC rather than EVP_DigestSign*(). This work is currently on hold due to an unexpected impact on the GOST engine - Fixed more spots in libssl where fetched ciphers were not being used - Update to provide better diagnostics in the event of a fetch failure - Updated test TLS framework to provide better error information if a connection fails - Added libctx aware functions OCSP_RESPID_set_by_key_ex() and OCSP_RESPID_match_ex() - Added function to explicitly cache X509v3 extensions with a libctx - and used that function in libssl - Made the SRP library libctx aware, and updated libssl to use the new functions - Updated libssl to give a better error if we can't find a sig alg - Fixed a bug in libssl to avoid attempting to up-ref a cipher that is NULL - Fixed a bug to avoid double freeing a DH object in libssl Matt From matt at openssl.org Wed Apr 8 22:41:58 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Apr 2020 23:41:58 +0100 Subject: OpenSSL 3.0 and FIPS talk Message-ID: <4da076b3-7d62-7a7c-5b1c-3904b12c0b36@openssl.org> I recently gave a talk at the RSA Conference with Ashit Vora from Acumen Security about OpenSSL 3.0 and FIPS. The conference have just posted the audio and slides here if you are interested: https://www.rsaconference.com/usa/agenda/openssl-and-fips-they-are-back-together Matt From levitte at openssl.org Fri Apr 10 18:28:18 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 10 Apr 2020 20:28:18 +0200 Subject: Revisiting tradition: branches and tags Message-ID: <874ktrfb5p.wl-levitte@openssl.org> Once upon a time, there was CVS (*). The story could stop there, but since CVS was what was available, OpenSSL was versioned with CVS. Among limitations that came with CVS was the allowed syntax in tag and branch names; letters, digits, dashes and underscores. At the time, eveyone that wanted to encode a version number in a tag had to convert periods to some other character. We chose underscores, ending up with tags like this: OpenSSL_0_9_7-beta2 OpenSSL_0_9_7a Furthermore, the culture that we have with git, where branches are being pulled between repositories... where you can actually have a multitude of repositories and pull data between them, was very hard if not practically impossible with CVS. So, we occasionally had feature branches for longer term work. To distinguish our so called stable branches, we had branch names with '-stable' added at the end: OpenSSL_0_9_7-stable We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but I guess that was too easy to mix up with our letter releases. With git, however, there's no technical reason why we must maintain what was originally a technical limitation. I therefore propose that we start using tags like this starting with OpenSSL 3.0: openssl-3.0.0-alpha1 openssl-3.0.0-beta2 openssl-3.0.0 openssl-3.0.1 openssl-3.1.0 This is a little more than just avoiding to change the periods with underscores. However, if you look at the tar files we've released for a long time, that's the naming format they use, and I can see benefits in having the tags for a release match the tar file of the same release: openssl-0.9.7a.tar.gz openssl-0.9.7a.tar.gz.asc openssl-0.9.7a.tar.gz.md5 Future tar files would be numbered with the new version scheme, of course: openssl-3.0.0-alpha1.tar.gz openssl-3.0.0-beta2.tar.gz openssl-3.0.0.tar.gz openssl-3.0.1.tar.gz openssl-3.1.0.tar.gz So what about release branches? We could actually follow a very similar new pattern, just replace the last digit with, say, an 'x', to signify that this branch will contain a series of patch releases: openssl-3.0.x In this branch, one would expect to see the tags 'openssl-3.0.0', 'openssl-3.0.1', 'openssl-3.0.2', ... Earlier today, I submitted a new release script that codifies exactly this: https://github.com/openssl/openssl/pull/11516 Thoughts? Cheers, Richard (*) Well, not quite, there was RCS, there was SCCS, and a few other versioning systems that would make your skin crawl by today's standards, even more so than CVS. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Sat Apr 11 09:53:32 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 11 Apr 2020 09:53:32 +0000 Subject: Revisiting tradition: branches and tags In-Reply-To: <874ktrfb5p.wl-levitte@openssl.org> References: <874ktrfb5p.wl-levitte@openssl.org> Message-ID: I love the new naming scheme, in particular the fact that it's all-lowercase and does not mix dashes and underscores anymore. I don't recall how often I cursed about the current scheme which is so typer unfriendly. I'd like to see *all* stable branch names and release tags converted to new-style uniformly (keeping the old names for compatibility), so we have an overall consistent scheme and people don't need to switch back and forth between naming conventions in the future when doing historical investigations. The old names could be deprecated for later removal. Matthias > -----Original Message----- > From: openssl-project On Behalf Of Richard Levitte > Sent: Friday, April 10, 2020 8:28 PM > To: openssl-project at openssl.org > Subject: Revisiting tradition: branches and tags > > Once upon a time, there was CVS (*). > > The story could stop there, but since CVS was what was available, > OpenSSL was versioned with CVS. > > Among limitations that came with CVS was the allowed syntax in tag and > branch names; letters, digits, dashes and underscores. At the time, > eveyone that wanted to encode a version number in a tag had to convert > periods to some other character. We chose underscores, ending up with > tags like this: > > OpenSSL_0_9_7-beta2 > OpenSSL_0_9_7a > > Furthermore, the culture that we have with git, where branches are > being pulled between repositories... where you can actually have a > multitude of repositories and pull data between them, was very hard if > not practically impossible with CVS. So, we occasionally had feature > branches for longer term work. To distinguish our so called stable > branches, we had branch names with '-stable' added at the end: > > OpenSSL_0_9_7-stable > > We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but > I guess that was too easy to mix up with our letter releases. > > With git, however, there's no technical reason why we must maintain > what was originally a technical limitation. I therefore propose that > we start using tags like this starting with OpenSSL 3.0: > > openssl-3.0.0-alpha1 > openssl-3.0.0-beta2 > openssl-3.0.0 > openssl-3.0.1 > openssl-3.1.0 > > This is a little more than just avoiding to change the periods with > underscores. However, if you look at the tar files we've released for > a long time, that's the naming format they use, and I can see benefits > in having the tags for a release match the tar file of the same > release: > > openssl-0.9.7a.tar.gz > openssl-0.9.7a.tar.gz.asc > openssl-0.9.7a.tar.gz.md5 > > Future tar files would be numbered with the new version scheme, of > course: > > openssl-3.0.0-alpha1.tar.gz > openssl-3.0.0-beta2.tar.gz > openssl-3.0.0.tar.gz > openssl-3.0.1.tar.gz > openssl-3.1.0.tar.gz > > So what about release branches? We could actually follow a very > similar new pattern, just replace the last digit with, say, an 'x', to > signify that this branch will contain a series of patch releases: > > openssl-3.0.x > > In this branch, one would expect to see the tags 'openssl-3.0.0', > 'openssl-3.0.1', 'openssl-3.0.2', ... > > Earlier today, I submitted a new release script that codifies exactly > this: https://github.com/openssl/openssl/pull/11516 > > Thoughts? > > Cheers, > Richard > > (*) Well, not quite, there was RCS, there was SCCS, and a few other > versioning systems that would make your skin crawl by today's > standards, even more so than CVS. > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Apr 13 08:48:35 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Apr 2020 09:48:35 +0100 Subject: Revisiting tradition: branches and tags In-Reply-To: References: <874ktrfb5p.wl-levitte@openssl.org> Message-ID: <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> On 11/04/2020 10:53, Dr. Matthias St. Pierre wrote: > I love the new naming scheme, in particular the fact that it's all-lowercase and does not > mix dashes and underscores anymore. I don't recall how often I cursed about the current > scheme which is so typer unfriendly. > > I'd like to see *all* stable branch names and release tags converted to new-style uniformly > (keeping the old names for compatibility), so we have an overall consistent scheme and people > don't need to switch back and forth between naming conventions in the future when doing > historical investigations. The old names could be deprecated for later removal. Yes - this aspect was my main hesitation about the proposed new format, i.e. the fact that we have a set of existing tags/branch names. Constantly changing between the new format and the old format as we look at older branches/tags could be painful. Just creating new tags for all the existing ones would be one way forward. Typing OpenSSL_1_1_1-stable and getting all the right upper/lower case characters in the right place and making sure to use _ vs - as appropriate is a challenge for my fingers which I constantly fail. Is it possible to set up alias names for the historical branches? Matt > > Matthias > > > >> -----Original Message----- >> From: openssl-project On Behalf Of Richard Levitte >> Sent: Friday, April 10, 2020 8:28 PM >> To: openssl-project at openssl.org >> Subject: Revisiting tradition: branches and tags >> >> Once upon a time, there was CVS (*). >> >> The story could stop there, but since CVS was what was available, >> OpenSSL was versioned with CVS. >> >> Among limitations that came with CVS was the allowed syntax in tag and >> branch names; letters, digits, dashes and underscores. At the time, >> eveyone that wanted to encode a version number in a tag had to convert >> periods to some other character. We chose underscores, ending up with >> tags like this: >> >> OpenSSL_0_9_7-beta2 >> OpenSSL_0_9_7a >> >> Furthermore, the culture that we have with git, where branches are >> being pulled between repositories... where you can actually have a >> multitude of repositories and pull data between them, was very hard if >> not practically impossible with CVS. So, we occasionally had feature >> branches for longer term work. To distinguish our so called stable >> branches, we had branch names with '-stable' added at the end: >> >> OpenSSL_0_9_7-stable >> >> We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but >> I guess that was too easy to mix up with our letter releases. >> >> With git, however, there's no technical reason why we must maintain >> what was originally a technical limitation. I therefore propose that >> we start using tags like this starting with OpenSSL 3.0: >> >> openssl-3.0.0-alpha1 >> openssl-3.0.0-beta2 >> openssl-3.0.0 >> openssl-3.0.1 >> openssl-3.1.0 >> >> This is a little more than just avoiding to change the periods with >> underscores. However, if you look at the tar files we've released for >> a long time, that's the naming format they use, and I can see benefits >> in having the tags for a release match the tar file of the same >> release: >> >> openssl-0.9.7a.tar.gz >> openssl-0.9.7a.tar.gz.asc >> openssl-0.9.7a.tar.gz.md5 >> >> Future tar files would be numbered with the new version scheme, of >> course: >> >> openssl-3.0.0-alpha1.tar.gz >> openssl-3.0.0-beta2.tar.gz >> openssl-3.0.0.tar.gz >> openssl-3.0.1.tar.gz >> openssl-3.1.0.tar.gz >> >> So what about release branches? We could actually follow a very >> similar new pattern, just replace the last digit with, say, an 'x', to >> signify that this branch will contain a series of patch releases: >> >> openssl-3.0.x >> >> In this branch, one would expect to see the tags 'openssl-3.0.0', >> 'openssl-3.0.1', 'openssl-3.0.2', ... >> >> Earlier today, I submitted a new release script that codifies exactly >> this: https://github.com/openssl/openssl/pull/11516 >> >> Thoughts? >> >> Cheers, >> Richard >> >> (*) Well, not quite, there was RCS, there was SCCS, and a few other >> versioning systems that would make your skin crawl by today's >> standards, even more so than CVS. >> >> -- >> Richard Levitte levitte at openssl.org >> OpenSSL Project http://www.openssl.org/~levitte/ > From Matthias.St.Pierre at ncp-e.com Mon Apr 13 11:12:33 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 13 Apr 2020 11:12:33 +0000 Subject: Revisiting tradition: branches and tags In-Reply-To: <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> References: <874ktrfb5p.wl-levitte@openssl.org> <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> Message-ID: > Is it possible to set up alias names for the historical branches? ... and tags, of course. All one needs to do is to write a little script which creates the additional references and pushes them. Matthias From levitte at openssl.org Mon Apr 13 17:09:07 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 13 Apr 2020 19:09:07 +0200 Subject: Revisiting tradition: branches and tags In-Reply-To: <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> References: <874ktrfb5p.wl-levitte@openssl.org> <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> Message-ID: <873697fh3g.wl-levitte@openssl.org> On Mon, 13 Apr 2020 10:48:35 +0200, Matt Caswell wrote: > On 11/04/2020 10:53, Dr. Matthias St. Pierre wrote: > > I love the new naming scheme, in particular the fact that it's all-lowercase and does not > > mix dashes and underscores anymore. I don't recall how often I cursed about the current > > scheme which is so typer unfriendly. > > > > I'd like to see *all* stable branch names and release tags converted to new-style uniformly > > (keeping the old names for compatibility), so we have an overall consistent scheme and people > > don't need to switch back and forth between naming conventions in the future when doing > > historical investigations. The old names could be deprecated for later removal. > > Yes - this aspect was my main hesitation about the proposed new format, > i.e. the fact that we have a set of existing tags/branch names. > Constantly changing between the new format and the old format as we look > at older branches/tags could be painful. Just creating new tags for all > the existing ones would be one way forward. New tags is perfectly possible to do. > Typing OpenSSL_1_1_1-stable and getting all the right upper/lower case > characters in the right place and making sure to use _ vs - as > appropriate is a challenge for my fingers which I constantly fail. I constantly fail the *current* names. > Is it possible to set up alias names for the historical branches? It's possible yes. The hard part is 1.1.1. There *is* something called 'git symbolic-ref', but they can only be added in repos we have physical access to, so while can add those on our git server, and they will work, we cannot add them in github. Ref git help symbolic-ref Cheers, Richard ( still thinks it's worth making the change with 3.0 ) > > Matt > > > > > > Matthias > > > > > > > >> -----Original Message----- > >> From: openssl-project On Behalf Of Richard Levitte > >> Sent: Friday, April 10, 2020 8:28 PM > >> To: openssl-project at openssl.org > >> Subject: Revisiting tradition: branches and tags > >> > >> Once upon a time, there was CVS (*). > >> > >> The story could stop there, but since CVS was what was available, > >> OpenSSL was versioned with CVS. > >> > >> Among limitations that came with CVS was the allowed syntax in tag and > >> branch names; letters, digits, dashes and underscores. At the time, > >> eveyone that wanted to encode a version number in a tag had to convert > >> periods to some other character. We chose underscores, ending up with > >> tags like this: > >> > >> OpenSSL_0_9_7-beta2 > >> OpenSSL_0_9_7a > >> > >> Furthermore, the culture that we have with git, where branches are > >> being pulled between repositories... where you can actually have a > >> multitude of repositories and pull data between them, was very hard if > >> not practically impossible with CVS. So, we occasionally had feature > >> branches for longer term work. To distinguish our so called stable > >> branches, we had branch names with '-stable' added at the end: > >> > >> OpenSSL_0_9_7-stable > >> > >> We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but > >> I guess that was too easy to mix up with our letter releases. > >> > >> With git, however, there's no technical reason why we must maintain > >> what was originally a technical limitation. I therefore propose that > >> we start using tags like this starting with OpenSSL 3.0: > >> > >> openssl-3.0.0-alpha1 > >> openssl-3.0.0-beta2 > >> openssl-3.0.0 > >> openssl-3.0.1 > >> openssl-3.1.0 > >> > >> This is a little more than just avoiding to change the periods with > >> underscores. However, if you look at the tar files we've released for > >> a long time, that's the naming format they use, and I can see benefits > >> in having the tags for a release match the tar file of the same > >> release: > >> > >> openssl-0.9.7a.tar.gz > >> openssl-0.9.7a.tar.gz.asc > >> openssl-0.9.7a.tar.gz.md5 > >> > >> Future tar files would be numbered with the new version scheme, of > >> course: > >> > >> openssl-3.0.0-alpha1.tar.gz > >> openssl-3.0.0-beta2.tar.gz > >> openssl-3.0.0.tar.gz > >> openssl-3.0.1.tar.gz > >> openssl-3.1.0.tar.gz > >> > >> So what about release branches? We could actually follow a very > >> similar new pattern, just replace the last digit with, say, an 'x', to > >> signify that this branch will contain a series of patch releases: > >> > >> openssl-3.0.x > >> > >> In this branch, one would expect to see the tags 'openssl-3.0.0', > >> 'openssl-3.0.1', 'openssl-3.0.2', ... > >> > >> Earlier today, I submitted a new release script that codifies exactly > >> this: https://github.com/openssl/openssl/pull/11516 > >> > >> Thoughts? > >> > >> Cheers, > >> Richard > >> > >> (*) Well, not quite, there was RCS, there was SCCS, and a few other > >> versioning systems that would make your skin crawl by today's > >> standards, even more so than CVS. > >> > >> -- > >> 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 Matthias.St.Pierre at ncp-e.com Tue Apr 14 07:28:26 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 14 Apr 2020 07:28:26 +0000 Subject: Revisiting tradition: branches and tags In-Reply-To: <873697fh3g.wl-levitte@openssl.org> References: <874ktrfb5p.wl-levitte@openssl.org> <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> <873697fh3g.wl-levitte@openssl.org> Message-ID: <0ec3ca786be04c30aaba66588d53d7ec@Ex13.ncp.local> > > Is it possible to set up alias names for the historical branches? > > It's possible yes. The hard part is 1.1.1. There *is* something > called 'git symbolic-ref', but they can only be added in repos we have > physical access to, so while can add those on our git server, and they > will work, we cannot add them in github. > > Ref git help symbolic-ref Symbolic references are *not* the right solution to the problem IMO. They are not equivalent to branches. Checking out a symbolic reference leaves you in the 'detached HEAD' state: msp at msppc:~/src/openssl$ git symbolic-ref ossl111 refs/heads/OpenSSL_1_1_1-stable msp at msppc:~/src/openssl$ cd ../openssl-1.1.1 msp at msppc:~/src/openssl-1.1.1$ git checkout ossl111 Note: switching to 'ossl111'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. The proper way to do it IMO is to create new branch and tag references for all the stable branches resp. release tags. We change the GitHub setup such that pull requests to stable branches need to be based onto the new-style branches, but keep the old-style stable branches in sync with the new-style branches for a little while. Currently, the only old-style branch which needs to be synchronized is ` OpenSSL_1_1_1-stable`. This could easily be done by the git post-receive hook on git.openssl.org. In fact, all old-style branch and tag references for all eol-branches could be removed immediately. Matthias From levitte at openssl.org Tue Apr 14 12:42:24 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 14 Apr 2020 14:42:24 +0200 Subject: Revisiting tradition: branches and tags In-Reply-To: <0ec3ca786be04c30aaba66588d53d7ec@Ex13.ncp.local> References: <874ktrfb5p.wl-levitte@openssl.org> <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> <873697fh3g.wl-levitte@openssl.org> <0ec3ca786be04c30aaba66588d53d7ec@Ex13.ncp.local> Message-ID: <87zhbedyrz.wl-levitte@openssl.org> On Tue, 14 Apr 2020 09:28:26 +0200, Dr. Matthias St. Pierre wrote: > > > > Is it possible to set up alias names for the historical branches? > > > > It's possible yes. The hard part is 1.1.1. There *is* something > > called 'git symbolic-ref', but they can only be added in repos we have > > physical access to, so while can add those on our git server, and they > > will work, we cannot add them in github. > > > > Ref git help symbolic-ref > > Symbolic references are *not* the right solution to the problem IMO. They are not equivalent to branches. > Checking out a symbolic reference leaves you in the 'detached HEAD' state: > > msp at msppc:~/src/openssl$ git symbolic-ref ossl111 refs/heads/OpenSSL_1_1_1-stable > msp at msppc:~/src/openssl$ cd ../openssl-1.1.1 > msp at msppc:~/src/openssl-1.1.1$ git checkout ossl111 > Note: switching to 'ossl111'. > > You are in 'detached HEAD' state. You can look around, make experimental > changes and commit them, and you can discard any commits you make in this > state without impacting any branches by switching back to a branch. Okie. I hadn't experimented with that, so didn't know. That manual is fantastically unclear on what this command does too, at least the way I read it. I guess that's another nail in its coffin. > The proper way to do it IMO is to create new branch and tag > references for all the stable branches resp. release tags. ... > Currently, the only old-style branch which needs to be synchronized > is `OpenSSL_1_1_1-stable`. This could easily be done by the git > post-receive hook on git.openssl.org. In fact, all old-style branch > and tag references for all eol-branches could be removed > immediately. Good point. The posst-update hook should be usable for this. > We change the GitHub setup such that pull requests to stable > branches need to be based onto the new-style branches, but keep the > old-style stable branches in sync with the new-style branches for a > little while. Er... how do you change that Github setup? I thought it simply showed a list of all available branches regardless. So if we got a duplicate set, it's going to show both, isn't it? Considering that the github repo is a --mirror of the git.openssl.org repo, I'm not sure how the old branch refs would be filtered out... It seems to me like this discussion is splitting into two: 1) Start with new names for 3.0 and on (I can only see positive responses so far, even with Matt's hesitance) 2) Rename of the old names. As far as I can see, those two don't have to be in absolute sync, even though that would be desirable. In other words, we can figure out the details of 2 even after we've started 1. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Apr 14 13:23:40 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Apr 2020 14:23:40 +0100 Subject: Forthcoming OpenSSL Release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1g. This release will be made available on Tuesday 21st April 2020 between 1300-1700 UTC. OpenSSL 1.1.g is a security-fix release. The highest severity issue fixed in this release is HIGH: https://www.openssl.org/policies/secpolicy.html#high Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6VuVwACgkQ2cTSbQ5g RJEGGwgAnvbo6LVTEz8PdAOoKPgHiz1ObbB8M/fNANk1Oog1w6CF7a8JPEuB/LlQ ZS0/31x+69xE+GzD4kPBglG6IVnt7F1mlXSc1YEh5c5zs2T5w5Gak5AIzJNZqEFK EmplFS8eZCpKJZc+0YKgMisF4Q+VbRjI+KVtYQKBn3sHRNH04z4Ti6jlS14R4pQd PCB4ftXS/LnISkrxL1uVf1seY+5SpmQjk3FR8ZgrR3vuYAyLcD7aeQNKf+unsS4W u8VnDmqONHa2JfHjsr5PezLZfWa3YTvK352gamyq5sn6y2ciTcI+fABeSD4OYjvQ I6t4kQrzfCdMrBNY8G2D5NYOi5cOKQ== =5CII -----END PGP SIGNATURE----- From Matthias.St.Pierre at ncp-e.com Tue Apr 14 14:04:43 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 14 Apr 2020 14:04:43 +0000 Subject: Revisiting tradition: branches and tags In-Reply-To: <87zhbedyrz.wl-levitte@openssl.org> References: <874ktrfb5p.wl-levitte@openssl.org> <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> <873697fh3g.wl-levitte@openssl.org> <0ec3ca786be04c30aaba66588d53d7ec@Ex13.ncp.local> <87zhbedyrz.wl-levitte@openssl.org> Message-ID: > > We change the GitHub setup such that pull requests to stable > > branches need to be based onto the new-style branches, but keep the > > old-style stable branches in sync with the new-style branches for a > > little while. > > Er... how do you change that Github setup? I thought it simply > showed a list of all available branches regardless. So if we got a > duplicate set, it's going to show both, isn't it? Considering that > the github repo is a --mirror of the git.openssl.org repo, I'm not > sure how the old branch refs would be filtered out... You are right, I thought it was possible using protected branches, but that doesn't seem to be the case. > > It seems to me like this discussion is splitting into two: > > 1) Start with new names for 3.0 and on (I can only see positive > responses so far, even with Matt's hesitance) > 2) Rename of the old names. > > As far as I can see, those two don't have to be in absolute sync, even > though that would be desirable. In other words, we can figure out the > details of 2 even after we've started 1. Agreed. The best thing would be to publicly announce the branch renaming in a blog post with a sufficient notice time (3-6 months) and with detailed instructions how to rename the local branches and how to reset the upstream branches (using `git branch --set-upstream-to=...`). Just as we did for the grand code reformatting. We might even provide a smart helper script for users to do the local conversion. Matthias From matt at openssl.org Tue Apr 21 09:23:18 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Apr 2020 10:23:18 +0100 Subject: Repo is frozen Message-ID: FYI, the repo is currently frozen in preparation for the release today. I'll let you know when its unfrozen again. Matt From matt at openssl.org Tue Apr 21 10:10:19 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Apr 2020 11:10:19 +0100 Subject: Alpha1 Message-ID: <83d11b4d-c914-ddb2-0a63-f42c0b8188f4@openssl.org> The 3.0 developers met via conference call this morning. All the functionality that we had planned for alpha 1 has now been merged, so we are now thinking that we will do the alpha 1 release on Thursday this week. That would imply a repo freeze tomorrow. Thoughts/opinions/objections to this proposal? Matt From openssl at openssl.org Tue Apr 21 13:16:08 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 21 Apr 2020 13:16:08 +0000 Subject: OpenSSL version 1.1.1g published Message-ID: <20200421131608.GA27174@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1g released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1g of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1g.tar.gz Size: 9801502 SHA1 checksum: b213a293f2127ec3e323fb3cfc0c9807664fd997 SHA256 checksum: ddb04774f1e32f0c49751e21b67216ac87852ceb056b75209af2443400636d46 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1g.tar.gz openssl sha256 openssl-1.1.1g.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e5ZUACgkQ2cTSbQ5g RJFGnQf8D8U0193cmqitZZ4L63ncx8aWPMdXMookxywTnhCHm7qyNGa0a41J0iZw pRebjlrjo1rEOMFo9rNmvtoBBUs/cFD8ARsItK3Kh2ms0z4MJV4F07XJHwNkd0Wf n18+oUS6Fj7Z8TgdA+UwBFuN248kqELDp8DYntLCzyEvkweU80JIRWhC+XawjcbA W/zlD6oVfNsgYP38hSCQg14B+/djMTVYqtDSOBm3B+J7zRndYoTvsankWlsMmDD5 Tb6lOQ8IBEsgnlriOH936eKhlJ5UeTr2hPONnzDJ/cIUWn1RwX9yPGOoaf74IoHc Hg/T6vP+pD3G3mDOS51Qm87A5+nDaQ== =eNCz -----END PGP SIGNATURE----- From openssl at openssl.org Tue Apr 21 13:25:24 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 21 Apr 2020 13:25:24 +0000 Subject: OpenSSL Security Advisory Message-ID: <20200421132524.GA5046@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [21 April 2020] ========================================= Segmentation fault in SSL_check_chain (CVE-2020-1967) ===================================================== Severity: High Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This issue did not affect OpenSSL versions prior to 1.1.1d. Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April 2020. It was found using the new static analysis pass being implemented in GCC, - -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin Kaduk. Note ===== This issue did not affect OpenSSL 1.0.2 however these versions are out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html This issue did not affect OpenSSL 1.1.0 however these versions are out of support and no longer receiving updates. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20200421.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt 2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ vj2rIjoJHRj0EXqXhHoABqBHedilJQ== =AXyP -----END PGP SIGNATURE----- From matt at openssl.org Tue Apr 21 13:40:18 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Apr 2020 14:40:18 +0100 Subject: Repo is frozen In-Reply-To: References: Message-ID: Repo is now unfrozen. I'm planning on freezing it again tomorrow, ready for the alpha1 release on Thursday. Matt On 21/04/2020 10:23, Matt Caswell wrote: > FYI, the repo is currently frozen in preparation for the release today. > I'll let you know when its unfrozen again. > > Matt > From kaduk at mit.edu Wed Apr 22 01:46:30 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 21 Apr 2020 18:46:30 -0700 Subject: Alpha1 In-Reply-To: <83d11b4d-c914-ddb2-0a63-f42c0b8188f4@openssl.org> References: <83d11b4d-c914-ddb2-0a63-f42c0b8188f4@openssl.org> Message-ID: <20200422014630.GW27494@kduck.mit.edu> On Tue, Apr 21, 2020 at 11:10:19AM +0100, Matt Caswell wrote: > The 3.0 developers met via conference call this morning. All the > functionality that we had planned for alpha 1 has now been merged, so we > are now thinking that we will do the alpha 1 release on Thursday this > week. That would imply a repo freeze tomorrow. > > Thoughts/opinions/objections to this proposal? Given that the list of required things for alpha 1 are done, it does seem appropriate. I know of a couple things that would be bug reports against an alpha1 if produced right now, but ... what is an alpha for, if not to trigger people to look and file bug reports? :) -Ben From matt at openssl.org Wed Apr 22 12:53:44 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Apr 2020 13:53:44 +0100 Subject: Alpha1 In-Reply-To: <20200422014630.GW27494@kduck.mit.edu> References: <83d11b4d-c914-ddb2-0a63-f42c0b8188f4@openssl.org> <20200422014630.GW27494@kduck.mit.edu> Message-ID: <3255225c-1939-ae61-82ec-fb9b00da428f@openssl.org> On 22/04/2020 02:46, Benjamin Kaduk wrote: > On Tue, Apr 21, 2020 at 11:10:19AM +0100, Matt Caswell wrote: >> The 3.0 developers met via conference call this morning. All the >> functionality that we had planned for alpha 1 has now been merged, so we >> are now thinking that we will do the alpha 1 release on Thursday this >> week. That would imply a repo freeze tomorrow. >> >> Thoughts/opinions/objections to this proposal? > > Given that the list of required things for alpha 1 are done, it does seem > appropriate. I know of a couple things that would be bug reports against > an alpha1 if produced right now, but ... what is an alpha for, if not to > trigger people to look and file bug reports? :) I've seen no objections and everyone seems to be assuming this is happening, so the repo is now frozen ready for the release tomorrow. Matt From matt at openssl.org Wed Apr 22 16:31:24 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Apr 2020 17:31:24 +0100 Subject: 3.0 wiki page Message-ID: <56359463-a2d1-81a6-3545-d839fd208f8c@openssl.org> The 3.0 wiki page is starting to look good: https://wiki.openssl.org/index.php/OpenSSL_3.0 I'd appreciate it if people could give it a read through before the alpha 1 release tomorrow and make any amendments or corrections as appropriate. Thanks! Matt From matt at openssl.org Thu Apr 23 12:51:21 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Apr 2020 13:51:21 +0100 Subject: 3.0 wiki page In-Reply-To: <56359463-a2d1-81a6-3545-d839fd208f8c@openssl.org> References: <56359463-a2d1-81a6-3545-d839fd208f8c@openssl.org> Message-ID: <2d591b67-ab69-c7b7-a871-cdae708448b6@openssl.org> Fantastic to see that 6 different authors have made contributions to this page! Matt On 22/04/2020 17:31, Matt Caswell wrote: > The 3.0 wiki page is starting to look good: > > https://wiki.openssl.org/index.php/OpenSSL_3.0 > > I'd appreciate it if people could give it a read through before the > alpha 1 release tomorrow and make any amendments or corrections as > appropriate. > > Thanks! > > Matt > From openssl at openssl.org Thu Apr 23 14:29:36 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 23 Apr 2020 14:29:36 +0000 Subject: OpenSSL version 3.0.0-alpha1 published Message-ID: <20200423142936.GA24450@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 1 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 1 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-alpha1.tar.gz Size: 9530120 SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 SHA256 checksum: 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha1.tar.gz openssl sha256 openssl-3.0.0-alpha1.tar.gz Please download and check this $LABEL 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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8 hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F hIr11rxXNxtBRKUSlOUyJATZn0sV6g== =uRpM -----END PGP SIGNATURE----- From matt at openssl.org Thu Apr 23 14:44:02 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Apr 2020 15:44:02 +0100 Subject: Alpha1 In-Reply-To: <3255225c-1939-ae61-82ec-fb9b00da428f@openssl.org> References: <83d11b4d-c914-ddb2-0a63-f42c0b8188f4@openssl.org> <20200422014630.GW27494@kduck.mit.edu> <3255225c-1939-ae61-82ec-fb9b00da428f@openssl.org> Message-ID: <431490a7-9d04-b29d-c492-312950021700@openssl.org> On 22/04/2020 13:53, Matt Caswell wrote: > > > On 22/04/2020 02:46, Benjamin Kaduk wrote: >> On Tue, Apr 21, 2020 at 11:10:19AM +0100, Matt Caswell wrote: >>> The 3.0 developers met via conference call this morning. All the >>> functionality that we had planned for alpha 1 has now been merged, so we >>> are now thinking that we will do the alpha 1 release on Thursday this >>> week. That would imply a repo freeze tomorrow. >>> >>> Thoughts/opinions/objections to this proposal? >> >> Given that the list of required things for alpha 1 are done, it does seem >> appropriate. I know of a couple things that would be bug reports against >> an alpha1 if produced right now, but ... what is an alpha for, if not to >> trigger people to look and file bug reports? :) > > I've seen no objections and everyone seems to be assuming this is > happening, so the repo is now frozen ready for the release tomorrow. The alpha1 release is now done!! Thanks to everyone that has helped to make this happen. We had a number of issues during the release itself - which is not surprising given this is the first of the 3.0 series - but nothing too significant. Thanks to Richard for helping out during the release. Matt From matt at openssl.org Wed Apr 29 12:08:44 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 Apr 2020 13:08:44 +0100 Subject: Cherry-pick proposal Message-ID: The OTC have received this proposal and a request that we vote on it: I would like to request that we do not allow cherry-picks between master and 1.1.1-stable because these two versions are now very different, if a cherry-pick succeeds, there is no guarantee that the result will work. Because we have no CI for the cherry-pick. If a cherry-pick is needed, a new PR for 1.1.1 should be done and approved independently. Before starting a vote I'd like to provide opportunity for comments, and also what the vote text should be. Thanks Matt From paul.dale at oracle.com Wed Apr 29 12:22:31 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 29 Apr 2020 22:22:31 +1000 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: <005D4623-1C57-4CAA-BD7A-9E5AE2EFD946@oracle.com> My concern is are 1.1.1 and 3.0 really all that different? The core is quite different but the cryptographic algorithms aren?t. CMS, x509, ?? I?d rather not introduce a burden where it isn?t necessary. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 29 Apr 2020, at 10:08 pm, Matt Caswell wrote: > > > The OTC have received this proposal and a request that we vote on it: > > I would like to request that we do not allow cherry-picks between master > and 1.1.1-stable because these two versions are now very different, if a > cherry-pick succeeds, there is no guarantee that the result will work. > Because we have no CI for the cherry-pick. If a cherry-pick is needed, a > new PR for 1.1.1 should be done and approved independently. > > Before starting a vote I'd like to provide opportunity for comments, and > also what the vote text should be. > > Thanks > > Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Wed Apr 29 13:04:57 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 29 Apr 2020 15:04:57 +0200 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: I can agree it is a good idea to always require backport as a separate PR, with the following conditions: - unless it's a 1.1.1 only issue, we MUST always wait to open the backport-to-111 PR until after the master PR has been approved and merged (to avoid splitting the discussions among different PRs, which make review and revisiting our history very hard) - trivial documentation changes, such as fixing typos, can be exempted It must be clear that although things have changed a lot in the inner plumbings, we have so far managed to keep crypto implementations very much in sync between 1.1.1 and master, by applying the policy of "first merge to master, then possibly backport". What I am afraid of in Bernd's proposal, and recent discussions, is that committers might be tempted to open PRs changing implementations against 1.1.1 first (to avoid frequent rebases due to unrelated changes) and let the `master` PR stagnate indefinitely because it feels like too much hassle to keep up with the development pace of master if your PR collaterally changes certain files. An example of what can go wrong if we open a 1.1.1 PR concurrently with a PR for master can be seen here: - `master` PR: https://github.com/openssl/openssl/pull/10828 - `1.1.1` PR: https://github.com/openssl/openssl/pull/11411 I highlight the following problems related to the above example: - as you can see the `1.1.1` has been merged, even though the `master` one has stalled while discussing which implementation we should pick. (this was my fault, I should have applied the `hold` label after stating that my approval for 1.1.1 was conditional to approving the `master` counterpart) - discussion that is integral part of the decision process was split among the 2 PRs, with over 40 comments each - there is no clear link between the `master` PR and the `1.1.1` PR for the same feature (this makes it very difficult to review what is the state of the "main" PR, and if we or someone else in some months or years needs to go check why we did things the way we did, will have a hard time connecting the dots) I also think that the proposal as written is a bit misleading: I would very like to keep seeing in 1.1.1 a majority of commits cherry-picked from commits merged to master, with explicit tags in the 1.1.1 commit messages (this helps keeping the git history self-contained without a too strong dependency on GitHub). I would rephrase the proposal as follows: Merge to 1.1.1 should only happen after approval of a dedicated PR targeting the OpenSSL_1_1_1-stable branch. Potential amendments that I'd like the OTC to consider are: a) before the end of the sentence add ", with the optional exclusion of trivial documentation-only changes" b) after the end of the sentence add "In composing backport pull requests, explicit cherry-picking (`git cherry-pick -x`) of relevant commits merged to `master` or another stable branch is recommended and encouraged whenever possible." c) adopt a more general statement: Merge to any stable branch should only happen after approval of a dedicated PR targeting specifically that branch. So, in summary, I would agree with the proposal, as I definitely think Bernd has a good point about running the 1.1.1 CI for things we think should be backported, but requires careful consideration of additional requirements to avoid duplicating review efforts, splitting discussions that should be kept together, or disrupting our processes making 1.1.1 and master diverge more than necessary. Cheers, Nicola On Wed, 29 Apr 2020 at 14:08, Matt Caswell wrote: > > The OTC have received this proposal and a request that we vote on it: > > I would like to request that we do not allow cherry-picks between master > and 1.1.1-stable because these two versions are now very different, if a > cherry-pick succeeds, there is no guarantee that the result will work. > Because we have no CI for the cherry-pick. If a cherry-pick is needed, a > new PR for 1.1.1 should be done and approved independently. > > Before starting a vote I'd like to provide opportunity for comments, and > also what the vote text should be. > > Thanks > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Wed Apr 29 13:12:27 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 29 Apr 2020 15:12:27 +0200 Subject: Cherry-pick proposal In-Reply-To: <005D4623-1C57-4CAA-BD7A-9E5AE2EFD946@oracle.com> References: <005D4623-1C57-4CAA-BD7A-9E5AE2EFD946@oracle.com> Message-ID: I think we changed enough things in the test infrastructure that there is a chance of creating subtle failures by merging cherry-picked commits from master directly. >From the burden perspective, from my point of view having a separate PR that ran all the CI without failures is actually a benefit: I can do some minimal testing on my machine before the final merge, instead of having to push a branch to my personal github fork to run travis and appveyor to test weird build options on platforms I don't have access to. If we stick to opening the PR for backporting only after master is completely approved, there shouldn't be too big a burden for the original reviewers either: we can use `fixup!` commits if trivial changes are required to clearly highlight what was changed compared to the original PR for master, and other than that it's just a matter of checking that nothing else changed from the originally approved changes. Approvals conditional to the CI passing can also help to further reduce the burden of the grace period for backport PRs. Nicola On Wed, 29 Apr 2020 at 14:24, Dr Paul Dale wrote: > My concern is are 1.1.1 and 3.0 really all that different? > The core is quite different but the cryptographic algorithms aren?t. CMS, > x509, ?? > > I?d rather not introduce a burden where it isn?t necessary. > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 29 Apr 2020, at 10:08 pm, Matt Caswell wrote: > > > The OTC have received this proposal and a request that we vote on it: > > I would like to request that we do not allow cherry-picks between master > and 1.1.1-stable because these two versions are now very different, if a > cherry-pick succeeds, there is no guarantee that the result will work. > Because we have no CI for the cherry-pick. If a cherry-pick is needed, a > new PR for 1.1.1 should be done and approved independently. > > Before starting a vote I'd like to provide opportunity for comments, and > also what the vote text should be. > > Thanks > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Apr 29 13:15:49 2020 From: levitte at openssl.org (Richard Levitte) Date: Wed, 29 Apr 2020 15:15:49 +0200 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: <87imhiqvp6.wl-levitte@openssl.org> I find the idea of *mandatory* separate PRs for master and 1.1.1 awful. There's still a lot of code that hasn't changed at all. CMS, BIO, ... We already have the policy that if we get a clean cherry-pick, we go with it, otherwise we make a separate PR. I've followed that guiding rule for a long time. As for always starting with master, I would say that it depends. If an issue has been identified in 1.1.1, I usually submit a PR against 1.1.1, because that's usually cleaner, i.e. the person making the issue can easily pick the fixing PR and try it out without having to wade through unrelated 3.0 things that may or may not work for them. Or to put it in harsher words, submitting a fix against master for an issue found in 1.1.1 is *user* *unfriendly*. With such a PR, I then cherry-pick to master if that's clean, or submit an up-port PR. Cheers, Richard On Wed, 29 Apr 2020 15:04:57 +0200, Nicola Tuveri wrote: > I can agree it is a good idea to always require backport as a separate PR, with the following > conditions: > - unless it's a 1.1.1 only issue, we MUST always wait to open the backport-to-111 PR until after > the master PR has been approved and merged (to avoid splitting the discussions among different > PRs, which make review and revisiting our history very hard) > - trivial documentation changes, such as fixing typos, can be exempted > > It must be clear that although things have changed a lot in the inner plumbings, we have so far > managed to keep crypto implementations very much in sync between 1.1.1 and master, by applying the > policy of "first merge to master, then possibly backport". > > What I am afraid of in Bernd's proposal, and recent discussions, is that committers might be > tempted to open PRs changing implementations against 1.1.1 first (to avoid frequent rebases due to > unrelated changes) and let the `master` PR stagnate indefinitely because it feels like too much > hassle to keep up with the development pace of master if your PR collaterally changes certain > files. > > An example of what can go wrong if we open a 1.1.1 PR concurrently with a PR for master can be > seen here: > - `master` PR:?https://github.com/openssl/openssl/pull/10828 > - `1.1.1` PR:?https://github.com/openssl/openssl/pull/11411 > > I highlight the following problems related to the above example: > - as you can see the `1.1.1` has been merged, even though the `master` one has stalled while > discussing which implementation we should pick. (this was my fault, I should have applied the > `hold` label after stating that my approval for 1.1.1 was conditional to approving the `master` > counterpart) > - discussion that is integral part of the decision process was split among the 2 PRs, with over 40 > comments each > - there is no clear link between the `master` PR and the `1.1.1` PR for the same feature (this > makes it very difficult to review what is the state of the "main" PR, and if we or someone else in > some months or years needs to go check why we did things the way we did, will have a hard time > connecting the dots) > > I also think that the proposal as written is a bit misleading: I would very like to keep seeing in > 1.1.1 a majority of commits cherry-picked from commits merged to master, with explicit tags in the > 1.1.1 commit messages (this helps keeping the git history self-contained without a too strong > dependency on GitHub). > I would rephrase the proposal as follows: > > ? ? Merge to 1.1.1 should only happen after approval of a dedicated PR targeting the > OpenSSL_1_1_1-stable branch. > > Potential amendments that I'd like the OTC to consider are: > a) before the end of the sentence add ", with the optional exclusion of trivial documentation-only > changes" > b) after the end of the sentence add "In composing backport pull requests, explicit cherry-picking > (`git cherry-pick -x`) of relevant commits merged to `master` or another stable branch is > recommended and encouraged whenever possible." > c) adopt a more general statement: > > ? ? Merge to any stable branch should only happen after approval of a dedicated PR targeting > specifically that branch. > > So, in summary, I would agree with the proposal, as I definitely think Bernd has a good point > about running the 1.1.1 CI for things we think should be backported, but requires careful > consideration of additional requirements to avoid duplicating review efforts, splitting > discussions that should be kept together, or disrupting our processes making 1.1.1 and master > diverge more than necessary. > > Cheers, > > Nicola > > On Wed, 29 Apr 2020 at 14:08, Matt Caswell wrote: > > The OTC have received this proposal and a request that we vote on it: > > I would like to request that we do not allow cherry-picks between master > and 1.1.1-stable because these two versions are now very different, if a > cherry-pick succeeds, there is no guarantee that the result will work. > Because we have no CI for the cherry-pick. If a cherry-pick is needed, a > new PR for 1.1.1 should be done and approved independently. > > Before starting a vote I'd like to provide opportunity for comments, and > also what the vote text should be. > > Thanks > > Matt > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Wed Apr 29 13:28:28 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 29 Apr 2020 13:28:28 +0000 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: I completely agree with Nicolas reasoning. But we should try to keep things simple and not add too many regulations. What do you think of the following formulation? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For change requests which target both the master and the OpenSSL_1_1_1-stable branch, the following procedure should be followed: - 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Matthias From: openssl-project On Behalf Of Nicola Tuveri Sent: Wednesday, April 29, 2020 3:05 PM To: openssl-project at openssl.org Subject: Re: Cherry-pick proposal I can agree it is a good idea to always require backport as a separate PR, with the following conditions: - unless it's a 1.1.1 only issue, we MUST always wait to open the backport-to-111 PR until after the master PR has been approved and merged (to avoid splitting the discussions among different PRs, which make review and revisiting our history very hard) - trivial documentation changes, such as fixing typos, can be exempted It must be clear that although things have changed a lot in the inner plumbings, we have so far managed to keep crypto implementations very much in sync between 1.1.1 and master, by applying the policy of "first merge to master, then possibly backport". What I am afraid of in Bernd's proposal, and recent discussions, is that committers might be tempted to open PRs changing implementations against 1.1.1 first (to avoid frequent rebases due to unrelated changes) and let the `master` PR stagnate indefinitely because it feels like too much hassle to keep up with the development pace of master if your PR collaterally changes certain files. An example of what can go wrong if we open a 1.1.1 PR concurrently with a PR for master can be seen here: - `master` PR: https://github.com/openssl/openssl/pull/10828 - `1.1.1` PR: https://github.com/openssl/openssl/pull/11411 I highlight the following problems related to the above example: - as you can see the `1.1.1` has been merged, even though the `master` one has stalled while discussing which implementation we should pick. (this was my fault, I should have applied the `hold` label after stating that my approval for 1.1.1 was conditional to approving the `master` counterpart) - discussion that is integral part of the decision process was split among the 2 PRs, with over 40 comments each - there is no clear link between the `master` PR and the `1.1.1` PR for the same feature (this makes it very difficult to review what is the state of the "main" PR, and if we or someone else in some months or years needs to go check why we did things the way we did, will have a hard time connecting the dots) I also think that the proposal as written is a bit misleading: I would very like to keep seeing in 1.1.1 a majority of commits cherry-picked from commits merged to master, with explicit tags in the 1.1.1 commit messages (this helps keeping the git history self-contained without a too strong dependency on GitHub). I would rephrase the proposal as follows: Merge to 1.1.1 should only happen after approval of a dedicated PR targeting the OpenSSL_1_1_1-stable branch. Potential amendments that I'd like the OTC to consider are: a) before the end of the sentence add ", with the optional exclusion of trivial documentation-only changes" b) after the end of the sentence add "In composing backport pull requests, explicit cherry-picking (`git cherry-pick -x`) of relevant commits merged to `master` or another stable branch is recommended and encouraged whenever possible." c) adopt a more general statement: Merge to any stable branch should only happen after approval of a dedicated PR targeting specifically that branch. So, in summary, I would agree with the proposal, as I definitely think Bernd has a good point about running the 1.1.1 CI for things we think should be backported, but requires careful consideration of additional requirements to avoid duplicating review efforts, splitting discussions that should be kept together, or disrupting our processes making 1.1.1 and master diverge more than necessary. Cheers, Nicola On Wed, 29 Apr 2020 at 14:08, Matt Caswell > wrote: The OTC have received this proposal and a request that we vote on it: I would like to request that we do not allow cherry-picks between master and 1.1.1-stable because these two versions are now very different, if a cherry-pick succeeds, there is no guarantee that the result will work. Because we have no CI for the cherry-pick. If a cherry-pick is needed, a new PR for 1.1.1 should be done and approved independently. Before starting a vote I'd like to provide opportunity for comments, and also what the vote text should be. Thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Wed Apr 29 13:49:44 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 29 Apr 2020 15:49:44 +0200 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: <9cb7a06a5fab6fbdf7cfccf76209a6b85b010780.camel@redhat.com> That we do not run CI explicitly before such cherry picks does not mean that there is no CI run at all. The CI is triggered when the cherry- picked commit is merged. If we were checking the status of the 1.1.1 branch CI runs periodically (with a bot sending e-mails about failures to openssl-project or another list perhaps?). We could then quickly fix it if cherry-pick introduced a regression. I also see only a single case where a cherry pick introduced regression on the 1.1.1 branch during the April. So I do not think we have a serious issue requiring the mandatory process change immediately. On the other hand I have no hard problems with the Matthias' proposal either. Also perhaps we should just make a recommendation on which kind of commits (although cherry-picking cleanly) should have a separate PR. For example commits touching crypto implementations and the EVP layer should have separate 1.1.1 PRs even though they cherry-pick cleanly. And of course there is no requirement to not do the cherry-pick PR even if the cherry-pick is clean. It is up to the committer discretion to decide whether it is needed or not. Tomas On Wed, 2020-04-29 at 13:28 +0000, Dr. Matthias St. Pierre wrote: > I completely agree with Nicolas reasoning. But we should try to keep > things simple and not > add too many regulations. What do you think of the following > formulation? > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > For change requests which target both the master and the > OpenSSL_1_1_1-stable branch, > the following procedure should be followed: > > - 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. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Matthias > > > From: openssl-project On Behalf > Of Nicola Tuveri > Sent: Wednesday, April 29, 2020 3:05 PM > To: openssl-project at openssl.org > Subject: Re: Cherry-pick proposal > > I can agree it is a good idea to always require backport as a > separate PR, with the following conditions: > - unless it's a 1.1.1 only issue, we MUST always wait to open the > backport-to-111 PR until after the master PR has been approved and > merged (to avoid splitting the discussions among different PRs, which > make review and revisiting our history very hard) > - trivial documentation changes, such as fixing typos, can be > exempted > > It must be clear that although things have changed a lot in the inner > plumbings, we have so far managed to keep crypto implementations very > much in sync between 1.1.1 and master, by applying the policy of > "first merge to master, then possibly backport". > > What I am afraid of in Bernd's proposal, and recent discussions, is > that committers might be tempted to open PRs changing implementations > against 1.1.1 first (to avoid frequent rebases due to unrelated > changes) and let the `master` PR stagnate indefinitely because it > feels like too much hassle to keep up with the development pace of > master if your PR collaterally changes certain files. > > An example of what can go wrong if we open a 1.1.1 PR concurrently > with a PR for master can be seen here: > - `master` PR: https://github.com/openssl/openssl/pull/10828 > - `1.1.1` PR: https://github.com/openssl/openssl/pull/11411 > > I highlight the following problems related to the above example: > - as you can see the `1.1.1` has been merged, even though the > `master` one has stalled while discussing which implementation we > should pick. (this was my fault, I should have applied the `hold` > label after stating that my approval for 1.1.1 was conditional to > approving the `master` counterpart) > - discussion that is integral part of the decision process was split > among the 2 PRs, with over 40 comments each > - there is no clear link between the `master` PR and the `1.1.1` PR > for the same feature (this makes it very difficult to review what is > the state of the "main" PR, and if we or someone else in some months > or years needs to go check why we did things the way we did, will > have a hard time connecting the dots) > > I also think that the proposal as written is a bit misleading: I > would very like to keep seeing in 1.1.1 a majority of commits cherry- > picked from commits merged to master, with explicit tags in the 1.1.1 > commit messages (this helps keeping the git history self-contained > without a too strong dependency on GitHub). > I would rephrase the proposal as follows: > > Merge to 1.1.1 should only happen after approval of a dedicated > PR targeting the OpenSSL_1_1_1-stable branch. > > Potential amendments that I'd like the OTC to consider are: > a) before the end of the sentence add ", with the optional exclusion > of trivial documentation-only changes" > b) after the end of the sentence add "In composing backport pull > requests, explicit cherry-picking (`git cherry-pick -x`) of relevant > commits merged to `master` or another stable branch is recommended > and encouraged whenever possible." > c) adopt a more general statement: > > Merge to any stable branch should only happen after approval of a > dedicated PR targeting specifically that branch. > > > > > So, in summary, I would agree with the proposal, as I definitely > think Bernd has a good point about running the 1.1.1 CI for things we > think should be backported, but requires careful consideration of > additional requirements to avoid duplicating review efforts, > splitting discussions that should be kept together, or disrupting our > processes making 1.1.1 and master diverge more than necessary. > > > Cheers, > > > Nicola > > On Wed, 29 Apr 2020 at 14:08, Matt Caswell wrote: > > The OTC have received this proposal and a request that we vote on > > it: > > > > I would like to request that we do not allow cherry-picks between > > master > > and 1.1.1-stable because these two versions are now very different, > > if a > > cherry-pick succeeds, there is no guarantee that the result will > > work. > > Because we have no CI for the cherry-pick. If a cherry-pick is > > needed, a > > new PR for 1.1.1 should be done and approved independently. > > > > Before starting a vote I'd like to provide opportunity for > > comments, and > > also what the vote text should be. > > > > Thanks > > > > Matt -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tshort at akamai.com Mon Apr 13 17:13:08 2020 From: tshort at akamai.com (Short, Todd) Date: Mon, 13 Apr 2020 17:13:08 -0000 Subject: Revisiting tradition: branches and tags In-Reply-To: <873697fh3g.wl-levitte@openssl.org> References: <874ktrfb5p.wl-levitte@openssl.org> <3ef3f6a6-d1c8-0153-4689-469302004a96@openssl.org> <873697fh3g.wl-levitte@openssl.org> Message-ID: As someone who is currently playing around with QUIC branches based on the tags and branch names, I *always* screw things up while typing. I wouldn't mind if the key were banned from tags and branch names. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." > On Apr 13, 2020, at 1:09 PM, Richard Levitte wrote: > > On Mon, 13 Apr 2020 10:48:35 +0200, > Matt Caswell wrote: >> On 11/04/2020 10:53, Dr. Matthias St. Pierre wrote: >>> I love the new naming scheme, in particular the fact that it's all-lowercase and does not >>> mix dashes and underscores anymore. I don't recall how often I cursed about the current >>> scheme which is so typer unfriendly. >>> >>> I'd like to see *all* stable branch names and release tags converted to new-style uniformly >>> (keeping the old names for compatibility), so we have an overall consistent scheme and people >>> don't need to switch back and forth between naming conventions in the future when doing >>> historical investigations. The old names could be deprecated for later removal. >> >> Yes - this aspect was my main hesitation about the proposed new format, >> i.e. the fact that we have a set of existing tags/branch names. >> Constantly changing between the new format and the old format as we look >> at older branches/tags could be painful. Just creating new tags for all >> the existing ones would be one way forward. > > New tags is perfectly possible to do. > >> Typing OpenSSL_1_1_1-stable and getting all the right upper/lower case >> characters in the right place and making sure to use _ vs - as >> appropriate is a challenge for my fingers which I constantly fail. > > I constantly fail the *current* names. > >> Is it possible to set up alias names for the historical branches? > > It's possible yes. The hard part is 1.1.1. There *is* something > called 'git symbolic-ref', but they can only be added in repos we have > physical access to, so while can add those on our git server, and they > will work, we cannot add them in github. > > Ref git help symbolic-ref > > Cheers, > Richard ( still thinks it's worth making the change with 3.0 ) > >> >> Matt >> >> >>> >>> Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: openssl-project On Behalf Of Richard Levitte >>>> Sent: Friday, April 10, 2020 8:28 PM >>>> To: openssl-project at openssl.org >>>> Subject: Revisiting tradition: branches and tags >>>> >>>> Once upon a time, there was CVS (*). >>>> >>>> The story could stop there, but since CVS was what was available, >>>> OpenSSL was versioned with CVS. >>>> >>>> Among limitations that came with CVS was the allowed syntax in tag and >>>> branch names; letters, digits, dashes and underscores. At the time, >>>> eveyone that wanted to encode a version number in a tag had to convert >>>> periods to some other character. We chose underscores, ending up with >>>> tags like this: >>>> >>>> OpenSSL_0_9_7-beta2 >>>> OpenSSL_0_9_7a >>>> >>>> Furthermore, the culture that we have with git, where branches are >>>> being pulled between repositories... where you can actually have a >>>> multitude of repositories and pull data between them, was very hard if >>>> not practically impossible with CVS. So, we occasionally had feature >>>> branches for longer term work. To distinguish our so called stable >>>> branches, we had branch names with '-stable' added at the end: >>>> >>>> OpenSSL_0_9_7-stable >>>> >>>> We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but >>>> I guess that was too easy to mix up with our letter releases. >>>> >>>> With git, however, there's no technical reason why we must maintain >>>> what was originally a technical limitation. I therefore propose that >>>> we start using tags like this starting with OpenSSL 3.0: >>>> >>>> openssl-3.0.0-alpha1 >>>> openssl-3.0.0-beta2 >>>> openssl-3.0.0 >>>> openssl-3.0.1 >>>> openssl-3.1.0 >>>> >>>> This is a little more than just avoiding to change the periods with >>>> underscores. However, if you look at the tar files we've released for >>>> a long time, that's the naming format they use, and I can see benefits >>>> in having the tags for a release match the tar file of the same >>>> release: >>>> >>>> openssl-0.9.7a.tar.gz >>>> openssl-0.9.7a.tar.gz.asc >>>> openssl-0.9.7a.tar.gz.md5 >>>> >>>> Future tar files would be numbered with the new version scheme, of >>>> course: >>>> >>>> openssl-3.0.0-alpha1.tar.gz >>>> openssl-3.0.0-beta2.tar.gz >>>> openssl-3.0.0.tar.gz >>>> openssl-3.0.1.tar.gz >>>> openssl-3.1.0.tar.gz >>>> >>>> So what about release branches? We could actually follow a very >>>> similar new pattern, just replace the last digit with, say, an 'x', to >>>> signify that this branch will contain a series of patch releases: >>>> >>>> openssl-3.0.x >>>> >>>> In this branch, one would expect to see the tags 'openssl-3.0.0', >>>> 'openssl-3.0.1', 'openssl-3.0.2', ... >>>> >>>> Earlier today, I submitted a new release script that codifies exactly >>>> this: https://github.com/openssl/openssl/pull/11516 >>>> >>>> Thoughts? >>>> >>>> Cheers, >>>> Richard >>>> >>>> (*) Well, not quite, there was RCS, there was SCCS, and a few other >>>> versioning systems that would make your skin crawl by today's >>>> standards, even more so than CVS. >>>> >>>> -- >>>> 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sfhacker at hotmail.com Fri Apr 24 20:31:43 2020 From: sfhacker at hotmail.com (Sergio NNX) Date: Fri, 24 Apr 2020 20:31:43 +0000 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200423142936.GA24450@openssl.org> References: <20200423142936.GA24450@openssl.org> Message-ID: * Windows 10 x64 * GCC 8.3.0 x86_64 $ openssl version -a OpenSSL 3.0.0-alpha1 "23 Apr 2020" (Library: OpenSSL 3.0.0-alpha1 "23 Apr 2020") built on: Fri Apr 24 18:14:53 2020 UTC platform: mingw64 options: bn(64,64) compiler: /mingw/bin/gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 -D__PTW32_STATIC_LIB -D__PTW32_CLEANUP_C -m64 -O2 -pipe -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -DL_ENDIAN -DOPENSSL_BUILDING_OPENSSL -DOPENSSL_PIC -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT -DZLIB -DNDEBUG -I/mingw/x86_64-pc-mingw32/include -I/mingw/x86_64-pc-mingw32/include/directx -I/mingw/include OPENSSLDIR: "C:/OpenSSL" ENGINESDIR: "C:/MinGW/lib/engines-3" MODULESDIR: "C:/MinGW/lib/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x29c67af Some issued found: on.obj crypto/cversion.c In file included from include/openssl/macros.h:11, from include/openssl/opensslconf.h:14, from include/openssl/macros.h:10, from include/openssl/crypto.h:15, from include/internal/cryptlib.h:23, from crypto/cversion.c:10: crypto/cversion.c: In function 'OpenSSL_version': include/openssl/opensslv.h:91:54: error: expected ';' before numeric constant # define OPENSSL_VERSION_TEXT "OpenSSL 3.0.0-alpha1 "23 Apr 2020"" ^~ crypto/cversion.c:50:16: note: in expansion of macro 'OPENSSL_VERSION_TEXT' return OPENSSL_VERSION_TEXT; ^~~~~~~~~~~~~~~~~~~~ make[1]: *** [crypto/libcrypto-lib-cversion.obj] Error 1 make[1]: Leaving directory `/src/openssl-3.0.0-alpha1' make: *** [build_sw] Error 2 ________________________________ From: openssl-users on behalf of OpenSSL Sent: Friday, 24 April 2020 12:29 AM To: openssl-project at openssl.org ; OpenSSL User Support ML ; OpenSSL Announce ML Subject: OpenSSL version 3.0.0-alpha1 published -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 1 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 1 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-alpha1.tar.gz Size: 9530120 SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 SHA256 checksum: 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha1.tar.gz openssl sha256 openssl-3.0.0-alpha1.tar.gz Please download and check this $LABEL 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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8 hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F hIr11rxXNxtBRKUSlOUyJATZn0sV6g== =uRpM -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Apr 29 13:30:12 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Apr 2020 13:30:12 +0000 Subject: Cherry-pick proposal In-Reply-To: References: Message-ID: <7605E76C-4898-4DA4-961B-DCACA942D556@akamai.com> I suspect that the primary motivation for this proposal is that PR?s against master often become stale because nobody on the project looks at them. And then submitters are told to rebase, fix conflicts, etc. It gets disheartening. If that is the motivation, then perhaps the project should address that root cause. Here are two ideas: 1. Mark?s scanning tool complains to the OTC if it has been ?X? weeks without OTC action. I would pick X as 2. 2. Change the submission rules to be one non-author OTC member review and allow OTC/OMC to put a hold for discussion during the 24-hour freeze period. That discussion must be concluded, perhaps by a vote, within ?Y? weeks (four?). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Wed Apr 29 18:22:36 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Thu, 30 Apr 2020 04:22:36 +1000 Subject: Cherry-pick proposal In-Reply-To: <7605E76C-4898-4DA4-961B-DCACA942D556@akamai.com> References: <7605E76C-4898-4DA4-961B-DCACA942D556@akamai.com> Message-ID: Any change to the review gate check we have in place now that lowers it will certainly not get my support. If anything, that check before code gets approved should be raised, not lowered. Tim. On Thu, 30 Apr 2020, 1:24 am Salz, Rich, wrote: > I suspect that the primary motivation for this proposal is that PR?s > against master often become stale because nobody on the project looks at > them. And then submitters are told to rebase, fix conflicts, etc. It gets > disheartening. If that is the motivation, then perhaps the project should > address that root cause. Here are two ideas: > > > > 1. Mark?s scanning tool complains to the OTC if it has been ?X? weeks > without OTC action. I would pick X as 2. > 2. Change the submission rules to be one non-author OTC member review > and allow OTC/OMC to put a hold for discussion during the 24-hour freeze > period. That discussion must be concluded, perhaps by a vote, within ?Y? > weeks (four?). > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: