From nic.tuv at gmail.com Thu Dec 1 09:58:29 2022 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 1 Dec 2022 11:58:29 +0200 Subject: OTC Vote: Backport PR #19681 to 3.0 as a bug fix Message-ID: Topic: Backport PR #19681 to 3.0 as a bug fix Comment: Fundamentally OTC must decide if in the 3.0 release we should honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and default to UNCOMPRESSED) in our provider implementations, and apply corresponding changes for handling legacy keys. Proposed by: Nicola Tuveri Issue link: https://github.com/openssl/technical-policies/issues/60 Public: yes Opened: 2022-12-01 Closed: YYYY-MM-DD Accepted: yes/no (for: X, against: Y, abstained: Z, not voted: W) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Hugo [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [+1] From openssl at openssl.org Thu Dec 1 14:00:02 2022 From: openssl at openssl.org (OpenSSL) Date: Thu, 1 Dec 2022 14:00:02 +0000 Subject: OpenSSL version 3.1.0-alpha1 published Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.1 alpha 1 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.1 is currently in alpha. OpenSSL 3.1 alpha 1 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.1 from previous versions are available in the OpenSSL Migration Guide, here: https://www.openssl.org/docs/man3.0/man7/migration_guide.html The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.1.0-alpha1.tar.gz Size: 15343477 SHA1 checksum: 91a7cbcb761c4bb8a460899bccddcbd5d047d3c3 SHA256 checksum: ef10f70023f4e3f701c434db0b4b0c8cfea1e1e473a0eb3c9ccbc5c54f5f5566 The checksums were calculated using the following commands: openssl sha1 openssl-3.1.0-alpha1.tar.gz openssl sha256 openssl-3.1.0-alpha1.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOIqpASHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tWrIQAJHT40JekEs3DacHjQrTmGLc56TmzaFD oDp8Md2E0RpX/vuANdIVGB89zGQMag13TPa9CzT1yk7wFBilPoiuapolmo8N0nvF OnMLIQjF+sbsQN0gqchuMKKD98omc1ZNNcijq/GlKM9wH6ey1uHnFAi2aXF4f6ai 2SviauJvHQDgDOe9tFfA5lDF1EdYZt20D46Yc+yJf/zr4MJZFcX2T2qmo+oew6VA djZ+cRPeeNmRXrl5Banqpfcy2iH4N57wvEcM4dtGaGY+4Pwr0H9XN6MxfamGUbLv oSySdFpTagPENPGDBPoRilPSXdapCD5m8Xd2FERM1HF5E1GaemqaQKUYiXbANqL/ SDBftayilhYf+tXg3/22xksZVEkEjFD79M0mj75dn+UgQilOTR/AOdup2imTB7PG 7Cgq2HGz93ppO3kG0iuTS5uc95Gfu9AfkjgfcydA2eZf+rmHAoocm8kpThdxD/a5 avpMudgklyXysmO+2MJ16806Sa27L8N52YTPzy4Zthx/SLR/RA//bXBnlSlguRGw 7+hIDPncmaCfegaI65yq/TgtU9z/OLhNTPmYaUQi3IFtsCrAahZNVYg8qZtnMtgC iaVYQkNZsqE0wSDalgJANJkZUa8VHdh2O3sOBSYbZvHWEiYJJ+9ATgLSLDjiGq0e l9cvtybysQsx =upN5 -----END PGP SIGNATURE----- From stephen.farrell at cs.tcd.ie Tue Dec 13 05:07:20 2022 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Tue, 13 Dec 2022 05:07:20 +0000 Subject: working towards a PR for ECH Message-ID: <788dc6ca-4779-014f-0487-5f3b70900027@cs.tcd.ie> Hi all, Me again:-) I've learned a lot from the extended processing of my HPKE PR [1] and was pondering how to proceed to get a PR for ECH ready for processing. (Thanks again to all of you who helped get [1] over the line, and apologies for being so inept along the way:-) TL:DR; suggestion is: create a mailing list for those interested in commenting on or watching the code that might end up being that PR; I'm happy to create such a list @tcd.ie or for it to be @openssl.org (presumably with an anyone-can-subscribe/open-archive setup). Reasons: - This is going to take a while, might interact with the quic stuff you're doing, and some of the likely politics (e.g. browsers turning ECH on by default) will likely benefit from a focused venue for technical implementation discussion - It's defo premature to produce a PR now, as the ECH draft [2] isn't yet an RFC, so you can't merge as per policy (a good policy), and my learnings from [1] are that my code [3] as-is definitely needs a large pile of work [/me being a willing worker still:-)] - The draft [2] is quite mature though, being deployed at a test cloudflare instance and (behind a flag) in released browsers, with interop already, (including with my test servers [4]) so it'd be a shame to fall behind by a year or more after the RFC pops out, were that due to not having a way to get ready beforehand - It'd seem sensible to discuss ECH APIs ahead of time, so that applications using OpenSSL (esp. web servers and clients like curl/wget) have a thing to discuss and compare vs. e.g. boringssl APIs (which are IMO understandably more browser-focused); I've had initial discussions with haproxy and lighttpd devs that I think have been valuable, so a place for that that's less ad-hoc and more public seems like a good plan - Similarly, a venue for discussion of implementation details should have value and save time/effort (see below for examples) So - whatcha think? I'd be happy to raise this on the openssl-users list if that's better or to join another of your calls to discuss (my take fwiw: better if you folk decide such a list is a good idea, and announce that list on openssl-users). Cheers, S. [1] https://github.com/openssl/openssl/pull/17172 [2] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ [3] https://github.com/sftcd/openssl/blob/ECH-draft-13c/esnistuff/README.md [4] https://defo.ie Examples of implementation things that'd benefit from list discussion prior to creating a PR after the RFC pops out: - My current code creates a "shadow" SSL_CONNECTION on the client as the client doesn't know which transcript is needed until it gets the ServerHello; I expect that you'll hate that:-) (which is ok, I'll probably change that anyway) - Extension constructors can have side-effects, which is a pain but can be handled, but for custom extensions I've no idea how to handle that, nor how widely used those may be - I'm unclear how to distribute code between ssl/ech.c and ssl/statem/*.c (and a few other similar things) and it'd likely be a lot easier to handle such comments via pre-PR mail threads I think - It may or may not be a good plan to mimic how boringssl or NSS handle ECH on the client (from the fingerprinting POV for a n/w observer), and that may change over time; I bet what I've done there won't be ubiquitously liked:-) - There are likely many corner-cases of which I'm utterly unaware that should be handled differently - ECH requires changes in various bits of the state machine that seem to overlap with new and older code that's hard to fathom for me;-) - I'm still fairly mystified by the perl/TLSProxy stuff and how it might need to be extended for ECH (I have a pile of bash scripting to do tests for ECH with HRR/early- data and other oddities but need help/guidance on how to make that part of the``make test`` target) - An eventual ECH PR is going to be >5k LOC I guess, so it seems reasonable that more than one modus-operandi for discussion may be needed to do that well without too much delay -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 5564 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From noreply at reply.github.openssl.org Tue Dec 13 09:59:10 2022 From: noreply at reply.github.openssl.org (Tomas Mraz) Date: Tue, 13 Dec 2022 09:59:10 +0000 Subject: [otc/technical-policies] 5f3152: Add vote about OpenSSL 3.1 beta1 release Message-ID: Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 5f31521702df2a90a82fff2ad35845f4f2c299fe https://github.openssl.org/otc/technical-policies/commit/5f31521702df2a90a82fff2ad35845f4f2c299fe Author: Tomas Mraz Date: 2022-12-13 (Tue, 13 Dec 2022) Changed paths: A votes/vote-20221213-beta1-release.txt Log Message: ----------- Add vote about OpenSSL 3.1 beta1 release From tomas at openssl.org Tue Dec 13 10:00:19 2022 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 13 Dec 2022 11:00:19 +0100 Subject: OTC Vote: OpenSSL 3.1 beta 1 release approval Message-ID: Topic: OTC approves 3.1 beta 1 release on Wed Dec 21 2022 assuming all the outstanding items on the release check-list (#19864) are done including the provisions for Coverity and Coveralls items as mentioned in the check list issue. Proposed by: Tomas Mraz Issue link: https://github.com/openssl/technical-policies/issues/61 Public: yes Opened: 2022-12-13 Closed: 2022-12-13 Accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3) Dmitry [+1] Matt [+1] Pauli [+1] Tim [ ] Hugo [+1] Richard [ ] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] -- Tom?? Mr?z, OpenSSL From noreply at github.com Tue Dec 13 10:01:00 2022 From: noreply at github.com (=?UTF-8?B?VG9tw6HFoSBNcsOheg==?=) Date: Tue, 13 Dec 2022 02:01:00 -0800 Subject: [openssl/technical-policies] 5f3152: Add vote about OpenSSL 3.1 beta1 release Message-ID: Branch: refs/heads/master Home: https://github.com/openssl/technical-policies Commit: 5f31521702df2a90a82fff2ad35845f4f2c299fe https://github.com/openssl/technical-policies/commit/5f31521702df2a90a82fff2ad35845f4f2c299fe Author: Tomas Mraz Date: 2022-12-13 (Tue, 13 Dec 2022) Changed paths: A votes/vote-20221213-beta1-release.txt Log Message: ----------- Add vote about OpenSSL 3.1 beta1 release From noreply at reply.github.openssl.org Tue Dec 13 10:40:40 2022 From: noreply at reply.github.openssl.org (Tomas Mraz) Date: Tue, 13 Dec 2022 10:40:40 +0000 Subject: [otc/technical-policies] 80a530: vote-20221213-beta1-release.txt: Record Tim's vote Message-ID: Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 80a530870ab33c96201b961759216bfe59afb8f2 https://github.openssl.org/otc/technical-policies/commit/80a530870ab33c96201b961759216bfe59afb8f2 Author: Tomas Mraz Date: 2022-12-13 (Tue, 13 Dec 2022) Changed paths: M votes/vote-20221213-beta1-release.txt Log Message: ----------- vote-20221213-beta1-release.txt: Record Tim's vote From noreply at github.com Tue Dec 13 10:43:01 2022 From: noreply at github.com (=?UTF-8?B?VG9tw6HFoSBNcsOheg==?=) Date: Tue, 13 Dec 2022 02:43:01 -0800 Subject: [openssl/technical-policies] 80a530: vote-20221213-beta1-release.txt: Record Tim's vote Message-ID: Branch: refs/heads/master Home: https://github.com/openssl/technical-policies Commit: 80a530870ab33c96201b961759216bfe59afb8f2 https://github.com/openssl/technical-policies/commit/80a530870ab33c96201b961759216bfe59afb8f2 Author: Tomas Mraz Date: 2022-12-13 (Tue, 13 Dec 2022) Changed paths: M votes/vote-20221213-beta1-release.txt Log Message: ----------- vote-20221213-beta1-release.txt: Record Tim's vote From hlandau at openssl.org Tue Dec 13 11:07:33 2022 From: hlandau at openssl.org (Hugo Landau) Date: Tue, 13 Dec 2022 11:07:33 +0000 Subject: working towards a PR for ECH In-Reply-To: <788dc6ca-4779-014f-0487-5f3b70900027@cs.tcd.ie> References: <788dc6ca-4779-014f-0487-5f3b70900027@cs.tcd.ie> Message-ID: Hi Stephen, First of all, thanks again for the herculean effort on your part in getting HPKE into OpenSSL. The OTC would really like to see ECH realised in OpenSSL, as would I personally. It goes without saying that getting ECH deployed in the world's most widely used SSL library has the potential to make a great positive impact in terms of metadata leakage. For now, I'll create a mailing list ech@ which can be used to discuss this further. I'll subscribe the OTC to this list, as well as you. We discussed this briefly at OTC today and would like to invite you to a meeting of the OTC to discuss ECH sometime in the new year, exact date TBD. There is the fact that that since we don't merge implementations of standards until they are actually standards, this does create an unfortunate tendency to be late to the game in implementing them once they actually are standards. But this doesn't have to be the case. While ECH isn't ratified yet, obviously if we can get a viable draft PR ready in the meantime which tracks the current I-D, we could hopefully get it in as soon as it becomes an RFC. I think this is basically what you are proposing and sounds like a good approach to me. API discussion is very important and I'd absolutely like to be part of that discussion. Feel free to get HAProxy, lighttpd, etc. and other interested parties on the new list, which is open to all. Yours, Hugo Landau From stephen.farrell at cs.tcd.ie Tue Dec 13 13:22:52 2022 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Tue, 13 Dec 2022 13:22:52 +0000 Subject: working towards a PR for ECH In-Reply-To: References: <788dc6ca-4779-014f-0487-5f3b70900027@cs.tcd.ie> Message-ID: <6f47a638-b4d5-6470-37a4-2a3577b02d29@cs.tcd.ie> Hiya, That was a quick response! (Which is great.) On 13/12/2022 11:07, Hugo Landau wrote: > Hi Stephen, > > First of all, thanks again for the herculean effort on your part in > getting HPKE into OpenSSL. > > The OTC would really like to see ECH realised in OpenSSL, as would I > personally. It goes without saying that getting ECH deployed in the > world's most widely used SSL library has the potential to make a great > positive impact in terms of metadata leakage. > > For now, I'll create a mailing list ech@ which can be used to discuss > this further. I'll subscribe the OTC to this list, as well as you. We > discussed this briefly at OTC today and would like to invite you to a > meeting of the OTC to discuss ECH sometime in the new year, exact date > TBD. Excellent! I'll send starter mail to that list (mostly for the archive) then send out a few pointers to it with a view to starting discussion in the new year. (BTW, if it helps to make me another mailman admin for that list, happy to do that if you want, or to not do it if you're good.) WRT state of play/timing for ECH and doing a call: very happy to do that as suits the OTC schedule. > There is the fact that that since we don't merge implementations of > standards until they are actually standards, this does create an > unfortunate tendency to be late to the game in implementing them once > they actually are standards. But this doesn't have to be the case. Right. Shortening that delay seems good in general so, if it works, this may be a useful modus operandi to keep in mind for other drafts of (some) upcoming standards. > While > ECH isn't ratified yet, obviously if we can get a viable draft PR ready > in the meantime which tracks the current I-D, we could hopefully get it > in as soon as it becomes an RFC. I think this is basically what you are > proposing and sounds like a good approach to me. > > API discussion is very important and I'd absolutely like to be part of > that discussion. My plan is to do a bit more work on the current APIs over the holidays then kick off discussion of those on the list early in the new year. > Feel free to get HAProxy, lighttpd, etc. and other > interested parties on the new list, which is open to all. Will do, Thanks! S. > > Yours, > Hugo Landau -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 5564 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From tomas at openssl.org Tue Dec 13 13:24:56 2022 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 13 Dec 2022 13:24:56 +0000 Subject: OpenSSL Security Advisory Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [13 December 2022] ============================================ X.509 Policy Constraints Double Locking (CVE-2022-3996) ======================================================= Severity: Low If an X.509 certificate contains a malformed policy constraint and policy processing is enabled, then a write lock will be taken twice recursively. On some operating systems (most widely: Windows) this results in a denial of service when the affected process hangs. Policy processing being enabled on a publicly facing server is not considered to be a common setup. Policy processing is enabled by passing the `-policy' argument to the command line utilities or by calling either `X509_VERIFY_PARAM_add0_policy()' or `X509_VERIFY_PARAM_set1_policies()' functions. OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue. However due to the low severity of this issue we are not creating a new release at this time. The mitigation for this issue can be found in commit 7725e7bfe. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8 once it is released. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was discovered on 7th November 2022 by Polar Bear. The fix was developed by Dr Paul Dale. We have no evidence of this issue being exploited as of the time of release of this advisory (December 13th 2022). References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20221213.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOYehASHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tRVsQAIW6PehuBCAjLZLWRlx85qIkGSKSuQoR K+Fl9C3zT2DOg0kldhE4rHRDoAOKhle9dOh4J46NVQ8TCPZYN9D0CTHpyY4YEOye CEyrozcaHnO9TwnWoFMhx76Vo9IMujogK+A/0pO7qACTJNsSlix/zWAkkzoD5Esi BJdlQMlLSi92cHISzY3YoY3td0BlR3b8/SQBeUj8O4n80c6P89U7cti9WyN+KSep gkB36n4k4cPQXTCB/K8OUC1F8az3PmndOKgxmo19cMWgElW06rFyYvhyWcv1ObjR dZxXbq8CV4pv4WexsFF8y0f8xplPi5kcdOe8mJMoPGCC0aRvhVDMxmE4r9/Xq8LL aZD6nYx4LBHBsdMsVuCLwds+BIhMYqs9KmjjxRRJDdMXpSCQT6LH2YfkevhIITfa bSb0TyX+1dSVieFr70pFDP/Fd1add7ktS+lu54i0oH8f1hQDmh7s+SXjcM3ULcXE REie5EZWALZX4T7gXNMeWIcNn7UL6xg7EU8Fq7aWy9bIyyy7d5GmFamLPLLzQc4s gs2DBkYiwpW/KuCksfGro1FQVMVxanVaFvqnYpl/W092F/JbN7XC2MLP7L6eGMKz RTvLpZ46c+nGfZ5Cx/dvv1efLfcAg1KX+182ITSjL7v/7XW4i1TOfzBmyZm6Vd9g 37jOuJ7uCQWG =r/+J -----END PGP SIGNATURE----- From noreply at github.com Tue Dec 13 23:26:01 2022 From: noreply at github.com (Nicola Tuveri) Date: Tue, 13 Dec 2022 15:26:01 -0800 Subject: [openssl/technical-policies] a74e68: [VOTE] Honor EC point conversion format in 3.0 Message-ID: Branch: refs/heads/master Home: https://github.com/openssl/technical-policies Commit: a74e6849cc0abbda6d78b1445656425071c2d175 https://github.com/openssl/technical-policies/commit/a74e6849cc0abbda6d78b1445656425071c2d175 Author: Nicola Tuveri Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: A votes/vote-20221128-honor-point-conversion-format-in-3.0.txt Log Message: ----------- [VOTE] Honor EC point conversion format in 3.0 From noreply at github.com Tue Dec 13 23:32:01 2022 From: noreply at github.com (Nicola Tuveri) Date: Tue, 13 Dec 2022 15:32:01 -0800 Subject: [openssl/technical-policies] 4fc155: Fix date in the filename of last recorded vote Message-ID: Branch: refs/heads/master Home: https://github.com/openssl/technical-policies Commit: 4fc15576a57ee6387dfe58ee241bda3e40e2f06c https://github.com/openssl/technical-policies/commit/4fc15576a57ee6387dfe58ee241bda3e40e2f06c Author: Nicola Tuveri Date: 2022-12-14 (Wed, 14 Dec 2022) Changed paths: R votes/vote-20221128-honor-point-conversion-format-in-3.0.txt A votes/vote-20221201-honor-point-conversion-format-in-3.0.txt Log Message: ----------- Fix date in the filename of last recorded vote From nic.tuv at gmail.com Wed Dec 14 00:39:04 2022 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 14 Dec 2022 02:39:04 +0200 Subject: OTC Vote: Backport PR #19681 to 3.0 as a bug fix In-Reply-To: References: Message-ID: The vote is now closed as accepted. As recorded [0], the final tally was: ~~~ Topic: Backport PR #19681 to 3.0 as a bug fix Comment: Fundamentally OTC must decide if in the 3.0 release we should honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and default to UNCOMPRESSED) in our provider implementations, and apply corresponding changes for handling legacy keys. Proposed by: Nicola Tuveri Issue link: https://github.com/openssl/technical-policies/issues/60 Public: yes Opened: 2022-12-01 Closed: 2022-12-14 Accepted: yes (for: 4, against: 0, abstained: 5, not voted: 2) Dmitry [+1] Matt [ 0] Pauli [+1] Tim [ 0] Hugo [+0] Richard [ ] Shane [ 0] Tomas [ 0] Kurt [ ] Matthias [+1] Nicola [+1] ~~~ [0]: https://github.com/openssl/technical-policies/blob/master/votes/vote-20221201-honor-point-conversion-format-in-3.0.txt From rsbecker at nexbridge.com Wed Dec 14 07:25:25 2022 From: rsbecker at nexbridge.com (rsbecker at nexbridge.com) Date: Wed, 14 Dec 2022 02:25:25 -0500 Subject: OTC Vote: OpenSSL 3.1 beta 1 release approval In-Reply-To: References: Message-ID: <014001d90f8d$40684180$c138c480$@nexbridge.com> On December 13, 2022 5:00 AM, Tomas Mraz wrote: >To: OpenSSL Project >Subject: OTC Vote: OpenSSL 3.1 beta 1 release approval > >Topic: OTC approves 3.1 beta 1 release on Wed Dec 21 2022 assuming all > the outstanding items on the release check-list (#19864) are done > including the provisions for Coverity and Coveralls items as > mentioned in the check list issue. >Proposed by: Tomas Mraz >Issue link: https://github.com/openssl/technical-policies/issues/61 >Public: yes >Opened: 2022-12-13 >Closed: 2022-12-13 >Accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3) > > Dmitry [+1] > Matt [+1] > Pauli [+1] > Tim [ ] > Hugo [+1] > Richard [ ] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [+1] > FYI: The openssl-3.1 still does not build on HPE NonStop based on issue https://github.com/openssl/openssl/issues/19838. Sincerely, Randall From tomas at openssl.org Fri Dec 16 15:51:41 2022 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 16 Dec 2022 16:51:41 +0100 Subject: Repo is frozen Message-ID: <7b4597100bb585c7cac16414e00169f3fbdeff44.camel@openssl.org> The openssl/openssl repository is frozen before the OpenSSL 3.1 Beta 1 release on Wednesday. Regards, -- Tom?? Mr?z, OpenSSL From noreply at github.com Tue Dec 20 03:18:47 2022 From: noreply at github.com (Tam) Date: Mon, 19 Dec 2022 19:18:47 -0800 Subject: [openssl/general-policies] 909547: Accessing sensitive information policy Message-ID: Branch: refs/heads/Branch_SponsorshipPolicy Home: https://github.com/openssl/general-policies Commit: 90954788007f882f554525e00060c4955e27260c https://github.com/openssl/general-policies/commit/90954788007f882f554525e00060c4955e27260c Author: TamaraDale Date: 2022-07-20 (Wed, 20 Jul 2022) Changed paths: A policies/SIT-SIAT_Tables.ods Log Message: ----------- Accessing sensitive information policy Also including related tables for review Commit: ce220e25fcd11eacd79dc0692c2f894dce229ce1 https://github.com/openssl/general-policies/commit/ce220e25fcd11eacd79dc0692c2f894dce229ce1 Author: TamaraDale Date: 2022-07-22 (Fri, 22 Jul 2022) Changed paths: A policies/accessing-sensitive-information-policy.md Log Message: ----------- Add sensitive information policy Commit: 92a4e4cd988df6e753632d6a91dac84068d2fd3c https://github.com/openssl/general-policies/commit/92a4e4cd988df6e753632d6a91dac84068d2fd3c Author: TamaraDale Date: 2022-09-30 (Fri, 30 Sep 2022) Changed paths: R policies/SIT-SIAT_Tables.ods Log Message: ----------- SIT & SIAT Tables in Markdown Commit: 4255cacd08b3ba911a81338d88f73cb4990f7cbb https://github.com/openssl/general-policies/commit/4255cacd08b3ba911a81338d88f73cb4990f7cbb Author: TamaraDale Date: 2022-12-20 (Tue, 20 Dec 2022) Changed paths: A policies/Sponsorship_Policy.md Log Message: ----------- Added Sponsorship Policy for review Compare: https://github.com/openssl/general-policies/compare/90954788007f%5E...4255cacd08b3 From tomas at openssl.org Wed Dec 21 10:58:12 2022 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 21 Dec 2022 10:58:12 +0000 Subject: OpenSSL version 3.1.0-beta1 published Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.1 beta 1 released =================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.1 is currently in beta. OpenSSL 3.1 beta 1 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.1 from previous versions are available in the OpenSSL Migration Guide, here: https://www.openssl.org/docs/man3.0/man7/migration_guide.html The beta release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.1.0-beta1.tar.gz Size: 15477820 SHA1 checksum: 8b1e5150c8148fb2a4c115e0c8641b8cfc339877 SHA256 checksum: e0d4bb52f7f9a745127b533be1c42bd4743467b180e7bc28a3d6ed40410c86d0 The checksums were calculated using the following commands: openssl sha1 openssl-3.1.0-beta1.tar.gz openssl sha256 openssl-3.1.0-beta1.tar.gz Please download and check this beta release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOi3rYSHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55t+SYP/iAe1G/sOzc19X3RgmhGwkMTWICGAmX9 GMhVQYo7+LMDuH1yrxklsRDqdMsGjN73omw1oiye+Wl74xsinV8MefNb/AdWX7uz u+7mI+fBwg3el7UquZWKIRo8XPXdOZUAVYdnpyCRCewGNFIqnkwSQfNBXPV2brY4 gzom+JaVG4riHaAAOB5FI/GG7zgaZ9y25PHd34aD+M/RcRbH0NQ+z21gSzxehFRL eHVO4ErNFswhDRyzsfq8BeJ2OAxS79Ue3UyV05cwEnEnv/eJq/Vy3ISthMx9Rl6v ALKJRmzo2lUUk1rwIVobOo6x4RKVNGbv9jnZpzVL6zmgozrv5/s0EzMTbkUMe69i G2REaZS26iQO99r1BD+cNNYDg85/inn8sjN2UxzYmFkLItea5XdK8Wths40DLzYz ozua4jkGQBqfb4xPFM2Ueq73Z2JMUype0HxNS/BgAYtyyV8E0jplf1oaacKB33k6 8ZLlWhh+tx9eAuMc59xthcaIxRC7S0TMOxRuFPQ7v/bWl90iJHac86s5QHm7Xfha 2NN5FhFRPYz4zbkQBX8WAiC76nZGBIxJAqhYV1UbX583kEXVgCxf42YV55bPWkIe HChMhr0saY/hQ8BlYSkNlFrzN50zGBINKwRXBhQuofrCmlwhky9eiw09h2sne4FE LJvNDpUY98tL =gT0X -----END PGP SIGNATURE----- From tomas at openssl.org Wed Dec 21 12:36:31 2022 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 21 Dec 2022 13:36:31 +0100 Subject: Repo is frozen In-Reply-To: <7b4597100bb585c7cac16414e00169f3fbdeff44.camel@openssl.org> References: <7b4597100bb585c7cac16414e00169f3fbdeff44.camel@openssl.org> Message-ID: <48d9f3912378e1dcadc90f9b572f4ebc49839e05.camel@openssl.org> Release done, repository is thawed. On Fri, 2022-12-16 at 16:51 +0100, Tomas Mraz wrote: > The openssl/openssl repository is frozen before the OpenSSL 3.1 Beta > 1 > release on Wednesday. > > Regards, -- Tom?? Mr?z, OpenSSL