From mark at openssl.org Fri May 1 07:52:53 2020 From: mark at openssl.org (Mark J Cox) Date: Fri, 1 May 2020 08:52:53 +0100 Subject: Stale PR stats @May01 In-Reply-To: References: <1585699695.181394.1105.nullmailer@dev.openssl.org> Message-ID: Last 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 ( 148 issues, median 188 days) of which: failed CI ( 23 issues, median 175 days) deferred after 1.1.1 ( 41 issues, median 188 days) cla required ( 19 issues, median 422 days) waiting for reporter ( 15 issues, median 275 days) waiting for review ( 1 issues, median 38 days) waiting for OMC ( 2 issues, median 112.0 days) waiting for OTC ( 1 issues, median 84 days) all other ( 46 issues, median 239.5 days) So, ignoring deferred issues too you could summarise this as: Stale PRs waiting for us to do something: 27 (last months: 29) Stale PRs waiting for the reporter to do something: 34 (last months: 37) Stale PRs with unclear next action: 46 (last months: 42) 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: failed CI ( 23 issues, median 175 days) 11349 branch: master, reviewed:commented days:43 11327 reviewed:commented days:48 11288 branch: master, reviewed:commented days:51 11257 branch: 1.1.1, branch: master, reviewed:approved days:49 11195 branch: 1.1.1, branch: master, reviewed:commented days:38 11151 days:60 10626 days:66 10556 days:147 10465 days:164 9926 days:226 9603 days:226 9155 reviewed:commented days:100 8955 branch: 1.1.1, branch: master, reviewed:dismissed days:175 8687 reviewed:commented days:210 8389 days:415 8115 reviewed:commented days:48 7921 reviewed:commented days:419 7914 reviewed:approved days:478 7380 reviewed:commented days:566 7051 milestone:Assessed, reviewed:commented days:615 6074 milestone:Assessed, reviewed:commented days:658 4992 milestone:Assessed, reviewed:commented days:188 4486 milestone:Assessed, days:658 waiting for reporter ( 15 issues, median 275 days) 11310 reviewed:changes_requested days:43 10887 branch: master, reviewed:changes_requested days:37 10590 reviewed:changes_requested days:115 9677 branch: master, reviewed:changes_requested days:32 9575 reviewed:changes_requested days:262 9461 reviewed:changes_requested days:275 9427 reviewed:changes_requested days:282 9243 reviewed:changes_requested days:284 9240 reviewed:changes_requested days:309 8992 reviewed:changes_requested days:226 8962 reviewed:changes_requested days:44 8730 reviewed:changes_requested days:323 8674 reviewed:changes_requested days:378 7961 reviewed:changes_requested days:480 7432 reviewed:changes_requested days:559 waiting for OMC ( 2 issues, median 112.0 days) 10786 approval: done, branch: 1.1.1, branch: master, hold: need omc decision, reviewed:approved days:52 10195 branch: master, hold: need omc decision, reviewed:commented days:172 waiting for OTC ( 1 issues, median 84 days) 8300 approval: otc review pending, branch: 1.1.1, branch: master, hold: need otc decision, reviewed:approved days:84 waiting for review ( 1 issues, median 38 days) 10587 approval: review pending, branch: 1.1.1, branch: master, reviewed:commented days:38 all other ( 46 issues, median 239.5 days) 11398 approval: done, branch: master, reviewed:approved days:35 11312 days:47 11277 resolved: not a bug, days:50 11260 reviewed:commented days:55 11154 days:66 11115 days:56 11057 days:80 10884 days:102 10818 days:108 10570 reviewed:commented days:124 10541 days:139 10338 reviewed:commented days:179 10320 branch: 1.1.1, branch: master, reviewed:commented days:170 10298 days:183 10268 days:185 10037 days:147 9655 days:157 9554 days:266 9421 branch: 1.1.1, branch: master, reviewed:approved days:121 9223 branch: master, reviewed:commented days:83 9206 days:314 9051 reviewed:commented days:177 8956 days:336 8920 days:213 8908 days:351 8862 days:330 8835 days:370 8743 branch: master, days:381 8668 days:392 8455 days:394 8420 days:395 8333 days:430 8309 branch: master, reviewed:commented days:316 8024 reviewed:commented days:81 7688 days:516 7615 days:520 7454 reviewed:commented days:471 7274 reviewed:approved days:322 7225 reviewed:commented days:587 6725 milestone:Assessed, reviewed:approved days:330 6518 milestone:Assessed, reviewed:approved days:681 6516 branch: 1.1.1, branch: master, milestone:Assessed, days:681 6448 milestone:Assessed, days:188 6219 milestone:Assessed, reviewed:approved days:719 5427 branch: master, milestone:Assessed, reviewed:commented days:481 4487 milestone:Assessed, days:658 From matt at openssl.org Fri May 1 08:45:30 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 1 May 2020 09:45:30 +0100 Subject: Stale PR stats @May01 In-Reply-To: References: <1585699695.181394.1105.nullmailer@dev.openssl.org> Message-ID: <14231488-8882-9d31-40c2-3bb0c3e589a8@openssl.org> This is really nice! Thanks Mark. Matt On 01/05/2020 08:52, Mark J Cox wrote: > Last 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 ( 148 issues, median 188 days) of which: > > failed CI ( 23 issues, median 175 days) > deferred after 1.1.1 ( 41 issues, median 188 days) > cla required ( 19 issues, median 422 days) > waiting for reporter ( 15 issues, median 275 days) > waiting for review ( 1 issues, median 38 days) > waiting for OMC ( 2 issues, median 112.0 days) > waiting for OTC ( 1 issues, median 84 days) > all other ( 46 issues, median 239.5 days) > > So, ignoring deferred issues too you could summarise this as: > > Stale PRs waiting for us to do something: 27 (last months: 29) > Stale PRs waiting for the reporter to do something: 34 (last months: 37) > Stale PRs with unclear next action: 46 (last months: 42) > > 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: > > failed CI ( 23 issues, median 175 days) > > 11349 branch: master, reviewed:commented days:43 > 11327 reviewed:commented days:48 > 11288 branch: master, reviewed:commented days:51 > 11257 branch: 1.1.1, branch: master, reviewed:approved days:49 > 11195 branch: 1.1.1, branch: master, reviewed:commented days:38 > 11151 days:60 > 10626 days:66 > 10556 days:147 > 10465 days:164 > 9926 days:226 > 9603 days:226 > 9155 reviewed:commented days:100 > 8955 branch: 1.1.1, branch: master, reviewed:dismissed days:175 > 8687 reviewed:commented days:210 > 8389 days:415 > 8115 reviewed:commented days:48 > 7921 reviewed:commented days:419 > 7914 reviewed:approved days:478 > 7380 reviewed:commented days:566 > 7051 milestone:Assessed, reviewed:commented days:615 > 6074 milestone:Assessed, reviewed:commented days:658 > 4992 milestone:Assessed, reviewed:commented days:188 > 4486 milestone:Assessed, days:658 > > waiting for reporter ( 15 issues, median 275 days) > > 11310 reviewed:changes_requested days:43 > 10887 branch: master, reviewed:changes_requested days:37 > 10590 reviewed:changes_requested days:115 > 9677 branch: master, reviewed:changes_requested days:32 > 9575 reviewed:changes_requested days:262 > 9461 reviewed:changes_requested days:275 > 9427 reviewed:changes_requested days:282 > 9243 reviewed:changes_requested days:284 > 9240 reviewed:changes_requested days:309 > 8992 reviewed:changes_requested days:226 > 8962 reviewed:changes_requested days:44 > 8730 reviewed:changes_requested days:323 > 8674 reviewed:changes_requested days:378 > 7961 reviewed:changes_requested days:480 > 7432 reviewed:changes_requested days:559 > > waiting for OMC ( 2 issues, median 112.0 days) > > 10786 approval: done, branch: 1.1.1, branch: master, hold: need > omc decision, reviewed:approved days:52 > 10195 branch: master, hold: need omc decision, reviewed:commented days:172 > > waiting for OTC ( 1 issues, median 84 days) > > 8300 approval: otc review pending, branch: 1.1.1, branch: master, > hold: need otc decision, reviewed:approved days:84 > > waiting for review ( 1 issues, median 38 days) > > 10587 approval: review pending, branch: 1.1.1, branch: master, > reviewed:commented days:38 > > all other ( 46 issues, median 239.5 days) > > 11398 approval: done, branch: master, reviewed:approved days:35 > 11312 days:47 > 11277 resolved: not a bug, days:50 > 11260 reviewed:commented days:55 > 11154 days:66 > 11115 days:56 > 11057 days:80 > 10884 days:102 > 10818 days:108 > 10570 reviewed:commented days:124 > 10541 days:139 > 10338 reviewed:commented days:179 > 10320 branch: 1.1.1, branch: master, reviewed:commented days:170 > 10298 days:183 > 10268 days:185 > 10037 days:147 > 9655 days:157 > 9554 days:266 > 9421 branch: 1.1.1, branch: master, reviewed:approved days:121 > 9223 branch: master, reviewed:commented days:83 > 9206 days:314 > 9051 reviewed:commented days:177 > 8956 days:336 > 8920 days:213 > 8908 days:351 > 8862 days:330 > 8835 days:370 > 8743 branch: master, days:381 > 8668 days:392 > 8455 days:394 > 8420 days:395 > 8333 days:430 > 8309 branch: master, reviewed:commented days:316 > 8024 reviewed:commented days:81 > 7688 days:516 > 7615 days:520 > 7454 reviewed:commented days:471 > 7274 reviewed:approved days:322 > 7225 reviewed:commented days:587 > 6725 milestone:Assessed, reviewed:approved days:330 > 6518 milestone:Assessed, reviewed:approved days:681 > 6516 branch: 1.1.1, branch: master, milestone:Assessed, days:681 > 6448 milestone:Assessed, days:188 > 6219 milestone:Assessed, reviewed:approved days:719 > 5427 branch: master, milestone:Assessed, reviewed:commented days:481 > 4487 milestone:Assessed, days:658 > From rsalz at akamai.com Fri May 1 14:16:11 2020 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 1 May 2020 14:16:11 +0000 Subject: Stale PR stats @May01 In-Reply-To: References: <1585699695.181394.1105.nullmailer@dev.openssl.org> Message-ID: This is great transparency info. Failed CI's are a problem since it's often the fault of timeouts, or sometimes master is broken. Any thoughts on how to handle that? > So, ignoring deferred issues too you could summarise this as: Stale PRs waiting for us to do something: 27 (last months: 29) Stale PRs waiting for the reporter to do something: 34 (last months: 37) Stale PRs with unclear next action: 46 (last months: 42) It would be great to see median days on those, too. From beldmit at gmail.com Fri May 1 14:30:28 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 1 May 2020 17:30:28 +0300 Subject: Stale PR stats @May01 In-Reply-To: References: <1585699695.181394.1105.nullmailer@dev.openssl.org> Message-ID: Dear Mark, Many thanks for your efforts! And I also got an idea that ping comment leaves PRs out of this statistics :) On Fri, May 1, 2020 at 10:53 AM Mark J Cox wrote: > Last 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 ( 148 issues, median 188 days) of which: > > failed CI ( 23 issues, median 175 days) > deferred after 1.1.1 ( 41 issues, median 188 days) > cla required ( 19 issues, median 422 days) > waiting for reporter ( 15 issues, median 275 days) > waiting for review ( 1 issues, median 38 days) > waiting for OMC ( 2 issues, median 112.0 days) > waiting for OTC ( 1 issues, median 84 days) > all other ( 46 issues, median 239.5 days) > > So, ignoring deferred issues too you could summarise this as: > > Stale PRs waiting for us to do something: 27 (last months: 29) > Stale PRs waiting for the reporter to do something: 34 (last months: > 37) > Stale PRs with unclear next action: 46 (last months: 42) > > 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: > > failed CI ( 23 issues, median 175 days) > > 11349 branch: master, reviewed:commented days:43 > 11327 reviewed:commented days:48 > 11288 branch: master, reviewed:commented days:51 > 11257 branch: 1.1.1, branch: master, reviewed:approved days:49 > 11195 branch: 1.1.1, branch: master, reviewed:commented days:38 > 11151 days:60 > 10626 days:66 > 10556 days:147 > 10465 days:164 > 9926 days:226 > 9603 days:226 > 9155 reviewed:commented days:100 > 8955 branch: 1.1.1, branch: master, reviewed:dismissed days:175 > 8687 reviewed:commented days:210 > 8389 days:415 > 8115 reviewed:commented days:48 > 7921 reviewed:commented days:419 > 7914 reviewed:approved days:478 > 7380 reviewed:commented days:566 > 7051 milestone:Assessed, reviewed:commented days:615 > 6074 milestone:Assessed, reviewed:commented days:658 > 4992 milestone:Assessed, reviewed:commented days:188 > 4486 milestone:Assessed, days:658 > > waiting for reporter ( 15 issues, median 275 days) > > 11310 reviewed:changes_requested days:43 > 10887 branch: master, reviewed:changes_requested days:37 > 10590 reviewed:changes_requested days:115 > 9677 branch: master, reviewed:changes_requested days:32 > 9575 reviewed:changes_requested days:262 > 9461 reviewed:changes_requested days:275 > 9427 reviewed:changes_requested days:282 > 9243 reviewed:changes_requested days:284 > 9240 reviewed:changes_requested days:309 > 8992 reviewed:changes_requested days:226 > 8962 reviewed:changes_requested days:44 > 8730 reviewed:changes_requested days:323 > 8674 reviewed:changes_requested days:378 > 7961 reviewed:changes_requested days:480 > 7432 reviewed:changes_requested days:559 > > waiting for OMC ( 2 issues, median 112.0 days) > > 10786 approval: done, branch: 1.1.1, branch: master, hold: need > omc decision, reviewed:approved days:52 > 10195 branch: master, hold: need omc decision, reviewed:commented > days:172 > > waiting for OTC ( 1 issues, median 84 days) > > 8300 approval: otc review pending, branch: 1.1.1, branch: master, > hold: need otc decision, reviewed:approved days:84 > > waiting for review ( 1 issues, median 38 days) > > 10587 approval: review pending, branch: 1.1.1, branch: master, > reviewed:commented days:38 > > all other ( 46 issues, median 239.5 days) > > 11398 approval: done, branch: master, reviewed:approved days:35 > 11312 days:47 > 11277 resolved: not a bug, days:50 > 11260 reviewed:commented days:55 > 11154 days:66 > 11115 days:56 > 11057 days:80 > 10884 days:102 > 10818 days:108 > 10570 reviewed:commented days:124 > 10541 days:139 > 10338 reviewed:commented days:179 > 10320 branch: 1.1.1, branch: master, reviewed:commented days:170 > 10298 days:183 > 10268 days:185 > 10037 days:147 > 9655 days:157 > 9554 days:266 > 9421 branch: 1.1.1, branch: master, reviewed:approved days:121 > 9223 branch: master, reviewed:commented days:83 > 9206 days:314 > 9051 reviewed:commented days:177 > 8956 days:336 > 8920 days:213 > 8908 days:351 > 8862 days:330 > 8835 days:370 > 8743 branch: master, days:381 > 8668 days:392 > 8455 days:394 > 8420 days:395 > 8333 days:430 > 8309 branch: master, reviewed:commented days:316 > 8024 reviewed:commented days:81 > 7688 days:516 > 7615 days:520 > 7454 reviewed:commented days:471 > 7274 reviewed:approved days:322 > 7225 reviewed:commented days:587 > 6725 milestone:Assessed, reviewed:approved days:330 > 6518 milestone:Assessed, reviewed:approved days:681 > 6516 branch: 1.1.1, branch: master, milestone:Assessed, days:681 > 6448 milestone:Assessed, days:188 > 6219 milestone:Assessed, reviewed:approved days:719 > 5427 branch: master, milestone:Assessed, reviewed:commented days:481 > 4487 milestone:Assessed, days:658 > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Fri May 1 15:19:07 2020 From: mark at openssl.org (Mark J Cox) Date: Fri, 1 May 2020 16:19:07 +0100 Subject: Stale PR stats @May01 In-Reply-To: References: <1585699695.181394.1105.nullmailer@dev.openssl.org> Message-ID: On Fri, May 1, 2020 at 3:30 PM Dmitry Belyavsky wrote: .. > And I also got an idea that ping comment leaves PRs out of this statistics :) Thanks! The script is designed to ignore the automated pings that it creates itself so they themselves don't reset the dates and artificially stop things being stale. Instead they will hopefully nudge folks into taking some action that will actually stop the PRs being stale :)) Mark From beldmit at gmail.com Fri May 1 15:23:08 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 1 May 2020 18:23:08 +0300 Subject: Stale PR stats @May01 In-Reply-To: References: <1585699695.181394.1105.nullmailer@dev.openssl.org> Message-ID: On Fri, May 1, 2020 at 6:19 PM Mark J Cox wrote: > On Fri, May 1, 2020 at 3:30 PM Dmitry Belyavsky wrote: > .. > > And I also got an idea that ping comment leaves PRs out of this > statistics :) > > Thanks! The script is designed to ignore the automated pings that it > creates itself so they themselves don't reset the dates and > artificially stop things being stale. Instead they will hopefully > nudge folks into taking some action that will actually stop the PRs > being stale :)) > Well, I see some Catch-22 elements here... -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From guidovranken at gmail.com Fri May 1 16:20:26 2020 From: guidovranken at gmail.com (Guido Vranken) Date: Fri, 1 May 2020 18:20:26 +0200 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: <20200423142936.GA24450@openssl.org> References: <20200423142936.GA24450@openssl.org> Message-ID: Reminder that in git master and 3.0.0, CAST5 gives the wrong output: https://github.com/openssl/openssl/issues/11459 (this proof of concept was made before you moved CAST5 to liblegacy, so just put OSSL_PROVIDER_load(nullptr, "legacy"); in there to make it work) On Thu, Apr 23, 2020 at 4:30 PM OpenSSL wrote: > -----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 shane.lontis at oracle.com Sat May 2 02:23:16 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Sat, 2 May 2020 12:23:16 +1000 Subject: OpenSSL version 3.0.0-alpha1 published In-Reply-To: References: <20200423142936.GA24450@openssl.org> Message-ID: <25EF9AE8-8549-42CC-B2CB-0CFCDD1A9175@oracle.com> Thanks.. I will take a look. Shane > On 2 May 2020, at 2:20 am, Guido Vranken wrote: > > Reminder that in git master and 3.0.0, CAST5 gives the wrong output: https://github.com/openssl/openssl/issues/11459 (this proof of concept was made before you moved CAST5 to liblegacy, so just put OSSL_PROVIDER_load(nullptr, "legacy"); in there to make it work) > > On Thu, Apr 23, 2020 at 4:30 PM OpenSSL > wrote: > -----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 paul.dale at oracle.com Mon May 4 09:32:19 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 4 May 2020 19:32:19 +1000 Subject: FIPS_mode() vote results Message-ID: <874F8EF8-CD11-4EC2-8EC7-6B1FB6210F88@oracle.com> The vote: Remove the calls FIPS_mode() & FIPS_mode_set() in 3.0. Has closed. For: 3 Against: 1 Abstain: 2 The vote passes. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu May 7 08:24:17 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 May 2020 09:24:17 +0100 Subject: Technically an API break Message-ID: PR11589 makes a change to the public API function `SSL_set_record_padding_callback` to change its return type from void to int: https://github.com/openssl/openssl/pull/11589 This is technically an API break - but it doesn't seem too serious. It's possible, I suppose, that existing applications that use this will fail to spot the error return since this function can now fail. The function itself was only recently added (in 1.1.1), and I suspect real-world usage is very small (or possibly nil). Is this considered ok? Matt From tmraz at redhat.com Thu May 7 08:31:42 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 07 May 2020 10:31:42 +0200 Subject: Technically an API break In-Reply-To: References: Message-ID: <3f737db0fb0569ef523310509044097ef8e7d02b.camel@redhat.com> On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote: > PR11589 makes a change to the public API function > `SSL_set_record_padding_callback` to change its return type from void > to > int: > > https://github.com/openssl/openssl/pull/11589 > > This is technically an API break - but it doesn't seem too serious. > It's > possible, I suppose, that existing applications that use this will > fail > to spot the error return since this function can now fail. The > function > itself was only recently added (in 1.1.1), and I suspect real-world > usage is very small (or possibly nil). > > Is this considered ok? I would say this is an acceptable thing if it is documented (which it is in the PR). Especially because the error return can happen only when the application sets up the SSL to use kernel TLS. -- 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 Thu May 7 11:15:04 2020 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 May 2020 13:15:04 +0200 Subject: Technically an API break In-Reply-To: <3f737db0fb0569ef523310509044097ef8e7d02b.camel@redhat.com> References: <3f737db0fb0569ef523310509044097ef8e7d02b.camel@redhat.com> Message-ID: <87r1vwov2f.wl-levitte@openssl.org> On Thu, 07 May 2020 10:31:42 +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote: > > PR11589 makes a change to the public API function > > `SSL_set_record_padding_callback` to change its return type from void > > to > > int: > > > > https://github.com/openssl/openssl/pull/11589 > > > > This is technically an API break - but it doesn't seem too serious. > > It's > > possible, I suppose, that existing applications that use this will > > fail > > to spot the error return since this function can now fail. The > > function > > itself was only recently added (in 1.1.1), and I suspect real-world > > usage is very small (or possibly nil). > > > > Is this considered ok? > > I would say this is an acceptable thing if it is documented (which it > is in the PR). Especially because the error return can happen only when > the application sets up the SSL to use kernel TLS. I agree with this assessment. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Thu May 7 11:22:43 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 7 May 2020 13:22:43 +0200 Subject: Unexpected EOF handling Message-ID: <20200507112243.GA1853215@roeckx.be> Hi, We introduced a change in the 1.1.1e release that changed how we handled an unexpected EOF. This broke various software which resulted in the release of 1.1.1f that reverted that change. In master we still have the 1.1.1e behaviour. The change itself is small, it just calls SSLfatal() with a new error code. This has at least 2 effects: - The error code was changed from SSL_ERROR_SYSCALL with errno 0 to SSL_ERROR_SSL with reason code SSL_R_UNEXPECTED_EOF_WHILE_READING - The session is marked as in error, and so can't be used to resume. There is code written that now checks for the SSL_ERROR_SYSCALL with errno 0 case, while we never documented that behaviour. The 1.1.1 manpage of SSL_get_error() currently reports this as a bug and that it will change to SSL_ERROR_SSL / SSL_R_UNEXPECTED_EOF_WHILE_READING. Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall in at least 2 categories: - Ignore the error - Check for the error, for instance in a test suite Not sending the close notify alert is a violation of the TLS specifications, but there is software out there doesn't send it, so there is a need to be able to deal with peers that don't send it. When the close notify alert wasn't received, but we did get an EOF, there are 2 cases: - It's a fatal error, the protocol needs the close notify alert to prevent a truncation attack - The protocol running on top of SSL can detect a truncation attack itself, and does so. It doesn't need the close notify alert. It's not a fatal error. They just want to check that that is what happened. The problem is that we can't make a distiction between the 2 cases, so the only thing we can do currently is to look at it as a fatal error. So the documentation was changed to say that if you're in the 2nd cases, and need to talk to a peer that doesn't send the close notify alert, you should not wait for the close notify alert, so that you don't get an error. The alternative is that we add an option that does tell us if we should look at it as a fatal error or not. There is at least a request that we keep returning the old error code (SSL_ERROR_SYSCALL with errno 0). I think that from an API point of view this is very confusing. We'd then have SSL_ERROR_SYSCALL as documented that it's fatal, except when errno is 0. If errno is 0, it can either be fatal or not, and we're not telling you which one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL with errno 0 is always the unexpected EOF, we returned that combination because of a bug in OpenSSL. So I think we need at least to agree on: - Do we want an option that makes the unexpected EOF either a fatal error or a non-fatal error? - Which error should we return? Kurt From matt at openssl.org Thu May 7 11:47:49 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 May 2020 12:47:49 +0100 Subject: Unexpected EOF handling In-Reply-To: <20200507112243.GA1853215@roeckx.be> References: <20200507112243.GA1853215@roeckx.be> Message-ID: <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> On 07/05/2020 12:22, Kurt Roeckx wrote: > So I think we need at least to agree on: > - Do we want an option that makes the unexpected EOF either a fatal > error or a non-fatal error? > - Which error should we return? This is an excellent summary of the current situation. I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a long term solution. It's a very confusing API for new applications to use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except when its not. SSL_ERROR_SYSCALL should mean fatal error. That said I also recognise that it is apparently commonplace to shut down a TLS connection without sending close_notify - despite what the standards may say about it (and TBH we can hardly claim the moral high ground here since s_server does exactly this - or at least it does in 1.1.1 and did until very recently in master). But we do have to consider usages beyond HTTPS. I have no idea if this occurs in other settings or not. Perhaps what we need is an option for "strict shutdown". With strict shutdown "off" we could treat EOF as if we had received a close_notify gracefully (and don't invalidate the session). Presumably existing code would be able to cope with that??? With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in master). I'm not sure though what the default should be. Matt From tmraz at redhat.com Thu May 7 11:46:05 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 07 May 2020 13:46:05 +0200 Subject: Unexpected EOF handling In-Reply-To: <20200507112243.GA1853215@roeckx.be> References: <20200507112243.GA1853215@roeckx.be> Message-ID: <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote: > Hi, > > We introduced a change in the 1.1.1e release that changed how we > handled an unexpected EOF. This broke various software which > resulted in the release of 1.1.1f that reverted that change. > In master we still have the 1.1.1e behaviour. > > The change itself is small, it just calls SSLfatal() with a new > error code. This has at least 2 effects: > - The error code was changed from SSL_ERROR_SYSCALL with errno 0 > to SSL_ERROR_SSL with reason code > SSL_R_UNEXPECTED_EOF_WHILE_READING > - The session is marked as in error, and so can't be used to > resume. > > There is code written that now checks for the SSL_ERROR_SYSCALL > with errno 0 case, while we never documented that behaviour. The > 1.1.1 manpage of SSL_get_error() currently reports this as a bug > and that it will change to SSL_ERROR_SSL / > SSL_R_UNEXPECTED_EOF_WHILE_READING. > > Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall > in at least 2 categories: > - Ignore the error > - Check for the error, for instance in a test suite > > Not sending the close notify alert is a violation of the TLS > specifications, but there is software out there doesn't send it, > so there is a need to be able to deal with peers that don't send > it. > > When the close notify alert wasn't received, but we did get an > EOF, there are 2 cases: > - It's a fatal error, the protocol needs the close notify alert to > prevent a truncation attack > - The protocol running on top of SSL can detect a truncation > attack itself, and does so. It doesn't need the close notify > alert. It's not a fatal error. They just want to check that that > is what happened. > > The problem is that we can't make a distiction between the 2 > cases, so the only thing we can do currently is to look at > it as a fatal error. So the documentation was changed to say > that if you're in the 2nd cases, and need to talk to a peer > that doesn't send the close notify alert, you should not wait > for the close notify alert, so that you don't get an error. > > The alternative is that we add an option that does tell us if we > should look at it as a fatal error or not. > > There is at least a request that we keep returning the old error code > (SSL_ERROR_SYSCALL with errno 0). I think that from an API point > of view this is very confusing. We'd then have SSL_ERROR_SYSCALL > as documented that it's fatal, except when errno is 0. If errno is > 0, it can either be fatal or not, and we're not telling you which > one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL > with errno 0 is always the unexpected EOF, we returned that > combination because of a bug in OpenSSL. > > So I think we need at least to agree on: > - Do we want an option that makes the unexpected EOF either a fatal > error or a non-fatal error? > - Which error should we return? >From application developer side of view for protocols that do not depend on SSL detecting the truncation I think inventing a different behavior for this condition than the existing one as of 1.1.1f would be clearly wrong. Switching on a SSL_OP if that newly provided OP is a trivial change to an application that needs to accommodate various versions of OpenSSL (and I am not talking about forks), however switching on a SSL_OP and also add another special error case is much more complicated change and has potential for bringing regressions in the applications that need to do it. It is also an API break, however we would do it anyway unless we make the legacy behavior the default one, so that is not really relevant here. Is there really another situation where SSL_ERROR_SYSCALL with errno 0 could be returned apart from the unclean EOF condition? I can't really think of any. So I would be just for properly documenting the condition and keeping it as is if the SSL_OP to ignore unclean EOF is in effect. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tmraz at redhat.com Thu May 7 12:31:24 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 07 May 2020 14:31:24 +0200 Subject: Unexpected EOF handling In-Reply-To: <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> References: <20200507112243.GA1853215@roeckx.be> <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> Message-ID: On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > So I think we need at least to agree on: > > - Do we want an option that makes the unexpected EOF either a fatal > > error or a non-fatal error? > > - Which error should we return? > > This is an excellent summary of the current situation. > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a > long term solution. It's a very confusing API for new applications to > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > That said I also recognise that it is apparently commonplace to shut > down a TLS connection without sending close_notify - despite what the > standards may say about it (and TBH we can hardly claim the moral > high > ground here since s_server does exactly this - or at least it does in > 1.1.1 and did until very recently in master). > > But we do have to consider usages beyond HTTPS. I have no idea if > this > occurs in other settings or not. > > Perhaps what we need is an option for "strict shutdown". With strict > shutdown "off" we could treat EOF as if we had received a > close_notify > gracefully (and don't invalidate the session). Presumably existing > code > would be able to cope with that??? Yes, existing code would be able to cope with that with one important exception that I am going to talk about below. > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > master). > > I'm not sure though what the default should be. In case we go with this solution, which would be acceptable I think, we MUST NOT EVER make it the default because existing applications that depend on the existing way how the unclean EOF condition is returned might actually depend on it to detect the truncation attack. The existing legacy way does not really prevent applications from detecting the truncation attack because the condition is reported to the application albeit in this legacy undocumented way. So changing the default to mean - never report the unclean EOF condition at all, simply return as if the shutdown was clean, would actually mean a security issue for these existing applications that care about the unclean EOF. So yes, perhaps it would be better for the SSL_OP to actually fully ignore the unclean EOF instead of returning this undocumented error condition, but it must not be a default (not even in SSL_OP_ALL). -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From kurt at roeckx.be Thu May 7 12:53:27 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 7 May 2020 14:53:27 +0200 Subject: Unexpected EOF handling In-Reply-To: <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> References: <20200507112243.GA1853215@roeckx.be> <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> Message-ID: <20200507125327.GB1853215@roeckx.be> On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > From application developer side of view for protocols that do not > depend on SSL detecting the truncation I think inventing a different > behavior for this condition than the existing one as of 1.1.1f would be > clearly wrong. Switching on a SSL_OP if that newly provided OP is a > trivial change to an application that needs to accommodate various > versions of OpenSSL (and I am not talking about forks), however > switching on a SSL_OP and also add another special error case is much > more complicated change and has potential for bringing regressions in > the applications that need to do it. Of course, just adding a call to get the old behaviour back is a very easy change. But I currently don't see how a different error is that much more complicated. > Is there really another situation where SSL_ERROR_SYSCALL with errno 0 > could be returned apart from the unclean EOF condition? > > I can't really think of any. It's not because we can't think of any other case that there aren't any. I also have a problem with checking errno being 0. We don't set errno. There is no reason to assume that errno is set to any value. errno can be modified on a succesful call. That errno is 0 is just a coincidence. If we're going to document that, we should actually make sure that that is the case. I think the other property of the old behaviour is that we don't add anything to the error stack. > So I would be just for properly documenting the condition and keeping > it as is if the SSL_OP to ignore unclean EOF is in effect. And also don't add an option for applications that do want to get a fatal error? Kurt From tmraz at redhat.com Thu May 7 13:15:22 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 07 May 2020 15:15:22 +0200 Subject: Unexpected EOF handling In-Reply-To: <20200507125327.GB1853215@roeckx.be> References: <20200507112243.GA1853215@roeckx.be> <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> <20200507125327.GB1853215@roeckx.be> Message-ID: <0d431caa59774a7f72cb390219b41857b6753085.camel@redhat.com> On Thu, 2020-05-07 at 14:53 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > > From application developer side of view for protocols that do not > > depend on SSL detecting the truncation I think inventing a > > different > > behavior for this condition than the existing one as of 1.1.1f > > would be > > clearly wrong. Switching on a SSL_OP if that newly provided OP is a > > trivial change to an application that needs to accommodate various > > versions of OpenSSL (and I am not talking about forks), however > > switching on a SSL_OP and also add another special error case is > > much > > more complicated change and has potential for bringing regressions > > in > > the applications that need to do it. > > Of course, just adding a call to get the old behaviour back is a > very easy change. But I currently don't see how a different error > is that much more complicated. > > > Is there really another situation where SSL_ERROR_SYSCALL with > > errno 0 > > could be returned apart from the unclean EOF condition? > > > > I can't really think of any. > > It's not because we can't think of any other case that there aren't > any. > > I also have a problem with checking errno being 0. We don't set > errno. There is no reason to assume that errno is set to any > value. errno can be modified on a succesful call. That errno is 0 > is just a coincidence. If we're going to document that, we should > actually make sure that that is the case. Actually the coincidence is that the errno is set to 0 on EOF. So yes, we should explicitly clear the errno on EOF so any leftover value from previous calls does not affect this. > I think the other property of the old behaviour is that we don't > add anything to the error stack. > > > So I would be just for properly documenting the condition and > > keeping > > it as is if the SSL_OP to ignore unclean EOF is in effect. > > And also don't add an option for applications that do want to get > a fatal error? Why another option? That would be the default behavior. But anyway I like the Matt's proposal even more. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From kurt at roeckx.be Thu May 7 13:45:08 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 7 May 2020 15:45:08 +0200 Subject: Unexpected EOF handling In-Reply-To: <0d431caa59774a7f72cb390219b41857b6753085.camel@redhat.com> References: <20200507112243.GA1853215@roeckx.be> <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> <20200507125327.GB1853215@roeckx.be> <0d431caa59774a7f72cb390219b41857b6753085.camel@redhat.com> Message-ID: <20200507134508.GC1853215@roeckx.be> On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So yes, > we should explicitly clear the errno on EOF so any leftover value from > previous calls does not affect this. On EOF, errno is normally not modified. It's value is not defined if no error is returned. It is not guaranteed to be 0 on success or EOF. It can be modified, because the implementation might have done other system calls that did return an error. But a simple test shows that it's not modified on my system. Kurt From tmraz at redhat.com Thu May 7 13:58:13 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 07 May 2020 15:58:13 +0200 Subject: Unexpected EOF handling In-Reply-To: <20200507134508.GC1853215@roeckx.be> References: <20200507112243.GA1853215@roeckx.be> <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> <20200507125327.GB1853215@roeckx.be> <0d431caa59774a7f72cb390219b41857b6753085.camel@redhat.com> <20200507134508.GC1853215@roeckx.be> Message-ID: <272acc26cd24c4f558d6017324d33f51b97ac8ab.camel@redhat.com> On Thu, 2020-05-07 at 15:45 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So > > yes, > > we should explicitly clear the errno on EOF so any leftover value > > from > > previous calls does not affect this. > > On EOF, errno is normally not modified. It's value is not defined > if no error is returned. It is not guaranteed to be 0 on success > or EOF. It can be modified, because the implementation might have > done other system calls that did return an error. But a simple test > shows that it's not modified on my system. > Yeah, that's what I actually meant, sorry for not being clear. I did not mean that the errno is explicitly set to 0 on EOF by the read call but that the errno is 0 because it is not modified and was 0 before coincidentally. -- 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 brian at briansmith.org Thu May 7 15:02:38 2020 From: brian at briansmith.org (Brian Smith) Date: Thu, 7 May 2020 10:02:38 -0500 Subject: Technically an API break In-Reply-To: References: Message-ID: Matt Caswell wrote: > PR11589 makes a change to the public API function > `SSL_set_record_padding_callback` to change its return type from void to > int: > > https://github.com/openssl/openssl/pull/11589 > > This is technically an API break - but it doesn't seem too serious. It's > possible, I suppose, that existing applications that use this will fail > to spot the error return since this function can now fail. The function > itself was only recently added (in 1.1.1), and I suspect real-world > usage is very small (or possibly nil). > > Is this considered ok? > This kind of change might cause memory unsafety issues unless the application is recompiled. At least, it's worth investigating that. On most platforms the ABI of a function that returns `void` and one that returns `int` is the same, from the perspective of a caller that doesn't expect or use the return value. I seem to vaguely remember in the past that there was at least one common platform where that isn't true though. Unfortunately I cannot remember which one it is. I also don't remember if it is problematic to change from "int" to "void" or "void" to "int" or both. Anyway, my point is that you should consider this an ABI-breaking change, not just an API breaking one. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu May 7 15:41:39 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 May 2020 16:41:39 +0100 Subject: Technically an API break In-Reply-To: References: Message-ID: On 07/05/2020 16:02, Brian Smith wrote: > This kind of change might cause memory unsafety issues unless the > application is recompiled. At least, it's worth investigating that. > > On most platforms the ABI of a function that returns `void` and one that > returns `int` is the same, from the perspective of a caller that?doesn't > expect or use the return value. I seem to vaguely remember in the past > that there was at least one common platform where that isn't true > though. Unfortunately I cannot remember which one it is. I also don't > remember if it is problematic to change from "int" to "void" or "void" > to "int" or both. > > Anyway, my point is that you should consider this an ABI-breaking > change, not just an API breaking one. Yes - thanks for that Brian. Actually though this change is targeted only at the master branch (which will become OpenSSL 3.0). That is a major release and is already ABI breaking - so recompilation is already a requirement. Actually as a major release we are allowed to be API breaking too, but we are trying to keep that to a minimum. Matt From matt at openssl.org Thu May 7 16:44:00 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 May 2020 17:44:00 +0100 Subject: Monthly Status Report (April) Message-ID: <9a1eab43-6a2d-73bc-965c-a195a8b94bca@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 review work on the CMP contribution - Fixed some issues with the XTS documentation - Updated WPACKET to be able to do "end first" writing to support DER_w_* functions - Make X509_STORE_CTX libctx aware - Updated the CT code to be library context aware - Enabled export_to functions to have access to the libctx - Made PrivateKey loading libctx aware - Enabled Ed25519/Ed448 signing/verifying to be libctx aware - Investigated and created a POC for CVE-2020-1967 - Made X509_verify() libctx aware - PR to run sslapitest with the FIPS module - PR to run ssl_test_new with the FIPS module - Investigated and fixed issue on website where the scripts failed if we only had one tarball - PR to run ssl_test_old with the FIPS module - Ensured calls to EC_POINT_point2buf use a libctx - Ensure import_to functions pass a libctx - Fixed an issue in libssl which resulted in no alert being sent even though a fatal error occurred - Wrote a wiki page about 3.0 - Performed the 1.1.1g release - Fixed no-des - Fixed no-ec - Fixed no-dh and no-dsa - Fixed no-deprecated tests when the GOST engine is present - Fixed no-err - Performed the alpha1 release - Fixed ssl_test_old when SSLv3 is enabled - Fixed typo in the makefile templates meaning that fips.so and legacy.so were not being installed - Fixed the raw provider key implementation - Performed the 1.0.2v release for premium support customers - Updated to the testsuite to centralise environment variable setting and fix a problem with test_includes Matt From beldmit at gmail.com Thu May 7 19:07:47 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 7 May 2020 22:07:47 +0300 Subject: Some more extra tests Message-ID: Dear colleagues, Let me draw your attention to a potentially reasonable set of extended tests for the openssl engines. The gost-engine project (https://github.com/gost-engine/engine) has some test scenarios robust enough for testing engine-provided algorithms and some basic RSA regression tests. It contains a rather eclectic set of C, Perl, and TCL(!) tests that are used by me on a regular basis. If these tests are included in the project extended test suite, they could reduce some regression that sometimes occurs (see https://github.com/gost-engine/engine/issues/232 as a current list of known problems). I will be happy to assist in enabling these tests as a part of openssl test suites. Many thanks! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu May 7 19:28:56 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 7 May 2020 22:28:56 +0300 Subject: Unexpected EOF handling In-Reply-To: <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> References: <20200507112243.GA1853215@roeckx.be> <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> Message-ID: Hello, I want to draw everybody's attention to the position (and argumentation) of Nginx developers: =========== As already mentioned by Dmitry, we here at nginx don't think the change was necessary. As Matt already said above in the comments to SSL_CONF_cmd.pod change, the error was always reported. The only issue is that SSL_ERROR_SYSCALL with a 0 errno is not properly documented. On the other hand, the behaviour was present since ancient OpenSSL versions, and actually tested in various software using OpenSSL library, including nginx. A better solution, in our opinion, would be to document the error instead. Right now the situation in OpenSSL 3.0 is that the error reporting behaviour was changed, and, if we are going to support OpenSSL 3.0, we have to introduce specific error testing for OpenSSL 3.0. And at the same time we have to support previous error reporting, since we support OpenSSL versions starting from OpenSSL 0.9.8, as well as other libraries such as BoringSSL and LibreSSL, which still report connection close with SSL_ERROR_SYSCALL with a 0 errno. For obvious reasons we don't want to support multiple code paths to test for the same error. Especially keeping in mind that due to BoringSSL and LibreSSL we probably have to support these multiple code paths forever. It would be really helpful if the change in question was reverted and the existing behaviour (that is, SSL_ERROR_SYSCALL with a 0 errno) was documented instead. =========== >From my point of view, if we don't revert the change for the sake of API clarity, we need to provide an option restoring old behaviour at least for test purposes. On Thu, May 7, 2020 at 2:52 PM Tomas Mraz wrote: > On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote: > > Hi, > > > > We introduced a change in the 1.1.1e release that changed how we > > handled an unexpected EOF. This broke various software which > > resulted in the release of 1.1.1f that reverted that change. > > In master we still have the 1.1.1e behaviour. > > > > The change itself is small, it just calls SSLfatal() with a new > > error code. This has at least 2 effects: > > - The error code was changed from SSL_ERROR_SYSCALL with errno 0 > > to SSL_ERROR_SSL with reason code > > SSL_R_UNEXPECTED_EOF_WHILE_READING > > - The session is marked as in error, and so can't be used to > > resume. > > > > There is code written that now checks for the SSL_ERROR_SYSCALL > > with errno 0 case, while we never documented that behaviour. The > > 1.1.1 manpage of SSL_get_error() currently reports this as a bug > > and that it will change to SSL_ERROR_SSL / > > SSL_R_UNEXPECTED_EOF_WHILE_READING. > > > > Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall > > in at least 2 categories: > > - Ignore the error > > - Check for the error, for instance in a test suite > > > > Not sending the close notify alert is a violation of the TLS > > specifications, but there is software out there doesn't send it, > > so there is a need to be able to deal with peers that don't send > > it. > > > > When the close notify alert wasn't received, but we did get an > > EOF, there are 2 cases: > > - It's a fatal error, the protocol needs the close notify alert to > > prevent a truncation attack > > - The protocol running on top of SSL can detect a truncation > > attack itself, and does so. It doesn't need the close notify > > alert. It's not a fatal error. They just want to check that that > > is what happened. > > > > The problem is that we can't make a distiction between the 2 > > cases, so the only thing we can do currently is to look at > > it as a fatal error. So the documentation was changed to say > > that if you're in the 2nd cases, and need to talk to a peer > > that doesn't send the close notify alert, you should not wait > > for the close notify alert, so that you don't get an error. > > > > The alternative is that we add an option that does tell us if we > > should look at it as a fatal error or not. > > > > There is at least a request that we keep returning the old error code > > (SSL_ERROR_SYSCALL with errno 0). I think that from an API point > > of view this is very confusing. We'd then have SSL_ERROR_SYSCALL > > as documented that it's fatal, except when errno is 0. If errno is > > 0, it can either be fatal or not, and we're not telling you which > > one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL > > with errno 0 is always the unexpected EOF, we returned that > > combination because of a bug in OpenSSL. > > > > So I think we need at least to agree on: > > - Do we want an option that makes the unexpected EOF either a fatal > > error or a non-fatal error? > > - Which error should we return? > > From application developer side of view for protocols that do not > depend on SSL detecting the truncation I think inventing a different > behavior for this condition than the existing one as of 1.1.1f would be > clearly wrong. Switching on a SSL_OP if that newly provided OP is a > trivial change to an application that needs to accommodate various > versions of OpenSSL (and I am not talking about forks), however > switching on a SSL_OP and also add another special error case is much > more complicated change and has potential for bringing regressions in > the applications that need to do it. > > It is also an API break, however we would do it anyway unless we make > the legacy behavior the default one, so that is not really relevant > here. > > Is there really another situation where SSL_ERROR_SYSCALL with errno 0 > could be returned apart from the unclean EOF condition? > > I can't really think of any. > > So I would be just for properly documenting the condition and keeping > it as is if the SSL_OP to ignore unclean EOF is in effect. > > -- > 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.] > > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Thu May 7 19:38:05 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 7 May 2020 21:38:05 +0200 Subject: Some more extra tests In-Reply-To: References: Message-ID: I would be interested in seeing a PR to see what enabling these tests would require! I believe we do indeed need to test more thoroughly to ensure we are not breaking the engine API! Nicola On Thu, May 7, 2020, 21:08 Dmitry Belyavsky wrote: > Dear colleagues, > > Let me draw your attention to a potentially reasonable set of extended > tests for the openssl engines. > > The gost-engine project (https://github.com/gost-engine/engine) has some > test scenarios robust enough for testing engine-provided algorithms and > some basic RSA regression tests. It contains a rather eclectic set of C, > Perl, and TCL(!) tests that are used by me on a regular basis. > > If these tests are included in the project extended test suite, they could > reduce some regression that sometimes occurs (see > https://github.com/gost-engine/engine/issues/232 as a current list of > known problems). > > I will be happy to assist in enabling these tests as a part of openssl > test suites. > Many thanks! > > -- > SY, Dmitry Belyavsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu May 7 19:55:04 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 7 May 2020 22:55:04 +0300 Subject: Some more extra tests In-Reply-To: References: Message-ID: Dear Nicola, I feel a significant lack of knowledge of preparing such a PR. If I was able to submit it, I would. On Thu, May 7, 2020 at 10:38 PM Nicola Tuveri wrote: > I would be interested in seeing a PR to see what enabling these tests > would require! > > I believe we do indeed need to test more thoroughly to ensure we are not > breaking the engine API! > > > Nicola > > On Thu, May 7, 2020, 21:08 Dmitry Belyavsky wrote: > >> Dear colleagues, >> >> Let me draw your attention to a potentially reasonable set of extended >> tests for the openssl engines. >> >> The gost-engine project (https://github.com/gost-engine/engine) has some >> test scenarios robust enough for testing engine-provided algorithms and >> some basic RSA regression tests. It contains a rather eclectic set of C, >> Perl, and TCL(!) tests that are used by me on a regular basis. >> >> If these tests are included in the project extended test suite, they >> could reduce some regression that sometimes occurs (see >> https://github.com/gost-engine/engine/issues/232 as a current list of >> known problems). >> >> I will be happy to assist in enabling these tests as a part of openssl >> test suites. >> Many thanks! >> >> -- >> SY, Dmitry Belyavsky >> > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu May 7 21:33:53 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 May 2020 22:33:53 +0100 Subject: Unexpected EOF handling In-Reply-To: References: <20200507112243.GA1853215@roeckx.be> <3c180cb0c6857c59ccd860bf22a7af36db309d8d.camel@redhat.com> Message-ID: <79141fb1-8f7b-cd44-c4ed-e7bf4cde261a@openssl.org> On 07/05/2020 20:28, Dmitry Belyavsky wrote: > From my point of view, if we don't revert the change for the sake of API > clarity, we need to provide an option restoring old behaviour at least > for test purposes. Presumably nginx can already handle the situation where a close_notify *is* received. So if we have an option to behave as if that had occurred in the event of eof then nginx should be able to handle it without requiring special codepaths?? If so then we don't necessarily have to have an option to restore the old behaviour - just an option to treat eof like a close_notify. Matt > > On Thu, May 7, 2020 at 2:52 PM Tomas Mraz > wrote: > > On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote: > > Hi, > > > > We introduced a change in the 1.1.1e release that changed how we > > handled an unexpected EOF. This broke various software which > > resulted in the release of 1.1.1f that reverted that change. > > In master we still have the 1.1.1e behaviour. > > > > The change itself is small, it just calls SSLfatal() with a new > > error code. This has at least 2 effects: > > - The error code was changed from SSL_ERROR_SYSCALL with errno 0 > >? ?to SSL_ERROR_SSL with reason code > >? ?SSL_R_UNEXPECTED_EOF_WHILE_READING > > - The session is marked as in error, and so can't be used to > >? ?resume. > > > > There is code written that now checks for the SSL_ERROR_SYSCALL > > with errno 0 case, while we never documented that behaviour. The > > 1.1.1 manpage of SSL_get_error() currently reports this as a bug > > and that it will change to SSL_ERROR_SSL / > > SSL_R_UNEXPECTED_EOF_WHILE_READING. > > > > Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall > > in at least 2 categories: > > - Ignore the error > > - Check for the error, for instance in a test suite > > > > Not sending the close notify alert is a violation of the TLS > > specifications, but there is software out there doesn't send it, > > so there is a need to be able to deal with peers that don't send > > it. > > > > When the close notify alert wasn't received, but we did get an > > EOF, there are 2 cases: > > - It's a fatal error, the protocol needs the close notify alert to > >? ?prevent a truncation attack > > - The protocol running on top of SSL can detect a truncation > >? ?attack itself, and does so. It doesn't need the close notify > >? ?alert. It's not a fatal error. They just want to check that that > >? ?is what happened. > > > > The problem is that we can't make a distiction between the 2 > > cases, so the only thing we can do currently is to look at > > it as a fatal error. So the documentation was changed to say > > that if you're in the 2nd cases, and need to talk to a peer > > that doesn't send the close notify alert, you should not wait > > for the close notify alert, so that you don't get an error. > > > > The alternative is that we add an option that does tell us if we > > should look at it as a fatal error or not. > > > > There is at least a request that we keep returning the old error code > > (SSL_ERROR_SYSCALL with errno 0). I think that from an API point > > of view this is very confusing. We'd then have SSL_ERROR_SYSCALL > > as documented that it's fatal, except when errno is 0. If errno is > > 0, it can either be fatal or not, and we're not telling you which > > one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL > > with errno 0 is always the unexpected EOF, we returned that > > combination because of a bug in OpenSSL. > > > > So I think we need at least to agree on: > > - Do we want an option that makes the unexpected EOF either a fatal > >? ?error or a non-fatal error? > > - Which error should we return? > > From application developer side of view for protocols that do not > depend on SSL detecting the truncation I think inventing a different > behavior for this condition than the existing one as of 1.1.1f would be > clearly wrong. Switching on a SSL_OP if that newly provided OP is a > trivial change to an application that needs to accommodate various > versions of OpenSSL (and I am not talking about forks), however > switching on a SSL_OP and also add another special error case is much > more complicated change and has potential for bringing regressions in > the applications that need to do it. > > It is also an API break, however we would do it anyway unless we make > the legacy behavior the default one, so that is not really relevant > here. > > Is there really another situation where SSL_ERROR_SYSCALL with errno 0 > could be returned apart from the unclean EOF condition? > > I can't really think of any. > > So I would be just for properly documenting the condition and keeping > it as is if the SSL_OP to ignore unclean EOF is in effect. > > -- > 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.] > > > > > -- > SY, Dmitry Belyavsky From paul.dale at oracle.com Fri May 8 05:08:07 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 8 May 2020 15:08:07 +1000 Subject: OMC Vote on deprecation of command line apps Message-ID: <944D72C4-582A-452D-BAE0-44F881130973@oracle.com> PR 11575 has been blocking awaiting decision for a while now. Time for a vote: topic: Merge #11575 for 3.0. comment: This PR removes the notes indicating that a number of the command line utilities are deprecated. Not merging it will leave them flagged as deprecated. Proposed by: Paul Dale Public: yes opened: 2020-05-08 Ideally we?ll have a decision in time for the next 3.0 alpha release. The crux of the matter is that a number of the command line utilities are flagged as deprecated currently: dhparam dsa dsaparam ec ecparam agendas rsa These commands are not being removed in 3.0, instead they?ve been rewritten to use the PKEY APIs instead of the low level APIs as far as possible. The reasons for keeping them are: they are easier to use than the pkey replacements a web search will likely result in thees commands not the pkey replacements. The reason for removing them is one of maintenance: having duplicate commands means having to make changes in two places and this has been missed in the past and will be in the future. Other random notes: Deprecation of these commands does not mandate that they are removed at the first opportunity. It only indicates that we want to move away from them. Rewriting these commands so that they call the pkey replacements looks to be very difficult. Reproducing the exact behaviours will be challenging, although the basic functionality would be straightforward. The rsautl command is deprecated and isn?t slated for being restored ? pkeyutl is every bit as easy to use. The -dsaparam option to dhparam is deprecated ? it cannot be supported without direct access to low level functionality we want to remove. Post quantum crypto will make the discussion obsolete ? none of these algorithms are useful in a quantum computer world. My personal opinion is that these commands are good being deprecated but that we should not remove them until their usefulness is at an end. This will likely mean not removing them after five years of deprecation. It would mean removing them once quantum computers are shown to be effective. Without deprecation now, we can?t remove them until a lot later. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri May 8 08:55:19 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 May 2020 09:55:19 +0100 Subject: Alpha2 Message-ID: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss current progress. It was proposed that we should do the Alpha 2 release next week (on Thursday 14th May). Unless I hear objections otherwise, I plan to go with that. Matt From beldmit at gmail.com Fri May 8 08:58:18 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 8 May 2020 11:58:18 +0300 Subject: Alpha2 In-Reply-To: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> References: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> Message-ID: Dear Matt, I kindly ask not to make release until issues raised in #11763 and #11764 are fixed. On Fri, May 8, 2020 at 11:55 AM Matt Caswell wrote: > Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss > current progress. It was proposed that we should do the Alpha 2 release > next week (on Thursday 14th May). Unless I hear objections otherwise, I > plan to go with that. > > Matt > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Fri May 8 10:09:57 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 8 May 2020 12:09:57 +0200 Subject: Unexpected EOF handling In-Reply-To: References: <20200507112243.GA1853215@roeckx.be> <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> Message-ID: <20200508100957.GA1917430@roeckx.be> On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > So I think we need at least to agree on: > > > - Do we want an option that makes the unexpected EOF either a fatal > > > error or a non-fatal error? > > > - Which error should we return? > > > > This is an excellent summary of the current situation. > > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a > > long term solution. It's a very confusing API for new applications to > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except > > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > > > That said I also recognise that it is apparently commonplace to shut > > down a TLS connection without sending close_notify - despite what the > > standards may say about it (and TBH we can hardly claim the moral > > high > > ground here since s_server does exactly this - or at least it does in > > 1.1.1 and did until very recently in master). > > > > But we do have to consider usages beyond HTTPS. I have no idea if > > this > > occurs in other settings or not. > > > > Perhaps what we need is an option for "strict shutdown". With strict > > shutdown "off" we could treat EOF as if we had received a > > close_notify > > gracefully (and don't invalidate the session). Presumably existing > > code > > would be able to cope with that??? > > Yes, existing code would be able to cope with that with one important > exception that I am going to talk about below. > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > > master). > > > > I'm not sure though what the default should be. > > In case we go with this solution, which would be acceptable I think, we > MUST NOT EVER make it the default because existing applications that > depend on the existing way how the unclean EOF condition is returned > might actually depend on it to detect the truncation attack. I agree that we should not return SSL_ERROR_ZERO_RETURN by default on an unexpected EOF. If the default behaviour should be to make it a non-fatal error, like the old behaviour is, I would really prefer a different error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL. So I think the suggestion is to have this: - By default, SSL_ERROR_SSL is returned with SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be marked invalid. - With an option, SSL_ERROR_ZERO_RETURN is returned, the session will stay valid. Kurt From beldmit at gmail.com Fri May 8 10:27:00 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 8 May 2020 13:27:00 +0300 Subject: Unexpected EOF handling In-Reply-To: <20200508100957.GA1917430@roeckx.be> References: <20200507112243.GA1853215@roeckx.be> <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> <20200508100957.GA1917430@roeckx.be> Message-ID: Dear Kurt On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote: > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > So I think we need at least to agree on: > > > > - Do we want an option that makes the unexpected EOF either a fatal > > > > error or a non-fatal error? > > > > - Which error should we return? > > > > > > This is an excellent summary of the current situation. > > > > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a > > > long term solution. It's a very confusing API for new applications to > > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except > > > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > > > > > That said I also recognise that it is apparently commonplace to shut > > > down a TLS connection without sending close_notify - despite what the > > > standards may say about it (and TBH we can hardly claim the moral > > > high > > > ground here since s_server does exactly this - or at least it does in > > > 1.1.1 and did until very recently in master). > > > > > > But we do have to consider usages beyond HTTPS. I have no idea if > > > this > > > occurs in other settings or not. > > > > > > Perhaps what we need is an option for "strict shutdown". With strict > > > shutdown "off" we could treat EOF as if we had received a > > > close_notify > > > gracefully (and don't invalidate the session). Presumably existing > > > code > > > would be able to cope with that??? > > > > Yes, existing code would be able to cope with that with one important > > exception that I am going to talk about below. > > > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > > > master). > > > > > > I'm not sure though what the default should be. > > > > In case we go with this solution, which would be acceptable I think, we > > MUST NOT EVER make it the default because existing applications that > > depend on the existing way how the unclean EOF condition is returned > > might actually depend on it to detect the truncation attack. > > I agree that we should not return SSL_ERROR_ZERO_RETURN by default > on an unexpected EOF. > > If the default behaviour should be to make it a non-fatal error, > like the old behaviour is, I would really prefer a different > error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL. > > So I think the suggestion is to have this: > - By default, SSL_ERROR_SSL is returned with > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > marked invalid. > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session > will stay valid. > If I remember correctly, session resumption is a way to significantly reduce a server's workload. So I think that by default (and maybe the only option) we should prefer the old behaviour. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Fri May 8 10:42:59 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 8 May 2020 12:42:59 +0200 Subject: Unexpected EOF handling In-Reply-To: References: <20200507112243.GA1853215@roeckx.be> <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> <20200508100957.GA1917430@roeckx.be> Message-ID: <20200508104259.GB1917430@roeckx.be> On Fri, May 08, 2020 at 01:27:00PM +0300, Dmitry Belyavsky wrote: > On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote: > > > > So I think the suggestion is to have this: > > - By default, SSL_ERROR_SSL is returned with > > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > > marked invalid. > > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session > > will stay valid. > > > > If I remember correctly, session resumption is a way to significantly > reduce a server's workload. > So I think that by default (and maybe the only option) we should prefer the > old behaviour. If it's a fatal error, the session should be marked as bad. So if you want that by default we don't mark is as bad, the default should be that it's a non-fatal error, and we don't want to return SSL_ERROR_ZERO_RETURN by default. SSL_ERROR_SYSCALL with errno 0 does not look like a good long term API to indicate a non-fatal error. And a different error is also not what people want. Kurt From beldmit at gmail.com Fri May 8 16:40:35 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 8 May 2020 19:40:35 +0300 Subject: Alpha2 In-Reply-To: References: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> Message-ID: Dear Matt, The workaround for the 11763 is implemented, 11764 seems to be fixed now, so no objections from my side. Happy weekend! On Fri, May 8, 2020 at 11:58 AM Dmitry Belyavsky wrote: > Dear Matt, > > I kindly ask not to make release until issues raised in #11763 and #11764 > are fixed. > > On Fri, May 8, 2020 at 11:55 AM Matt Caswell wrote: > >> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss >> current progress. It was proposed that we should do the Alpha 2 release >> next week (on Thursday 14th May). Unless I hear objections otherwise, I >> plan to go with that. >> >> Matt >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri May 8 17:23:34 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 08 May 2020 19:23:34 +0200 Subject: Alpha2 In-Reply-To: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> References: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> Message-ID: <87r1vucpd5.wl-levitte@openssl.org> You might want to consider reviewing #11630, an reminding me what else needs to get fixed in there. On Fri, 08 May 2020 10:55:19 +0200, Matt Caswell wrote: > > Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss > current progress. It was proposed that we should do the Alpha 2 release > next week (on Thursday 14th May). Unless I hear objections otherwise, I > plan to go with that. > > Matt > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Fri May 8 23:43:22 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 9 May 2020 09:43:22 +1000 Subject: OMC Vote on deprecation of command line apps In-Reply-To: <944D72C4-582A-452D-BAE0-44F881130973@oracle.com> References: <944D72C4-582A-452D-BAE0-44F881130973@oracle.com> Message-ID: This vote has passed: 3 for, 1 against and 2 abstentions. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 8 May 2020, at 3:08 pm, Dr Paul Dale wrote: > > PR 11575 has been blocking awaiting decision for a while now. Time for a vote: > > topic: Merge #11575 for 3.0. > comment: This PR removes the notes indicating that a number of the command > line utilities are deprecated. Not merging it will leave them flagged > as deprecated. > Proposed by: Paul Dale > Public: yes > opened: 2020-05-08 > > Ideally we?ll have a decision in time for the next 3.0 alpha release. > > > The crux of the matter is that a number of the command line utilities are flagged as deprecated currently: > dhparam > dsa > dsaparam > ec > ecparam > agendas > rsa > These commands are not being removed in 3.0, instead they?ve been rewritten to use the PKEY APIs instead of the low level APIs as far as possible. > > > The reasons for keeping them are: > they are easier to use than the pkey replacements > a web search will likely result in thees commands not the pkey replacements. > > The reason for removing them is one of maintenance: having duplicate commands means having to make changes in two places and this has been missed in the past and will be in the future. > > > Other random notes: > Deprecation of these commands does not mandate that they are removed at the first opportunity. It only indicates that we want to move away from them. > Rewriting these commands so that they call the pkey replacements looks to be very difficult. Reproducing the exact behaviours will be challenging, although the basic functionality would be straightforward. > The rsautl command is deprecated and isn?t slated for being restored ? pkeyutl is every bit as easy to use. > The -dsaparam option to dhparam is deprecated ? it cannot be supported without direct access to low level functionality we want to remove. > Post quantum crypto will make the discussion obsolete ? none of these algorithms are useful in a quantum computer world. > > My personal opinion is that these commands are good being deprecated but that we should not remove them until their usefulness is at an end. This will likely mean not removing them after five years of deprecation. It would mean removing them once quantum computers are shown to be effective. Without deprecation now, we can?t remove them until a lot later. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Mon May 11 11:07:30 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 11 May 2020 13:07:30 +0200 Subject: Unexpected EOF handling In-Reply-To: <20200508100957.GA1917430@roeckx.be> References: <20200507112243.GA1853215@roeckx.be> <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> <20200508100957.GA1917430@roeckx.be> Message-ID: <182be42230280c3d817a044be4f92c924a3fc97f.camel@redhat.com> On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > So I think we need at least to agree on: > > > > - Do we want an option that makes the unexpected EOF either a > > > > fatal > > > > error or a non-fatal error? > > > > - Which error should we return? > > > > > > This is an excellent summary of the current situation. > > > > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno > > > as a > > > long term solution. It's a very confusing API for new > > > applications to > > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - > > > except > > > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > > > > > That said I also recognise that it is apparently commonplace to > > > shut > > > down a TLS connection without sending close_notify - despite what > > > the > > > standards may say about it (and TBH we can hardly claim the moral > > > high > > > ground here since s_server does exactly this - or at least it > > > does in > > > 1.1.1 and did until very recently in master). > > > > > > But we do have to consider usages beyond HTTPS. I have no idea if > > > this > > > occurs in other settings or not. > > > > > > Perhaps what we need is an option for "strict shutdown". With > > > strict > > > shutdown "off" we could treat EOF as if we had received a > > > close_notify > > > gracefully (and don't invalidate the session). Presumably > > > existing > > > code > > > would be able to cope with that??? > > > > Yes, existing code would be able to cope with that with one > > important > > exception that I am going to talk about below. > > > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > > > master). > > > > > > I'm not sure though what the default should be. > > > > In case we go with this solution, which would be acceptable I > > think, we > > MUST NOT EVER make it the default because existing applications > > that > > depend on the existing way how the unclean EOF condition is > > returned > > might actually depend on it to detect the truncation attack. > > I agree that we should not return SSL_ERROR_ZERO_RETURN by default > on an unexpected EOF. > > If the default behaviour should be to make it a non-fatal error, > like the old behaviour is, I would really prefer a different > error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL. > > So I think the suggestion is to have this: > - By default, SSL_ERROR_SSL is returned with > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > marked invalid. > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session > will stay valid. +1 And my suggestion for the SSL_OP name is SSL_OP_IGNORE_UNEXPECTED_EOF. Dmitry, I think this solution should be working well for nginx and similar http related applications. They just need to use the SSL_OP_IGNORE_UNEXPECTED_EOF and the peers that do not properly terminate the TLS session will just appear as if they properly terminated 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 beldmit at gmail.com Mon May 11 14:15:59 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 11 May 2020 17:15:59 +0300 Subject: Some more extra tests In-Reply-To: References: Message-ID: Dear Nicola, Please see https://github.com/openssl/openssl/pull/11792 It currently does not enable TCL and Perl tests, but the C tests also helped me to find regression in the master branch. On Thu, May 7, 2020 at 10:55 PM Dmitry Belyavsky wrote: > Dear Nicola, > > I feel a significant lack of knowledge of preparing such a PR. > If I was able to submit it, I would. > > On Thu, May 7, 2020 at 10:38 PM Nicola Tuveri wrote: > >> I would be interested in seeing a PR to see what enabling these tests >> would require! >> >> I believe we do indeed need to test more thoroughly to ensure we are not >> breaking the engine API! >> >> >> Nicola >> >> On Thu, May 7, 2020, 21:08 Dmitry Belyavsky wrote: >> >>> Dear colleagues, >>> >>> Let me draw your attention to a potentially reasonable set of extended >>> tests for the openssl engines. >>> >>> The gost-engine project (https://github.com/gost-engine/engine) has >>> some test scenarios robust enough for testing engine-provided algorithms >>> and some basic RSA regression tests. It contains a rather eclectic set of >>> C, Perl, and TCL(!) tests that are used by me on a regular basis. >>> >>> If these tests are included in the project extended test suite, they >>> could reduce some regression that sometimes occurs (see >>> https://github.com/gost-engine/engine/issues/232 as a current list of >>> known problems). >>> >>> I will be happy to assist in enabling these tests as a part of openssl >>> test suites. >>> Many thanks! >>> >>> -- >>> SY, Dmitry Belyavsky >>> >> > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon May 11 15:38:40 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 11 May 2020 18:38:40 +0300 Subject: Unexpected EOF handling In-Reply-To: <182be42230280c3d817a044be4f92c924a3fc97f.camel@redhat.com> References: <20200507112243.GA1853215@roeckx.be> <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> <20200508100957.GA1917430@roeckx.be> <182be42230280c3d817a044be4f92c924a3fc97f.camel@redhat.com> Message-ID: Dear Tomas, On Mon, May 11, 2020 at 2:07 PM Tomas Mraz wrote: > On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote: > > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > > So I think we need at least to agree on: > > > > > - Do we want an option that makes the unexpected EOF either a > > > > > fatal > > > > > error or a non-fatal error? > > > > > - Which error should we return? > > > > > > > > This is an excellent summary of the current situation. > > > > > > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno > > > > as a > > > > long term solution. It's a very confusing API for new > > > > applications to > > > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - > > > > except > > > > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > > > > > > > That said I also recognise that it is apparently commonplace to > > > > shut > > > > down a TLS connection without sending close_notify - despite what > > > > the > > > > standards may say about it (and TBH we can hardly claim the moral > > > > high > > > > ground here since s_server does exactly this - or at least it > > > > does in > > > > 1.1.1 and did until very recently in master). > > > > > > > > But we do have to consider usages beyond HTTPS. I have no idea if > > > > this > > > > occurs in other settings or not. > > > > > > > > Perhaps what we need is an option for "strict shutdown". With > > > > strict > > > > shutdown "off" we could treat EOF as if we had received a > > > > close_notify > > > > gracefully (and don't invalidate the session). Presumably > > > > existing > > > > code > > > > would be able to cope with that??? > > > > > > Yes, existing code would be able to cope with that with one > > > important > > > exception that I am going to talk about below. > > > > > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > > > > master). > > > > > > > > I'm not sure though what the default should be. > > > > > > In case we go with this solution, which would be acceptable I > > > think, we > > > MUST NOT EVER make it the default because existing applications > > > that > > > depend on the existing way how the unclean EOF condition is > > > returned > > > might actually depend on it to detect the truncation attack. > > > > I agree that we should not return SSL_ERROR_ZERO_RETURN by default > > on an unexpected EOF. > > > > If the default behaviour should be to make it a non-fatal error, > > like the old behaviour is, I would really prefer a different > > error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL. > > > > So I think the suggestion is to have this: > > - By default, SSL_ERROR_SSL is returned with > > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > > marked invalid. > > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session > > will stay valid. > > +1 > > And my suggestion for the SSL_OP name is SSL_OP_IGNORE_UNEXPECTED_EOF. > > Dmitry, I think this solution should be working well for nginx and > similar http related applications. They just need to use the > SSL_OP_IGNORE_UNEXPECTED_EOF and the peers that do not properly > terminate the TLS session will just appear as if they properly > terminated it. > I'm not sure this is the best possible solution because it makes the application developers doing extra compile-time checks. But anyway, is it a final decision and the patch can be amended or we are waiting for objections some more time? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Mon May 11 18:31:13 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 11 May 2020 20:31:13 +0200 Subject: Unexpected EOF handling In-Reply-To: References: <20200507112243.GA1853215@roeckx.be> <3eaf9aa0-8529-8567-f9b4-0f0c22950300@openssl.org> <20200508100957.GA1917430@roeckx.be> <182be42230280c3d817a044be4f92c924a3fc97f.camel@redhat.com> Message-ID: <20200511183113.GA2209823@roeckx.be> On Mon, May 11, 2020 at 06:38:40PM +0300, Dmitry Belyavsky wrote: > Dear Tomas, > > I'm not sure this is the best possible solution because it makes the > application developers doing extra compile-time checks. This is a very minimal change they they need to do that doesn't have much risk. But if you have a different suggestion, please say so. > But anyway, is it a final decision and the patch can be amended or we are > waiting for objections some more time? I think there is just a concensus that that is the way forward. There has not been a vote, nor do I see a reason to hold a vote at this point. Kurt From mark at openssl.org Tue May 12 09:17:14 2020 From: mark at openssl.org (Mark J Cox) Date: Tue, 12 May 2020 10:17:14 +0100 Subject: Prenotification policy change In-Reply-To: References: Message-ID: FYI The OMC voted last week to update the security policy extending prenotifications[1] and we've just released a blog explaining this change[2] [1] https://github.com/openssl/web/pull/176/files [2] https://www.openssl.org/blog/blog/2020/05/12/security-prenotifications/ Regards, Mark From matt at openssl.org Wed May 13 16:00:35 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 May 2020 17:00:35 +0100 Subject: Alpha2 In-Reply-To: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> References: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> Message-ID: <48b50f6f-021a-3297-236e-e64258c165c5@openssl.org> On 08/05/2020 09:55, Matt Caswell wrote: > Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss > current progress. It was proposed that we should do the Alpha 2 release > next week (on Thursday 14th May). Unless I hear objections otherwise, I > plan to go with that. I'm currently thinking that we're not quite ready for alpha2 and I would like to push it by a day. Any objections? At the dev meeting on Tuesday we discussed a slight change of approach with the alpha releases, i.e. rather than have a set number of alpha releases - we would simply do them every 3 weeks or so. I'd like to hear opinions on that proposal too. Matt From rsalz at akamai.com Wed May 13 16:02:05 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 13 May 2020 16:02:05 +0000 Subject: Alpha2 In-Reply-To: <48b50f6f-021a-3297-236e-e64258c165c5@openssl.org> References: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> <48b50f6f-021a-3297-236e-e64258c165c5@openssl.org> Message-ID: <20F87095-5844-41EB-A6DE-7F6A78C416DB@akamai.com> > releases - we would simply do them every 3 weeks or so. I'd like to hear opinions on that proposal too. I am in favor of this, but you HAVE to keep the cadence regular: no slipping. From Tim.Chevalier at netapp.com Wed May 13 16:35:56 2020 From: Tim.Chevalier at netapp.com (Chevalier, Tim) Date: Wed, 13 May 2020 16:35:56 +0000 Subject: Alpha2 In-Reply-To: <20F87095-5844-41EB-A6DE-7F6A78C416DB@akamai.com> References: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> <48b50f6f-021a-3297-236e-e64258c165c5@openssl.org> <20F87095-5844-41EB-A6DE-7F6A78C416DB@akamai.com> Message-ID: We're ok with regularly scheduled alpha releases. ?-----Original Message----- From: openssl-project on behalf of "Salz, Rich" Date: Wednesday, May 13, 2020 at 12:03 PM To: Matt Caswell , "openssl-project at openssl.org" Subject: Re: Alpha2 NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. > releases - we would simply do them every 3 weeks or so. I'd like to hear opinions on that proposal too. I am in favor of this, but you HAVE to keep the cadence regular: no slipping. From levitte at openssl.org Thu May 14 08:00:03 2020 From: levitte at openssl.org (Richard Levitte) Date: Thu, 14 May 2020 10:00:03 +0200 Subject: Alpha2 In-Reply-To: <48b50f6f-021a-3297-236e-e64258c165c5@openssl.org> References: <0813bdc5-6529-280e-10c5-43d59afb7e21@openssl.org> <48b50f6f-021a-3297-236e-e64258c165c5@openssl.org> Message-ID: <87lflvc5fg.wl-levitte@openssl.org> On Wed, 13 May 2020 18:00:35 +0200, Matt Caswell wrote: > > On 08/05/2020 09:55, Matt Caswell wrote: > > Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss > > current progress. It was proposed that we should do the Alpha 2 release > > next week (on Thursday 14th May). Unless I hear objections otherwise, I > > plan to go with that. > > I'm currently thinking that we're not quite ready for alpha2 and I would > like to push it by a day. Any objections? Not from me... among others, I want to see #11758 in there... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu May 14 17:52:39 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 14 May 2020 18:52:39 +0100 Subject: Repo is frozen Message-ID: The repo is frozen is readiness for the alpha2 release. I'll let you know when it is available again. Matt From rsalz at akamai.com Fri May 15 14:00:49 2020 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 May 2020 14:00:49 +0000 Subject: error conversion macro's Message-ID: Perhaps the next Alpha release can do the error macro conversion? Add script to convert XXXerr() to XXXerror, https://github.com/openssl/openssl/pull/9441 In particular, https://github.com/openssl/openssl/pull/9441#issuecomment-522171044 It might need updating if any new ?error facility? values have been added, but I didn?t notice any of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Fri May 15 14:19:59 2020 From: openssl at openssl.org (OpenSSL) Date: Fri, 15 May 2020 14:19:59 +0000 Subject: OpenSSL version 3.0.0-alpha2 published Message-ID: <20200515141959.GA21247@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 2 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 2 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-alpha2.tar.gz Size: 9601205 SHA1 checksum: 9224a8957232db61b1e9cf1a80b3a19165f47236 SHA256 checksum: 9077d53d889f9708c261ee8a698df10575e2fd191de6924d89136b97dc8bc0c0 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha2.tar.gz openssl sha256 openssl-3.0.0-alpha2.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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6+miwACgkQ2cTSbQ5g RJFqZggAhQGdzxbmbIa6aKeaX3sNpIYEpnu1W3htP/d2tMuqUlv31qG+IKZEnqHy kk/rhpHj9XU08MurpZ9caALayA3WNSpZXCwzpG85pgIm/KlwM2YN2CdmFCuh/G4K sMyU8UgSEcuEfF7BpYNgmfifYxDdRJjlrnrHwBPpFRJ0MdvS+8GN0a9n9b3o2eOm u2Dnub85W7NUH4St4YdKqDfxUF3rIPg+hvgOllb8JjZAqbrnCkeFek2SL9fVYJBM ORy3QODr2ahOo5sOYi61y7qe/MpcLdyjr5btm0L/xggWjBJ+EOo7m1iG2eQdzE88 AvcvALAtph/vmvfU3uPGWL7ms3z9Jg== =ixcT -----END PGP SIGNATURE----- From matt at openssl.org Fri May 15 14:24:24 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 15 May 2020 15:24:24 +0100 Subject: Repo is frozen In-Reply-To: References: Message-ID: The release is now complete, and the repo is unfrozen. Matt On 14/05/2020 18:52, Matt Caswell wrote: > The repo is frozen is readiness for the alpha2 release. > > I'll let you know when it is available again. > > Matt > From levitte at openssl.org Fri May 15 19:24:38 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 15 May 2020 21:24:38 +0200 Subject: error conversion macro's In-Reply-To: References: Message-ID: <87tv0ht30p.wl-levitte@openssl.org> We can, given time. This is one of those things that can be saved for the beta period, since it doesn't affect anything public. But sure, if someone feel inclined to do that earlier, I don't see why that should be a problem. Cheers, Richard On Fri, 15 May 2020 16:00:49 +0200, Salz, Rich wrote: > Perhaps the next Alpha release can do the error macro conversion? > > Add script to convert XXXerr() to XXXerror, https://github.com/openssl/openssl/pull/9441 > > In particular, https://github.com/openssl/openssl/pull/9441#issuecomment-522171044 > > It might need updating if any new ?error facility? values have been added, but I didn?t notice any > of them. > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue May 19 07:42:10 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 May 2020 08:42:10 +0100 Subject: Alpha2 blog post Message-ID: Nicola has kindly written another blog post for us - this time on the alpha 2 release. I've just published it, and you can read it here: https://www.openssl.org/blog/blog/2020/05/16/OpenSSL3.0Alpha2/ Matt From matt at openssl.org Wed May 27 11:14:13 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 May 2020 12:14:13 +0100 Subject: Reducing the security bits for MD5 and SHA1 in TLS Message-ID: <38fdd617-86ca-0440-e259-964863989e43@openssl.org> 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: "The TLS security bit values for MD5, MD5_SHA1 and SHA1 should be set to 39, 67 and 65 respectively in OpenSSL 3.0. Consequently TLS < 1.2 will be disallowed in the default security level" Thoughts? Matt From tmraz at redhat.com Wed May 27 11:28:59 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 27 May 2020 13:28:59 +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: <0b577c0ae42c611c67526190c48ba6ad2f8cb456.camel@redhat.com> On Wed, 2020-05-27 at 12:14 +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: > > "The TLS security bit values for MD5, MD5_SHA1 and SHA1 should be set > to > 39, 67 and 65 respectively in OpenSSL 3.0. Consequently TLS < 1.2 > will > be disallowed in the default security level" > > Thoughts? +1 I do not even think this is too much controversial to do in a major release. The only possibly controversial thing is the handling of the certificates signed with SHA1 and especially rejecting the client certificates on the client side before they are sent to the server. That is the: https://github.com/openssl/openssl/issues/11702 -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From rsalz at akamai.com Wed May 27 13:37:08 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 May 2020 13:37:08 +0000 Subject: Reducing the security bits for MD5 and SHA1 in TLS In-Reply-To: <0b577c0ae42c611c67526190c48ba6ad2f8cb456.camel@redhat.com> References: <38fdd617-86ca-0440-e259-964863989e43@openssl.org> <0b577c0ae42c611c67526190c48ba6ad2f8cb456.camel@redhat.com> Message-ID: <9EA74D7A-39BE-44B5-B0C0-3CD635CB43C3@akamai.com> If you do this, you should add a FAQ (in addition to NEWS) explaining it. From Matthias.St.Pierre at ncp-e.com Wed May 27 14:16:17 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 27 May 2020 14:16:17 +0000 Subject: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote? Message-ID: > IMO it seems appropriate to have an OMC vote on this topic (or should it > be OTC?). Possible wording: Personally, I would prefer if technical questions would by default be discussed (and voted on) by the OTC, unless an OMC member explicitly puts in his veto and claims that higher level strategical interests of the OpenSSL project are affected. But according to the current wording of the bylaws, I would say it is a 'feature requirement' and requires an OMC vote: > The OMC: > > * 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; Matthias From tmraz at redhat.com Wed May 27 14:33:56 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 27 May 2020 16:33:56 +0200 Subject: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote? In-Reply-To: References: Message-ID: <02a98e6ef8c63c5ac03df95752919068849d8f9b.camel@redhat.com> On Wed, 2020-05-27 at 14:16 +0000, Dr. Matthias St. Pierre wrote: > > IMO it seems appropriate to have an OMC vote on this topic (or > > should it > > be OTC?). Possible wording: > > Personally, I would prefer if technical questions would by default be > discussed (and voted on) > by the OTC, unless an OMC member explicitly puts in his veto and > claims that higher level > strategical interests of the OpenSSL project are affected. > > But according to the current wording of the bylaws, I would say it is > a 'feature requirement' and > requires an OMC vote: I do not understand this to be a 'feature requirement' - IMO if this was a 'feature requirement' it would mean that OMC decides that something must be implemented in such and such way that the OpenSSL 3.0 does this and that as a feature. But we do not do that for every feature that is being added to master. So I do not even think this requires any formal vote, unless someone from OTC or OMC calls for it explicitly. Of course it is kind-of API break but again I do not think every API break in OpenSSL 3.0 was voted upon by OMC. I mean I am definitely not against having a vote if someone feels it should be done but if nobody requires it, I do not think it would be a violation of anything if this is merged without a vote. > > The OMC: > > > > * 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; > > Matthias > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From Matthias.St.Pierre at ncp-e.com Wed May 27 14:46:32 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 27 May 2020 14:46:32 +0000 Subject: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote? In-Reply-To: <02a98e6ef8c63c5ac03df95752919068849d8f9b.camel@redhat.com> References: <02a98e6ef8c63c5ac03df95752919068849d8f9b.camel@redhat.com> Message-ID: > I mean I am definitely not against having a vote if someone feels it > should be done but if nobody requires it, I do not think it would be a > violation of anything if this is merged without a vote. Tom?? I dont't mind following your viewpoint at all, and if the OMC thinks the same, that's fine. Also, I agree that an OTC/OMC discussion does not automatically have to be resolved by an OTC/OMC vote. Maybe my original post was a bit misleading. The main motivation behind it was my impression that we tend to start many technical discussions with a general discussion about whether it should be discussed/decided by the OMC or the OTC. Matthias From matt at openssl.org Wed May 27 14:48:26 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 May 2020 15:48:26 +0100 Subject: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote? In-Reply-To: <02a98e6ef8c63c5ac03df95752919068849d8f9b.camel@redhat.com> References: <02a98e6ef8c63c5ac03df95752919068849d8f9b.camel@redhat.com> Message-ID: <0b9f8269-c58a-6593-0ade-2f9bb8449478@openssl.org> On 27/05/2020 15:33, Tomas Mraz wrote: > On Wed, 2020-05-27 at 14:16 +0000, Dr. Matthias St. Pierre wrote: >>> IMO it seems appropriate to have an OMC vote on this topic (or >>> should it >>> be OTC?). Possible wording: >> >> Personally, I would prefer if technical questions would by default be >> discussed (and voted on) >> by the OTC, unless an OMC member explicitly puts in his veto and >> claims that higher level >> strategical interests of the OpenSSL project are affected. >> >> But according to the current wording of the bylaws, I would say it is >> a 'feature requirement' and >> requires an OMC vote: > > I do not understand this to be a 'feature requirement' - IMO if this > was a 'feature requirement' it would mean that OMC decides that > something must be implemented in such and such way that the OpenSSL 3.0 > does this and that as a feature. But we do not do that for every > feature that is being added to master. So I do not even think this > requires any formal vote, unless someone from OTC or OMC calls for it > explicitly. > > Of course it is kind-of API break but again I do not think every API > break in OpenSSL 3.0 was voted upon by OMC. > > I mean I am definitely not against having a vote if someone feels it > should be done but if nobody requires it, I do not think it would be a > violation of anything if this is merged without a vote. I think there should be a vote. IMO such a significant break should be done as a result of a positive decision and not on the basis of a very small number of people approving a PR. I can see arguments both ways for it being an OTC vote or an OMC vote. To an extent it is purely a technical decision i.e. to answer the question: "does it technically make sense to make this change?" It also has a business requirements aspect to it i.e. to answer the question "would this have such a significant impact on the OpenSSL user base that, regardless of its technical merits, we still shouldn't do it?" On reflection though I'm not sure that the technical merits of this are particularly controversial. So I'm thinking that the OMC is still the right forum for this. However if someone else thinks that the *technical* arguments are controversial there is no reason why we couldn't have an OTC vote *as well*. I won't be proposing that though. Matt From beldmit at gmail.com Sun May 31 09:44:07 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 31 May 2020 12:44:07 +0300 Subject: Detecting Bad OpenSSL Usage Message-ID: Hello, Here is a nice article about a tool desired to catch misuse of the OpenSSL API. https://blog.trailofbits.com/2020/05/29/detecting-bad-openssl-usage/ I'm not sure whether it's worth using by the team but maybe it's worth mentioning in OpenSSL Wiki. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun May 31 13:50:24 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 31 May 2020 13:50:24 +0000 Subject: Detecting Bad OpenSSL Usage In-Reply-To: References: Message-ID: It would be really interesting to run this over the apps. Maybe reach out to the author for help with that? From: Dmitry Belyavsky Date: Sunday, May 31, 2020 at 5:44 AM To: "openssl-project at openssl.org" Subject: Detecting Bad OpenSSL Usage Hello, Here is a nice article about a tool desired to catch misuse of the OpenSSL API. https://blog.trailofbits.com/2020/05/29/detecting-bad-openssl-usage/ I'm not sure whether it's worth using by the team but maybe it's worth mentioning in OpenSSL Wiki. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: