From matt at openssl.org Sat Feb 1 00:10:22 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 1 Feb 2020 00:10:22 +0000 Subject: Travis in solid red mode again In-Reply-To: References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> Message-ID: <17106546-5331-4605-89b9-99ab16e04110@openssl.org> On 31/01/2020 22:55, Matt Caswell wrote: > > > On 31/01/2020 17:07, Matthias St. Pierre wrote: >> >> After a much to short green period, Travis has turned to solid red mode >> again: >> >> https://travis-ci.org/openssl/openssl/builds?utm_medium=notification&utm_source=github_status >> >> >> This fact causes a lot of pain for reviewers, because every failing job >> needs to be checked manually. >> I would be happy to fix some of the failures if I could, but in most >> cases I have no clue what the problem is, >> because I can't reproduce the issue locally. Could we try to fix them in >> a joint effort?? For your convenience, >> I added a summary of all failing jobs of Build #31837 below. > > Trial fix for at least some of these issues in #10989. We'll see what > travis makes of it. It fixed most of the test failures but not the krb5 one. I have another trial fix in #10992 (which includes the fix in #10989). Matt > >> >> Since this is not the first time that this happens, I think it is >> overdue that the OTC discusses those constant >> build failures and proposes some measures to raise the priority for >> fixing CI errors. One drastic possibility >> would be to allow only CI fixing pull requests to be merged as long as >> master and the stable branches are red. >> But I am sure there is a golden middle way between such an extreme >> sanction and our current indifference. >> > > Part of the issue is that the master branch travis failures are not > visible in the PRs because the master branch runs the full tests > (including the extended tests), whereas the PRs don't run the extended > tests by default. However running the extended tests takes too long. > > Could we add a CI check for PRs that confirms that the target branch is > green in travis? > > Matt > > >> >> Regards, >> >> Matthias >> >> >> >> ---- >> >> >> Last Successful Build: #31583 (10 days ago!) >> https://travis-ci.org/openssl/openssl/builds/639939072?utm_medium=notification&utm_source=github_status >> >> >> Recent Build: #31837 >> https://travis-ci.org/openssl/openssl/builds/644238908?utm_medium=notification&utm_source=github_status >> >> >> >> SSL TESTS >> ========= >> >> * >> https://travis-ci.org/openssl/openssl/jobs/644238919?utm_medium=notification&utm_source=github_status >> >> * >> https://travis-ci.org/openssl/openssl/jobs/644238926?utm_medium=notification&utm_source=github_status >> >> * >> https://travis-ci.org/openssl/openssl/jobs/644238929?utm_medium=notification&utm_source=github_status >> >> >>> ? Test Summary Report >>> ------------------- >>> ? 80-test_ssl_new.t??????????????? (Wstat: 256 Tests: 30 Failed: 1) >>> ??? Failed test:? 4 >>> ??? Non-zero exit status: 1 >>> ? 80-test_ssl_old.t??????????????? (Wstat: 256 Tests: 6 Failed: 1) >>> ??? Failed test:? 2 >>> ??? Non-zero exit status: 1 >> >> >> >> BORINGSSL AND KRB5 >> ================== >> >> * >> https://travis-ci.org/openssl/openssl/jobs/644238927?utm_medium=notification&utm_source=github_status >> >> >>> Test Summary Report >>> ------------------- >> >>> 95-test_external_boringssl.t (Wstat: 256 Tests: 1 Failed: 1) >>> ?? Failed test:? 1 >>> ?? Non-zero exit status: 1 >>> 95-test_external_krb5.t???? (Wstat: 256 Tests: 1 Failed: 1) >>> ?? Failed test:? 1 >>> ?? Non-zero exit status: 1 >> >> >> >> 95-test_external_boringssl.t: >> ----------------------- >> >> ??? grep 'go.*FAILED' tffff >> ??? go test: FAILED (SSL3-Client-ClientAuth-RSA) >> ??? go test: FAILED (SSL3-Server-ClientAuth-RSA) >> ??? go test: FAILED (ClientAuth-Sign-RSA-SSL3) >> ??? go test: FAILED (ClientAuth-InvalidSignature-RSA-SSL3) >> ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Sync) >> ??? go test: FAILED >> (CertificateVerificationSucceed-Server-SSL3-Sync-SplitHandshakeRecords) >> ??? go test: FAILED >> (CertificateVerificationSucceed-Server-SSL3-Sync-PackHandshakeFlight) >> ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Async) >> ??? go test: FAILED >> (CertificateVerificationSucceed-Server-SSL3-Async-SplitHandshakeRecords) >> ??? go test: FAILED >> (CertificateVerificationSucceed-Server-SSL3-Async-PackHandshakeFlight) >> >> >> >> 95-test_external_krb5.t: >> ----------------------- >> >> ??? LD_LIBRARY_PATH=`echo -L../../../lib | sed -e "s/-L//g" -e "s/ >> /:/g"` KRB5_CONFIG=../../../config-files/krb5.conf LC_ALL=C ./t_nfold >> ??? N-fold >> ??????? Input:??? "basch" >> ??????? 192-Fold:???? 1aab6b42 964b98b2 1f8cde2d 2448ba34 55d7862c 9731643f >> ??????? Input:??? "eichin" >> ??????? 192-Fold:???? 65696368 696e4b73 2b4b1b43 da1a5b99 5a58d2c6 d0d2dcca >> ??????? Input:??? "sommerfeld" >> ??????? 192-Fold:???? 2f7a9855 7c6ee4ab adf4e711 92dd442b d4ff5325 a5def75c >> ??????? Input:??? "MASSACHVSETTS INSTITVTE OF TECHNOLOGY" >> ??????? 192-Fold:???? db3b0d8f 0b061e60 3282b308 a5084122 9ad798fa b9540c1b >> ??? RFC tests: >> >> ??? ... >> >> ??? Generating random keyblock: . . . OK >> ??? Creating opaque key from keyblock: . . . OK >> ??? Encrypting (c): . . . Failed: Cannot allocate memory <===ALLOC >> FAILURE== >> ??? Aborted (core >> dumped)???????????????????????????????????????????????? <===CORE DUMPED== >> ??? Makefile:684: recipe for target 'check-unix' failed >> ??? make[5]: *** [check-unix] Error 134 >> ??? make[5]: Leaving directory >> '/home/travis/build/openssl/openssl/krb5/src/lib/crypto/crypto_tests' >> ??? Makefile:1107: recipe for target 'check-recurse' failed >> ??? make[4]: *** [check-recurse] Error 1 >> ??? make[4]: Leaving directory >> '/home/travis/build/openssl/openssl/krb5/src/lib/crypto' >> ??? Makefile:992: recipe for target 'check-recurse' failed >> ??? make[3]: *** [check-recurse] Error 1 >> ??? make[3]: Leaving directory >> '/home/travis/build/openssl/openssl/krb5/src/lib' >> ??? Makefile:1533: recipe for target 'check-recurse' failed >> ??? make[2]: *** [check-recurse] Error 1 >> ??? make[2]: Leaving directory >> '/home/travis/build/openssl/openssl/krb5/src' >> ??? ../../util/shlib_wrap.sh >> ../recipes/95-test_external_krb5_data/krb5.sh => 2 >> ??? not ok 1 - running krb5 tests >> >> >> >> > From matt at openssl.org Sat Feb 1 09:51:22 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 1 Feb 2020 09:51:22 +0000 Subject: Travis in solid red mode again In-Reply-To: <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> Message-ID: <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> On 01/02/2020 00:34, Salz, Rich wrote: > > > Could we add a CI check for PRs that confirms that the target branch is > green in travis? > > Looking at https://docs.travis-ci.com/user/notifications/#conditional-notifications and https://config.travis-ci.com/ref/notifications/email it seems like it should be fairly easy configure builds to do "send email to openssl-commits when builds on master fail" We already have that. Matt From Matthias.St.Pierre at ncp-e.com Sat Feb 1 10:35:03 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 1 Feb 2020 10:35:03 +0000 Subject: Travis in solid red mode again In-Reply-To: <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> Message-ID: <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> > -----Original Message----- > On 01/02/2020 00:34, Salz, Rich wrote: > > > > > Could we add a CI check for PRs that confirms that the target branch is > > green in travis? > > > > Looking at https://docs.travis-ci.com/user/notifications/#conditional-notifications and https://config.travis- > ci.com/ref/notifications/email it seems like it should be fairly easy configure builds to do "send email to openssl-commits when builds on > master fail" > > We already have that. Maybe we should make it a requirement that at least all OTC members subscribe to openssl-commits? Matthias From paul.dale at oracle.com Sat Feb 1 10:39:02 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 1 Feb 2020 20:39:02 +1000 Subject: Travis in solid red mode again In-Reply-To: <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> Message-ID: <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> I thought I was subscribed but don?t seem to see the failures. I do get the (very many) PR activity emails?. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 1 Feb 2020, at 8:35 pm, Dr. Matthias St. Pierre wrote: > >> -----Original Message----- >> On 01/02/2020 00:34, Salz, Rich wrote: >>> >>>> Could we add a CI check for PRs that confirms that the target branch is >>> green in travis? >>> >>> Looking at https://docs.travis-ci.com/user/notifications/#conditional-notifications and https://config.travis- >> ci.com/ref/notifications/email it seems like it should be fairly easy configure builds to do "send email to openssl-commits when builds on >> master fail" >> >> We already have that. > > Maybe we should make it a requirement that at least all OTC members subscribe to openssl-commits? > > Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Sat Feb 1 11:38:14 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 1 Feb 2020 11:38:14 +0000 Subject: Travis in solid red mode again In-Reply-To: <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> Message-ID: <7ab80fc7b76d424bbb57f1e7386d2f2a@Ex13.ncp.local> > I thought I was subscribed but don?t seem to see the failures. > I do get the (very many) PR activity emails?. You are right, those ?[openssl] update? mails generate a lot of noise. Do we really need them? If not, we could just deactivate them. Alternatively, we could move the CI failures to a separate openssl-ci list. Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sat Feb 1 23:55:36 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 1 Feb 2020 23:55:36 +0000 Subject: Travis in solid red mode again In-Reply-To: <7ab80fc7b76d424bbb57f1e7386d2f2a@Ex13.ncp.local> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> <7ab80fc7b76d424bbb57f1e7386d2f2a@Ex13.ncp.local> Message-ID: <67cc2f36-9026-8aee-053f-319bee416db0@openssl.org> On 01/02/2020 11:38, Dr. Matthias St. Pierre wrote: >> I thought I was subscribed but don?t seem to see the failures. > >> I do get the (very many) PR activity emails?. > > ? > > You are right, those ?[openssl] update? mails generate a lot > > of noise. Do we really need them? If not, we could just deactivate them. I regularly look at these, so would like to keep them. Matt > > Alternatively, we could move the CI failures to a separate openssl-ci list. > > ? > > Matthias > > ? > From matt at openssl.org Sat Feb 1 23:57:39 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 1 Feb 2020 23:57:39 +0000 Subject: Travis in solid red mode again In-Reply-To: <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> Message-ID: <9b041340-7d0d-3314-4fd3-e97000c1a4bc@openssl.org> On 01/02/2020 10:39, Dr Paul Dale wrote: > I thought I was subscribed but don?t seem to see the failures. > I do get the (very many) PR activity emails?. Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures and not Travis? Matt > > > Pauli > --? > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 1 Feb 2020, at 8:35 pm, Dr. Matthias St. Pierre >> > >> wrote: >> >>> -----Original Message----- >>> On 01/02/2020 00:34, Salz, Rich wrote: >>>> >>>>> Could we add a CI check for PRs that confirms that the target branch is >>>> ???green in travis? >>>> >>>> Looking at >>>> https://docs.travis-ci.com/user/notifications/#conditional-notifications >>>> and https://config.travis- >>> ci.com/ref/notifications/email >>> it seems like it should be >>> fairly easy configure builds to do "send email to openssl-commits >>> when builds on >>> master fail" >>> >>> We already have that. >> >> Maybe we should make it a requirement that at least all OTC members >> subscribe to openssl-commits? >> >> Matthias >> > From Matthias.St.Pierre at ncp-e.com Sun Feb 2 00:18:06 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sun, 2 Feb 2020 00:18:06 +0000 Subject: Travis in solid red mode again In-Reply-To: <9b041340-7d0d-3314-4fd3-e97000c1a4bc@openssl.org> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> <9b041340-7d0d-3314-4fd3-e97000c1a4bc@openssl.org> Message-ID: <9c767af668f14c488d0e4a5aa7624869@Ex13.ncp.local> > -----Original Message----- > From: Matt Caswell > Sent: Sunday, February 2, 2020 12:58 AM > To: Dr Paul Dale ; Dr. Matthias St. Pierre > Cc: Salz, Rich ; openssl-project at openssl.org > Subject: Re: Travis in solid red mode again > > > > On 01/02/2020 10:39, Dr Paul Dale wrote: > > I thought I was subscribed but don?t seem to see the failures. > > I do get the (very many) PR activity emails?. > > Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures > and not Travis? I see both CI's posting in January: https://mta.openssl.org/pipermail/openssl-commits/2020-January/thread.html Broken: openssl/openssl#30961 (master - 2de5a5f) Travis CI Broken: openssl/openssl#30962 (OpenSSL_1_1_1-stable - 10e166a) Travis CI Build failed: openssl master.30389 AppVeyor Build completed: openssl OpenSSL_1_1_1-stable.30390 AppVeyor Fixed: openssl/openssl#30966 (master - e7b834b) Travis CI Fixed: openssl/openssl#30967 (OpenSSL_1_1_1-stable - 2c52a36) Travis CI Build failed: openssl master.30394 AppVeyor Build completed: openssl OpenSSL_1_1_1-stable.30395 AppVeyor Build failed: openssl master.30405 AppVeyor Build completed: openssl master.30406 AppVeyor Build failed: openssl master.30411 AppVeyor Build failed: openssl master.30412 AppVeyor From rsalz at akamai.com Sat Feb 1 00:34:17 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 1 Feb 2020 00:34:17 +0000 Subject: Travis in solid red mode again In-Reply-To: References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> Message-ID: <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> > Could we add a CI check for PRs that confirms that the target branch is green in travis? Looking at https://docs.travis-ci.com/user/notifications/#conditional-notifications and https://config.travis-ci.com/ref/notifications/email it seems like it should be fairly easy configure builds to do "send email to openssl-commits when builds on master fail" From rsalz at akamai.com Sun Feb 2 00:35:43 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 2 Feb 2020 00:35:43 +0000 Subject: Travis in solid red mode again In-Reply-To: <9b041340-7d0d-3314-4fd3-e97000c1a4bc@openssl.org> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <577E8A01-A127-4AC8-8DD4-84BB953FC4BB@akamai.com> <5c6db617-c757-7f25-7640-7f80da0e02d5@openssl.org> <91d41e5da8c740fa8182d01cc202e8fd@Ex13.ncp.local> <224FB8E7-ED68-41A9-86C2-9457D4B499F5@oracle.com> <9b041340-7d0d-3314-4fd3-e97000c1a4bc@openssl.org> Message-ID: <87EDF946-4704-4E4D-B494-8CEC3D6412C3@akamai.com> > Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures and not Travis? Yes. You need to config travis to mail failures, as I pointed out in my earlier message. From Matthias.St.Pierre at ncp-e.com Mon Feb 3 19:19:28 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Mon, 3 Feb 2020 20:19:28 +0100 Subject: Travis in solid red mode again In-Reply-To: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> Message-ID: <32b04490-fbd1-4a87-59a6-02c994c7389f@ncp-e.com> Mission accomplished, Travis just turned green again on master? :-) https://travis-ci.org/openssl/openssl/builds/645563965?utm_source=github_status&utm_medium=notification Thanks to Matt, Richard and everybody else who participated in fixing it. Matthias From matt at openssl.org Wed Feb 5 09:25:14 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Feb 2020 09:25:14 +0000 Subject: Fwd: Errored: openssl/openssl#31939 (master - 34b1676) In-Reply-To: <5e3a05f94b2ee_43fb2926da1f82485e1@2f147ff5-212e-4b07-88f1-e30936129eef.mail> References: <5e3a05f94b2ee_43fb2926da1f82485e1@2f147ff5-212e-4b07-88f1-e30936129eef.mail> Message-ID: <7ec6629c-2e17-c86e-7f4d-96935bd84a72@openssl.org> Since we fixed the Travis builds 4 out of the 8 builds on master that have taken place have errored due to a timeout. The msan build is consistently taking a *very* long time to run. If it gets to 50 minutes then Travis cuts it off and the build fails. Should we disable the msan build? Matt -------- Forwarded Message -------- Subject: Errored: openssl/openssl#31939 (master - 34b1676) Date: Wed, 05 Feb 2020 00:02:01 +0000 From: Travis CI To: openssl-commits at openssl.org openssl / openssl branch iconmaster build has errored Build #31939 has errored arrow to build time clock icon50 mins and 3 secs Pauli avatarPauli 34b1676 CHANGESET ? Make minimum size for secure memory a size_t. The minimum size argument to CRYPTO_secure_malloc_init() was an int but ought to be a size_t since it is a size. >From an API perspective, this is a change. However, the minimum size is verified as being a positive power of two and it will typically be a small constant. Reviewed-by: David von Oheimb (Merged from #11003) Want to know about upcoming build environment updates? Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! SIGN UP HERE book icon Documentation about Travis CI Have any questions? We're here to help. Unsubscribe from build emails from the openssl/openssl repository. To unsubscribe from *all* build emails, please update your settings . black and white travis ci logo Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy Jacops | Contact: contact at travis-ci.com | Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gem?? ?27 a Umsatzsteuergesetz: DE282002648 From rsalz at akamai.com Thu Feb 6 15:54:31 2020 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 6 Feb 2020 15:54:31 +0000 Subject: QUIC support Message-ID: <49C3B974-DDB8-4AE0-BA58-D549B58A3672@akamai.com> A month ago Tim said[2] that PR 8797[1] requires on OMC decision on ?whether or not QUIC in this manner of approach should be added into OpenSSL at this time.? To save you a click, this PR adds API?s to OpenSSL so that Google?s open source QUIC implementation can be built on top of OpenSSL. For more details, perhaps my comment [3] explains the situation best. I am asking the OMC to come to call a vote on this *NOW* I am CC?ing openssl-users so that the community can comment. [1] https://github.com/openssl/openssl/pull/8797 [2] https://github.com/openssl/openssl/pull/8797#issuecomment-571899829 [3] https://github.com/openssl/openssl/pull/8797#issuecomment-485002590 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Feb 6 16:03:45 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 6 Feb 2020 16:03:45 +0000 Subject: QUIC support In-Reply-To: <49C3B974-DDB8-4AE0-BA58-D549B58A3672@akamai.com> References: <49C3B974-DDB8-4AE0-BA58-D549B58A3672@akamai.com> Message-ID: On 06/02/2020 15:54, Salz, Rich via openssl-users wrote: > A month ago Tim said[2] that PR 8797[1] requires on OMC decision on > ?whether or not QUIC in this manner of approach should be added into > OpenSSL at this time.? > > To save you a click, this PR adds API?s to OpenSSL so that Google?s open > source QUIC implementation can be built on top of OpenSSL. ?For more > details, perhaps my comment [3] explains the situation best. > > I am asking the OMC to come to call a vote on this **NOW**? I am CC?ing > openssl-users so that the community can comment. As per Tim's recent post (which may have crossed with you posting this), the OMC consensus is that the QUIC PR is outside of the scope of the 3.0 release and will not be included. The hold remains until the 3.0 work is concluded. Matt From matt at openssl.org Fri Feb 7 09:53:57 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 7 Feb 2020 09:53:57 +0000 Subject: Travis in solid red mode again In-Reply-To: <32b04490-fbd1-4a87-59a6-02c994c7389f@ncp-e.com> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <32b04490-fbd1-4a87-59a6-02c994c7389f@ncp-e.com> Message-ID: <47e9a7aa-ba34-f923-851f-e245561e53c4@openssl.org> On 03/02/2020 19:19, Matthias St. Pierre wrote: > Mission accomplished, Travis just turned green again on master? :-) Every one of the last 12 master jobs have failed to complete successfully due to a travis timeout. Apart from the build that is timing out (enable-msan), all the other builds in the job are green. Matt > > https://travis-ci.org/openssl/openssl/builds/645563965?utm_source=github_status&utm_medium=notification > > > Thanks to Matt, Richard and everybody else who participated in fixing it. > > > Matthias > > > From matt at openssl.org Fri Feb 7 11:20:50 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 7 Feb 2020 11:20:50 +0000 Subject: Monthly Status Report (January) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Further work and eventual merge of the fix for the SSL_get_servername() issue - Fixed New Year "make update" issues - Deprecated the low level Blowfish APIs - Deprecated the low level Camellia APIs - Deprecated the low level CAST APIs - Continued working on deprecation of the low level AES APIs - Fixed HMAC_CTX to not store a key for any longer than needed - Continued review of the CMP contribution - Updates to the website to remove various 1.0.2 references - Proposed and published the 3.0 timeline - Fixed a seg fault in EVP_DigestSignUpdate - PR to make libssl provider aware - Fixed bug where drbg_delete_thread_state was registered twice - Fixed a bug in init_thread_stop - Converted rand_bytes_ex and rand_priv_bytes_ex to public functions - Implemented the NULL cipher in the default provider - Introduced the SSL_CTX_new_with_libctx function - PR to make the RSA ASYM_CIPHER implementation available inside the FIPS provider - Fix to detect EOF correctly in libssl - Modified EVP_PKEY_CTX_new_from_pkey() to take a propquery parameter - Updated libssl to use RAND_bytes_ex() and RAND_priv_bytes_ex() - Fixed common test framework options with some tests - Fixed problem where doc-nits was ignoring ASN1 functions when checking for undocumented symbols - Modified doc-nits to not complain about documented symbols when checking missingcrypto111.txt and missingssl111.txt - Investigated and proposed fixes for various travis failures - Fixed builds with no-dh Matt From Matthias.St.Pierre at ncp-e.com Fri Feb 7 11:29:15 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Fri, 7 Feb 2020 12:29:15 +0100 Subject: Travis in solid red mode again In-Reply-To: <47e9a7aa-ba34-f923-851f-e245561e53c4@openssl.org> References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com> <32b04490-fbd1-4a87-59a6-02c994c7389f@ncp-e.com> <47e9a7aa-ba34-f923-851f-e245561e53c4@openssl.org> Message-ID: <75a7c48d-bab6-9de2-38ef-63e8de2d5562@ncp-e.com> Well,?nobody?else?seems?to?care;?In?this?case,?I?would?like?to?suggest?that?you disable?the?enable-msan?build?and?create?an?issue?for?fixing?it. Matthias On 07.02.20 10:53, Matt Caswell wrote: > > On 03/02/2020 19:19, Matthias St. Pierre wrote: >> Mission accomplished, Travis just turned green again on master? :-) > Every one of the last 12 master jobs have failed to complete > successfully due to a travis timeout. Apart from the build that is > timing out (enable-msan), all the other builds in the job are green. > > Matt > >> https://travis-ci.org/openssl/openssl/builds/645563965?utm_source=github_status&utm_medium=notification >> >> >> Thanks to Matt, Richard and everybody else who participated in fixing it. >> >> >> Matthias >> >> >> From mark at openssl.org Sat Feb 8 15:56:19 2020 From: mark at openssl.org (Mark J Cox) Date: Sat, 8 Feb 2020 15:56:19 +0000 Subject: Github PR label automation Message-ID: I've currently got a cron job running every hour that looks at open PR requests against github openssl repo and does various actions. So if you were wondering why I was altering labels and making comments at 4am, now you know. No doubt we'll use some tool user for this in the future. So right now here's what it does: Every hour it looks at open PRs that are labelled "approval: done". If 24 hours has elapsed since that label was assigned and if there have been no comments made to the PR since the label was assigned then it is automatically moved to "approval: ready to merge" with a comment added to trigger notifications. So if you want to stop something going to "ready to merge" just add any comment to the PR. I'm thinking of using this script also to 1) collect interesting stats and 2) do some other actions. So if there's some automation you'd like to see just add an enhancement issue against the openssl/tools repo. 1 Matt already asked for committer notification trigger for anything labelled Urgent. 2 If there were comments made after "approval: done" then I think we really ought to drop the "approval: done" label as the comments likely invalidated the approval. So I'll likely add that next week (if "approval: done" label and has comments since that label then remove the label and add a comment 'please review if this is really approval: done'. If the approval: done label gets set again then after 24 hours the existing automation will trigger. #10786 is a good example of this. Mark From beldmit at gmail.com Sat Feb 8 16:57:07 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 8 Feb 2020 19:57:07 +0300 Subject: Github PR label automation In-Reply-To: References: Message-ID: Dear Mark, Thank you for a nice job! As the reviewers are expected to commit the PRs, could you also add the reviewers' names as a part of the notification? On Sat, Feb 8, 2020 at 6:56 PM Mark J Cox wrote: > I've currently got a cron job running every hour that looks at open PR > requests against github openssl repo and does various actions. So if > you were wondering why I was altering labels and making comments at > 4am, now you know. No doubt we'll use some tool user for this in the > future. > > So right now here's what it does: > > Every hour it looks at open PRs that are labelled "approval: done". > If 24 hours has elapsed since that label was assigned and if there > have been no comments made to the PR since the label was assigned then > it is automatically moved to "approval: ready to merge" with a comment > added to trigger notifications. So if you want to stop something > going to "ready to merge" just add any comment to the PR. > > I'm thinking of using this script also to 1) collect interesting stats > and 2) do some other actions. So if there's some automation you'd > like to see just add an enhancement issue against the openssl/tools > repo. > > 1 Matt already asked for committer notification trigger for anything > labelled Urgent. > > 2 If there were comments made after "approval: done" then I think we > really ought to drop the "approval: done" label as the comments likely > invalidated the approval. So I'll likely add that next week (if > "approval: done" label and has comments since that label then remove > the label and add a comment 'please review if this is really approval: > done'. If the approval: done label gets set again then after 24 hours > the existing automation will trigger. #10786 is a good example of > this. > > Mark > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Sat Feb 8 19:52:28 2020 From: mark at openssl.org (Mark J Cox) Date: Sat, 8 Feb 2020 19:52:28 +0000 Subject: Github PR label automation In-Reply-To: References: Message-ID: Thanks Dmitry; I hope that the comment triggers notifications to the creator without mentioning them? (let me know if you get something changed labels that doesn't) Mark On Sat, Feb 8, 2020 at 4:57 PM Dmitry Belyavsky wrote: > > Dear Mark, > > Thank you for a nice job! > > As the reviewers are expected to commit the PRs, could you also add the reviewers' names as a part of the notification? > > On Sat, Feb 8, 2020 at 6:56 PM Mark J Cox wrote: >> >> I've currently got a cron job running every hour that looks at open PR >> requests against github openssl repo and does various actions. So if >> you were wondering why I was altering labels and making comments at >> 4am, now you know. No doubt we'll use some tool user for this in the >> future. >> >> So right now here's what it does: >> >> Every hour it looks at open PRs that are labelled "approval: done". >> If 24 hours has elapsed since that label was assigned and if there >> have been no comments made to the PR since the label was assigned then >> it is automatically moved to "approval: ready to merge" with a comment >> added to trigger notifications. So if you want to stop something >> going to "ready to merge" just add any comment to the PR. >> >> I'm thinking of using this script also to 1) collect interesting stats >> and 2) do some other actions. So if there's some automation you'd >> like to see just add an enhancement issue against the openssl/tools >> repo. >> >> 1 Matt already asked for committer notification trigger for anything >> labelled Urgent. >> >> 2 If there were comments made after "approval: done" then I think we >> really ought to drop the "approval: done" label as the comments likely >> invalidated the approval. So I'll likely add that next week (if >> "approval: done" label and has comments since that label then remove >> the label and add a comment 'please review if this is really approval: >> done'. If the approval: done label gets set again then after 24 hours >> the existing automation will trigger. #10786 is a good example of >> this. >> >> Mark > > > > -- > SY, Dmitry Belyavsky From Matthias.St.Pierre at ncp-e.com Sat Feb 8 20:33:28 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 8 Feb 2020 20:33:28 +0000 Subject: Github PR label automation In-Reply-To: References: Message-ID: <351fde2bd1e94a46935a55860bb35d74@Ex13.ncp.local> First of all, thank you Mark for implementing the notification daemon. You did a great job and I think it's very useful. Here are some comments and thoughts about your last mail. > No doubt we'll use some tool user for this in the future. Can't you just use an API-token generated for the openssl-machine account, as the issue closing bot does? A propos bot: I thought that GitHub provides official support for this kind of watch-bots we are seeking and that they can be configured or programmed in an event driven fashion. Executing specific actions (like setting labels or posting messages) in response to specific GitHub events (approval added, change requested, timer expired, etc.) would have some advantages compared to an external timer based approach. Did someone of you consider this option and do some investigations in that direction? Please don't misinterpret my question, I think that the current cron job solution is already a great improvement and a big step forward. > 2 If there were comments made after "approval: done" then I think we > really ought to drop the "approval: done" label as the comments likely > invalidated the approval. ... I don't think that an *arbitrary comment* should automatically reset the approval state. Anybody could just post a "nice job" comment or some side note. Resetting the approval state could happen automatically if a *team member* posts a review with *change requests*. But not in any other case (e.g. a change requests by a non-team member or an additional approving review). Also, I am strongly convinced that making the transition from the [approval: * review pending] to the [approval:done] state should remain a *purely manual* state. I don't think it's a good idea to leave this decision to an "artificial intelligence" whatsoever. And just counting whether the number of approvals has reached the required minimum is too simplistic anyway. Just imagine the pull request has reached the required number of reviews, but the submitter or a reviewer is still waiting for another important outstanding review. Do you really want the bot to interfere? What about the existing approvals? They need to be dismissed if 'too much' has changed, but not if the author pushed a trivial fixup addressing an approving review. Do you really want to leave this decision to a bot? This approach will just not work. It is really almost no extra effort if we demand that the second reviewer sets the [approval: done] label manually, unless he sees that there are still unresolved discussions in progress. Only the grace period handling should be automated IMHO. Regards, Matthias From Matthias.St.Pierre at ncp-e.com Sat Feb 8 20:40:54 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 8 Feb 2020 20:40:54 +0000 Subject: Github PR label automation In-Reply-To: References: Message-ID: <0ae5cb33eeb14be695951282aed944b8@Ex13.ncp.local> > -----Original Message----- > From: openssl-project On Behalf Of Mark J Cox > Sent: Saturday, February 8, 2020 8:52 PM > To: Dmitry Belyavsky > Cc: openssl-project at openssl.org > Subject: Re: Github PR label automation > > Thanks Dmitry; I hope that the comment triggers notifications to the > creator without mentioning them? (let me know if you get something > changed labels that doesn't) Mark In fact, it was my suggestion *not* to add personal mentions. Since anybody who has posted comments to the pull request (which includes the submitter and all reviewers) will be subscribed to the pull request's thread, I think a general comment which addresses nobody specific (just like our "ping" messages) is less intrusive. Matthias From paul.dale at oracle.com Sat Feb 8 23:49:16 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sun, 9 Feb 2020 09:49:16 +1000 Subject: Github PR label automation In-Reply-To: References: Message-ID: <8F738EB5-7EFE-4C1F-A9FB-BC1A7390EE60@oracle.com> Please don?t automatically drop the "appoval: done" label after a comment. I feel that is not uncommon for comments to be added that in no way invalidate the approval. I agree with not switching to ?ready to merge? if there are comments ? manual intervention in this case is required to judge the relevancy. Agreed also over the ?urgent? label. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Feb 2020, at 1:56 am, Mark J Cox wrote: > > I've currently got a cron job running every hour that looks at open PR > requests against github openssl repo and does various actions. So if > you were wondering why I was altering labels and making comments at > 4am, now you know. No doubt we'll use some tool user for this in the > future. > > So right now here's what it does: > > Every hour it looks at open PRs that are labelled "approval: done". > If 24 hours has elapsed since that label was assigned and if there > have been no comments made to the PR since the label was assigned then > it is automatically moved to "approval: ready to merge" with a comment > added to trigger notifications. So if you want to stop something > going to "ready to merge" just add any comment to the PR. > > I'm thinking of using this script also to 1) collect interesting stats > and 2) do some other actions. So if there's some automation you'd > like to see just add an enhancement issue against the openssl/tools > repo. > > 1 Matt already asked for committer notification trigger for anything > labelled Urgent. > > 2 If there were comments made after "approval: done" then I think we > really ought to drop the "approval: done" label as the comments likely > invalidated the approval. So I'll likely add that next week (if > "approval: done" label and has comments since that label then remove > the label and add a comment 'please review if this is really approval: > done'. If the approval: done label gets set again then after 24 hours > the existing automation will trigger. #10786 is a good example of > this. > > Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sun Feb 9 00:18:58 2020 From: matt at openssl.org (Matt Caswell) Date: Sun, 9 Feb 2020 00:18:58 +0000 Subject: Github PR label automation In-Reply-To: References: Message-ID: <5469b05b-4ceb-a842-52cc-9a72c5c50b6e@openssl.org> On 08/02/2020 15:56, Mark J Cox wrote: > I've currently got a cron job running every hour that looks at open PR > requests against github openssl repo and does various actions. So if > you were wondering why I was altering labels and making comments at > 4am, now you know. No doubt we'll use some tool user for this in the > future. > > So right now here's what it does: > > Every hour it looks at open PRs that are labelled "approval: done". > If 24 hours has elapsed since that label was assigned and if there > have been no comments made to the PR since the label was assigned then > it is automatically moved to "approval: ready to merge" with a comment > added to trigger notifications. So if you want to stop something > going to "ready to merge" just add any comment to the PR. > > I'm thinking of using this script also to 1) collect interesting stats > and 2) do some other actions. So if there's some automation you'd > like to see just add an enhancement issue against the openssl/tools > repo. > > 1 Matt already asked for committer notification trigger for anything > labelled Urgent. > > 2 If there were comments made after "approval: done" then I think we > really ought to drop the "approval: done" label as the comments likely > invalidated the approval. So I'll likely add that next week (if > "approval: done" label and has comments since that label then remove > the label and add a comment 'please review if this is really approval: > done'. If the approval: done label gets set again then after 24 hours > the existing automation will trigger. #10786 is a good example of > this. I'm less sure about this. I think there are probably many examples where this is not the case. E.g. a quick review found these recent cases: https://github.com/openssl/openssl/pull/11003 https://github.com/openssl/openssl/pull/11015 https://github.com/openssl/openssl/pull/10992 https://github.com/openssl/openssl/pull/10991 https://github.com/openssl/openssl/pull/10990 https://github.com/openssl/openssl/pull/10989 I would be more minded to think that if a comment invalidates an "approval done" then the committer should explicitly decide to do that. Matt From mark at awe.com Sun Feb 9 10:22:48 2020 From: mark at awe.com (Mark J Cox) Date: Sun, 9 Feb 2020 10:22:48 +0000 Subject: Github PR label automation In-Reply-To: <5469b05b-4ceb-a842-52cc-9a72c5c50b6e@openssl.org> References: <5469b05b-4ceb-a842-52cc-9a72c5c50b6e@openssl.org> Message-ID: Okay, I'll leave things as they are with those issues and just add the addition of notification on urgent labels. As to the earlier question form the thread as why this isn't a github automation: the actual reason I was writing the script was to get some on-demand statistics for my own interest and it just turned out this was something that bugged me that I could use the same framework for (I did a trivial review and thought how annoying it would be to have to manually set a reminder myself to do a future action). I was a pretty trivial (few hours) script, so I have no concern if it is done differently or not used in the future should a better way present itself. Mark On Sun, Feb 9, 2020 at 12:19 AM Matt Caswell wrote: > > > > On 08/02/2020 15:56, Mark J Cox wrote: > > I've currently got a cron job running every hour that looks at open PR > > requests against github openssl repo and does various actions. So if > > you were wondering why I was altering labels and making comments at > > 4am, now you know. No doubt we'll use some tool user for this in the > > future. > > > > So right now here's what it does: > > > > Every hour it looks at open PRs that are labelled "approval: done". > > If 24 hours has elapsed since that label was assigned and if there > > have been no comments made to the PR since the label was assigned then > > it is automatically moved to "approval: ready to merge" with a comment > > added to trigger notifications. So if you want to stop something > > going to "ready to merge" just add any comment to the PR. > > > > I'm thinking of using this script also to 1) collect interesting stats > > and 2) do some other actions. So if there's some automation you'd > > like to see just add an enhancement issue against the openssl/tools > > repo. > > > > 1 Matt already asked for committer notification trigger for anything > > labelled Urgent. > > > > 2 If there were comments made after "approval: done" then I think we > > really ought to drop the "approval: done" label as the comments likely > > invalidated the approval. So I'll likely add that next week (if > > "approval: done" label and has comments since that label then remove > > the label and add a comment 'please review if this is really approval: > > done'. If the approval: done label gets set again then after 24 hours > > the existing automation will trigger. #10786 is a good example of > > this. > > I'm less sure about this. I think there are probably many examples where > this is not the case. E.g. a quick review found these recent cases: > > https://github.com/openssl/openssl/pull/11003 > > https://github.com/openssl/openssl/pull/11015 > > https://github.com/openssl/openssl/pull/10992 > > https://github.com/openssl/openssl/pull/10991 > > https://github.com/openssl/openssl/pull/10990 > > https://github.com/openssl/openssl/pull/10989 > > I would be more minded to think that if a comment invalidates an > "approval done" then the committer should explicitly decide to do that. > > Matt From shane.lontis at oracle.com Mon Feb 10 00:15:38 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Mon, 10 Feb 2020 10:15:38 +1000 Subject: Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked? In-Reply-To: References: Message-ID: <6CA71838-4736-4701-AD3C-2CD06AA83A0C@oracle.com> With the new architecture changes there are quite a few new calls to CRYPTO_UP_REF() CRYPTO_DOWN_REF() These methods return an int that is not being checked in lots of places. This return value only seems to affect fallback code that calls CRYPTO_atomic_add (which can return 0 on lock or unlock failure) SO the question is should we be checking this return value? Note that not checking has resulted in a few assumptions in other code? e.g the following function returns void. /crypto/evp/keymgmt_lib.c: 165 in evp_keymgmt_util_cache_pkey() 159 } 160 161 void evp_keymgmt_util_cache_pkey(EVP_PKEY *pk, size_t index, 162 EVP_KEYMGMT *keymgmt, void *keydata) 163 { 164 if (keydata != NULL) { >>> CID 1458170: Error handling issues (CHECKED_RETURN) >>> Calling "EVP_KEYMGMT_up_ref" without checking return value (as is done elsewhere 4 out of 5 times). 165 EVP_KEYMGMT_up_ref(keymgmt); NOTE: EVP_KEYMGMT_up_ref() just does an CRYPTO_UP_REF() call and always returns 1. From vieuxtech at gmail.com Sun Feb 9 18:35:27 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Sun, 9 Feb 2020 10:35:27 -0800 Subject: Github PR label automation In-Reply-To: References: <5469b05b-4ceb-a842-52cc-9a72c5c50b6e@openssl.org> Message-ID: I've seen some projects enjoying https://github.com/apps/stale, though its focus is not so much relabelling things that are ready, but closing things that are not active, which might not be relevant here. On Sun, Feb 9, 2020 at 2:23 AM Mark J Cox wrote: > > Okay, I'll leave things as they are with those issues and just add the > addition of notification on urgent labels. > > As to the earlier question form the thread as why this isn't a github > automation: the actual reason I was writing the script was to get some > on-demand statistics for my own interest and it just turned out this > was something that bugged me that I could use the same framework for > (I did a trivial review and thought how annoying it would be to have > to manually set a reminder myself to do a future action). I was a > pretty trivial (few hours) script, so I have no concern if it is done > differently or not used in the future should a better way present > itself. > > Mark > > On Sun, Feb 9, 2020 at 12:19 AM Matt Caswell wrote: > > > > > > > > On 08/02/2020 15:56, Mark J Cox wrote: > > > I've currently got a cron job running every hour that looks at open PR > > > requests against github openssl repo and does various actions. So if > > > you were wondering why I was altering labels and making comments at > > > 4am, now you know. No doubt we'll use some tool user for this in the > > > future. > > > > > > So right now here's what it does: > > > > > > Every hour it looks at open PRs that are labelled "approval: done". > > > If 24 hours has elapsed since that label was assigned and if there > > > have been no comments made to the PR since the label was assigned then > > > it is automatically moved to "approval: ready to merge" with a comment > > > added to trigger notifications. So if you want to stop something > > > going to "ready to merge" just add any comment to the PR. > > > > > > I'm thinking of using this script also to 1) collect interesting stats > > > and 2) do some other actions. So if there's some automation you'd > > > like to see just add an enhancement issue against the openssl/tools > > > repo. > > > > > > 1 Matt already asked for committer notification trigger for anything > > > labelled Urgent. > > > > > > 2 If there were comments made after "approval: done" then I think we > > > really ought to drop the "approval: done" label as the comments likely > > > invalidated the approval. So I'll likely add that next week (if > > > "approval: done" label and has comments since that label then remove > > > the label and add a comment 'please review if this is really approval: > > > done'. If the approval: done label gets set again then after 24 hours > > > the existing automation will trigger. #10786 is a good example of > > > this. > > > > I'm less sure about this. I think there are probably many examples where > > this is not the case. E.g. a quick review found these recent cases: > > > > https://github.com/openssl/openssl/pull/11003 > > > > https://github.com/openssl/openssl/pull/11015 > > > > https://github.com/openssl/openssl/pull/10992 > > > > https://github.com/openssl/openssl/pull/10991 > > > > https://github.com/openssl/openssl/pull/10990 > > > > https://github.com/openssl/openssl/pull/10989 > > > > I would be more minded to think that if a comment invalidates an > > "approval done" then the committer should explicitly decide to do that. > > > > Matt From matt at openssl.org Mon Feb 10 16:19:20 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 10 Feb 2020 16:19:20 +0000 Subject: Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked? In-Reply-To: <6CA71838-4736-4701-AD3C-2CD06AA83A0C@oracle.com> References: <6CA71838-4736-4701-AD3C-2CD06AA83A0C@oracle.com> Message-ID: <7dc2558c-9ef0-5410-1cb9-771fde9d91bd@openssl.org> On 10/02/2020 00:15, SHANE LONTIS wrote: > With the new architecture changes there are quite a few new calls to > > CRYPTO_UP_REF() > CRYPTO_DOWN_REF() > > These methods return an int that is not being checked in lots of places. > > This return value only seems to affect fallback code that calls CRYPTO_atomic_add (which can return 0 on lock or unlock failure) > > SO the question is should we be checking this return value? Yes, I think we should be. Matt > > > Note that not checking has resulted in a few assumptions in other code? > e.g the following function returns void. > > /crypto/evp/keymgmt_lib.c: 165 in evp_keymgmt_util_cache_pkey() > 159 } > 160 > 161 void evp_keymgmt_util_cache_pkey(EVP_PKEY *pk, size_t index, > 162 EVP_KEYMGMT *keymgmt, void *keydata) > 163 { > 164 if (keydata != NULL) { >>>> CID 1458170: Error handling issues (CHECKED_RETURN) >>>> Calling "EVP_KEYMGMT_up_ref" without checking return value (as is done elsewhere 4 out of 5 times). > 165 EVP_KEYMGMT_up_ref(keymgmt); > > NOTE: EVP_KEYMGMT_up_ref() just does an CRYPTO_UP_REF() call and always returns 1. > > From kurt at roeckx.be Mon Feb 10 17:29:52 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 10 Feb 2020 18:29:52 +0100 Subject: Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked? In-Reply-To: <7dc2558c-9ef0-5410-1cb9-771fde9d91bd@openssl.org> References: <6CA71838-4736-4701-AD3C-2CD06AA83A0C@oracle.com> <7dc2558c-9ef0-5410-1cb9-771fde9d91bd@openssl.org> Message-ID: <20200210172952.GA1242839@roeckx.be> On Mon, Feb 10, 2020 at 04:19:20PM +0000, Matt Caswell wrote: > > > On 10/02/2020 00:15, SHANE LONTIS wrote: > > With the new architecture changes there are quite a few new calls to > > > > CRYPTO_UP_REF() > > CRYPTO_DOWN_REF() > > > > These methods return an int that is not being checked in lots of places. > > > > This return value only seems to affect fallback code that calls CRYPTO_atomic_add (which can return 0 on lock or unlock failure) > > > > SO the question is should we be checking this return value? > > Yes, I think we should be. I think that as long as we have that fallback code, that it should be checked. Kurt From bernd.edlinger at hotmail.de Mon Feb 10 19:18:34 2020 From: bernd.edlinger at hotmail.de (Bernd Edlinger) Date: Mon, 10 Feb 2020 19:18:34 +0000 Subject: Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked? In-Reply-To: <20200210172952.GA1242839@roeckx.be> References: <6CA71838-4736-4701-AD3C-2CD06AA83A0C@oracle.com> <7dc2558c-9ef0-5410-1cb9-771fde9d91bd@openssl.org> <20200210172952.GA1242839@roeckx.be> Message-ID: On 2/10/20 6:29 PM, Kurt Roeckx wrote: > On Mon, Feb 10, 2020 at 04:19:20PM +0000, Matt Caswell wrote: >> >> >> On 10/02/2020 00:15, SHANE LONTIS wrote: >>> With the new architecture changes there are quite a few new calls to >>> >>> CRYPTO_UP_REF() >>> CRYPTO_DOWN_REF() >>> >>> These methods return an int that is not being checked in lots of places. >>> >>> This return value only seems to affect fallback code that calls CRYPTO_atomic_add (which can return 0 on lock or unlock failure) >>> >>> SO the question is should we be checking this return value? >> >> Yes, I think we should be. > > I think that as long as we have that fallback code, that it should > be checked. > > Yes, although I wonder why a function that checks the return value of CRYPTO_THREAD_write_lock and CRYPTO_THREAD_unlock does not check for possible overflow of the addition, which is far more likely to happen. Bernd. From kurt at roeckx.be Tue Feb 11 22:33:14 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 11 Feb 2020 23:33:14 +0100 Subject: Github PR label automation In-Reply-To: References: Message-ID: <20200211223314.GA1349861@roeckx.be> On Sat, Feb 08, 2020 at 03:56:19PM +0000, Mark J Cox wrote: > So right now here's what it does: > > Every hour it looks at open PRs that are labelled "approval: done". > If 24 hours has elapsed since that label was assigned and if there > have been no comments made to the PR since the label was assigned then > it is automatically moved to "approval: ready to merge" with a comment > added to trigger notifications. So if you want to stop something > going to "ready to merge" just add any comment to the PR. Does it also check that the CI says that everything is OK? From mark at openssl.org Wed Feb 12 08:22:25 2020 From: mark at openssl.org (Mark J Cox) Date: Wed, 12 Feb 2020 08:22:25 +0000 Subject: Github PR label automation In-Reply-To: <20200211223314.GA1349861@roeckx.be> References: <20200211223314.GA1349861@roeckx.be> Message-ID: > Does it also check that the CI says that everything is OK? Do we want it to? I assumed that Approval: done was not being applied unless tests past (but looking that's not always the case). Can we assume that something in "approval: ready to merge" but that failed CI won't get merged? Otherwise I could add a CI check on the move to "ready to merge". Mark From Matthias.St.Pierre at ncp-e.com Wed Feb 12 08:49:04 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 12 Feb 2020 08:49:04 +0000 Subject: Github PR label automation In-Reply-To: References: <20200211223314.GA1349861@roeckx.be> Message-ID: > > Does it also check that the CI says that everything is OK? > > Do we want it to? I assumed that Approval: done was not being applied > unless tests past (but looking that's not always the case). Can we > assume that something in "approval: ready to merge" but that failed CI > won't get merged? Otherwise I could add a CI check on the move to > "ready to merge". It does not check and I don't think it should attempt to do it. The only task of this script should be to automatically promote the [approval: done] state to [approval: ready to merge] after the grace period has expired, because humans tend to forget that. Anything beyond that, in particular an attempt to judge whether the approval is valid or not, and whether a CI failure can be ignored or not, should be left to humans. Matthias From mark at openssl.org Wed Feb 12 08:56:45 2020 From: mark at openssl.org (Mark J Cox) Date: Wed, 12 Feb 2020 08:56:45 +0000 Subject: Github PR label automation In-Reply-To: References: <20200211223314.GA1349861@roeckx.be> Message-ID: I thought about it some more and Kurt is right. Something shouldn't be in "Ready to Merge" unless it's actually ready to merge. For example 10993. This PR shouldn't be ever automatically moved to ready to merge because it failed CI. A human has determined it is ready to merge and applied the label. So "ready to merge" really ought to mean that. So I've updated the live script that's running to do that check. It will not move to 'ready to merge' state automatically unless (or until) all CI passes. (I'll do a PR for the tool with that change shortly). Mark On Wed, Feb 12, 2020 at 8:49 AM Dr. Matthias St. Pierre wrote: > > > > Does it also check that the CI says that everything is OK? > > > > Do we want it to? I assumed that Approval: done was not being applied > > unless tests past (but looking that's not always the case). Can we > > assume that something in "approval: ready to merge" but that failed CI > > won't get merged? Otherwise I could add a CI check on the move to > > "ready to merge". > > It does not check and I don't think it should attempt to do it. The only task of > this script should be to automatically promote the [approval: done] state to > [approval: ready to merge] after the grace period has expired, because humans > tend to forget that. Anything beyond that, in particular an attempt to judge > whether the approval is valid or not, and whether a CI failure can be ignored or > not, should be left to humans. > > Matthias > From Matthias.St.Pierre at ncp-e.com Wed Feb 12 10:39:16 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 12 Feb 2020 10:39:16 +0000 Subject: Github PR label automation In-Reply-To: References: <20200211223314.GA1349861@roeckx.be> Message-ID: <5ce9addd240043a685479a64ddce1c9c@Ex13.ncp.local> > check. It will not move to 'ready to merge' state automatically > unless (or until) all CI passes. (I'll do a PR for the tool with that > change shortly). If the does not automatically remove the "ready to merge" label, but only refrains from setting it automatically, that's a good compromise I can live with. Matthias From mark at openssl.org Wed Feb 12 10:50:44 2020 From: mark at openssl.org (Mark J Cox) Date: Wed, 12 Feb 2020 10:50:44 +0000 Subject: Github PR label automation In-Reply-To: <5ce9addd240043a685479a64ddce1c9c@Ex13.ncp.local> References: <20200211223314.GA1349861@roeckx.be> <5ce9addd240043a685479a64ddce1c9c@Ex13.ncp.local> Message-ID: Correct, it has no way to know if something has been put into ready to merge deliberately despite it failing checks etc so it won't mess with removing the label. Mark On Wed, Feb 12, 2020 at 10:39 AM Dr. Matthias St. Pierre wrote: > > > check. It will not move to 'ready to merge' state automatically > > unless (or until) all CI passes. (I'll do a PR for the tool with that > > change shortly). > > If the does not automatically remove the "ready to merge" label, but only > refrains from setting it automatically, that's a good compromise I can live with. > > Matthias > From paul.dale at oracle.com Fri Feb 14 02:30:04 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 14 Feb 2020 12:30:04 +1000 Subject: Deprecation Message-ID: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> There is some pushback against the deprecations going on in various PRs. The plan has always been to deprecate engines in 3.0 and removing support for them 5+ years later. Originally, the path was to have included an engine provider that could load engines and make them appear to be a provider. After a fair amount of investigation, this was deemed to be too difficult in the 3.0 time frame. Do we still want to deprecate engines in 3.0? Should we defer until 4.0 instead? The main benefits seem to boil down to continuing to support existing engines vs removing the legacy code paths and switching to the provider model. 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 Fri Feb 14 07:24:35 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 14 Feb 2020 08:24:35 +0100 Subject: Deprecation In-Reply-To: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> Message-ID: <9bae0ca0687c8fbff9f657c88739a3d8e9a8d380.camel@redhat.com> On Fri, 2020-02-14 at 12:30 +1000, Dr Paul Dale wrote: > There is some pushback against the deprecations going on in various > PRs. > > The plan has always been to deprecate engines in 3.0 and removing > support for them 5+ years later. Originally, the path was to have > included an engine provider that could load engines and make them > appear to be a provider. After a fair amount of investigation, this > was deemed to be too difficult in the 3.0 time frame. > > Do we still want to deprecate engines in 3.0? > Should we defer until 4.0 instead? > > > The main benefits seem to boil down to continuing to support existing > engines vs removing the legacy code paths and switching to the > provider model. I do not understand the pushback too much - Perhaps it could be resolved by proper explanation that deprecation does not mean a removal? Also even if some stuff deprecated in 3.0 is removed in 4.0, it does not necessarily mean that engines must be removed in the same release. They can continue to be supported (just deprecated) until 5.0 for example. I think that doing the deprecation as early as possible is better - it properly gives the signal that the engine interface is legacy and it will disappear at some point. It provides more time for 3rd party engines to transform into providers. -- 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 Fri Feb 14 09:21:49 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Fri, 14 Feb 2020 10:21:49 +0100 Subject: Deprecation In-Reply-To: <9bae0ca0687c8fbff9f657c88739a3d8e9a8d380.camel@redhat.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <9bae0ca0687c8fbff9f657c88739a3d8e9a8d380.camel@redhat.com> Message-ID: <5d52a15d-a51b-7123-6d39-54e304445d04@ncp-e.com> On 14.02.20 08:24, Tomas Mraz wrote: > > I do not understand the pushback too much - Perhaps it could be > resolved by proper explanation that deprecation does not mean a > removal? > > Also even if some stuff deprecated in 3.0 is removed in 4.0, it does > not necessarily mean that engines must be removed in the same release. > They can continue to be supported (just deprecated) until 5.0 for > example. > > I think that doing the deprecation as early as possible is better - it > properly gives the signal that the engine interface is legacy and it > will disappear at some point. It provides more time for 3rd party > engines to transform into providers. > I agree with Tomas. In addition, I think it is high time to publish a definite timescale for actually *removing* the older deprecated APIs, at least for the first three entries in the list below: ??? OPENSSL_NO_DEPRECATED_0_9_8? # ??? OPENSSL_NO_DEPRECATED_1_0_0? # ??? OPENSSL_NO_DEPRECATED_1_0_1? # ??? OPENSSL_NO_DEPRECATED_1_0_2 ??? OPENSSL_NO_DEPRECATED_1_1_0 ??? OPENSSL_NO_DEPRECATED_1_1_1 ??? OPENSSL_NO_DEPRECATED_3_0 Because deprecation without removal is futile, it increases complexity of the code instead of reducing it. Matthias From Matthias.St.Pierre at ncp-e.com Fri Feb 14 09:31:26 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Fri, 14 Feb 2020 10:31:26 +0100 Subject: Deprecation In-Reply-To: <5d52a15d-a51b-7123-6d39-54e304445d04@ncp-e.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <9bae0ca0687c8fbff9f657c88739a3d8e9a8d380.camel@redhat.com> <5d52a15d-a51b-7123-6d39-54e304445d04@ncp-e.com> Message-ID: <7cf06209-6b7c-066d-d6d6-d12d81697fb9@ncp-e.com> On 14.02.20 10:21, Matthias St. Pierre wrote: > > Because deprecation without removal is futile, it increases complexity of the code > instead of reducing it. > > Matthias > To underlinie my last statement, I added the initial release dates: ??? OPENSSL_NO_DEPRECATED_0_9_8? # 05 Jul 2005 ??? OPENSSL_NO_DEPRECATED_1_0_0? # 29 Mar 2010 ??? OPENSSL_NO_DEPRECATED_1_0_1? # 14 Mar 2012 From beldmit at gmail.com Fri Feb 14 09:36:10 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 14 Feb 2020 12:36:10 +0300 Subject: Deprecation In-Reply-To: <7cf06209-6b7c-066d-d6d6-d12d81697fb9@ncp-e.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <9bae0ca0687c8fbff9f657c88739a3d8e9a8d380.camel@redhat.com> <5d52a15d-a51b-7123-6d39-54e304445d04@ncp-e.com> <7cf06209-6b7c-066d-d6d6-d12d81697fb9@ncp-e.com> Message-ID: Hello, I think OPENSSL_NO_DEPRECATED_1_0_2 should be added to this list too. On Fri, Feb 14, 2020 at 12:31 PM Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > > > On 14.02.20 10:21, Matthias St. Pierre wrote: > > > > Because deprecation without removal is futile, it increases complexity > of the code > > instead of reducing it. > > > > Matthias > > > > To underlinie my last statement, I added the initial release dates: > > OPENSSL_NO_DEPRECATED_0_9_8 # 05 Jul 2005 > OPENSSL_NO_DEPRECATED_1_0_0 # 29 Mar 2010 > OPENSSL_NO_DEPRECATED_1_0_1 # 14 Mar 2012 > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Feb 14 09:37:33 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 14 Feb 2020 09:37:33 +0000 Subject: Deprecation In-Reply-To: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> Message-ID: <5db000b5-49a1-e684-d2ee-bdb7fa516b34@openssl.org> On 14/02/2020 02:30, Dr Paul Dale wrote: > There is some pushback against the deprecations going on in various PRs. I've not followed all of the PRs. Can you point at some specific comments you've received pushing back on this? Matt > > The plan has always been to deprecate engines in 3.0 and removing > support for them 5+ years later. ?Originally, the path was to have > included an engine provider that could load engines and make them appear > to be a provider. ?After a fair amount of investigation, this was deemed > to be too difficult in the 3.0 time frame. > > Do we still want to deprecate engines in 3.0? > Should we defer until 4.0 instead? > > > The main benefits seem to boil down to continuing to support existing > engines vs removing the legacy code paths and switching to the provider > model. > > > Pauli > --? > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? > Phone +61 7 3031 7217 > Oracle Australia > From beldmit at gmail.com Fri Feb 14 09:41:05 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 14 Feb 2020 12:41:05 +0300 Subject: Deprecation In-Reply-To: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> Message-ID: Hello, On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale wrote: > There is some pushback against the deprecations going on in various PRs. > > The plan has always been to deprecate engines in 3.0 and removing support > for them 5+ years later. Originally, the path was to have included an > engine provider that could load engines and make them appear to be a > provider. After a fair amount of investigation, this was deemed to be too > difficult in the 3.0 time frame. > > Do we still want to deprecate engines in 3.0? > Should we defer until 4.0 instead? > I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of provider API. The main benefits seem to boil down to continuing to support existing > engines vs removing the legacy code paths and switching to the provider > model. > For me, both as open-source and commercial engine developer seems reasonable to delay conversion from engines to providers at least until 3.0.0 feature freeze happens. But some features I'm interested in imply engine model (and it will be great if somebody else could look at PR 10904 to avoid it when possible). -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Feb 14 09:48:04 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 14 Feb 2020 09:48:04 +0000 Subject: Deprecation In-Reply-To: References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> Message-ID: <794e4896-4d76-9cd0-f702-1b8a30d26182@openssl.org> On 14/02/2020 09:41, Dmitry Belyavsky wrote: > Hello, > > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale > wrote: > > There is some pushback against the deprecations going on in various PRs. > > The plan has always been to deprecate engines in 3.0 and removing > support for them 5+ years later.? Originally, the path was to have > included an engine provider that could load engines and make them > appear to be a provider.? After a fair amount of investigation, this > was deemed to be too difficult in the 3.0 time frame. > > Do we still want to deprecate engines in 3.0? > Should we defer until 4.0 instead? > > > I think we should delay the deprecation of engine stuff to 4.0. > Personally I don't have sense of stability of provider API. Well - it isn't stable *right now*. Its in development. But moving forward the provider model *is* the way we intend to go. By the time of the 3.0 release the provider stuff had better be stable, otherwise we've gone wrong. As has been pointed out many times. Deprecation does not mean removal (yet). Its just a signal that at some later time we will remove it. And the 3.0 is the right time to signal that. We don't want to hold on the "legacy" codepaths for any longer than we have to. They were only ever originally intended to be temporary, and to be removed before 3.0 got released. However it now looks like they will live beyond the 3.0 release. They should not live for any longer than absolutely necessary. > > The main benefits seem to boil down to continuing to support > existing engines vs removing the legacy code paths and switching to > the provider model. > > > For me, both as open-source and commercial engine developer seems > reasonable to delay conversion from engines to providers at least until > 3.0.0 feature freeze happens. That's a perfectly reasonable strategy. But this decision is independent of whether we deprecate the ENGINE APIs in 3.0 or not. It would be perfectly ok for people to continue to *use* engines in 3.0 even though they are deprecated. > But some features I'm interested in imply engine model (and it will be > great if somebody else could look at PR 10904 to avoid it when possible). If there are gaps then we need to plug them. The provider model should be able to do everything that you can do now in ENGINEs. Matt From levitte at openssl.org Fri Feb 14 10:36:56 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 14 Feb 2020 11:36:56 +0100 Subject: Deprecation In-Reply-To: References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> Message-ID: <87h7zt5ubb.wl-levitte@openssl.org> On Fri, 14 Feb 2020 10:41:05 +0100, Dmitry Belyavsky wrote: > > > Hello, > > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale wrote: > > There is some pushback against the deprecations going on in various PRs. > > The plan has always been to deprecate engines in 3.0 and removing support for them 5+ years later.? > Originally, the path was to have included an engine provider that could load engines and make them appear > to be a provider.? After a fair amount of investigation, this was deemed to be too difficult in the 3.0 > time frame. > > Do we still want to deprecate engines in 3.0? > Should we defer until 4.0 instead? > > I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of > provider API. It should be pointed out that the engine stuff isn't as stable as you might think, because it shares internal structures with libcrypto. Even if we handle those structures via function calls, all it takes is loading an engine linked against - say - 1.1.0 in 1.1.1 to run a real risk of a spectacular KABOOM if any of the structure that are touched changed between those OpenSSL versions. This is a consequence of making structures opaque and feeling much more liberty in changing them, and we didn't quite pay attention. The whole model around providers is intentionally designed to allow providers to run flexibly with any OpenSSL version, even if they are linked with some (possibly different) libcrypto version. So the question of stability depends on what you look at. It's true that some parts of the provider API is fluctuating a bit, as early designs need modifications to better meet demands. We're still in development. Come beta1 (schedule for June), I expect that it will have stabilized. Come the release, it must have. > The main benefits seem to boil down to continuing to support existing engines vs removing the legacy code > paths and switching to the provider model. > > For me, both as open-source and commercial engine developer seems > reasonable to delay conversion from engines to providers at least > until 3.0.0 feature freeze happens. According to our policy, a deprecation starts at the release that has those deprecations, and removal of deprecated stuff can only happen 5 years later at the earliest. Seeing deprecations in the source now doesn't change that, the clock will start ticking when we release 3.0, so consider what you see happening on github as a pre-deprecation warning. > But some features I'm interested in imply engine model (and it will > be great if somebody else could look at PR 10904 to avoid it when > possible). Apart from a few details, that PR looks rather innocuous. I frankly haven't had time to look at it too deeply (I just discovered that I was prompted), as I haven't dived in the CMS code yet... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Fri Feb 14 10:46:30 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 14 Feb 2020 20:46:30 +1000 Subject: Deprecation In-Reply-To: <5db000b5-49a1-e684-d2ee-bdb7fa516b34@openssl.org> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <5db000b5-49a1-e684-d2ee-bdb7fa516b34@openssl.org> Message-ID: <0DED6D1A-6243-472C-A305-1437143D127F@oracle.com> Roumen in https://github.com/openssl/openssl/pull/10977#issuecomment-584818517 Dmitry in https://github.com/openssl/openssl/pull/11082#issuecomment-585603911 And a further one via private email. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 14 Feb 2020, at 7:37 pm, Matt Caswell wrote: > > > > On 14/02/2020 02:30, Dr Paul Dale wrote: >> There is some pushback against the deprecations going on in various PRs. > > I've not followed all of the PRs. Can you point at some specific > comments you've received pushing back on this? > > Matt > > >> >> The plan has always been to deprecate engines in 3.0 and removing >> support for them 5+ years later. Originally, the path was to have >> included an engine provider that could load engines and make them appear >> to be a provider. After a fair amount of investigation, this was deemed >> to be too difficult in the 3.0 time frame. >> >> Do we still want to deprecate engines in 3.0? >> Should we defer until 4.0 instead? >> >> >> The main benefits seem to boil down to continuing to support existing >> engines vs removing the legacy code paths and switching to the provider >> model. >> >> >> 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 Feb 14 10:58:32 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 14 Feb 2020 10:58:32 +0000 Subject: Deprecation In-Reply-To: <0DED6D1A-6243-472C-A305-1437143D127F@oracle.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <5db000b5-49a1-e684-d2ee-bdb7fa516b34@openssl.org> <0DED6D1A-6243-472C-A305-1437143D127F@oracle.com> Message-ID: <2f35e26f-8ee7-a2ed-5327-b740f226a5f0@openssl.org> On 14/02/2020 10:46, Dr Paul Dale wrote: > Roumen in > https://github.com/openssl/openssl/pull/10977#issuecomment-584818517 > Dmitry > in?https://github.com/openssl/openssl/pull/11082#issuecomment-585603911 Thanks. Having re-read the comments and the thread here, I am still of the opinion that we should press ahead with the deprecations as planned. Matt > And a further one via private email. > > Pauli > --? > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 14 Feb 2020, at 7:37 pm, Matt Caswell > > wrote: >> >> >> >> On 14/02/2020 02:30, Dr Paul Dale wrote: >>> There is some pushback against the deprecations going on in various PRs. >> >> I've not followed all of the PRs. Can you point at some specific >> comments you've received pushing back on this? >> >> Matt >> >> >>> >>> The plan has always been to deprecate engines in 3.0 and removing >>> support for them 5+ years later. ?Originally, the path was to have >>> included an engine provider that could load engines and make them appear >>> to be a provider. ?After a fair amount of investigation, this was deemed >>> to be too difficult in the 3.0 time frame. >>> >>> Do we still want to deprecate engines in 3.0? >>> Should we defer until 4.0 instead? >>> >>> >>> The main benefits seem to boil down to continuing to support existing >>> engines vs removing the legacy code paths and switching to the provider >>> model. >>> >>> >>> Pauli >>> --? >>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? >>> Phone +61 7 3031 7217 >>> Oracle Australia >>> > From beldmit at gmail.com Fri Feb 14 11:08:28 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 14 Feb 2020 14:08:28 +0300 Subject: Deprecation In-Reply-To: <794e4896-4d76-9cd0-f702-1b8a30d26182@openssl.org> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <794e4896-4d76-9cd0-f702-1b8a30d26182@openssl.org> Message-ID: Dear Matt, On Fri, Feb 14, 2020 at 12:48 PM Matt Caswell wrote: > > > On 14/02/2020 09:41, Dmitry Belyavsky wrote: > > Hello, > > > > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale > > wrote: > > > > There is some pushback against the deprecations going on in various > PRs. > > > > The plan has always been to deprecate engines in 3.0 and removing > > support for them 5+ years later. Originally, the path was to have > > included an engine provider that could load engines and make them > > appear to be a provider. After a fair amount of investigation, this > > was deemed to be too difficult in the 3.0 time frame. > > > > Do we still want to deprecate engines in 3.0? > > Should we defer until 4.0 instead? > > > > > > I think we should delay the deprecation of engine stuff to 4.0. > > Personally I don't have sense of stability of provider API. > > Well - it isn't stable *right now*. Its in development. But moving > forward the provider model *is* the way we intend to go. By the time of > the 3.0 release the provider stuff had better be stable, otherwise we've > gone wrong. > Totally agree. Though the conversion between engines and providers is not as straightforward as I want, so I prefer to wait for some time. > > As has been pointed out many times. Deprecation does not mean removal > (yet). Its just a signal that at some later time we will remove it. > Sure. > > And the 3.0 is the right time to signal that. We don't want to hold on > the "legacy" codepaths for any longer than we have to. They were only > ever originally intended to be temporary, and to be removed before 3.0 > got released. However it now looks like they will live beyond the 3.0 > release. They should not live for any longer than absolutely necessary. > Hmmm. Not sure here. I remember the introduction of EVP_PKEY_ameth/pmeth currently moving to providers. > The main benefits seem to boil down to continuing to support > > existing engines vs removing the legacy code paths and switching to > > the provider model. > It's worth explaining the benefits to engine authors :) I understand the benefits of OpenSSL as a product and still now don't have a firm understanding of benefits for the surrounding ecosystem. Though I did not dive into the providers deeply. I still have a suspicion that we will not have function signatures for callbacks in providers. Do we? If don't, we'll have a set of errors implementing it. > For me, both as open-source and commercial engine developer seems > > reasonable to delay conversion from engines to providers at least until > > 3.0.0 feature freeze happens. > > That's a perfectly reasonable strategy. But this decision is independent > of whether we deprecate the ENGINE APIs in 3.0 or not. It would be > perfectly ok for people to continue to *use* engines in 3.0 even though > they are deprecated. > Sure. > > But some features I'm interested in imply engine model (and it will be > > great if somebody else could look at PR 10904 to avoid it when possible). > > If there are gaps then we need to plug them. The provider model should > be able to do everything that you can do now in ENGINEs. > Totally agree. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Feb 14 11:17:30 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 14 Feb 2020 14:17:30 +0300 Subject: Deprecation In-Reply-To: <87h7zt5ubb.wl-levitte@openssl.org> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <87h7zt5ubb.wl-levitte@openssl.org> Message-ID: Dear Richard, On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte wrote: > On Fri, 14 Feb 2020 10:41:05 +0100, > Dmitry Belyavsky wrote: > > > > > > Hello, > > > > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale > wrote: > > > > There is some pushback against the deprecations going on in various > PRs. > > > > The plan has always been to deprecate engines in 3.0 and removing > support for them 5+ years later. > > Originally, the path was to have included an engine provider that > could load engines and make them appear > > to be a provider. After a fair amount of investigation, this was > deemed to be too difficult in the 3.0 > > time frame. > > > > Do we still want to deprecate engines in 3.0? > > Should we defer until 4.0 instead? > > > > I think we should delay the deprecation of engine stuff to 4.0. > Personally I don't have sense of stability of > > provider API. > > It should be pointed out that the engine stuff isn't as stable as you > might think, because it shares internal structures with libcrypto. > Even if we handle those structures via function calls, all it takes is > loading an engine linked against - say - 1.1.0 in 1.1.1 to run a real > risk of a spectacular KABOOM if any of the structure that are touched > changed between those OpenSSL versions. > Does ABI compatibility cover a significant share of these cases? > This is a consequence of making structures opaque and feeling much > more liberty in changing them, and we didn't quite pay attention. > > The whole model around providers is intentionally designed to allow > providers to run flexibly with any OpenSSL version, even if they are > linked with some (possibly different) libcrypto version. > > So the question of stability depends on what you look at. > Agreed. It's true that some parts of the provider API is fluctuating a bit, as > early designs need modifications to better meet demands. We're still > in development. Come beta1 (schedule for June), I expect that it will > have stabilized. Come the release, it must have. > Sure. > The main benefits seem to boil down to continuing to support existing > engines vs removing the legacy code > > paths and switching to the provider model. > > > > For me, both as open-source and commercial engine developer seems > > reasonable to delay conversion from engines to providers at least > > until 3.0.0 feature freeze happens. > > According to our policy, a deprecation starts at the release that has > those deprecations, and removal of deprecated stuff can only happen 5 > years later at the earliest. Seeing deprecations in the source now > doesn't change that, the clock will start ticking when we release > 3.0, so consider what you see happening on github as a pre-deprecation > warning. > Yes. > > But some features I'm interested in imply engine model (and it will > > be great if somebody else could look at PR 10904 to avoid it when > > possible). > > Apart from a few details, that PR looks rather innocuous. I frankly > haven't had time to look at it too deeply (I just discovered that I > was prompted), as I haven't dived in the CMS code yet... > Well, the problem is introducing some new control values. I don't feel policy here very well. I also plan to submit at least one TLS-related PR significantly more innocent... -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Feb 14 11:37:12 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 14 Feb 2020 12:37:12 +0100 Subject: Deprecation In-Reply-To: References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <87h7zt5ubb.wl-levitte@openssl.org> Message-ID: <87d0ah5riv.wl-levitte@openssl.org> On Fri, 14 Feb 2020 12:17:30 +0100, Dmitry Belyavsky wrote: > > > Dear Richard, > > On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte wrote: > > It should be pointed out that the engine stuff isn't as stable as you > might think, because it shares internal structures with libcrypto. > Even if we handle those structures via function calls, all it takes is > loading an engine linked against - say - 1.1.0 in 1.1.1 to run a real > risk of a spectacular KABOOM if any of the structure that are touched > changed between those OpenSSL versions. > > Does ABI compatibility cover a significant share of these cases? Yes. Any structure change between those OpenSSL version potentially means an ABI incompatibility between an engine and the libcrypto that loads it. This is precisely the reason why we have forbidden shared opaque structures over the libcrypto <-> provider boundary. ... > > But some features I'm interested in imply engine model (and it will > > be great if somebody else could look at PR 10904 to avoid it when > > possible). > > Apart from a few details, that PR looks rather innocuous.? I frankly > haven't had time to look at it too deeply (I just discovered that I > was prompted), as I haven't dived in the CMS code yet... > > Well, the problem is introducing some new control values. I don't > feel policy here very well. I also plan to submit at least one > TLS-related PR significantly more innocent... We haven't formed a clear policy on those, it's a bit of play as we go and do what makes most sense. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From nic.tuv at gmail.com Fri Feb 14 12:23:34 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 14 Feb 2020 13:23:34 +0100 Subject: Errored: openssl/openssl#31939 (master - 34b1676) In-Reply-To: <7ec6629c-2e17-c86e-7f4d-96935bd84a72@openssl.org> References: <5e3a05f94b2ee_43fb2926da1f82485e1@2f147ff5-212e-4b07-88f1-e30936129eef.mail> <7ec6629c-2e17-c86e-7f4d-96935bd84a72@openssl.org> Message-ID: If ASAN is too slow to run in the CI should we restore the previous homemade checks for memory leaks as an alternative to be run in regular CI runs and leave ASAN builds to run-checker on the master branch only? Here is another idea that would be interesting if we restore the previous checks: I don't know what kind of options github offers on this, but would it be possible to run triggered CI on something that is not Travis and does not timeout and still have the results in the PR? If something like that would be possible we could move the ASAN builds to extended_tests, rely on the previous memleak detection for the regular CI runs, and then trigger with a script or Github Action the extended_tests when the approval:done label is added. That way, by the time something is ready to be merged we should have a full picture! Nicola On Wed, Feb 5, 2020, 10:25 Matt Caswell wrote: > Since we fixed the Travis builds 4 out of the 8 builds on master that > have taken place have errored due to a timeout. > > The msan build is consistently taking a *very* long time to run. If it > gets to 50 minutes then Travis cuts it off and the build fails. > > Should we disable the msan build? > > Matt > > > -------- Forwarded Message -------- > Subject: Errored: openssl/openssl#31939 (master - 34b1676) > Date: Wed, 05 Feb 2020 00:02:01 +0000 > From: Travis CI > To: openssl-commits at openssl.org > > > > openssl > > / > > openssl > > < > https://travis-ci.org/openssl/openssl?utm_medium=notification&utm_source=email > > > > > branch iconmaster > > build has errored > Build #31939 has errored > < > https://travis-ci.org/openssl/openssl/builds/646181069?utm_medium=notification&utm_source=email > > > arrow to build time > clock icon50 mins and 3 secs > > Pauli avatarPauli > > 34b1676 CHANGESET ? > > > Make minimum size for secure memory a size_t. > > The minimum size argument to CRYPTO_secure_malloc_init() was an int but > ought > to be a size_t since it is a size. > > From an API perspective, this is a change. However, the minimum size is > verified as being a positive power of two and it will typically be a small > constant. > > Reviewed-by: David von Oheimb > (Merged from #11003) > > Want to know about upcoming build environment updates? > > Would you like to stay up-to-date with the upcoming Travis CI build > environment updates? We set up a mailing list for you! > > SIGN UP HERE > > book icon > > Documentation about Travis CI > > Have any questions? We're here to help. > Unsubscribe > < > https://travis-ci.org/account/preferences/unsubscribe?repository=5849220&utm_medium=notification&utm_source=email > > > from build emails from the openssl/openssl repository. > To unsubscribe from *all* build emails, please update your settings > < > https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email > >. > > black and white travis ci logo > > Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy > Jacops | Contact: contact at travis-ci.com | > Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gem?? > ?27 a Umsatzsteuergesetz: DE282002648 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Feb 14 13:00:34 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 14 Feb 2020 13:00:34 +0000 Subject: Errored: openssl/openssl#31939 (master - 34b1676) In-Reply-To: References: <5e3a05f94b2ee_43fb2926da1f82485e1@2f147ff5-212e-4b07-88f1-e30936129eef.mail> <7ec6629c-2e17-c86e-7f4d-96935bd84a72@openssl.org> Message-ID: On 14/02/2020 12:23, Nicola Tuveri wrote: > If ASAN is too slow to run in the CI should we restore the previous > homemade checks for memory leaks as an alternative to be run in regular > CI runs and leave ASAN builds to run-checker on the master branch only? To be clear the build that is timing out uses *msan* not *asan*. As I understand it msan detects unitialised reads. whereas asan detects memory corruption, buffer overflows, use-after-free bugs, and memory leaks. The previous "home-made" checks only detected memory leaks, so it is not comparable with the functionality offered by msan. The msan documentation (https://clang.llvm.org/docs/MemorySanitizer.html) suggests that a slow down of 3x is typical. It seems reasonable to me to disable msan checks in Travis entirely, and have them only in run-checker. > > Here is another idea that would be interesting if we restore the > previous checks: > I don't know what kind of options github offers on this, but would it be > possible to run triggered CI on something that is not Travis and does > not timeout and still have the results in the PR? I am sure there are hooks to do this. Richard has been talking for quite a while about setting up a buildbot infrastructure. If that could be integrated into github that would be really neat. Matt > If something like that would be possible we could move the ASAN builds > to extended_tests, rely on the previous memleak detection for the > regular CI runs, and then trigger with a script or Github Action the > extended_tests when the approval:done label is added.? > > That way, by the time something is ready to be merged we should have a > full picture!? > > > Nicola > > On Wed, Feb 5, 2020, 10:25 Matt Caswell > wrote: > > Since we fixed the Travis builds 4 out of the 8 builds on master that > have taken place have errored due to a timeout. > > The msan build is consistently taking a *very* long time to run. If it > gets to 50 minutes then Travis cuts it off and the build fails. > > Should we disable the msan build? > > Matt > > > -------- Forwarded Message -------- > Subject:? ? ? ? Errored: openssl/openssl#31939 (master - 34b1676) > Date:? ?Wed, 05 Feb 2020 00:02:01 +0000 > From:? ?Travis CI > > To:? ? ?openssl-commits at openssl.org > > > > openssl > > / > > openssl > > > > > branch iconmaster > > build has errored > Build #31939 has errored > > arrow to build time > clock icon50 mins and 3 secs > > Pauli avatarPauli > > 34b1676 CHANGESET ? > > > Make minimum size for secure memory a size_t. > > The minimum size argument to CRYPTO_secure_malloc_init() was an int but > ought > to be a size_t since it is a size. > > From an API perspective, this is a change. However, the minimum size is > verified as being a positive power of two and it will typically be a > small > constant. > > Reviewed-by: David von Oheimb > > (Merged from #11003) > > Want to know about upcoming build environment updates? > > Would you like to stay up-to-date with the upcoming Travis CI build > environment updates? We set up a mailing list for you! > > SIGN UP HERE > > book icon > > Documentation about Travis CI > > Have any questions? We're here to help. > > > Unsubscribe > > from build emails from the openssl/openssl repository. > To unsubscribe from *all* build emails, please update your settings > . > > black and white travis ci logo > > Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy > Jacops | Contact: contact at travis-ci.com > > | > Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gem?? > ?27 a Umsatzsteuergesetz: DE282002648 > From nic.tuv at gmail.com Fri Feb 14 13:21:03 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 14 Feb 2020 14:21:03 +0100 Subject: Errored: openssl/openssl#31939 (master - 34b1676) In-Reply-To: References: <5e3a05f94b2ee_43fb2926da1f82485e1@2f147ff5-212e-4b07-88f1-e30936129eef.mail> <7ec6629c-2e17-c86e-7f4d-96935bd84a72@openssl.org> Message-ID: On Fri, 14 Feb 2020 at 14:00, Matt Caswell wrote: > > To be clear the build that is timing out uses *msan* not *asan*. > As I understand it msan detects unitialised reads. whereas asan detects > memory corruption, buffer overflows, use-after-free bugs, and memory leaks. > > The previous "home-made" checks only detected memory leaks, so it is not > comparable with the functionality offered by msan. > > Thanks for the clarification! I was indeed confused! > The msan documentation > (https://clang.llvm.org/docs/MemorySanitizer.html) suggests that a slow > down of 3x is typical. > > It seems reasonable to me to disable msan checks in Travis entirely, and > have them only in run-checker. > > I agree with you. > > Here is another idea that would be interesting if we restore the > > previous checks: > > I don't know what kind of options github offers on this, but would it be > > possible to run triggered CI on something that is not Travis and does > > not timeout and still have the results in the PR? > > I am sure there are hooks to do this. Richard has been talking for quite > a while about setting up a buildbot infrastructure. If that could be > integrated into github that would be really neat. > > It would be neat indeed, when I first heard about buildbot I tried to set aside some time to play with it, but failed in finding the time needed! But at least from what I read it does indeed seem like a very interesting and useful tool for our purposes! I have no doubt sooner or later Richard will be more successful than I was at finding the time to work on this item as well! Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Feb 14 16:17:48 2020 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 14 Feb 2020 16:17:48 +0000 Subject: Deprecation In-Reply-To: References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> Message-ID: * I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of provider API. I share this concern. This is the first release of the provider infrastructure, and while it will be known to work for FIPS modules, it?s hubris to think OpenSSL will get it completely right for other uses. All other deprecations point to existing API?s or, if they are brand new, are not a lot of code/work to implement them. The provider interface is both brand new and significant work. Deprecating and saying ?use providers? without at least one release cycle of providers, seems premature. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Fri Feb 14 16:59:32 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 14 Feb 2020 17:59:32 +0100 Subject: Deprecation In-Reply-To: References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> Message-ID: <582566772f9d528799d2d4bc6045953831bc9ce2.camel@redhat.com> On Fri, 2020-02-14 at 16:17 +0000, Salz, Rich wrote: > I think we should delay the deprecation of engine stuff to 4.0. > Personally I don't have sense of stability of provider API. > > I share this concern. This is the first release of the provider > infrastructure, and while it will be known to work for FIPS modules, > it?s hubris to think OpenSSL will get it completely right for other > uses. > > All other deprecations point to existing API?s or, if they are brand > new, are not a lot of code/work to implement them. The provider > interface is both brand new and significant work. Deprecating and > saying ?use providers? without at least one release cycle of > providers, seems premature. This is an argument for not removing engines in 4.0 (or earlier than one major release after the provider interface fully stabilizes and proves viable). However I do not think that it is argument for not deprecating it. Deprecation is declaration of intent and not a way to force people stop using the API immediately. How is the provider API going to improve/stabilize, if the 3rd party engine suppliers will not get the the message that the engine API is eventually going away in future and start writing providers as replacement. -- 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 kaduk at mit.edu Fri Feb 14 18:51:24 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 14 Feb 2020 10:51:24 -0800 Subject: Deprecation In-Reply-To: <582566772f9d528799d2d4bc6045953831bc9ce2.camel@redhat.com> References: <24781BB2-1B3D-4250-B874-830B2710122C@oracle.com> <582566772f9d528799d2d4bc6045953831bc9ce2.camel@redhat.com> Message-ID: <20200214185124.GC43385@kduck.mit.edu> On Fri, Feb 14, 2020 at 05:59:32PM +0100, Tomas Mraz wrote: > On Fri, 2020-02-14 at 16:17 +0000, Salz, Rich wrote: > > I think we should delay the deprecation of engine stuff to 4.0. > > Personally I don't have sense of stability of provider API. > > > > I share this concern. This is the first release of the provider > > infrastructure, and while it will be known to work for FIPS modules, > > it?s hubris to think OpenSSL will get it completely right for other > > uses. > > > > All other deprecations point to existing API?s or, if they are brand > > new, are not a lot of code/work to implement them. The provider > > interface is both brand new and significant work. Deprecating and > > saying ?use providers? without at least one release cycle of > > providers, seems premature. > > This is an argument for not removing engines in 4.0 (or earlier than > one major release after the provider interface fully stabilizes and > proves viable). However I do not think that it is argument for not > deprecating it. Deprecation is declaration of intent and not a way to > force people stop using the API immediately. > > How is the provider API going to improve/stabilize, if the 3rd party > engine suppliers will not get the the message that the engine API is > eventually going away in future and start writing providers as > replacement. I have similar feelings to Tomas. Note that the current policy's test for "is removal allowed" is a two-pronged test, and if the next release after 3.0 is 4.0, we would not be allowed to remove engines in 4.0, since providers (the "engine replacement") will not have been available in a (previous) LTS release. If we know that something will need to go away eventually, it seems like we can use deprecation annotations to publicize that fact, even if the eventual removal will be delayed for quite some time due to other considerations. -Ben From paul.dale at oracle.com Fri Feb 14 23:33:48 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 15 Feb 2020 09:33:48 +1000 Subject: Errored: openssl/openssl#31939 (master - 34b1676) In-Reply-To: References: <5e3a05f94b2ee_43fb2926da1f82485e1@2f147ff5-212e-4b07-88f1-e30936129eef.mail> <7ec6629c-2e17-c86e-7f4d-96935bd84a72@openssl.org> Message-ID: An alternative would be to only run a cut down selection of tests with msan. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 14 Feb 2020, at 11:00 pm, Matt Caswell wrote: > > > > On 14/02/2020 12:23, Nicola Tuveri wrote: >> If ASAN is too slow to run in the CI should we restore the previous >> homemade checks for memory leaks as an alternative to be run in regular >> CI runs and leave ASAN builds to run-checker on the master branch only? > > To be clear the build that is timing out uses *msan* not *asan*. > > As I understand it msan detects unitialised reads. whereas asan detects > memory corruption, buffer overflows, use-after-free bugs, and memory leaks. > > The previous "home-made" checks only detected memory leaks, so it is not > comparable with the functionality offered by msan. > > The msan documentation > (https://urldefense.com/v3/__https://clang.llvm.org/docs/MemorySanitizer.html__;!!GqivPVa7Brio!JwD52xjNRP5yVXTD3K12Mn17HiC2xHM_O6YzFE7G32G1BYh-NID9mIM6xiEvnC0$ ) suggests that a slow > down of 3x is typical. > > It seems reasonable to me to disable msan checks in Travis entirely, and > have them only in run-checker. > >> >> Here is another idea that would be interesting if we restore the >> previous checks: >> I don't know what kind of options github offers on this, but would it be >> possible to run triggered CI on something that is not Travis and does >> not timeout and still have the results in the PR? > > I am sure there are hooks to do this. Richard has been talking for quite > a while about setting up a buildbot infrastructure. If that could be > integrated into github that would be really neat. > > Matt > > >> If something like that would be possible we could move the ASAN builds >> to extended_tests, rely on the previous memleak detection for the >> regular CI runs, and then trigger with a script or Github Action the >> extended_tests when the approval:done label is added. >> >> That way, by the time something is ready to be merged we should have a >> full picture! >> >> >> Nicola >> >> On Wed, Feb 5, 2020, 10:25 Matt Caswell > > wrote: >> >> Since we fixed the Travis builds 4 out of the 8 builds on master that >> have taken place have errored due to a timeout. >> >> The msan build is consistently taking a *very* long time to run. If it >> gets to 50 minutes then Travis cuts it off and the build fails. >> >> Should we disable the msan build? >> >> Matt >> >> >> -------- Forwarded Message -------- >> Subject: Errored: openssl/openssl#31939 (master - 34b1676) >> Date: Wed, 05 Feb 2020 00:02:01 +0000 >> From: Travis CI > >> To: openssl-commits at openssl.org >> >> >> >> openssl >> >> / >> >> openssl >> >> >> >> >> branch iconmaster >> >> build has errored >> Build #31939 has errored >> >> arrow to build time >> clock icon50 mins and 3 secs >> >> Pauli avatarPauli >> >> 34b1676 CHANGESET ? >> >> >> Make minimum size for secure memory a size_t. >> >> The minimum size argument to CRYPTO_secure_malloc_init() was an int but >> ought >> to be a size_t since it is a size. >> >> From an API perspective, this is a change. However, the minimum size is >> verified as being a positive power of two and it will typically be a >> small >> constant. >> >> Reviewed-by: David von Oheimb > > >> (Merged from #11003) >> >> Want to know about upcoming build environment updates? >> >> Would you like to stay up-to-date with the upcoming Travis CI build >> environment updates? We set up a mailing list for you! >> >> SIGN UP HERE >> >> book icon >> >> Documentation about Travis CI >> >> Have any questions? We're here to help. >> > >> Unsubscribe >> >> from build emails from the openssl/openssl repository. >> To unsubscribe from *all* build emails, please update your settings >> . >> >> black and white travis ci logo >> >> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy >> Jacops | Contact: contact at travis-ci.com >> > > | >> Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gem?? >> ?27 a Umsatzsteuergesetz: DE282002648 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Feb 17 12:07:08 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 17 Feb 2020 12:07:08 +0000 Subject: QUIC in OpenSSL Message-ID: <688f28e0-1d43-f528-8aff-849a57b4f52c@openssl.org> The OMC has just published a blog post on our thoughts on QUIC in OpenSSL. You can read it here: https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/ Matt From matt at openssl.org Wed Feb 19 15:06:57 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 19 Feb 2020 15:06:57 +0000 Subject: Tools repo ownership Message-ID: <3a688ce5-7d3c-f1b0-48cb-7a3385eefe92@openssl.org> Following the discussion in PR 58 [1] about the ownership of the tools repo, I've started an OMC vote to see the tools repo split into "tools" and "omc-tools", with some tools moving to omc-tools. OMC would have commit/approval rights for omc-tools, and the OTC would have commit/approval rights for tools. I'll report back here once the vote is complete. Matt [1] https://github.com/openssl/tools/pull/58 From kurt at roeckx.be Fri Feb 21 08:06:39 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 21 Feb 2020 09:06:39 +0100 Subject: Deprecations Message-ID: <20200221080639.GA2050170@roeckx.be> Hi, We seem to be deprecating a lot of the old APIs, which I think is a good thing. But I think we might either be deprecating too much, or not actually using the alternatives ourself. In the apps, a lot of the files define OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do it. We should stop using the deprecated functions ourself. If there is no way to do this using non-deprecated functions, the function should probably not have been deprecated in the first place. The apps might have functionality that we want to deprecate too, that depends on the deprecated functions. In which case we should also mark that as deprecated, and the apps should always build in no-deprecation mode. We might also be deprecating APIs that we don't use ourself, so it's harder to know if there are alternatives for it. It would also be nice that if you deprecate a function, that you point to the alternative way to do the same thing in the manual. Kurt From matt at openssl.org Fri Feb 21 09:50:10 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 21 Feb 2020 09:50:10 +0000 Subject: Deprecations In-Reply-To: <20200221080639.GA2050170@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> Message-ID: <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> On 21/02/2020 08:06, Kurt Roeckx wrote: > In the apps, a lot of the files define > OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do > it. We should stop using the deprecated functions ourself. If > there is no way to do this using non-deprecated functions, the > function should probably not have been deprecated in the first > place. > > The apps might have functionality that we want to deprecate too, > that depends on the deprecated functions. In which case we should > also mark that as deprecated, and the apps should always build in > no-deprecation mode. I think we have a number of strategies for dealing with deprecated APIs in the apps depending on the situation: 1) Ideally we just rewrite the functionality using non-deprecated APIs 2) In some cases that isn't possible for some reason. For example in the "passwd" app the "-crypt" option uses the deprecated API "DES_crypt". We have chosen not to provide an alternative for this API, so in this case the option itself is deprecated.[1] There are other examples of this in the "speed" application where a particular option specifically tests the speed of the low-level APIs (i.e. the "-evp" option hasn't been used). Again in those cases the options themselves are deprecated. 3) In some cases we have chosen to deprecate an entire application. This is usually because the whole application is written depending on the low-level APIs and there is an alternative application available that does the same thing and uses the high-level APIs. Given the existence of the other application there seems little point in spending a lot of time rewriting an entire app when we have equivalent functionality elsewhere. Examples of this are dhparam, dsaparam and ecparam which are deprecated in favour of pkeyparam. The user gets a warning displayed when they use one of these deprecated applications. Everything should build in a no-deprecated build. In the case of (1) the functionality is obviously still present because we've rewritten it. In (2) the deprecated options are no longer available and in (3) the whole command is no longer available. This seems reasonable to me since the user has specifically requested a build without deprecated functionality in it. In the case of both (2) and (3) where the user has not requested a no-deprecated build, the use of the deprecated APIs obviously still remains and therefore we need to use OPENSSL_SUPPRESS_DEPRECATED. This will eventually disappear in future releases as the deprecated APIs are removed. Matt [1] I note BTW that although the option is deprecated this doesn't seem to have been reflected in the documentation - nor do I see any code to indicate to the end user that a deprecated option has been used. We should probably do that. > > We might also be deprecating APIs that we don't use ourself, so > it's harder to know if there are alternatives for it. > > It would also be nice that if you deprecate a function, that you > point to the alternative way to do the same thing in the manual. > > > Kurt > From levitte at openssl.org Fri Feb 21 14:48:39 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 21 Feb 2020 15:48:39 +0100 Subject: Deprecations In-Reply-To: <20200221080639.GA2050170@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> Message-ID: <8BF27285-040B-42AB-8ABF-D08598C019B5@openssl.org> A small note about the 'no-deprecated' configuration option: this is an option to simulate the far future when the deprecated stuff has been removed from the public eye. Deprecated openssl commands should not build with such a configuration. Cheers Richard Kurt Roeckx skrev: (21 februari 2020 09:06:39 CET) >Hi, > >We seem to be deprecating a lot of the old APIs, which I think is >a good thing. But I think we might either be deprecating too much, >or not actually using the alternatives ourself. > >In the apps, a lot of the files define >OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do >it. We should stop using the deprecated functions ourself. If >there is no way to do this using non-deprecated functions, the >function should probably not have been deprecated in the first >place. > >The apps might have functionality that we want to deprecate too, >that depends on the deprecated functions. In which case we should >also mark that as deprecated, and the apps should always build in >no-deprecation mode. > >We might also be deprecating APIs that we don't use ourself, so >it's harder to know if there are alternatives for it. > >It would also be nice that if you deprecate a function, that you >point to the alternative way to do the same thing in the manual. > > >Kurt -- Richard by mobile From levitte at openssl.org Fri Feb 21 16:50:45 2020 From: levitte at openssl.org (Richard Levitte) Date: Fri, 21 Feb 2020 17:50:45 +0100 Subject: Deprecations In-Reply-To: <779CEE63-D171-4330-945F-EC7BEAA1AFF2@akamai.com> References: <20200221080639.GA2050170@roeckx.be> <8BF27285-040B-42AB-8ABF-D08598C019B5@openssl.org> <779CEE63-D171-4330-945F-EC7BEAA1AFF2@akamai.com> Message-ID: <758F3EF2-B82E-47BF-A4B2-5470D2FDC5BB@openssl.org> "Salz, Rich" skrev: (21 februari 2020 17:17:54 CET) >> A small note about the 'no-deprecated' configuration option: this >is an option to simulate the far future when the deprecated stuff has >been removed from the public eye. Deprecated openssl commands should >not build with such a configuration. > >How can that work? If the deprecated command calls deprecated API's >then you'll get build failures. It works by not building the deprecated command in that configuration. -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From rsalz at akamai.com Fri Feb 21 16:17:54 2020 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 21 Feb 2020 16:17:54 +0000 Subject: Deprecations In-Reply-To: <8BF27285-040B-42AB-8ABF-D08598C019B5@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <8BF27285-040B-42AB-8ABF-D08598C019B5@openssl.org> Message-ID: <779CEE63-D171-4330-945F-EC7BEAA1AFF2@akamai.com> > A small note about the 'no-deprecated' configuration option: this is an option to simulate the far future when the deprecated stuff has been removed from the public eye. Deprecated openssl commands should not build with such a configuration. How can that work? If the deprecated command calls deprecated API's then you'll get build failures. From M.Lindner at f5.com Fri Feb 21 19:45:58 2020 From: M.Lindner at f5.com (Matthew Lindner) Date: Fri, 21 Feb 2020 19:45:58 +0000 Subject: Deprecations In-Reply-To: <20200221080639.GA2050170@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> Message-ID: <4E5A6D50-A0D4-4135-B555-2C72506AD2C4@f5.com> As a user I'm strongly in favor of this. It gives an example of how to implement something using the new interfaces. Even in 1.1.1 there are things that are impossible to implement without using low level interfaces. The applications should be guides on how to correctly implement something and will point out interface deficiencies. 3.0.0 should not ship with deprecated code in the apps (and 1.1.1 should stop using deprecated code in its apps). - Matthew Lindner > On Feb 21, 2020, at 12:06 AM, Kurt Roeckx wrote: > > EXTERNAL MAIL: openssl-project-bounces at openssl.org > > Hi, > > We seem to be deprecating a lot of the old APIs, which I think is > a good thing. But I think we might either be deprecating too much, > or not actually using the alternatives ourself. > > In the apps, a lot of the files define > OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do > it. We should stop using the deprecated functions ourself. If > there is no way to do this using non-deprecated functions, the > function should probably not have been deprecated in the first > place. > > The apps might have functionality that we want to deprecate too, > that depends on the deprecated functions. In which case we should > also mark that as deprecated, and the apps should always build in > no-deprecation mode. > > We might also be deprecating APIs that we don't use ourself, so > it's harder to know if there are alternatives for it. > > It would also be nice that if you deprecate a function, that you > point to the alternative way to do the same thing in the manual. > > > Kurt > > From matt at openssl.org Fri Feb 21 20:14:39 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 21 Feb 2020 20:14:39 +0000 Subject: Deprecations In-Reply-To: <4E5A6D50-A0D4-4135-B555-2C72506AD2C4@f5.com> References: <20200221080639.GA2050170@roeckx.be> <4E5A6D50-A0D4-4135-B555-2C72506AD2C4@f5.com> Message-ID: <36155427-0bd2-6d7e-01aa-2dcc8e6aab45@openssl.org> On 21/02/2020 19:45, Matthew Lindner wrote: > As a user I'm strongly in favor of this. It gives an example of how > to implement something using the new interfaces. Even in 1.1.1 there > are things that are impossible to implement without using low level > interfaces. The applications should be guides on how to correctly > implement something and will point out interface deficiencies. 3.0.0 > should not ship with deprecated code in the apps (and 1.1.1 should > stop using deprecated code in its apps). As I mentioned in my earlier post I don't believe that this is feasible: - In some cases an API has been deliberately deprecated with no replacement. This functionality is also deprecated and will eventually be removed from the app at the same time that the deprecated API is removed. - In the case of the speed app, the whole point of some functionality is to test the speed of the deprecated API. When the deprecated APIs go, so will that functionality from speed. - In other cases whole apps are deprecated in favour of a different one that does the same job. The deprecated app will be kept around until the deprecated APIs they use are removed, and then the app will also be removed. Application authors looking for an example should refer to the non-deprecated alternative app. For all of the above reasons there will have to be some deprecated APIs still being used in the apps in 3.0. Any uses that remain are expected to be removed at the same time as the APIs themselves are removed. Matt > > - Matthew Lindner > >> On Feb 21, 2020, at 12:06 AM, Kurt Roeckx wrote: >> >> EXTERNAL MAIL: openssl-project-bounces at openssl.org >> >> Hi, >> >> We seem to be deprecating a lot of the old APIs, which I think is a >> good thing. But I think we might either be deprecating too much, or >> not actually using the alternatives ourself. >> >> In the apps, a lot of the files define OPENSSL_SUPPRESS_DEPRECATED, >> which I think is the wrong way to do it. We should stop using the >> deprecated functions ourself. If there is no way to do this using >> non-deprecated functions, the function should probably not have >> been deprecated in the first place. >> >> The apps might have functionality that we want to deprecate too, >> that depends on the deprecated functions. In which case we should >> also mark that as deprecated, and the apps should always build in >> no-deprecation mode. >> >> We might also be deprecating APIs that we don't use ourself, so >> it's harder to know if there are alternatives for it. >> >> It would also be nice that if you deprecate a function, that you >> point to the alternative way to do the same thing in the manual. >> >> >> Kurt >> >> > From kurt at roeckx.be Fri Feb 21 22:17:17 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 21 Feb 2020 23:17:17 +0100 Subject: Deprecations In-Reply-To: <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> Message-ID: <20200221221717.GA2169205@roeckx.be> On Fri, Feb 21, 2020 at 09:50:10AM +0000, Matt Caswell wrote: > > > On 21/02/2020 08:06, Kurt Roeckx wrote: > > In the apps, a lot of the files define > > OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do > > it. We should stop using the deprecated functions ourself. If > > there is no way to do this using non-deprecated functions, the > > function should probably not have been deprecated in the first > > place. > > > > The apps might have functionality that we want to deprecate too, > > that depends on the deprecated functions. In which case we should > > also mark that as deprecated, and the apps should always build in > > no-deprecation mode. > > I think we have a number of strategies for dealing with deprecated APIs > in the apps depending on the situation: > > 1) Ideally we just rewrite the functionality using non-deprecated APIs The problem is that many of the apps already define OPENSSL_SUPPRESS_DEPRECATED so that you don't know that something you're deprecating is used there without checking for it. The commit I was looking at was ada66e78ef535fe80e422bbbadffe8e7863d457c: Deprecate the low level Diffie-Hellman functions. At least one of the functions being deprecated is DH_check, which is still used by dhparam. Dhparam is our replacement for dh and gendh. I don't know if any of the other function that were deprecated are still used internally or not. The define was added in commit 1ddf2594e18137aeb7ce861e54f46824db76e36f, and so when DH_check later got deprecated, nobody noticed that the now deprecated function is still being used. I think the replacement function is EVP_PKEY_param_check(). DH_check is not mentioned as deprecated in the manual. Kurt From matt at openssl.org Fri Feb 21 23:00:10 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 21 Feb 2020 23:00:10 +0000 Subject: Deprecations In-Reply-To: <20200221221717.GA2169205@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> Message-ID: <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> On 21/02/2020 22:17, Kurt Roeckx wrote: > On Fri, Feb 21, 2020 at 09:50:10AM +0000, Matt Caswell wrote: >> >> >> On 21/02/2020 08:06, Kurt Roeckx wrote: >>> In the apps, a lot of the files define >>> OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do >>> it. We should stop using the deprecated functions ourself. If >>> there is no way to do this using non-deprecated functions, the >>> function should probably not have been deprecated in the first >>> place. >>> >>> The apps might have functionality that we want to deprecate too, >>> that depends on the deprecated functions. In which case we should >>> also mark that as deprecated, and the apps should always build in >>> no-deprecation mode. >> >> I think we have a number of strategies for dealing with deprecated APIs >> in the apps depending on the situation: >> >> 1) Ideally we just rewrite the functionality using non-deprecated APIs > > The problem is that many of the apps already define > OPENSSL_SUPPRESS_DEPRECATED so that you don't know that something > you're deprecating is used there without checking for it. This is not the case. The only effect that OPENSSL_SUPPRESS_DEPRECATED has is that it suppreses deprecated warnings from the compiler. However, if you don't handle that deprecated code in some way you will get a build failure in a no-deprecated build because the deprecated function doesn't exist at all. *If* we use any deprecated APIs we *must* make an informed decision about what to do about that API use to avoid a no-deprecated build failure. Since our no-deprecated builds are working just fine, I don't believe there are any instances in the apps where we haven't made that informed decision. > > The commit I was looking at was ada66e78ef535fe80e422bbbadffe8e7863d457c: > Deprecate the low level Diffie-Hellman functions. > > At least one of the functions being deprecated is DH_check, which > is still used by dhparam. Dhparam is our replacement for dh and gendh. > I don't know if any of the other function that were deprecated are > still used internally or not. dhparam itself has been deprecated. For that reason we are not attempting to rewrite it to use non-deprecated APIs. The informed decision we have made about DH_check use in dhparam is to not build the whole application in a no-deprecated build: *) The command line utilities dhparam, dsa, gendsa and dsaparam have been deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam programs respectively. [Paul Dale] > > The define was added in commit 1ddf2594e18137aeb7ce861e54f46824db76e36f, > and so when DH_check later got deprecated, nobody noticed that the > now deprecated function is still being used. > > I think the replacement function is EVP_PKEY_param_check(). > > DH_check is not mentioned as deprecated in the manual. Yes, it is: #include Deprecated since OpenSSL 3.0, can be hidden entirely by defining B with a suitable version value, see L: int DH_generate_parameters_ex(DH *dh, int prime_len, int generator, BN_GENCB *cb); int DH_check(DH *dh, int *codes); int DH_check_params(DH *dh, int *codes); int DH_check_ex(const DH *dh); int DH_check_params_ex(const DH *dh); int DH_check_pub_key_ex(const DH *dh, const BIGNUM *pub_key); =head1 DESCRIPTION All of the functions described on this page are deprecated. Applications should instead use L, L, L and L. Matt > > > Kurt > From matt at openssl.org Fri Feb 21 23:03:05 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 21 Feb 2020 23:03:05 +0000 Subject: Deprecations In-Reply-To: <0C5E342B-6C13-4BD3-A425-AAF8E6DCF32E@f5.com> References: <20200221080639.GA2050170@roeckx.be> <4E5A6D50-A0D4-4135-B555-2C72506AD2C4@f5.com> <36155427-0bd2-6d7e-01aa-2dcc8e6aab45@openssl.org> <0C5E342B-6C13-4BD3-A425-AAF8E6DCF32E@f5.com> Message-ID: <5dedafd1-4e63-0f13-e047-95d64e778dd8@openssl.org> On 21/02/2020 20:33, Matthew Lindner wrote: > I think any deprecated apps or options that must be kept and not > implemented in the new interface should print a warning when used in > that case then, and only do that when it's impossible to implement it > in the current release. I agree with this. We already do that if you use a deprecated application. I'm not so sure we've been quite so careful with the deprecated options, so we should check that. > > That's not at all clear with the speed app for example. (That speed > app was deprecated I just found out in this email thread.) > That's not actually what I said. The speed app itself is not deprecated. There are options to the speed app, which are deprecated. Its quite possible we don't print a warning for those - which we should do. Matt > - Matthew Lindner > >> On Feb 21, 2020, at 12:14 PM, Matt Caswell >> wrote: >> >> EXTERNAL MAIL: openssl-project-bounces at openssl.org >> >> >> On 21/02/2020 19:45, Matthew Lindner wrote: >>> As a user I'm strongly in favor of this. It gives an example of >>> how to implement something using the new interfaces. Even in >>> 1.1.1 there are things that are impossible to implement without >>> using low level interfaces. The applications should be guides on >>> how to correctly implement something and will point out interface >>> deficiencies. 3.0.0 should not ship with deprecated code in the >>> apps (and 1.1.1 should stop using deprecated code in its apps). >> >> As I mentioned in my earlier post I don't believe that this is >> feasible: >> >> - In some cases an API has been deliberately deprecated with no >> replacement. This functionality is also deprecated and will >> eventually be removed from the app at the same time that the >> deprecated API is removed. >> >> - In the case of the speed app, the whole point of some >> functionality is to test the speed of the deprecated API. When the >> deprecated APIs go, so will that functionality from speed. >> >> - In other cases whole apps are deprecated in favour of a different >> one that does the same job. The deprecated app will be kept around >> until the deprecated APIs they use are removed, and then the app >> will also be removed. Application authors looking for an example >> should refer to the non-deprecated alternative app. >> >> For all of the above reasons there will have to be some deprecated >> APIs still being used in the apps in 3.0. Any uses that remain are >> expected to be removed at the same time as the APIs themselves are >> removed. >> >> Matt >> >> >>> >>> - Matthew Lindner >>> >>>> On Feb 21, 2020, at 12:06 AM, Kurt Roeckx >>>> wrote: >>>> >>>> EXTERNAL MAIL: openssl-project-bounces at openssl.org >>>> >>>> Hi, >>>> >>>> We seem to be deprecating a lot of the old APIs, which I think >>>> is a good thing. But I think we might either be deprecating too >>>> much, or not actually using the alternatives ourself. >>>> >>>> In the apps, a lot of the files define >>>> OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to >>>> do it. We should stop using the deprecated functions ourself. >>>> If there is no way to do this using non-deprecated functions, >>>> the function should probably not have been deprecated in the >>>> first place. >>>> >>>> The apps might have functionality that we want to deprecate >>>> too, that depends on the deprecated functions. In which case we >>>> should also mark that as deprecated, and the apps should always >>>> build in no-deprecation mode. >>>> >>>> We might also be deprecating APIs that we don't use ourself, so >>>> it's harder to know if there are alternatives for it. >>>> >>>> It would also be nice that if you deprecate a function, that >>>> you point to the alternative way to do the same thing in the >>>> manual. >>>> >>>> >>>> Kurt >>>> >>>> >>> > From kurt at roeckx.be Fri Feb 21 23:18:08 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 22 Feb 2020 00:18:08 +0100 Subject: Deprecations In-Reply-To: <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> Message-ID: <20200221231808.GA2169191@roeckx.be> On Fri, Feb 21, 2020 at 11:00:10PM +0000, Matt Caswell wrote: > > dhparam itself has been deprecated. For that reason we are not > attempting to rewrite it to use non-deprecated APIs. The informed > decision we have made about DH_check use in dhparam is to not build the > whole application in a no-deprecated build: > > *) The command line utilities dhparam, dsa, gendsa and dsaparam have been > deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam > programs respectively. > [Paul Dale] For some reason I seem to have missed various things. But I think deprecating tools like dhparam, dsaparam in favour of genpkey is something that we should reconsider. Kurt From matt at openssl.org Fri Feb 21 23:27:55 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 21 Feb 2020 23:27:55 +0000 Subject: Deprecations In-Reply-To: <20200221231808.GA2169191@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> Message-ID: <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> On 21/02/2020 23:18, Kurt Roeckx wrote: > On Fri, Feb 21, 2020 at 11:00:10PM +0000, Matt Caswell wrote: >> >> dhparam itself has been deprecated. For that reason we are not >> attempting to rewrite it to use non-deprecated APIs. The informed >> decision we have made about DH_check use in dhparam is to not build the >> whole application in a no-deprecated build: >> >> *) The command line utilities dhparam, dsa, gendsa and dsaparam have been >> deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam >> programs respectively. >> [Paul Dale] > > For some reason I seem to have missed various things. > > But I think deprecating tools like dhparam, dsaparam in favour of > genpkey is something that we should reconsider. What is your reasoning? (I just realised that what the CHANGES entry says is that dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I think the equivalent functionality is more split between genpkey and pkeyparam) Matt From M.Lindner at f5.com Fri Feb 21 20:33:00 2020 From: M.Lindner at f5.com (Matthew Lindner) Date: Fri, 21 Feb 2020 20:33:00 +0000 Subject: Deprecations In-Reply-To: <36155427-0bd2-6d7e-01aa-2dcc8e6aab45@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <4E5A6D50-A0D4-4135-B555-2C72506AD2C4@f5.com> <36155427-0bd2-6d7e-01aa-2dcc8e6aab45@openssl.org> Message-ID: <0C5E342B-6C13-4BD3-A425-AAF8E6DCF32E@f5.com> I think any deprecated apps or options that must be kept and not implemented in the new interface should print a warning when used in that case then, and only do that when it's impossible to implement it in the current release. That's not at all clear with the speed app for example. (That speed app was deprecated I just found out in this email thread.) - Matthew Lindner > On Feb 21, 2020, at 12:14 PM, Matt Caswell wrote: > > EXTERNAL MAIL: openssl-project-bounces at openssl.org > > > On 21/02/2020 19:45, Matthew Lindner wrote: >> As a user I'm strongly in favor of this. It gives an example of how >> to implement something using the new interfaces. Even in 1.1.1 there >> are things that are impossible to implement without using low level >> interfaces. The applications should be guides on how to correctly >> implement something and will point out interface deficiencies. 3.0.0 >> should not ship with deprecated code in the apps (and 1.1.1 should >> stop using deprecated code in its apps). > > As I mentioned in my earlier post I don't believe that this is feasible: > > - In some cases an API has been deliberately deprecated with no > replacement. This functionality is also deprecated and will eventually > be removed from the app at the same time that the deprecated API is removed. > > - In the case of the speed app, the whole point of some functionality is > to test the speed of the deprecated API. When the deprecated APIs go, so > will that functionality from speed. > > - In other cases whole apps are deprecated in favour of a different one > that does the same job. The deprecated app will be kept around until the > deprecated APIs they use are removed, and then the app will also be > removed. Application authors looking for an example should refer to the > non-deprecated alternative app. > > For all of the above reasons there will have to be some deprecated APIs > still being used in the apps in 3.0. Any uses that remain are expected > to be removed at the same time as the APIs themselves are removed. > > Matt > > >> >> - Matthew Lindner >> >>> On Feb 21, 2020, at 12:06 AM, Kurt Roeckx wrote: >>> >>> EXTERNAL MAIL: openssl-project-bounces at openssl.org >>> >>> Hi, >>> >>> We seem to be deprecating a lot of the old APIs, which I think is a >>> good thing. But I think we might either be deprecating too much, or >>> not actually using the alternatives ourself. >>> >>> In the apps, a lot of the files define OPENSSL_SUPPRESS_DEPRECATED, >>> which I think is the wrong way to do it. We should stop using the >>> deprecated functions ourself. If there is no way to do this using >>> non-deprecated functions, the function should probably not have >>> been deprecated in the first place. >>> >>> The apps might have functionality that we want to deprecate too, >>> that depends on the deprecated functions. In which case we should >>> also mark that as deprecated, and the apps should always build in >>> no-deprecation mode. >>> >>> We might also be deprecating APIs that we don't use ourself, so >>> it's harder to know if there are alternatives for it. >>> >>> It would also be nice that if you deprecate a function, that you >>> point to the alternative way to do the same thing in the manual. >>> >>> >>> Kurt >>> >>> >> From kurt at roeckx.be Fri Feb 21 23:51:17 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 22 Feb 2020 00:51:17 +0100 Subject: Deprecations In-Reply-To: <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> Message-ID: <20200221235117.GA2196588@roeckx.be> On Fri, Feb 21, 2020 at 11:27:55PM +0000, Matt Caswell wrote: > > > On 21/02/2020 23:18, Kurt Roeckx wrote: > > On Fri, Feb 21, 2020 at 11:00:10PM +0000, Matt Caswell wrote: > >> > >> dhparam itself has been deprecated. For that reason we are not > >> attempting to rewrite it to use non-deprecated APIs. The informed > >> decision we have made about DH_check use in dhparam is to not build the > >> whole application in a no-deprecated build: > >> > >> *) The command line utilities dhparam, dsa, gendsa and dsaparam have been > >> deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam > >> programs respectively. > >> [Paul Dale] > > > > For some reason I seem to have missed various things. > > > > But I think deprecating tools like dhparam, dsaparam in favour of > > genpkey is something that we should reconsider. > > What is your reasoning? > > (I just realised that what the CHANGES entry says is that > dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I > think the equivalent functionality is more split between genpkey and > pkeyparam) Some equivalants: openssl dhparam 2048 openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048 openssl dsaparam 2048 openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 If you search internet, you will more than likely find the first ones. They are very easy. I have to look up at the manual page examples to know how to use genpkey. Kurt From openssl-users at dukhovni.org Sat Feb 22 03:34:17 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 21 Feb 2020 22:34:17 -0500 Subject: Deprecations In-Reply-To: <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> Message-ID: <20200222033417.GD49778@straasha.imrryr.org> On Fri, Feb 21, 2020 at 11:00:10PM +0000, Matt Caswell wrote: > dhparam itself has been deprecated. For that reason we are not > attempting to rewrite it to use non-deprecated APIs. The informed > decision we have made about DH_check use in dhparam is to not build the > whole application in a no-deprecated build: > > *) The command line utilities dhparam, dsa, gendsa and dsaparam have been > deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam > programs respectively. > [Paul Dale] Dropping "dhparam" is rather an incompatible change. It is widely used, and its replacemnt is much more complex, and does not appear in how-to guides that explain how to generate DH parameters. Whatever API is used in "pkeyparam", needs to be inserted into dhparam without changing its CLI. The same applies to genrsa, ... and even though I'm sometimes masochist enough to use "genpkey" (after checking the manpage again, or re-reading my own mkcert.sh script), it somehow has never managed to get to a point where I can emit its various options from finger memory. -- Viktor. From openssl-users at dukhovni.org Sat Feb 22 03:36:35 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 21 Feb 2020 22:36:35 -0500 Subject: Deprecations In-Reply-To: <20200221235117.GA2196588@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> <20200221235117.GA2196588@roeckx.be> Message-ID: <20200222033635.GE49778@straasha.imrryr.org> On Sat, Feb 22, 2020 at 12:51:17AM +0100, Kurt Roeckx wrote: > > (I just realised that what the CHANGES entry says is that > > dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I > > think the equivalent functionality is more split between genpkey and > > pkeyparam) > > Some equivalants: > openssl dhparam 2048 > openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048 > > openssl dsaparam 2048 > openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 +100. The new commands are nice for professionally written utilities that need to be algorithm polymorphic, ... But there's nothing like using a screwdriver to turn a screw, rather than banging it in with an all-purpose hammer! > If you search internet, you will more than likely find the first > ones. They are very easy. I have to look up at the manual page > examples to know how to use genpkey. Yes, same here. -- Viktor. From shane.lontis at oracle.com Sat Feb 22 04:02:08 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Sat, 22 Feb 2020 14:02:08 +1000 Subject: Deprecations In-Reply-To: <20200222033635.GE49778@straasha.imrryr.org> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> <20200221235117.GA2196588@roeckx.be> <20200222033635.GE49778@straasha.imrryr.org> Message-ID: <03C87C5C-8E04-4AA5-A721-BF04987F3002@oracle.com> > On 22 Feb 2020, at 1:36 pm, Viktor Dukhovni wrote: > > But there's nothing like > using a screwdriver to turn a screw, rather than banging it in with > an all-purpose hammer! If we are trying to tell users to not use the low level API?s, and then we go and use them everywhere in apps it is not really sending the correct message. If we need to keep them - then they probably would need to be rewritten in terms of evp. (Or parse the parameters and pass them to another app call) :)). Either way its quite a bit of work. > If you search internet, you will more than likely find the first > ones. They are very easy. I have to look up at the manual page > examples to know how to use genpkey. Agreed. Being able to list all the pkey options from the app might be helpful here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Sat Feb 22 05:31:31 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 22 Feb 2020 15:31:31 +1000 Subject: Deprecations In-Reply-To: <20200221235117.GA2196588@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> <20200221235117.GA2196588@roeckx.be> Message-ID: <74801EA6-60D9-48D9-8B62-A13F12272B83@oracle.com> The added complexity was of some concern to me when doing the deprecations. I suspect we?ll also encounter difficulties getting 100% equivalent behaviour via PKEY. There are some pretty arcane options in some of these. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 22 Feb 2020, at 9:51 am, Kurt Roeckx wrote: > > On Fri, Feb 21, 2020 at 11:27:55PM +0000, Matt Caswell wrote: >> >> >> On 21/02/2020 23:18, Kurt Roeckx wrote: >>> On Fri, Feb 21, 2020 at 11:00:10PM +0000, Matt Caswell wrote: >>>> >>>> dhparam itself has been deprecated. For that reason we are not >>>> attempting to rewrite it to use non-deprecated APIs. The informed >>>> decision we have made about DH_check use in dhparam is to not build the >>>> whole application in a no-deprecated build: >>>> >>>> *) The command line utilities dhparam, dsa, gendsa and dsaparam have been >>>> deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam >>>> programs respectively. >>>> [Paul Dale] >>> >>> For some reason I seem to have missed various things. >>> >>> But I think deprecating tools like dhparam, dsaparam in favour of >>> genpkey is something that we should reconsider. >> >> What is your reasoning? >> >> (I just realised that what the CHANGES entry says is that >> dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I >> think the equivalent functionality is more split between genpkey and >> pkeyparam) > > Some equivalants: > openssl dhparam 2048 > openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048 > > openssl dsaparam 2048 > openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 > > > If you search internet, you will more than likely find the first > ones. They are very easy. I have to look up at the manual page > examples to know how to use genpkey. > > > Kurt -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Feb 22 09:43:30 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 22 Feb 2020 10:43:30 +0100 Subject: Deprecations In-Reply-To: <5dedafd1-4e63-0f13-e047-95d64e778dd8@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <4E5A6D50-A0D4-4135-B555-2C72506AD2C4@f5.com> <36155427-0bd2-6d7e-01aa-2dcc8e6aab45@openssl.org> <0C5E342B-6C13-4BD3-A425-AAF8E6DCF32E@f5.com> <5dedafd1-4e63-0f13-e047-95d64e778dd8@openssl.org> Message-ID: <87r1yn7y9p.wl-levitte@openssl.org> On Sat, 22 Feb 2020 00:03:05 +0100, Matt Caswell wrote: > On 21/02/2020 20:33, Matthew Lindner wrote: > > I think any deprecated apps or options that must be kept and not > > implemented in the new interface should print a warning when used in > > that case then, and only do that when it's impossible to implement it > > in the current release. > > I agree with this. We already do that if you use a deprecated > application. I'm not so sure we've been quite so careful with the > deprecated options, so we should check that. We haven't been very careful at all, all we've done so far is to say that they are deprecated, nothing else said. So yeah, I completely agree. We also need to decide what such an update should look like. Looking through some manuals on my Linux installation, I find deprecation notices in: - the DESCRIPTION section, which seems to happen when all the functions described on the page are deprecated. Ref: freehostent(3), gets(3) - the NOTES sections, which seems to be typically done when only some of the functions described on the page are deprecated. Ref: dlopen(3), - as part of the function description Ref: getwd(3) - the CONFORMING TO section, when an external standardisation (typically POSIX, LSB, ...) has deprecated a function. Ref: bzero(3), gets(3) - a dedicated deprecation section like DEPRECATED INTERFACES Ref: ldap(3) (all applicable LDAP manpages, actually, such as ldap_abandon(3)) For those that don't have direct access to a Linux box: http://man7.org/linux/man-pages/man3/freehostent.3.html http://man7.org/linux/man-pages/man3/gets.3.html http://man7.org/linux/man-pages/man3/dlopen.3.html http://man7.org/linux/man-pages/man3/getwd.3.html http://man7.org/linux/man-pages/man3/bzero.3.html http://man7.org/linux/man-pages/man3/ldap.3.html http://man7.org/linux/man-pages/man3/ldap_abandon.3.html My personal preference is either the whole page deprecation for pages where all described functions are deprecated (so, early in DESCRIPTION, like freehostent(3)), or a dedicated section like the LDAP manpages. > > > > That's not at all clear with the speed app for example. (That speed > > app was deprecated I just found out in this email thread.) > > > That's not actually what I said. The speed app itself is not deprecated. > There are options to the speed app, which are deprecated. Its quite > possible we don't print a warning for those - which we should do. I wholeheartedly think that we should replace the asymmetric tests with the EVP variants, to be used with the '-evp' option. Just dropping them isn't a great solution. (as a matter of fact, I would turn everything to go through the EVP interface, whether the '-evp' option has been given or not) Cheers, Richard ( std::mantra: PR welcome! ) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Feb 22 09:53:32 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 22 Feb 2020 10:53:32 +0100 Subject: Deprecations In-Reply-To: <20200221235117.GA2196588@roeckx.be> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> <20200221235117.GA2196588@roeckx.be> Message-ID: <87pne77xsz.wl-levitte@openssl.org> On Sat, 22 Feb 2020 00:51:17 +0100, Kurt Roeckx wrote: > Some equivalants: > openssl dhparam 2048 > openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048 > > openssl dsaparam 2048 > openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 Side note: I never quite understood why we had to have such verbose pkey opts. "prime_len" and "bits" would have been enough, the rest is known by context (the command line already specifies that it wants to generate domain parameters and that the algorithm is DH, or DSA) I have to agree with Viktor that some of those pkey commands are overly complicated at times... it's a bit hard to undo at this point, though, apart from creating an entirely new openssl command with a different, and possibly more intuitive interface. Something that could be done is to take all those aged commands and rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create and populate a new argv and call genpkey_main(), pkey_main() or pkeyutl_main(). std::mantra: PR welcome! Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Sun Feb 23 19:53:01 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 23 Feb 2020 14:53:01 -0500 Subject: Deprecations In-Reply-To: <87pne77xsz.wl-levitte@openssl.org> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org> Message-ID: <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org> > On Feb 22, 2020, at 4:53 AM, Richard Levitte wrote: > > Something that could be done is to take all those aged commands and > rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create > and populate a new argv and call genpkey_main(), pkey_main() or > pkeyutl_main(). Agreed, that sounds quite reasonable at first blush, and could be fantastic if it can be made to work (no immediate obstacles come to mind). -- Viktor. From paul.dale at oracle.com Mon Feb 24 07:08:57 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 24 Feb 2020 17:08:57 +1000 Subject: Deprecations In-Reply-To: <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org> <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org> Message-ID: <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com> Most of the conversions to using PKEY were straightforward. One didn?t require any changes (dsa but my memory is suspect). One seemed quite difficult. Some I didn?t check. Modifying the commands so that they continue to work and print (to stderr) an alternative pkey based command might be workable too. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Feb 2020, at 5:53 am, Viktor Dukhovni wrote: > >> On Feb 22, 2020, at 4:53 AM, Richard Levitte wrote: >> >> Something that could be done is to take all those aged commands and >> rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create >> and populate a new argv and call genpkey_main(), pkey_main() or >> pkeyutl_main(). > > Agreed, that sounds quite reasonable at first blush, and could be fantastic > if it can be made to work (no immediate obstacles come to mind). > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Tue Feb 25 09:34:32 2020 From: mark at openssl.org (Mark J Cox) Date: Tue, 25 Feb 2020 09:34:32 +0000 Subject: Fwd: [openssl/openssl] A nonce does not have a minimum length (#5909) In-Reply-To: References: Message-ID: If you are wondering what the strange automated pings are, I'm just experimenting looking at stale issues in various states and what we should do about them. (The tool is clever enough to ignore its own comments etc). I'm just running the tool manually at the moment. The idea is it will ping issues where appropriate and do reports and generally end up being a way we can monitor to make sure our project is healthy. For example, nothing should be in a state waiting for an OMC decision for more than a few weeks - it should be decided upon and moved to whatever state the outcome of the decision is. We had three of these (and looking at them they all should just be in a different state). For every issue it ought to be very clear what the next action is (I'm a big fan of GTD (Getting Things Done) process!) So, right now, we have 82 PR's that have not been touched in the last 180 days. I picked 180 just for an example because it creates a shorter list and in practice I imagine 30 days will be the reports we do: So of the 82: * deferred after 1.1.1 ( 5 issues) - this is a valid state for stale PRs. An item falls here if it's set to the milestone for 1.1.1 or it's marked branch 1.1.1 and not master * waiting for OMC ( 2 issues) - as discussed above, we'll just comment them to ping the OMC * waiting for OTC/waiting for review ( 0 issues) - similar to OMC, we'll just autocomment them to ping the OTC/committers * cla required ( 22 issues) - if something has been waiting for a CLA for 30 days or more we probably ought to ping it a couple of times, but then reject the PR as it's unlikely we'll get a CLA if none have been supplied after a couple of pings and a couple of months. * failed CI ( 14 issues) - if it's not in any of the states above but it failed CI it ends up here. Some of these might be known false positives, so no action other than interesting to monitor? Maybe we need some label for "it failed CI but that's expected and not a blocker"? that way there's an action on the PR creator to "get this in a state where CI passes" and we could auto comment anything that's failed CI and not been touched for a month (and perhaps even close it as rejected the next time). * all the rest ( 39 issues) - most of these have no labels or milestones. Some have milestone:Assessed (but not sure how that helps). Some have branch labels. This is just the backlog. Mark ---------- Forwarded message --------- From: openssl-machine Date: Tue, Feb 25, 2020 at 9:00 AM Subject: Re: [openssl/openssl] A nonce does not have a minimum length (#5909) To: openssl/openssl Automated Ping: This issue is in a state where it requires action by @openssl/omc but the last update was 607 days ago ? You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub , or unsubscribe . -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Wed Feb 26 20:12:57 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 26 Feb 2020 20:12:57 +0000 Subject: New GitHub Project Landing Page Message-ID: The OpenSSL Project GitHub has a new landing page: https://github.com/openssl/openssl Scroll down. Enjoy. Matthias From beldmit at gmail.com Wed Feb 26 21:12:57 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 27 Feb 2020 00:12:57 +0300 Subject: New GitHub Project Landing Page In-Reply-To: References: Message-ID: Looks great! Many thanks for your efforts! On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > The OpenSSL Project GitHub has a new landing page: > > https://github.com/openssl/openssl > > Scroll down. Enjoy. > > > Matthias > > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaishen.yy at alipay.com Thu Feb 27 06:17:58 2020 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 27 Feb 2020 14:17:58 +0800 Subject: New GitHub Project Landing Page In-Reply-To: References: Message-ID: The logo could be changed to the 'correct-font' version -as the one printed on the stickers I brought to Nuremberg I have an '.ai? image file at hand an I think someone needs to figure how to extract the image then include it in the markdown file... Regards, Paul Yang > On Feb 27, 2020, at 5:12 AM, Dmitry Belyavsky wrote: > > Looks great! Many thanks for your efforts! > > On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre > wrote: > The OpenSSL Project GitHub has a new landing page: > > https://github.com/openssl/openssl > > Scroll down. Enjoy. > > > Matthias > > > > > -- > SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Thu Feb 27 07:15:10 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 27 Feb 2020 08:15:10 +0100 Subject: New GitHub Project Landing Page In-Reply-To: References: Message-ID: Could you, please, send me the .ai file? I'll try converting it. Is the font freely available? Tomas On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: > The logo could be changed to the 'correct-font' version -as the one > printed on the stickers I brought to Nuremberg > > I have an '.ai? image file at hand an I think someone needs to figure > how to extract the image then include it in the markdown file... > > Regards, > > Paul Yang > > > On Feb 27, 2020, at 5:12 AM, Dmitry Belyavsky > > wrote: > > > > Looks great! Many thanks for your efforts! > > > > On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre < > > Matthias.St.Pierre at ncp-e.com> wrote: > > > The OpenSSL Project GitHub has a new landing page: > > > > > > https://github.com/openssl/openssl > > > > > > Scroll down. Enjoy. > > > > > > > > > Matthias > > > > > > > > > > > > -- > > SY, Dmitry Belyavsky > > -- 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 kaishen.yy at alipay.com Thu Feb 27 08:58:37 2020 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 27 Feb 2020 16:58:37 +0800 Subject: New GitHub Project Landing Page In-Reply-To: References: Message-ID: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> Sent Regards, Paul Yang > On Feb 27, 2020, at 3:15 PM, Tomas Mraz wrote: > > Could you, please, send me the .ai file? I'll try converting it. Is the > font freely available? > > Tomas > > On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: >> The logo could be changed to the 'correct-font' version -as the one >> printed on the stickers I brought to Nuremberg >> >> I have an '.ai? image file at hand an I think someone needs to figure >> how to extract the image then include it in the markdown file... >> >> Regards, >> >> Paul Yang >> >>> On Feb 27, 2020, at 5:12 AM, Dmitry Belyavsky >>> wrote: >>> >>> Looks great! Many thanks for your efforts! >>> >>> On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre < >>> Matthias.St.Pierre at ncp-e.com> wrote: >>>> The OpenSSL Project GitHub has a new landing page: >>>> >>>> https://github.com/openssl/openssl >>>> >>>> Scroll down. Enjoy. >>>> >>>> >>>> Matthias >>>> >>>> >>> >>> >>> -- >>> SY, Dmitry Belyavsky >> >> > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Feb 27 09:31:34 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Thu, 27 Feb 2020 10:31:34 +0100 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> Message-ID: <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> The openssl.svg was chosen to match the current logo at https://www.openssl.org/ as close as possible. According to the style sheet, the font of the logo is HelveticaNeue-Light. https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158 While I'm not opposed to brush up the OpenSSL logo, I think this can't be done simply be replacing it on the fly. I think this requires a general discussion among the team members and finally an OMC decision, and shouldn't be rushed. Because after all, the shape of the logo is an essential part of the OpenSSL 'trade mark'. If we we want to brush up the Logo, we should give everybody time to come up with proposals and then have an open contest, ideally among all committers, not only OMC or OTC.? (And you can be sure, I will come up with a proposal ;-) ) Finally, the OMC can run a vote, for example whether to pick the winner of the contest or to leave the logo as it is. Regards, Matthias On 27.02.20 09:58, Paul Yang wrote: > Sent > > Regards, > > Paul Yang > >> On Feb 27, 2020, at 3:15 PM, Tomas Mraz > wrote: >> >> Could you, please, send me the .ai file? I'll try converting it. Is the >> font freely available? >> >> Tomas >> >> On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: >>> The logo could be changed to the 'correct-font' version -as the one >>> printed on the stickers I brought to Nuremberg >>> >>> I have an '.ai? image file at hand an I think someone needs to figure >>> how to extract the image then include it in the markdown file... >>> >>> Regards, >>> >>> Paul Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Thu Feb 27 09:52:30 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 27 Feb 2020 10:52:30 +0100 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: On Thu, 2020-02-27 at 10:31 +0100, Matthias St. Pierre wrote: > > The openssl.svg was chosen to match the current logo at > > https://www.openssl.org/ > > as close as possible. According to the style sheet, the font of the > logo > is HelveticaNeue-Light. > > https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158 > > While I'm not opposed to brush up the OpenSSL logo, I think this > can't > be done simply be replacing it on the fly. I think this requires a > general > discussion among the team members and finally an OMC decision, > and shouldn't be rushed. Because after all, the shape of the logo is > an > essential part of the OpenSSL 'trade mark'. > > If we we want to brush up the Logo, we should give everybody time to > come up > with proposals and then have an open contest, ideally among all > committers, > not only OMC or OTC. (And you can be sure, I will come up with a > proposal ;-) ) > > Finally, the OMC can run a vote, for example whether to pick the > winner of the > contest or to leave the logo as it is. The logo (attached) that Paul Yang created is matching the logo on the old OpenSSL website. You can see it here for example: https://j3pd.files.wordpress.com/2011/08/openssl.jpg I do not know how the current logo on the web was created or if there was any formal decision process applied but I would expect it was created just as an approximation of the original logo without using a picture. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-logo-dark.svg Type: image/svg+xml Size: 29403 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Thu Feb 27 09:54:04 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Thu, 27 Feb 2020 10:54:04 +0100 Subject: OpenSSL Logo In-Reply-To: <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: The logo on this site https://unixblogger.com/how-to-convert-split-p12-certificates-into-single-files/ seems to be very similar to the one on your stickers, Paul. According to that site, it used to be at http://openssl.com/images/openssl-logo.png It even has a (TM) marker. Can the OMC please clarify whether this is the current official OpenSSL logo? And if it is, point us to a location where the original file can be found? Matthias On 27.02.20 10:31, Matthias St. Pierre wrote: > > The openssl.svg was chosen to match the current logo at > > https://www.openssl.org/ > > as close as possible. According to the style sheet, the font of the logo > is HelveticaNeue-Light. > > https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158 > > While I'm not opposed to brush up the OpenSSL logo, I think this can't > be done simply be replacing it on the fly. I think this requires a general > discussion among the team members and finally an OMC decision, > and shouldn't be rushed. Because after all, the shape of the logo is an > essential part of the OpenSSL 'trade mark'. > > If we we want to brush up the Logo, we should give everybody time to come up > with proposals and then have an open contest, ideally among all committers, > not only OMC or OTC.? (And you can be sure, I will come up with a proposal ;-) ) > > Finally, the OMC can run a vote, for example whether to pick the winner of the > contest or to leave the logo as it is. > > Regards, > > Matthias > > > > On 27.02.20 09:58, Paul Yang wrote: >> Sent >> >> Regards, >> >> Paul Yang >> >>> On Feb 27, 2020, at 3:15 PM, Tomas Mraz > wrote: >>> >>> Could you, please, send me the .ai file? I'll try converting it. Is the >>> font freely available? >>> >>> Tomas >>> >>> On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: >>>> The logo could be changed to the 'correct-font' version -as the one >>>> printed on the stickers I brought to Nuremberg >>>> >>>> I have an '.ai? image file at hand an I think someone needs to figure >>>> how to extract the image then include it in the markdown file... >>>> >>>> Regards, >>>> >>>> Paul Yang > From kaishen.yy at alipay.com Thu Feb 27 09:57:05 2020 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 27 Feb 2020 17:57:05 +0800 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: As far as I know the original intended logo is not the HelveticalNeue-Light one (the one currently on openssl.org). Long time ago someone has designed a logo with the font similar to the one I printed on the stickers and that logo has also been used in some other places during that time. I think you can still found that version on Goolge. But the original high resolution version of that logo was lost for unknown reason. So the openssl.org has no choice to use a text-based version of the logo, with the HelveticalNeue-Light font. The logo in the ?.ai? file I mentioned previously is actually one reissued version of the 'correct-but-lost? version. It was created by ?hand-imitating? the low-resolution image files found on Google?(that was in around 2018 IIRC and I asked a BaishanCloud UED guy to help on the reissue task ;-). Regards, Paul Yang > On Feb 27, 2020, at 5:31 PM, Matthias St. Pierre wrote: > > > The openssl.svg was chosen to match the current logo at > > https://www.openssl.org/ > > as close as possible. According to the style sheet, the font of the logo > is HelveticaNeue-Light. > > https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158 > > While I'm not opposed to brush up the OpenSSL logo, I think this can't > be done simply be replacing it on the fly. I think this requires a general > discussion among the team members and finally an OMC decision, > and shouldn't be rushed. Because after all, the shape of the logo is an > essential part of the OpenSSL 'trade mark'. > > If we we want to brush up the Logo, we should give everybody time to come up > with proposals and then have an open contest, ideally among all committers, > not only OMC or OTC. (And you can be sure, I will come up with a proposal ;-) ) > > Finally, the OMC can run a vote, for example whether to pick the winner of the > contest or to leave the logo as it is. > > Regards, > > Matthias > > > > On 27.02.20 09:58, Paul Yang wrote: >> Sent >> >> Regards, >> >> Paul Yang >> >>> >>> Dr. Matthias St. Pierre >>> >>> Senior Software Engineer >>> matthias.st.pierre at ncp-e.com >>> Phone: +49 911 9968-0 >>> www.ncp-e.com >>> >>> Follow us on: Facebook | Twitter | Xing | YouTube | LinkedIn >>> >>> Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? Nuremberg >>> North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? Sunnyvale, CA 94085 >>> East Coast Office: NCP engineering Inc. ? 601 Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 >>> >>> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich >>> Registry Court: Lower District Court of Nuremberg >>> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619 >>> >>> This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. >>> >>> >>> >>> >>> On Feb 27, 2020, at 3:15 PM, Tomas Mraz > wrote: >>> >>> Could you, please, send me the .ai file? I'll try converting it. Is the >>> font freely available? >>> >>> Tomas >>> >>> On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: >>>> The logo could be changed to the 'correct-font' version -as the one >>>> printed on the stickers I brought to Nuremberg >>>> >>>> I have an '.ai? image file at hand an I think someone needs to figure >>>> how to extract the image then include it in the markdown file... >>>> >>>> Regards, >>>> >>>> Paul Yang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaishen.yy at alipay.com Thu Feb 27 09:59:09 2020 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 27 Feb 2020 17:59:09 +0800 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: <69EBBCB4-885F-4D47-A06F-13FD32C622F5@alipay.com> This reminds me that it seems the lost of the original logo caused the new logo on the new website. (No high resolution source image) Regards, Paul Yang > On Feb 27, 2020, at 5:52 PM, Tomas Mraz wrote: > > On Thu, 2020-02-27 at 10:31 +0100, Matthias St. Pierre wrote: >> >> The openssl.svg was chosen to match the current logo at >> >> https://www.openssl.org/ >> >> as close as possible. According to the style sheet, the font of the >> logo >> is HelveticaNeue-Light. >> >> https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158 >> >> While I'm not opposed to brush up the OpenSSL logo, I think this >> can't >> be done simply be replacing it on the fly. I think this requires a >> general >> discussion among the team members and finally an OMC decision, >> and shouldn't be rushed. Because after all, the shape of the logo is >> an >> essential part of the OpenSSL 'trade mark'. >> >> If we we want to brush up the Logo, we should give everybody time to >> come up >> with proposals and then have an open contest, ideally among all >> committers, >> not only OMC or OTC. (And you can be sure, I will come up with a >> proposal ;-) ) >> >> Finally, the OMC can run a vote, for example whether to pick the >> winner of the >> contest or to leave the logo as it is. > > The logo (attached) that Paul Yang created is matching the logo on the > old OpenSSL website. You can see it here for example: > > https://j3pd.files.wordpress.com/2011/08/openssl.jpg > > I do not know how the current logo on the web was created or if there > was any formal decision process applied but I would expect it was > created just as an approximation of the original logo without using a > picture. > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Thu Feb 27 10:16:10 2020 From: mark at openssl.org (Mark J Cox) Date: Thu, 27 Feb 2020 10:16:10 +0000 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: On Thu, Feb 27, 2020 at 9:31 AM Matthias St. Pierre wrote: > Because after all, the shape of the logo is an > essential part of the OpenSSL 'trade mark'. Although the current website logo as of January 2020 was used as the specimen to show our use of the trademark at renewal time, our official trademark registration is a standard character mark: i.e. "The mark consists of standard characters without claim to any particular font style, size, or color.". Regards, Mark From Matthias.St.Pierre at ncp-e.com Thu Feb 27 10:28:38 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Thu, 27 Feb 2020 11:28:38 +0100 Subject: OpenSSL Logo In-Reply-To: References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: <8fe9310c-1b7c-5288-16d3-d6505a4405f5@ncp-e.com> Thank you for the clarification, Mark. So this means we have some artistic freedom in choosing the logo? Personally, I'm not sure whether we really should aim at restoring the historic logo. IMHO this ornate font with 3D appearance reminds me of the nineties and has slightly gone out of style. Just take a look how the Google logo changed over time [1], for example. I think it's time for a more modern layout. Let's have a competition. Matthias [1] https://germany.googleblog.com/2015/09/google-update.html On 27.02.20 11:16, Mark J Cox wrote: > On Thu, Feb 27, 2020 at 9:31 AM Matthias St. Pierre > wrote: >> Because after all, the shape of the logo is an >> essential part of the OpenSSL 'trade mark'. > Although the current website logo as of January 2020 was used as the > specimen to show our use of the trademark at renewal time, our > official trademark registration is a standard character mark: i.e. > "The mark consists of standard characters without claim to any > particular font style, size, or color.". > > Regards, Mark From Matthias.St.Pierre at ncp-e.com Thu Feb 27 10:31:07 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Thu, 27 Feb 2020 11:31:07 +0100 Subject: OpenSSL Logo In-Reply-To: <8fe9310c-1b7c-5288-16d3-d6505a4405f5@ncp-e.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> <8fe9310c-1b7c-5288-16d3-d6505a4405f5@ncp-e.com> Message-ID: <9b0fbc74-ef9b-75d5-69bd-ddd1a6376ac0@ncp-e.com> Sorry for linking a german page (although the video is english). This seems to be the corresponding english version. https://googleblog.blogspot.com/2015/09/google-update.html On 27.02.20 11:28, Matthias St. Pierre wrote: > Thank you for the clarification, Mark. > > So this means we have some artistic freedom in choosing the logo? > > Personally, I'm not sure whether we really should aim at restoring > the historic logo. IMHO this ornate font with 3D appearance reminds > me of the nineties and has slightly gone out of style. Just take a look > how the Google logo changed over time [1], for example. > > I think it's time for a more modern layout. Let's have a competition. > > Matthias > > > > [1] https://germany.googleblog.com/2015/09/google-update.html > > From tmraz at redhat.com Thu Feb 27 10:54:12 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 27 Feb 2020 11:54:12 +0100 Subject: OpenSSL Logo In-Reply-To: <8fe9310c-1b7c-5288-16d3-d6505a4405f5@ncp-e.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> <8fe9310c-1b7c-5288-16d3-d6505a4405f5@ncp-e.com> Message-ID: <4b9efbbe8821d05a51490aa399f6ba8f51622aa4.camel@redhat.com> On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote: > Thank you for the clarification, Mark. > > So this means we have some artistic freedom in choosing the logo? > > Personally, I'm not sure whether we really should aim at restoring > the historic logo. IMHO this ornate font with 3D appearance reminds > me of the nineties and has slightly gone out of style. Just take a > look > how the Google logo changed over time [1], for example. > > I think it's time for a more modern layout. Let's have a competition. I like the logo as sent by Paul. There is no "3D appearance" in 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 kaishen.yy at alipay.com Thu Feb 27 13:08:41 2020 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 27 Feb 2020 21:08:41 +0800 Subject: OpenSSL Logo In-Reply-To: <4b9efbbe8821d05a51490aa399f6ba8f51622aa4.camel@redhat.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> <8fe9310c-1b7c-5288-16d3-d6505a4405f5@ncp-e.com> <4b9efbbe8821d05a51490aa399f6ba8f51622aa4.camel@redhat.com> Message-ID: <15F58E34-277D-4E14-86D9-7DE1F13B1316@alipay.com> Right, there is no 3D. Regards, Paul Yang > On Feb 27, 2020, at 6:54 PM, Tomas Mraz wrote: > > On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote: >> Thank you for the clarification, Mark. >> >> So this means we have some artistic freedom in choosing the logo? >> >> Personally, I'm not sure whether we really should aim at restoring >> the historic logo. IMHO this ornate font with 3D appearance reminds >> me of the nineties and has slightly gone out of style. Just take a >> look >> how the Google logo changed over time [1], for example. >> >> I think it's time for a more modern layout. Let's have a competition. > > I like the logo as sent by Paul. There is no "3D appearance" in 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.] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Feb 27 13:27:52 2020 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Thu, 27 Feb 2020 14:27:52 +0100 Subject: OpenSSL Logo In-Reply-To: <15F58E34-277D-4E14-86D9-7DE1F13B1316@alipay.com> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> <8fe9310c-1b7c-5288-16d3-d6505a4405f5@ncp-e.com> <4b9efbbe8821d05a51490aa399f6ba8f51622aa4.camel@redhat.com> <15F58E34-277D-4E14-86D9-7DE1F13B1316@alipay.com> Message-ID: Well then, if Tom?? manages to convert it to SVG and if there is no problem with the font, you may raise a pull request. (BTW: what is the font's name?) Please note that you might have to enlarge the bounding box to increase the border around the text. Because GitHub will automatically scale the image to full width on https://github.com/openssl/openssl and there is no way to downsize the image if we restrict ourselves to plain markdown (i.e. without adding inline HTML).? See [1] for an example. Matthias [1] https://github.com/openssl/openssl/blob/master/doc/images/openssl.svg On 27.02.20 14:08, Paul Yang wrote: > Right, there is no 3D. > > Regards, > > Paul Yang > >> On Feb 27, 2020, at 6:54 PM, Tomas Mraz > wrote: >> >> On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote: >>> Thank you for the clarification, Mark. >>> >>> So this means we have some artistic freedom in choosing the logo? >>> >>> Personally, I'm not sure whether we really should aim at restoring >>> the historic logo. IMHO this ornate font with 3D appearance reminds >>> me of the nineties and has slightly gone out of style. Just take a >>> look >>> how the Google logo changed over time [1], for example. >>> >>> I think it's time for a more modern layout. Let's have a competition. >> >> I like the logo as sent by Paul. There is no "3D appearance" in 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.] >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Feb 27 22:03:53 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 27 Feb 2020 22:03:53 +0000 Subject: OpenSSL Logo In-Reply-To: References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: <92c8ceb903374d6994020fbfe7241ea3@Ex13.ncp.local> > According to that site, it used to be at > > http://openssl.com/images/openssl-logo.png > Thanks to the Wayback Machine, nothing gets lost: Here is the historical OpenSSL Logo: https://web.archive.org/web/20141231112717/http://openssl.com/images/openssl-logo.png Matthias From matt at openssl.org Fri Feb 28 02:51:21 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 28 Feb 2020 02:51:21 +0000 Subject: OpenSSL Logo In-Reply-To: <92c8ceb903374d6994020fbfe7241ea3@Ex13.ncp.local> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> <92c8ceb903374d6994020fbfe7241ea3@Ex13.ncp.local> Message-ID: The design of the logo was deliberately changed back in (I think) 2015. The OMC have access to the logo in .xcf, .psd and .png formats. The new logo had these notes associated with it: This is the official OpenSSL logo. It was created in Adobe Photoshop 8.0 with the fonts Adobe Palatino Bold (for "Open"), Bitstream Gothic 725 Bold (for "SSL") and Tahoma (for "TM" and "Cryptography and SSL/TLS Toolkit"). Its original size is 30x10cm with a resolution of 300dpi, hence it is suitable for good quality printing in A4 paper. Higher resolution versions can be created easily by loading it into Adobe Photoshop and just resizing to the required size and/or resolution. This is possible because the text is not rasterized and both the inner bevel and drop shadow effects are reapplied automatically. Similarily, all elements are on separated layers, so they can be switched on/off individually. For processing the image under Unix, load it into The Gimp 2.0. But keep in mind that you need the above three fonts installed in other to change the original source. Matt On 27/02/2020 22:03, Dr. Matthias St. Pierre wrote: > >> According to that site, it used to be at >> >> http://openssl.com/images/openssl-logo.png >> > > Thanks to the Wayback Machine, nothing gets lost: Here is the historical OpenSSL Logo: > > https://web.archive.org/web/20141231112717/http://openssl.com/images/openssl-logo.png > > Matthias > > From rsalz at akamai.com Thu Feb 27 13:23:16 2020 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 27 Feb 2020 13:23:16 +0000 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: For what it?s worth, during the Website redesign I asked if anyone could provide a scalable logo so that our website worked on mobile, tablets, etc. Tony Arceri sent me a pure-CSS solution that worked and looked similar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Fri Feb 28 17:55:54 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 28 Feb 2020 18:55:54 +0100 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> Message-ID: <20200228175554.GA2704892@roeckx.be> On Thu, Feb 27, 2020 at 01:23:16PM +0000, Salz, Rich wrote: > Tony Arceri sent me a pure-CSS solution that worked and looked similar. I was about to mention that the website it just text+css. Kurt From Matthias.St.Pierre at ncp-e.com Fri Feb 28 23:30:22 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 28 Feb 2020 23:30:22 +0000 Subject: OpenSSL Logo (was: New GitHub Project Landing Page) In-Reply-To: <20200228175554.GA2704892@roeckx.be> References: <64F67698-68E9-4354-A0A3-437507A5C5A8@alipay.com> <0f7959f5-7de9-5540-2193-0fca44e67503@ncp-e.com> <20200228175554.GA2704892@roeckx.be> Message-ID: > On Thu, Feb 27, 2020 at 01:23:16PM +0000, Salz, Rich wrote: > > Tony Arceri sent me a pure-CSS solution that worked and looked similar. > > I was about to mention that the website it just text+css. > > > Kurt FYI: there is another discussion about the OpenSSL logo going on in pr #11200. In particular this post contains a link to text+css of the OpenSSL logo: https://github.com/openssl/openssl/pull/11200#issuecomment-592673575 Matthias From paul.dale at oracle.com Fri Feb 28 23:43:11 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 28 Feb 2020 15:43:11 -0800 (PST) Subject: Deprecations In-Reply-To: <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com> References: <20200221080639.GA2050170@roeckx.be> <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org> <20200221221717.GA2169205@roeckx.be> <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org> <20200221231808.GA2169191@roeckx.be> <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org> <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org> <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org> <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com> Message-ID: <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com> Any suggestions for a consensus on this thread? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 24 Feb 2020, at 5:08 pm, Dr Paul Dale wrote: > > Most of the conversions to using PKEY were straightforward. One didn?t require any changes (dsa but my memory is suspect). One seemed quite difficult. Some I didn?t check. > > Modifying the commands so that they continue to work and print (to stderr) an alternative pkey based command might be workable too. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni > wrote: >> >>> On Feb 22, 2020, at 4:53 AM, Richard Levitte > wrote: >>> >>> Something that could be done is to take all those aged commands and >>> rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create >>> and populate a new argv and call genpkey_main(), pkey_main() or >>> pkeyutl_main(). >> >> Agreed, that sounds quite reasonable at first blush, and could be fantastic >> if it can be made to work (no immediate obstacles come to mind). >> >> -- >> Viktor. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: