From paul.dale at oracle.com Fri Feb 1 09:00:54 2019 From: paul.dale at oracle.com (Paul Dale) Date: Fri, 1 Feb 2019 01:00:54 -0800 (PST) Subject: [openssl-project] FYI: NIST's post quantum cryptography progress Message-ID: <64700c00-1e68-49cc-81cc-48182926fee0@default> NIST's post quantum cryptography 1st round report is out: https://nvlpubs.nist.gov/nistpubs/ir/2019/NIST.IR.8240.pdf Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Feb 4 21:51:07 2019 From: paul.dale at oracle.com (Paul Dale) Date: Mon, 4 Feb 2019 21:51:07 +0000 (UTC) Subject: [openssl-project] OMC vote regarding completeness of CCLA and ICLA forms Message-ID: <70dfc0fa-6da4-4a23-9ba5-1598237f967b@default> The vote text says: CCLAs and ICLAs will not be accepted unless they include all non-optional details. The fields which are considered optional are public name and telephone for an ICLA and telephone and fax for a CCLA. The vote passed with five +1's and two abstentions. What does this mean for existing CLAs? Nothing. They are still valid. For CLAs going forwards, we'd prefer that all fields are provided but will accept forms with the some or all of the specified fields left blank. We will not accept CLAs with any other field left blank. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----BEGIN PGP MESSAGE----- Version: GnuPG v2 owFdUn1QFGUYv0PA85gDxAqZGH3oEgE9vo5QQEE80CAV4iOcoIO92xduYdlddvfu uFFJwAyMkdD8I9FijEadiqwrsMgiUBg/gAGkSWF0hGFIL0LHdGIi6t070ZlmdmZ3 n+d9fs/v431ftUSmkN8f2xn080hWlPzqXYOsYLe9I8eEwMKKCERUKYJA2IR4lRJU Sp1uR7IABENCmvPLStE0MKwIBgSE0Yg4EZFgZmgkCCCakA0oxkibSdykaZWSYRkN y4kUyxA0kEgkKFoIB5CWFVOIJjGeiTKagOARGFlGoEjEY7ynI7iuUnJmA00ZgSHK kZOIiGjEmVgGY7A8rjiZ/a8j/RUTla4TIIkId8p5KpMjBAFvslKiCVOxIFgXNbH/ Q5dS0coCYRBExEg0BNdknokQgWSRJJMSoBzhxRI6qqQEkWJKQLInCWAXi/tMiUul zakM97FpFoKmSIy1DQ85rSxhpTGMYSV4UlgPVoQZkMDxqBjxeAveh01cNEoC4njW gi0iwWAWXUm4IpBAygWXGBwCCCy2SlKOT7DFrhKHjBSGIhfxaFSMQ6QJpktehlnl oWfRPgF9kjfGJBgbYFmYlXP42WyZyxv8ZBJmmlIpNRr8ncETRhoHl8KDVIYUgkaw F3S8jRPZEp7gJKS9sAtho/kyyEZGM0+JNgiGVMYoHcKuS5DOJNfFRsEG0EZq8Ss6 asMiOiSbBZHHlhJ4fb1boLtMrpB5erhJd1mmXOa7eMFf+dZXdnLkjGGqcXrKJ9Hj +Or++SMPw1J7e9NSMrvTOtxtTbn5jjcqIh5HyCuvXFSXJVxoTPnxCB10zW/zlslJ zzD1pgq/8kOr1rp7q8Zzh37VDg0eyKoNcbdrxnKDqgOaw+tC49We6pi39lRn3zl4 cuncyhVffbBZCA7uGo6LnR4s1RQNT1LDdYP9utpox86xaZ+BPW1kPtuubzjX6JY+ YJn545+chtPL4YH+gmJZZJP81vXhXPK9s1Uou09j+miw6lDgiuSKpO3ZKu9R7YGa WiFlSVDnphBHxqPOmmOx9RdH7IovdXFvDrS9nL7v1ZrUgBNKr63P//v6lYKORy0Z yaUBGf0R+uCrS0uX92+JMMdE3pqb2ritKi/izjcn/K/ZHe3HVAWe1qP2wvv3HPm9 7pk1/hsV/Tvmel7r8XHUD/rdaM0oJAPiTqftHzoruzzxTvDCxG/zw9XlM52H9ePn P2vK6fOe5dhfdqvTzySkff3T9tKWU2u0ITcF/46Xwru7KpqbE6OTvoO21bdrGov+ fNH/dmrLp9pQy9EY/dqbIe0DF+uuf9Jw6fgX6tkiYiFm1PFxDnruh77P2cNM49u+ dqvXmvMJC/NTnZETM/Fl+vq7JaHjc4U6S2K1r7/3+r+YsLhTHq1j7z7ueXjje3Tu wb6tgb9Xz2a90OpVd09xaYpd6fb3KlXMwMHuqsuto/H/AQ== =yaLX -----END PGP MESSAGE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Feb 5 17:20:21 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 5 Feb 2019 17:20:21 +0000 Subject: [openssl-project] 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: - Significant work on the FIPS design/architecture - Fixed no-cmac - Fixed no-sock - Finished and pushed the no-pinshared PR, and backported it to 1.1.1 - Fixed handling of the cryptopro extension - Review of the CMP PR - Review of the Kernel TLS receive side PR - Fixed compilation on sparc - Review of the async notification callback PR - Investigations related to CVE-2019-0190 - Added some additional return checking in the SRP code - Worked on various updates to the release strategy - Fixed a missing array initialiser - Implemented a fix for a DTLS timer buf - Fixed s_client to build properly on Windows - Fixed -verify_return_error in s_client - Created PR to allow more than 32 KeyUpdates per connection - Created PR to not signal post-handshake exchanges with SSL_CB_HANDSHAKE_START - Fixed memory leak from ERR_add_error_vdata() - Fixed no-dso - Fixed handling of -twopass option in pkcs12 app Matt From kurt at roeckx.be Wed Feb 6 23:11:00 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 7 Feb 2019 00:11:00 +0100 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> Message-ID: <20190206231100.GA31488@roeckx.be> On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote: > On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell wrote: > > > > > On 31/01/2019 18:50, David Benjamin wrote: > > > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL > > can at > > > least help slow its spread by issuing a fix > > > > That's precisely what PR 8096 does. > > > > > > > As a heuristic for API design: if the caller needs to know the > > implementation > > > details of OpenSSL to understand what this API does, the API is no good. > > > Existing code cannot possibly predict how OpenSSL's implementation will > > evolve > > > over time, so there is no way to use such an API in a future-proof way. > > Do not > > > introduce such APIs. > > > > The info callback has been around a *long* time. In fact OpenSSL did not > > introduce it at all - we inherited it from SSLeay. Arguments about whether > > it is > > a good API or not don't help the issue at hand. The API exists, > > applications use > > it, and so (for now at least) we continue to support it. > > > > Given that it already existed we had to make a decision about how it was > > going > > to work in the presence of TLSv1.3. We did what we believed to be the > > correct > > thing at the time. The changes were pretty minimal and we tried to keep > > things > > as close to what existing users of the callback would expect. It turns out > > we > > got it wrong. > > > > Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are > new. It seems best to just omit it, so OpenSSL is not tied to the nebulous > notion of "post-handshake exchange". > > I.e. don't bracket post-handshake things with START/END at all. Matt, do you have any comment on this? Can we go forward with this? Kurt From matt at openssl.org Thu Feb 7 15:03:44 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 Feb 2019 15:03:44 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <20190206231100.GA31488@roeckx.be> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> <20190206231100.GA31488@roeckx.be> Message-ID: On 06/02/2019 23:11, Kurt Roeckx wrote: > On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote: >> On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell wrote: >> >>> >>> On 31/01/2019 18:50, David Benjamin wrote: >>>> We will see if this damage turns out fatal for KeyUpdate, but OpenSSL >>> can at >>>> least help slow its spread by issuing a fix >>> >>> That's precisely what PR 8096 does. >>> >>> >>>> As a heuristic for API design: if the caller needs to know the >>> implementation >>>> details of OpenSSL to understand what this API does, the API is no good. >>>> Existing code cannot possibly predict how OpenSSL's implementation will >>> evolve >>>> over time, so there is no way to use such an API in a future-proof way. >>> Do not >>>> introduce such APIs. >>> >>> The info callback has been around a *long* time. In fact OpenSSL did not >>> introduce it at all - we inherited it from SSLeay. Arguments about whether >>> it is >>> a good API or not don't help the issue at hand. The API exists, >>> applications use >>> it, and so (for now at least) we continue to support it. >>> >>> Given that it already existed we had to make a decision about how it was >>> going >>> to work in the presence of TLSv1.3. We did what we believed to be the >>> correct >>> thing at the time. The changes were pretty minimal and we tried to keep >>> things >>> as close to what existing users of the callback would expect. It turns out >>> we >>> got it wrong. >>> >> >> Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are >> new. It seems best to just omit it, so OpenSSL is not tied to the nebulous >> notion of "post-handshake exchange". >> >> I.e. don't bracket post-handshake things with START/END at all. > > Matt, do you have any comment on this? Can we go forward with > this? I'm not particularly keen on not signalling at all. But its also "not a hill I'm going to die on". So I updated #8096 accordingly. That would make the proposed vote text for this OMC vote: "master and 1.1.1 will be updated so that they do not signal the start and end of post-handshake message exchanges in the info callback using SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_DONE." Matt From matt at openssl.org Tue Feb 12 10:08:27 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 12 Feb 2019 10:08:27 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> <20190206231100.GA31488@roeckx.be> Message-ID: <6d3244da-9c5c-ba58-9ba2-56cbc3b1e7fa@openssl.org> On 07/02/2019 15:03, Matt Caswell wrote: > That would make the proposed vote text for this OMC vote: > > "master and 1.1.1 will be updated so that they do not signal the start and end > of post-handshake message exchanges in the info callback using > SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_DONE." I started this vote and will report back on the results in due course. Matt From matt at openssl.org Tue Feb 12 10:54:15 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 12 Feb 2019 10:54:15 +0000 Subject: [openssl-project] Updates to the release strategy Message-ID: <6e74f90b-0a7b-f7df-58d4-62305ffb0670@openssl.org> Is there any more feedback on the release strategy updates? See: https://github.com/openssl/web/pull/82 Since this is a policy change it will need an OMC vote. Proposed vote wording: "The release strategy should be updated as per commit 8166924606 in https://github.com/openssl/web/pull/82" Matt From matt at openssl.org Wed Feb 13 10:53:31 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 Feb 2019 10:53:31 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <6d3244da-9c5c-ba58-9ba2-56cbc3b1e7fa@openssl.org> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> <20190206231100.GA31488@roeckx.be> <6d3244da-9c5c-ba58-9ba2-56cbc3b1e7fa@openssl.org> Message-ID: <206b159f-1fda-f282-bb6d-3417edcade12@openssl.org> On 12/02/2019 10:08, Matt Caswell wrote: > > > On 07/02/2019 15:03, Matt Caswell wrote: >> That would make the proposed vote text for this OMC vote: >> >> "master and 1.1.1 will be updated so that they do not signal the start and end >> of post-handshake message exchanges in the info callback using >> SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_DONE." > > I started this vote and will report back on the results in due course. This vote passed: +1: 5 0: 2 -1: 0 Matt From matt at openssl.org Wed Feb 13 11:26:05 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 Feb 2019 11:26:05 +0000 Subject: [openssl-project] OpenSSL 3.0 and FIPS Update Message-ID: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> Please see my blog post for an OpenSSL 3.0 and FIPS Update: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Matt From mcr at sandelman.ca Wed Feb 13 20:28:30 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 13 Feb 2019 15:28:30 -0500 Subject: [openssl-project] OpenSSL 3.0 and FIPS Update In-Reply-To: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> References: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> Message-ID: <2274.1550089710@localhost> Matt Caswell wrote: > Please see my blog post for an OpenSSL 3.0 and FIPS Update: > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Thank you, it is very useful to have these plans made up front. I think your posts should probably explain what happened to 2.x, and if this represents a move towards semantic versioning. (I think it does...?) In the various things linked, in particular: https://www.openssl.org/docs/OpenSSL300Design.html I think that there is a missing box. Specifically, the PERL API wrappers that are used in the test bench. I believe that the "applications" are a serious problem as there are (in 1.1.1) still many things that are very difficult (sometimes, it seems, impossible) to do programmatically, and which the test cases actually simply shell out to the application to do. An example of this is adding certain extensions to a certificate when generating it, which is only really possible by loading pieces of configuration file in. So what I'd like to see is to remove many of the applications from the core of OpenSSL, put them into a seperate package using better-documented API calls. Let them evolve according their own time-scale, probably taking patches faster without disrupting the underlying libraries. My observation is that the Perl testing system is used to drive the tests, but the tests do not actually use the Perl API wrapper for OpenSSL, but rather rely on the vast number of .c files in test/*. In other (more purely agile) projects, the test cases often serve as documentation as to how to use the API. In OpenSSL, the test cases rely too much on the openssl "applications", and the API is hidden. This would involve adopting some or all of Net::SSLeay. While there would be some initial duplication of effort, I think that over time it would sort itself out. Perl is no longer as cool as it used to be (I still like it) and maybe someone would argue for Python3 or something, and frankly I don't care which. What I care about is that the test cases actually test the API, rather than depend upon 20 years of twisty code in the "applications". And that the applications are permitted to grow/change/adapt to people's needs, rather than living in a hard spot between developer needs and end user needs, pissing off both groups. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matt at openssl.org Thu Feb 14 14:20:59 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 14 Feb 2019 14:20:59 +0000 Subject: [openssl-project] Updates to the release strategy In-Reply-To: <6e74f90b-0a7b-f7df-58d4-62305ffb0670@openssl.org> References: <6e74f90b-0a7b-f7df-58d4-62305ffb0670@openssl.org> Message-ID: On 12/02/2019 10:54, Matt Caswell wrote: > Is there any more feedback on the release strategy updates? See: > > https://github.com/openssl/web/pull/82 > > Since this is a policy change it will need an OMC vote. Proposed vote wording: > > "The release strategy should be updated as per commit 8166924606 in > https://github.com/openssl/web/pull/82" > I have now started the above vote (with the commit id updated to 034fe56f250). I'll report back when it is complete. Matt From kaduk at mit.edu Thu Feb 14 17:07:11 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Thu, 14 Feb 2019 11:07:11 -0600 Subject: [openssl-project] OpenSSL 3.0 and FIPS Update In-Reply-To: <2274.1550089710@localhost> References: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> <2274.1550089710@localhost> Message-ID: <20190214170711.GL56447@kduck.mit.edu> On Wed, Feb 13, 2019 at 03:28:30PM -0500, Michael Richardson wrote: > > Matt Caswell wrote: > > Please see my blog post for an OpenSSL 3.0 and FIPS Update: > > > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ > > Thank you, it is very useful to have these plans made up front. > I think your posts should probably explain what happened to 2.x, and if this > represents a move towards semantic versioning. (I think it does...?) > > In the various things linked, in particular: > https://www.openssl.org/docs/OpenSSL300Design.html > > I think that there is a missing box. Specifically, the PERL API wrappers Later on you seem to clarify that by "PERL API" you mean "Net::SSLeay" but I just want to double-check. > that are used in the test bench. I believe that the "applications" are > a serious problem as there are (in 1.1.1) still many things that are very > difficult (sometimes, it seems, impossible) to do programmatically, and which > the test cases actually simply shell out to the application to do. > An example of this is adding certain extensions to a certificate when > generating it, which is only really possible by loading pieces of > configuration file in. It might we worth raising github issues to point out these omissions. > So what I'd like to see is to remove many of the applications from the core > of OpenSSL, put them into a seperate package using better-documented API > calls. Let them evolve according their own time-scale, probably taking > patches faster without disrupting the underlying libraries. In the vein of your later comment about "20 years of twisty code", I'm actually somewhat inclined to clave off the applications and leave them alone, so that people needing bug-for-bug compatibility can keep it. Then we could rewrite the functionality in question with a more maintainable structure in a way that would also function as examplar API usage. > My observation is that the Perl testing system is used to drive the tests, > but the tests do not actually use the Perl API wrapper for OpenSSL, but > rather rely on the vast number of .c files in test/*. > In other (more purely agile) projects, the test cases often serve as > documentation as to how to use the API. In OpenSSL, the test cases > rely too much on the openssl "applications", and the API is hidden. So, when I write new code that requires tests (which is basically all new code, try as I may to convince myself otherwise), the first thing I try to do is put in an API-only test that's a "standalone" executable (ignore sslapitest.c which is not standalone but functionally is so) to exercise narrowly the functionality in question. Only if it's a big hassle, requires additional (certificate) input and/or configuration files, etc., do I fail over to using the "application" as the testbed. There's a tradeoff, and while the current playing field often biases that tradeoff in a direction I'd rather not go, changing the playing field is more work than I have time to take on while a sitting IETF AD. > This would involve adopting some or all of Net::SSLeay. > While there would be some initial duplication of effort, I think that over > time it would sort itself out. Perl is no longer as cool as it used to be (I > still like it) and maybe someone would argue for Python3 or something, and > frankly I don't care which. I don't think that OpenSSL itself should adopt Net::SSLeay, even though we do seem to have one of the higher perl usage fractions of the open-source projects I interact with. We have enough on our hands with the core C libraries to modernize. > What I care about is that the test cases actually test the API, rather than > depend upon 20 years of twisty code in the "applications". > And that the applications are permitted to grow/change/adapt to people's > needs, rather than living in a hard spot between developer needs and end > user needs, pissing off both groups. I agree that mixing user needs and developer needs is a recipe for sadness. I'm not sure that actually tearing them apart from the current "apps" is something that we can realistically do while preserving our goal of cross-release stability. -Ben From Zeke.Evans at microfocus.com Thu Feb 14 16:26:50 2019 From: Zeke.Evans at microfocus.com (Zeke Evans) Date: Thu, 14 Feb 2019 16:26:50 +0000 Subject: [openssl-project] OpenSSL 3.0 and FIPS Update In-Reply-To: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> References: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> Message-ID: Can you give any guidance on which platforms will be validated with the OpenSSL FIPS 3.0 module? My recollection is that it will only be a handful of platforms. It would be helpful to have an idea which platforms will and will not be included. Any additional information about how other platforms can be validated would also be helpful. Thanks, Zeke Evans Senior Software Engineer, Micro Focus ________________________________ From: openssl-project on behalf of Matt Caswell Sent: Wednesday, February 13, 2019 4:26 AM To: openssl-announce at openssl.org; openssl-users at openssl.org; openssl-project at openssl.org Subject: [openssl-project] OpenSSL 3.0 and FIPS Update Please see my blog post for an OpenSSL 3.0 and FIPS Update: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Matt _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Feb 14 17:39:41 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 14 Feb 2019 17:39:41 +0000 Subject: [openssl-project] OpenSSL 3.0 and FIPS Update In-Reply-To: References: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> Message-ID: On 14/02/2019 16:26, Zeke Evans wrote: > Can you give any guidance on which platforms will be validated with the OpenSSL > FIPS 3.0 module?? My recollection is that it will only be a handful of > platforms.? It would be helpful to have an idea which platforms will and will > not be included.? Any additional information about how other platforms can be > validated would also be helpful. We haven't yet published the list of platforms that we will be validating. It will at least include a Linux based platform and a Windows based one as well as several others. We won't be offering the service to add new platforms onto our own certificate, but you should be able perform your own validation for your own platforms based on ours (I forget the correct FIPS term for this...perhaps someone more FIPSy than I am can chip in). Matt > > Thanks, > Zeke Evans > Senior Software Engineer, Micro Focus > > -------------------------------------------------------------------------------- > *From:* openssl-project on behalf of Matt > Caswell > *Sent:* Wednesday, February 13, 2019 4:26 AM > *To:* openssl-announce at openssl.org; openssl-users at openssl.org; > openssl-project at openssl.org > *Subject:* [openssl-project] OpenSSL 3.0 and FIPS Update > ? > Please see my blog post for an OpenSSL 3.0 and FIPS Update: > > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ > > Matt > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From rsalz at akamai.com Thu Feb 14 18:35:06 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Feb 2019 18:35:06 +0000 Subject: [openssl-project] OpenSSL 3.0 and FIPS Update In-Reply-To: References: <2c9fe037-9817-ba6f-1062-1d574264318a@openssl.org> Message-ID: <446F5F52-BC72-4288-BFBE-D83537E66591@akamai.com> > We won't be offering the service to add new platforms onto our own certificate, but you should be able perform your own validation for your own platforms based on ours (I forget the correct FIPS term for this...perhaps someone more FIPSy than I am can chip in). Vendor-affirmed. If you follow the documented build procedure exactly, you can claim FIPS validation. From levitte at openssl.org Fri Feb 15 16:16:56 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 15 Feb 2019 17:16:56 +0100 Subject: Undecorating postings Message-ID: <87o97dni13.wl-levitte@openssl.org> Hi all, because we seem to get a lot of bounces possibly due to DKIM signature breakage, we've removed the subject tag and the added mail body footer, and stopped munging Reply-To: If anyone filtered these emails based on the subject tag, you will have to change your filter. I suggest looking at the List-Id: header instead. Cheers, Richard ( role: postmaster ) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Sun Feb 17 22:18:08 2019 From: paul.dale at oracle.com (Paul Dale) Date: Sun, 17 Feb 2019 14:18:08 -0800 (PST) Subject: Thoughts about library contexts Message-ID: <98483b88-d481-4092-b1b0-75cc07a80579@default> Library contexts are going to allow us to separate different portions of the TLS/cryptographic activity within one application. No problems, here. This seems like a useful and worthwhile idea. It will e.g. be a way to separate FIPS and non-FIPS streams nicely. I've a reservation about the current definition. Why must they be opaque? I'm not suggesting that complete visible is a good idea, but partial visibility over some areas of the core would be useful. E.g. the core components ought to be able to access other core components without diving through an indirection scheme. What level of isolation do we want between different contexts? We're unlikely to be able to completely segregate them but should we make an effort to reduce information leakage between them? E.g. the current properties has a couple of global databases that will be shared across all contexts - would they make better sense being one per context? There would be a space cost, a reduction in the cache efficiency, . but it would add to segregation. Enclaves could also assist. Thoughts anyone? Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Feb 18 09:27:00 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 18 Feb 2019 10:27:00 +0100 Subject: Thoughts about library contexts In-Reply-To: <98483b88-d481-4092-b1b0-75cc07a80579@default> References: <98483b88-d481-4092-b1b0-75cc07a80579@default> Message-ID: <87ftslo3a3.wl-levitte@openssl.org> On Sun, 17 Feb 2019 23:18:08 +0100, Paul Dale wrote: > Library contexts are going to allow us to separate different portions of the TLS/cryptographic > activity within one application. No problems, here. This seems like a useful and worthwhile > idea. It will e.g. be a way to separate FIPS and non-FIPS streams nicely. > > I?ve a reservation about the current definition. Why must they be opaque? I?m not suggesting > that complete visible is a good idea, but partial visibility over some areas of the core would be > useful. E.g. the core components ought to be able to access other core components without diving > through an indirection scheme. I'm not sure I understand... Are you saying that you want OPENSSL_CTX to be non-opaque? What for? The current implementation is basically as a bag of "things", where the exact "thing" is identified with an index. The rest is defined by every sub-system that wants to store "things" in a library context, i.e. they must get themselves an index for each type of "thing", and then they simply get it from the library context. Do you need to know exactly how the bag of "things" is organized? The diverse sub-system structures may be opaque or non-opaque as they see fit, of course. > What level of isolation do we want between different contexts? We?re unlikely to be able to > completely segregate them but should we make an effort to reduce information leakage between them? > E.g. the current properties has a couple of global databases that will be shared across all > contexts ? would they make better sense being one per context? There would be a space cost, a > reduction in the cache efficiency, ? but it would add to segregation. Enclaves could also assist. You're talking about the property string cache... yeah, I see no real reason to store them away in a library context, it's not really like we'd gain anything by having several of them with potentially the exact same information. So yeah, we do need to think about what stuff should go into the library context and what shouldn't. (I think Rich has voiced the opinion that error stacks and error string tables shouldn't be tied to a library context, and for the moment, I agree with that view) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From mcr at sandelman.ca Mon Feb 18 01:38:00 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 17 Feb 2019 20:38:00 -0500 Subject: Thoughts about library contexts In-Reply-To: <98483b88-d481-4092-b1b0-75cc07a80579@default> References: <98483b88-d481-4092-b1b0-75cc07a80579@default> Message-ID: <13196.1550453880@localhost> Paul Dale wrote: > Library contexts are going to allow us to separate different portions of the > TLS/cryptographic activity within one application. No problems, here. This > seems like a useful and worthwhile idea. It will e.g. be a way to separate > FIPS and non-FIPS streams nicely. > I?ve a reservation about the current definition. Why must they be opaque? I?m > not suggesting that complete visible is a good idea, but partial visibility > over some areas of the core would be useful. E.g. the core components ought > to be able to access other core components without diving through an > indirection scheme. If by opaque, you mean that the C "struct" definition is not visible to the application, then that's required so that we can maintain ABI across changes to the structure. > What level of isolation do we want between different contexts? We?re unlikely > to be able to completely segregate them but should we make an effort to > reduce information leakage between them? E.g. the current properties has a > couple of global databases that will be shared across all contexts ? would > they make better sense being one per context? There would be a space cost, a > reduction in the cache efficiency, ? but it would add to segregation. > Enclaves could also assist. > Thoughts anyone? > Pauli > -- > Oracle > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matt at openssl.org Mon Feb 18 10:17:45 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 18 Feb 2019 10:17:45 +0000 Subject: Thoughts about library contexts In-Reply-To: <13196.1550453880@localhost> References: <98483b88-d481-4092-b1b0-75cc07a80579@default> <13196.1550453880@localhost> Message-ID: <540d6f25-5215-5d65-6d07-418c9f637216@openssl.org> On 18/02/2019 01:38, Michael Richardson wrote: > > Paul Dale wrote: > > Library contexts are going to allow us to separate different portions of the > > TLS/cryptographic activity within one application. No problems, here. This > > seems like a useful and worthwhile idea. It will e.g. be a way to separate > > FIPS and non-FIPS streams nicely. > > > I?ve a reservation about the current definition. Why must they be opaque? I?m > > not suggesting that complete visible is a good idea, but partial visibility > > over some areas of the core would be useful. E.g. the core components ought > > to be able to access other core components without diving through an > > indirection scheme. > > If by opaque, you mean that the C "struct" definition is not visible to the > application, then that's required so that we can maintain ABI across changes > to the structure. I think Paul is specifically referring to the new OPENSSL_CTX structure which is opaque even internally (i.e. it it's only transparent to the OPENSSL_CTX code itself). At the moment OPENSSL_CTX is implemented using CRYPTO_EX_DATA. An alternative implementation approach would be that the struct is internally transparent and is just a bucket of stuff (without using CRYPTO_EX at all). I guess the reason for doing so would be performance (to reduce the indirection of going via CRYPTO_EX). Matt > > > What level of isolation do we want between different contexts? We?re unlikely > > to be able to completely segregate them but should we make an effort to > > reduce information leakage between them? E.g. the current properties has a > > couple of global databases that will be shared across all contexts ? would > > they make better sense being one per context? There would be a space cost, a > > reduction in the cache efficiency, ? but it would add to segregation. > > Enclaves could also assist. > > > Thoughts anyone? > > > Pauli > > > -- > > > Oracle > > > Dr Paul Dale | Cryptographer | Network Security & Encryption > > > Phone +61 7 3031 7217 > > > Oracle Australia > > > > > ---------------------------------------------------- > > Alternatives: > > > ---------------------------------------------------- > From tjh at cryptsoft.com Mon Feb 18 10:28:31 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Mon, 18 Feb 2019 20:28:31 +1000 Subject: Thoughts about library contexts In-Reply-To: <540d6f25-5215-5d65-6d07-418c9f637216@openssl.org> References: <98483b88-d481-4092-b1b0-75cc07a80579@default> <13196.1550453880@localhost> <540d6f25-5215-5d65-6d07-418c9f637216@openssl.org> Message-ID: It should remain completely opaque. As a general rule, I've never seen a context where someone regretted making a structure opaque over time, but the converse is not true. This is opaque and should remain opaque. We need the flexibility to adjust the implementation at will over time. For anything where partial visibility is seen as desirable, it should be raised specifically as to what issue would drive that - as frankly I don't see a context where that would make sense. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Feb 18 10:36:16 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 18 Feb 2019 10:36:16 +0000 Subject: Thoughts about library contexts In-Reply-To: References: <98483b88-d481-4092-b1b0-75cc07a80579@default> <13196.1550453880@localhost> <540d6f25-5215-5d65-6d07-418c9f637216@openssl.org> Message-ID: <977353be-5ba5-7d6d-2630-b70bcd7ae4fa@openssl.org> On 18/02/2019 10:28, Tim Hudson wrote: > It should remain completely opaque. > As a general rule, I've never seen a context where someone regretted making a > structure opaque over time, but the converse is not true. > This is opaque and should remain opaque. > We need the flexibility to adjust the implementation at will over time. I think we're debating whether it is internally opaque or not. Externally opaque is a given IMO. Matt > > For anything where partial visibility is seen as desirable, it should be raised > specifically as to what issue would drive that - as frankly I don't see a > context where that would make sense. > > Tim. From tjh at cryptsoft.com Mon Feb 18 11:04:32 2019 From: tjh at cryptsoft.com (Tim Hudson) Date: Mon, 18 Feb 2019 21:04:32 +1000 Subject: Thoughts about library contexts In-Reply-To: <977353be-5ba5-7d6d-2630-b70bcd7ae4fa@openssl.org> References: <98483b88-d481-4092-b1b0-75cc07a80579@default> <13196.1550453880@localhost> <540d6f25-5215-5d65-6d07-418c9f637216@openssl.org> <977353be-5ba5-7d6d-2630-b70bcd7ae4fa@openssl.org> Message-ID: On Mon, Feb 18, 2019 at 8:36 PM Matt Caswell wrote: > > > On 18/02/2019 10:28, Tim Hudson wrote: > > It should remain completely opaque. > > As a general rule, I've never seen a context where someone regretted > making a > > structure opaque over time, but the converse is not true. > > This is opaque and should remain opaque. > > We need the flexibility to adjust the implementation at will over time. > > I think we're debating whether it is internally opaque or not. Externally > opaque > is a given IMO. > And my comments apply to internally opaque too - I was aware of that context when I wrote them - this is something that we will want to change as it evolves over time. And we shouldn't have a pile of knowledge of the internals of one part of the library spreading over the other parts. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Feb 18 12:16:18 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 18 Feb 2019 13:16:18 +0100 Subject: Thoughts about library contexts In-Reply-To: <540d6f25-5215-5d65-6d07-418c9f637216@openssl.org> References: <98483b88-d481-4092-b1b0-75cc07a80579@default> <13196.1550453880@localhost> <540d6f25-5215-5d65-6d07-418c9f637216@openssl.org> Message-ID: <875zthnvfx.wl-levitte@openssl.org> On Mon, 18 Feb 2019 11:17:45 +0100, Matt Caswell wrote: > At the moment OPENSSL_CTX is implemented using CRYPTO_EX_DATA. An alternative > implementation approach would be that the struct is internally transparent and > is just a bucket of stuff (without using CRYPTO_EX at all). I guess the reason > for doing so would be performance (to reduce the indirection of going via > CRYPTO_EX). The central idea here is that OPENSSL_CTX is a bag of "stuff" and that each sub-system should decide on their own what its "stuff" is. Of course, the bag could have been made like a structure with specific pointers for each sub-system that wants to store something, but I find that approach a bit messy, as the sub-systems become less self contained, and also have less control over their own "stuff". For example, if there's a need for a lock to retrieve some data, does everyone else have to learn to use that lock, and what happens if someone forgets, i.e. how error prone can it become? As an alternative, if the sub-system defines its own internal API for access of stuff, that does all the needed locking, why does everyone else need to know exactly how it's stored in the library context? The reason why I chose CRYPTO_EX_DATA for internal storage? I was actually about to implement a generic "bag", when I realised that we already have that in CRYPTO_EX_DATA. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Feb 19 16:10:20 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 Feb 2019 16:10:20 +0000 Subject: Forthcoming OpenSSL Releases Message-ID: <9b5740f6-0f40-0adf-3b60-beda7707edb3@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1b and 1.0.2r. There will be no new 1.1.0 release at this time. These releases will be made available on 26th February 2019 between approximately 1300-1700 UTC. OpenSSL 1.0.2r is a security-fix release. The highest severity issue fixed in this release is MODERATE: https://www.openssl.org/policies/secpolicy.html#moderate OpenSSL 1.1.1b is a bug-fix release. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Matthias.St.Pierre at ncp-e.com Fri Feb 22 10:28:35 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Fri, 22 Feb 2019 11:28:35 +0100 Subject: C source file naming conventions Message-ID: <4012c51c-c00f-1fcb-2bf7-3b1a86f910d6@ncp-e.com> Hi, there has been some discussion going on between Richard and me about the new naming style he introduced in pull request #8287. It would be nice to get some independent opinions from the team. Regards, Matthias See https://github.com/openssl/openssl/pull/8287#pullrequestreview-206706986 and ff. From matt at openssl.org Mon Feb 25 16:14:47 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 25 Feb 2019 16:14:47 +0000 Subject: [openssl-project] Updates to the release strategy In-Reply-To: References: <6e74f90b-0a7b-f7df-58d4-62305ffb0670@openssl.org> Message-ID: <4af5d5a6-8126-96d6-0b7b-0b8f1c51524d@openssl.org> On 14/02/2019 14:20, Matt Caswell wrote: > > > On 12/02/2019 10:54, Matt Caswell wrote: >> Is there any more feedback on the release strategy updates? See: >> >> https://github.com/openssl/web/pull/82 >> >> Since this is a policy change it will need an OMC vote. Proposed vote wording: >> >> "The release strategy should be updated as per commit 8166924606 in >> https://github.com/openssl/web/pull/82" >> > > I have now started the above vote (with the commit id updated to 034fe56f250). > I'll report back when it is complete. This vote passed: +1: 7 0: 0 -1: 0 Matt From matt at openssl.org Mon Feb 25 18:41:16 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 25 Feb 2019 18:41:16 +0000 Subject: Repo frozen Message-ID: <16b0a12a-538e-0599-ad39-a6a1f1d46d0a@openssl.org> All The repo has been frozen in preparation for tomorrow's release. I'll let you all know when it is available for pushes again. Matt From openssl at openssl.org Tue Feb 26 14:54:20 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 26 Feb 2019 14:54:20 +0000 Subject: OpenSSL version 1.0.2r published Message-ID: <20190226145420.GA1729@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.0.2r released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2r of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2r is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2r.tar.gz Size: 5348369 SHA1 checksum: b9aec1fa5cedcfa433aed37c8fe06b0ab0ce748d SHA256 checksum: ae51d08bba8a83958e894946f15303ff894d75c2b8bbd44a852b64e3fe11d0d6 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2r.tar.gz openssl sha256 openssl-1.0.2r.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx1S0oACgkQ2cTSbQ5g RJH9UQf9Gi2WrDyOwxtlu84f7vlcQX1zfG+Fs10OZgYi6rvD6VprJJewsWaJI9S+ O5LDv0p1aCFNgcTc57oNZCb+Or8xWdhvTOc5cNa408nFVK4wVazTdzKRFLECZEL4 E0vs22XNEIhrPHuHAJnuYaP12232Wymn9VHSbWeNl2ZR7Vj64rJ8Lqp8w+YpBU5+ eGidbLSKC29r8VV/6/9ei8PUSGEpy6ci8Tp+oMn6iVgMx6fuAnVDWDL32kWbzdAB r/OUee06D+QQFQMAJGAiDRxbC4XuNaLCiysr8a7QoltsxJjCaq7H9zRlArv3iE27 /fuwegvHE+upW2k3J1ZCL/Dlq+MuxA== =MwGd -----END PGP SIGNATURE----- From openssl at openssl.org Tue Feb 26 14:54:38 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 26 Feb 2019 14:54:38 +0000 Subject: OpenSSL version 1.1.1b published Message-ID: <20190226145438.GA1980@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1b released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1b of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1b is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1b.tar.gz Size: 8213737 SHA1 checksum: e9710abf5e95c48ebf47991b10cbb48c09dae102 SHA256 checksum: 5c557b023230413dfb0756f3137a13e6d726838ccd1430888ad15bfb2b43ea4b The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1b.tar.gz openssl sha256 openssl-1.1.1b.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx1SgkACgkQ2cTSbQ5g RJEc5QgAoB+R93O6fi3QBaLM6zcZQWcq0y/c2fEo+tybClP4DfUudJij5cjlfzfN W0srK+qq15PJPxbH02fUcUdIBHF5OdQv0XMIS5ueN1clvGTcvpqdmyvE7INqouFd xUGbRzNw8hN4BY/skamuc1uxMXQUFx4ek2W12q4D/oCSOuPrS411uSev3pACLyK8 Bchcs/TLSreaz46ckRC+fiQ9jgBKjcA5q4pC/kIn+KGrfoRZz+no4cQlZS84NFgN BbT4bn9mV1+f1PksSlBZ6r+YSeaFrXP/e0sfTuMGYiXUx+XPQ+uMHjiljAGuYYz3 Nr2GqL9nHLvJ5xMBJmJCes4zkd0J9g== =Wh0M -----END PGP SIGNATURE----- From openssl at openssl.org Tue Feb 26 14:59:17 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 26 Feb 2019 14:59:17 +0000 Subject: OpenSSL Security Advisory Message-ID: <20190226145917.GA5404@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [26 February 2019] ============================================ 0-byte record padding oracle (CVE-2019-1559) ============================================ Severity: Moderate If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). This issue does not impact OpenSSL 1.1.1 or 1.1.0. OpenSSL 1.0.2 users should upgrade to 1.0.2r. This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod Aviram, with additional investigation by Steven Collison and Andrew Hourselt. It was reported to OpenSSL on 10th December 2018. Note ==== OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end on 11th September 2019. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20190226.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----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx1U+gACgkQ2cTSbQ5g RJFnlAf/U9yZtCz59BjgD0Kh7Eya5KxlmUWItdBu1r3DwbY4KDgL/Wwh4UxG3Qim D7Ht5Xsta4iAywrMRI/iPEdEQct8pcpWjq4/65lEbTYjToEnNWhIeWHH/Lw3Jfza gcVpIfbWoWc7OL7U4uPQuGWcb/PO8fJXF+HcCdZ+kIuut0peMSgN5sK/wBnmSdsM +sJXCei+jwVy/9WvCBMOooX7D8oerJ6NX12n2cNAYH/K7e2deiPZ7D/HB7T9MSv/ BgOi1UqFzBxcsNhFpY5NMTHG8pl0bmS0OiZ9bThN0YHwxFVJz6ZsVX/L5cYOAbm/ mJAdDE24XMmUAOlVZrROzCZKXADx/A== =8h8L -----END PGP SIGNATURE----- From matt at openssl.org Tue Feb 26 15:04:43 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 26 Feb 2019 15:04:43 +0000 Subject: Repo frozen In-Reply-To: <16b0a12a-538e-0599-ad39-a6a1f1d46d0a@openssl.org> References: <16b0a12a-538e-0599-ad39-a6a1f1d46d0a@openssl.org> Message-ID: On 25/02/2019 18:41, Matt Caswell wrote: > All > > The repo has been frozen in preparation for tomorrow's release. I'll let you all > know when it is available for pushes again. The release is done and I have unfrozen the repo. Thanks to Richard for his support during the release. Matt From tjh at openssl.org Tue Feb 26 23:35:15 2019 From: tjh at openssl.org (Tim Hudson) Date: Wed, 27 Feb 2019 09:35:15 +1000 Subject: Fwd: openssl-announce post from hongcho@gmail.com requires approval In-Reply-To: References: Message-ID: Add a -r to your diff command so you recursively compare ... then you will see the actual code changes. Without the -r you are only comparing files in the top-level directory of each tree. diff *-r* -dup openssl-1.0.2q openssl-1.0.2r Tim. ---------- Forwarded message ---------- From: Hong Cho To: openssl at openssl.org, openssl-project at openssl.org Cc: OpenSSL User Support ML , OpenSSL Announce ML Bcc: Date: Wed, 27 Feb 2019 08:28:17 +0900 Subject: Re: [openssl-project] OpenSSL version 1.0.2q published I see no code change between 1.0.2q and 1.0.2r. ------ # diff -dup openssl-1.0.2q openssl-1.0.2r |& grep '^diff' | awk '{print $4}' openssl-1.0.2r/CHANGES openssl-1.0.2r/Makefile openssl-1.0.2r/Makefile.org openssl-1.0.2r/NEWS openssl-1.0.2r/README openssl-1.0.2r/openssl.spec hongch at hongch_bldx:~/downloads> diff -dup openssl-1.0.2q openssl-1.0.2r | & grep '^Only' Only in openssl-1.0.2q: Makefile.bak ------ It's supposed have a fix for CVE-2019-1559? Am I missing something? Hong. -------------- next part -------------- An HTML attachment was scrubbed... URL: