From matt at openssl.org Thu Aug 2 11:01:22 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Aug 2018 12:01:22 +0100 Subject: [openssl-project] 1.1.1 Release criteria update Message-ID: A quick update on the status of the 1.1.1 release criteria: - All open github issues/PRs older than 2 weeks at the time of release to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone to be closed Status: We have 5 open issues (4 of which were opened within the last 2 weeks). The most significant one is the PSK reuse issue. If we decide to make a change then there is a PR there ready and waiting. All we really need to do is decide whether to make that change or not. We've been waiting on the TLS WG to make its mind up on what advice it's going to put into the RFC on this. We also need to make a decision on what we will do about the TLSv1.3 downgrade protection issue (with "do nothing" a possibility). We also have 5 open PRs. One of these is blocked on the publication of the RFC, and another is blocked on a decision being made on PSK reuse. The other 3 are all in active development and I expect to see them merged or closed very soon. Only the PR blocked on the RFC publication is older than 2 weeks. - Clean builds in Travis and Appveyor for two days Status: Both Travis and Appveyor are currently green - run-checker.sh to be showing as clean 2 days before release Status: There has been one recent issue, but that should have been fixed yesterday. I've not seen any run-checker reports since then. - No open Coverity issues (not flagged as "False Positive" or "Ignore") Status: There are no open issues not flagged as ignore - TLSv1.3 RFC published (with at least one beta release after the publicaction) Status: The RFC has been imminent for a long time. The latest smoke signals indicate that it is now imminently imminent :-) My summary is that I think we are in a good place for the 1.1.1 release. Once the PSK wording in the RFC is decided we should seek to make a decision on the PSK reuse issue quickly. With that resolved and the RFC published we should be able to get another beta release out quickly afterwards. Assuming there are no significant issues raised during that beta cycle I am hopeful we can get the 1.1.1 release out the door 2 weeks or so later. Matt From matt at openssl.org Fri Aug 3 10:02:06 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Aug 2018 11:02:06 +0100 Subject: [openssl-project] Monthly Status Report (July) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Attended a number of meetings re FIPS - Fixed a bug in 1.1.0/1.0.2 which can result in an invalid CertificateRequest message being sent - Reviewed lots of issues with respect to the 1.1.1 milestone - Fixed no_tls1_2, no-psk - Implemented changes to avoid GOST sigalg usage in TLSv1.3 - Fixed some issues found by Coverity - Implemented changes so that unexpected early data is tolerated (skipped) by default - Improved consistency between 1.1.0 and 1.1.1 in s_server where a PSK identity doesn't match - Updated run-checker to run a GOST test - Investigated problems on android with pthread_atfork - Fixed some TLSv1.3 session issues - Fixed a mem leak in the ticket test - Ensured that we skip the GOST test when DSA or CMS or disabled (because GOST requires those symbols) - Implemented stricter checking of key OIDs against the sig alg - Fixed a bug where we incorrectly skipped over early_data sent after an HRR - Updated the early data documentation to describe some scenarios where the connection could abort - Prepared the PR for updated the TLSv1.3 code to the final RFC version - Updated the TLSv1.3 test vectors to match those in the latest test vectors document - Added validation of the legacy_version field for TLSv1.3 - Implemented a fix allowing both prime and binary curves in SM2. This later changed into a more generic fix that removed some prime/binary curve specific functions in preference for generic ones - Removed testing of no-md5 from run-checker since it is not a valid option - Fixed some TLSv1.3 alert issues A slightly shorter list this month due to holidays. Matt From rsalz at akamai.com Fri Aug 3 18:40:45 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Aug 2018 18:40:45 +0000 Subject: [openssl-project] Vote notice Message-ID: We discussed and are now voting on removing some of the support options listed on our website. FYI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 7 14:09:19 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Aug 2018 15:09:19 +0100 Subject: [openssl-project] Forthcoming OpenSSL releases Message-ID: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.0i and 1.0.2p. These releases will be made available on 14th August 2018 between approximately 1200-1600 UTC. These are bug-fix releases. They also contain the fixes for two LOW severity security issues (CVE-2018-0732 and CVE-2018-0737) which were previously announced here: https://www.openssl.org/news/secadv/20180612.txt https://www.openssl.org/news/secadv/20180416.txt 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 appro at openssl.org Tue Aug 7 14:15:52 2018 From: appro at openssl.org (Andy Polyakov) Date: Tue, 7 Aug 2018 16:15:52 +0200 Subject: [openssl-project] Forthcoming OpenSSL releases In-Reply-To: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> References: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> Message-ID: <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> > Forthcoming OpenSSL releases > ============================ I have some RSA hardening fixes in pipeline... From matt at openssl.org Tue Aug 7 14:16:54 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Aug 2018 15:16:54 +0100 Subject: [openssl-project] Forthcoming OpenSSL releases In-Reply-To: <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> References: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> Message-ID: On 07/08/18 15:15, Andy Polyakov wrote: >> Forthcoming OpenSSL releases >> ============================ > > I have some RSA hardening fixes in pipeline... Do you have PR numbers for them? Matt > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From appro at openssl.org Tue Aug 7 14:31:09 2018 From: appro at openssl.org (Andy Polyakov) Date: Tue, 7 Aug 2018 16:31:09 +0200 Subject: [openssl-project] Forthcoming OpenSSL releases In-Reply-To: References: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> Message-ID: >>> Forthcoming OpenSSL releases >>> ============================ >> >> I have some RSA hardening fixes in pipeline... > > Do you have PR numbers for them? "in pipeline" kind of means "not yet [but I'll intensify the work to put them out]". In other words it's a pre-heads-up thing... From kurt at roeckx.be Tue Aug 7 14:44:21 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 7 Aug 2018 16:44:21 +0200 Subject: [openssl-project] Forthcoming OpenSSL releases In-Reply-To: <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> References: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> Message-ID: <20180807144420.GA26225@roeckx.be> On Tue, Aug 07, 2018 at 04:15:52PM +0200, Andy Polyakov wrote: > > Forthcoming OpenSSL releases > > ============================ > > I have some RSA hardening fixes in pipeline... Do you suggest we wait with a release on that, or can we just put it in the next release? Kurt From appro at openssl.org Tue Aug 7 14:52:28 2018 From: appro at openssl.org (Andy Polyakov) Date: Tue, 7 Aug 2018 16:52:28 +0200 Subject: [openssl-project] Forthcoming OpenSSL releases In-Reply-To: <20180807144420.GA26225@roeckx.be> References: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> <20180807144420.GA26225@roeckx.be> Message-ID: <21222dfe-5d7a-2702-b2bf-021bdc7d6881@openssl.org> >>> Forthcoming OpenSSL releases >>> ============================ >> >> I have some RSA hardening fixes in pipeline... > > Do you suggest we wait with a release on that, or can we just put > it in the next release? I should be able to pull it off in before release. What I'm saying is that it would probably be appropriate to review them as they appear. From matt at openssl.org Wed Aug 8 10:08:14 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Aug 2018 11:08:14 +0100 Subject: [openssl-project] Removal of NULL checks Message-ID: We've had a policy for a while of not requiring NULL checks in functions. However there is a difference between not adding them for new functions and actively removing them for old ones. See https://github.com/openssl/openssl/pull/6893 In this case the removal of a NULL check in the stack code had the unintended consequence of a crash in a no-comp build. Is it wise to be actively removing existing NULL checks like this? It does have an impact on the behaviour of a function (even if that behaviour is undocumented and not encouraged). The concern I have is for our API/ABI compatibility guarantee. If we make changes like this then 1.1.1 may no longer be a drop in replacement for 1.1.0 for some apps. Matt From tjh at cryptsoft.com Wed Aug 8 10:19:24 2018 From: tjh at cryptsoft.com (Tim Hudson) Date: Wed, 8 Aug 2018 20:19:24 +1000 Subject: [openssl-project] Removal of NULL checks In-Reply-To: References: Message-ID: We don't have a formal policy of no NULL checks - we just have a few members that think we should have such a policy but it has never been voted on as we had sufficiently varying views for a consensus approach to not be possible. Personally I'm in favour of high-level APIs having NULL checks as it (in my experience) leads to less bogus error crash reports from users and simpler handling in error cleanup logic. Otherwise you end up writing a whole pile of if(x!=NULL) FOO_free(x); etc But it is a style issue. However in the context of removing such checks - that we should *not* be doing - the behaviour of the APIs in this area should not be changed outside of a major version increment - and even then I would not make the change either because it introduces changes which in themselves serve no real purpose - i.e. a style change can result in making a program that used to work fine crash in bad ways - and that we shouldn't be doing even across major version increments in my view. Tim. On Wed, Aug 8, 2018 at 8:08 PM, Matt Caswell wrote: > We've had a policy for a while of not requiring NULL checks in > functions. However there is a difference between not adding them for new > functions and actively removing them for old ones. > > See https://github.com/openssl/openssl/pull/6893 > > In this case the removal of a NULL check in the stack code had the > unintended consequence of a crash in a no-comp build. Is it wise to be > actively removing existing NULL checks like this? It does have an impact > on the behaviour of a function (even if that behaviour is undocumented > and not encouraged). The concern I have is for our API/ABI compatibility > guarantee. If we make changes like this then 1.1.1 may no longer be a > drop in replacement for 1.1.0 for some apps. > > 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 Wed Aug 8 10:28:11 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Aug 2018 11:28:11 +0100 Subject: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3 Message-ID: <2881167d-8450-f6c7-0109-4836a166b4d7@openssl.org> For the full background to this issue see: https://github.com/openssl/openssl/issues/6490 TL;DR summary: The TLSv1.2 and TLSv1.3 PSK mechanisms are quite different to each other. OpenSSL (along with at least GnuTLS maybe others) has implemented an upgrade path which enables the reuse of a TLSv1.2 PSK in TLSv1.3. This is not prohibited by the spec. David Benjamin has raised concerns about this due to key separation. Everything else in TLSv1.3 is provably secure - but this is not. The spec has been updated to add some words of warning about this. There seems to be two schools of thought on what to do about this: 1) We should seek to avoid this risk. As a fix we should disable TLSv1.3 if TLSv1.2 PSKs have been configured. We expect that at some later time the IETF will come up with a better answer and when that happens we can implement it then. A PR to do the removal is here: https://github.com/openssl/openssl/pull/6836 2) This is a theoretical risk - there might not actually be a problem at all, its just that we can't prove it. OTOH not upgrading to TLSv1.3 is definitely a bad thing, so we should just leave things as they are and accept the theoretical risk. I'll admit that I've been flip-flopping between the two approaches to this and there doesn't seem to be a clear consensus forming. How should we take this forward? Does it require an OMC vote? Matt From openssl-users at dukhovni.org Wed Aug 8 13:52:06 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Aug 2018 09:52:06 -0400 Subject: [openssl-project] Removal of NULL checks In-Reply-To: References: Message-ID: > On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote: > > However in the context of removing such checks - that we should not be doing - the behaviour of the APIs in this area should not be changed Should not be changed period. Even across major release boundaries. This is not an ABI compatibility issue, it is a source compatibility issue, and should avoided all the time. If we want to write a *new* function that skips the NULL checks it gets a new name. -- Viktor. From kurt at roeckx.be Wed Aug 8 17:26:20 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 8 Aug 2018 19:26:20 +0200 Subject: [openssl-project] Removal of NULL checks In-Reply-To: References: Message-ID: <20180808172619.GA11283@roeckx.be> On Wed, Aug 08, 2018 at 08:19:24PM +1000, Tim Hudson wrote: > We don't have a formal policy of no NULL checks - we just have a few > members that think we should have such a policy but it has never been voted > on as we had sufficiently varying views for a consensus approach to not be > possible. > > Personally I'm in favour of high-level APIs having NULL checks as it (in my > experience) leads to less bogus error crash reports from users and simpler > handling in error cleanup logic. > Otherwise you end up writing a whole pile of if(x!=NULL) FOO_free(x); etc I think at least Rich would not add checks for NULL in functions that don't expect to be called with NULL, but on the other hand moves the NULL check into the free() calls. But in that case, we also clearly document that it can be called with NULL. So it's at least not general that there shouldn't be a NULL check. Kurt From openssl-users at dukhovni.org Wed Aug 8 20:22:23 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 8 Aug 2018 16:22:23 -0400 Subject: [openssl-project] EdDSA and "default_md"? Message-ID: Don't know whether everyone here also reads openssl-users, so to recap, Robert Moskowitz reports considerable frustration as a result of "default_md = sha256" being incompatible with Ed25519 (and Ed448). He's working around this with "-md null" sprinkled about liberally, but it is not especially intutive. What should we do here? Perhaps we need a "default_md = default" that picks a sensible default for each key algorithm (sha256 typically, but "null" for EdDSA)? Or ignore "default_md" with EdDSA, or ??? -- Viktor. From matt at openssl.org Wed Aug 8 20:40:59 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Aug 2018 21:40:59 +0100 Subject: [openssl-project] EdDSA and "default_md"? In-Reply-To: References: Message-ID: <17adce77-d928-00f4-cb48-f86ac3f49414@openssl.org> On 08/08/18 21:22, Viktor Dukhovni wrote: > Don't know whether everyone here also reads openssl-users, so to recap, > Robert Moskowitz reports considerable frustration > as a result of "default_md = sha256" being incompatible with Ed25519 > (and Ed448). He's working around this with "-md null" sprinkled about > liberally, but it is not especially intutive. > > What should we do here? Perhaps we need a "default_md = default" that > picks a sensible default for each key algorithm (sha256 typically, > but "null" for EdDSA)? Or ignore "default_md" with EdDSA, or ??? > Probably we should just ignore default_md for EdDSA. Matt From paul.dale at oracle.com Wed Aug 8 23:58:06 2018 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 8 Aug 2018 16:58:06 -0700 (PDT) Subject: [openssl-project] Removal of NULL checks In-Reply-To: References: Message-ID: <413082f0-45b3-4bed-8503-c7ee732a0400@default> I'm firmly in the don't remove them camp too. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Viktor Dukhovni [mailto:openssl-users at dukhovni.org] Sent: Wednesday, 8 August 2018 11:52 PM To: openssl-project at openssl.org Subject: Re: [openssl-project] Removal of NULL checks > On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote: > > However in the context of removing such checks - that we should not be > doing - the behaviour of the APIs in this area should not be changed Should not be changed period. Even across major release boundaries. This is not an ABI compatibility issue, it is a source compatibility issue, and should avoided all the time. If we want to write a *new* function that skips the NULL checks it gets a new name. -- Viktor. _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From matt at openssl.org Thu Aug 9 09:31:20 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 9 Aug 2018 10:31:20 +0100 Subject: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3 In-Reply-To: <2881167d-8450-f6c7-0109-4836a166b4d7@openssl.org> References: <2881167d-8450-f6c7-0109-4836a166b4d7@openssl.org> Message-ID: <80b47d16-e4b1-beaa-f42f-575b7e90bddd@openssl.org> On 08/08/18 11:28, Matt Caswell wrote: > For the full background to this issue see: > > https://github.com/openssl/openssl/issues/6490 > > TL;DR summary: > > The TLSv1.2 and TLSv1.3 PSK mechanisms are quite different to each > other. OpenSSL (along with at least GnuTLS maybe others) has implemented > an upgrade path which enables the reuse of a TLSv1.2 PSK in TLSv1.3. > This is not prohibited by the spec. David Benjamin has raised concerns > about this due to key separation. Everything else in TLSv1.3 is provably > secure - but this is not. The spec has been updated to add some words of > warning about this. > > > There seems to be two schools of thought on what to do about this: > > 1) We should seek to avoid this risk. As a fix we should disable TLSv1.3 > if TLSv1.2 PSKs have been configured. We expect that at some later time > the IETF will come up with a better answer and when that happens we can > implement it then. A PR to do the removal is here: > https://github.com/openssl/openssl/pull/6836 > > 2) This is a theoretical risk - there might not actually be a problem at > all, its just that we can't prove it. OTOH not upgrading to TLSv1.3 is > definitely a bad thing, so we should just leave things as they are and > accept the theoretical risk. > > > I'll admit that I've been flip-flopping between the two approaches to > this and there doesn't seem to be a clear consensus forming. How should > we take this forward? Does it require an OMC vote? Ok...no discussion... I think perhaps a vote is the only way forward then. Does this vote text seem reasonable? "We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3 PSKs) then we should disable TLSv1.3." If the vote fails then we will, by default, stick with the status quo (which is effectively option 2). If it passes then that is option 1. Matt From appro at openssl.org Thu Aug 9 10:29:43 2018 From: appro at openssl.org (Andy Polyakov) Date: Thu, 9 Aug 2018 12:29:43 +0200 Subject: [openssl-project] Removal of NULL checks In-Reply-To: References: Message-ID: > Should not be changed period. Even across major release boundaries. > This is not an ABI compatibility issue, it is a source compatibility > issue, and should avoided all the time. If we want to write a *new* > function that skips the NULL checks it gets a new name. While I admittedly crossed a line, I would actually argue against drawing the line as categorically as above. In sense that NULL checks *can* be excessive, and thing is that such checks can jeopardize application security. And in such case it wouldn't be totally inappropriate to remove them, excessive checks, *without* renaming function as suggested above. It would be kind of equivalent of changing one undefined behaviour pattern for another undefined one. Or rather for more "honest" undefined behaviour pattern:-) As for jeopardizing application security, taking this case as an example. What worked so far? Create stack without paying attention to result[!], dump things into stack even if it's NULL, pull nothing if it's NULL. Now imagine that this stack was some kind of deny list. If entry producer didn't pay attention to error when creating stack and putting things into it, consumer would be led to belief that there is nothing to deny and let through the requests that are supposed to be denied. This is kind of not-quite-right example in the context, because it implies that *all* NULL checks should have been removed, thus making *every* caller to pay attention, including consumer. While I left checks in some of the consume operations reckoning that at least those who will be putting things into NULL stack will have to pay attention and will cancel whole operation hopefully without getting to pull-nothing step. So that those entry producers who are not *currently* paying attention would actually be caught. Which actually would be a positive thing! Oh! Triggering factor was quite a number of unchecked pushes in apps. Yes, you can sense contradiction in sense that one can't "fix" those unchecked pushes with removal of NULL checks in questions. But they were just something that made me look at stack.c and wonder above questions. From rsalz at akamai.com Thu Aug 9 13:49:27 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Aug 2018 13:49:27 +0000 Subject: [openssl-project] Removal of NULL checks In-Reply-To: References: Message-ID: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> > it's NULL. Now imagine that this stack was some kind of deny list. If > entry producer didn't pay attention to error when creating stack and > putting things into it, consumer would be led to belief that there is > nothing to deny and let through the requests that are supposed to be > denied. This is another reason why I am opposed to NULL checks. > Oh! Triggering factor was quite a number of unchecked pushes in apps. Real code often doesn't check return values. Even ours. :( From rsalz at akamai.com Thu Aug 9 14:10:29 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Aug 2018 14:10:29 +0000 Subject: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3 In-Reply-To: <80b47d16-e4b1-beaa-f42f-575b7e90bddd@openssl.org> References: <2881167d-8450-f6c7-0109-4836a166b4d7@openssl.org> <80b47d16-e4b1-beaa-f42f-575b7e90bddd@openssl.org> Message-ID: > "We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3 PSKs) then we should disable TLSv1.3." This seems reasonable to me, albeit a bit wordy since you could delete the first sentence. :) From openssl-users at dukhovni.org Thu Aug 9 15:02:16 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Aug 2018 11:02:16 -0400 Subject: [openssl-project] Removal of NULL checks In-Reply-To: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> References: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> Message-ID: <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> > On Aug 9, 2018, at 9:49 AM, Salz, Rich wrote: > > This is another reason why I am opposed to NULL checks. Whether one's for them, or against them, removing a check from a function that would formerly return an error and making it crash is a substantial API change. We must avoid API changes whenever we can. We can introduce new functions and gradually deprecate the old over a number (at least 3 IMHO) major release cycles, but what we MUST NOT do is just change the API of an existing function. -- Viktor. From rsalz at akamai.com Thu Aug 9 15:03:44 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Aug 2018 15:03:44 +0000 Subject: [openssl-project] Removal of NULL checks In-Reply-To: <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> References: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> Message-ID: <0EEA0CA4-643B-4A1B-A2AD-073373640C07@akamai.com> > Whether one's for them, or against them, removing a check from a function that would formerly return an error and making it crash is a substantial API change. I don't disagree. From levitte at openssl.org Thu Aug 9 15:53:11 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 09 Aug 2018 17:53:11 +0200 (CEST) Subject: [openssl-project] Removal of NULL checks In-Reply-To: <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> References: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> Message-ID: <20180809.175311.836050178334040993.levitte@openssl.org> In message <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8 at dukhovni.org> on Thu, 9 Aug 2018 11:02:16 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Aug 9, 2018, at 9:49 AM, Salz, Rich wrote: openssl-users> > openssl-users> > This is another reason why I am opposed to NULL checks. openssl-users> openssl-users> Whether one's for them, or against them, removing a check openssl-users> from a function that would formerly return an error and openssl-users> making it crash is a substantial API change. We must openssl-users> avoid API changes whenever we can. We can introduce openssl-users> new functions and gradually deprecate the old over openssl-users> a number (at least 3 IMHO) major release cycles, but openssl-users> what we MUST NOT do is just change the API of an openssl-users> existing function. I think we need to be a bit more nuanced in our views. Bug fixes are potentially behaviour changes (for example, I recently got through a PR that added a stricter check of EVP_PKEY_asn1_new() input; see #6880 (*)). Also, we might want to look at our own documentation to see what can be reasonably expected. doc/man3/DEFINE_STACK_OF.pod defines all the stack functions. Just scanning for NULL shows that sk == NULL is defined for sk_TYPE_num() and sk_TYPE_set(). That possibility isn't mentioned for any other of the safestack functions, and the behaviour could therefore be seen as undefined. "But this is how it has worked so far!" Yeah? Still undefined behaviour. I think we're doing ourselves a disservice if we get too stuck by behaviour that can only be reasonably derived by reading the source code rather than the docs. So there's a choice, and if we accept that NULL is valid input the the safestack functions, we should document it. If not, then sk == NULL is still mostly undefined, and crashes are therefore as expected as anything else. However, caution isn't a bad thing. I think that as part of a minor version upgrade, removing existing NULL checks may be a bit rad. However, I'd say that for the next major version, we're free to change an undefined behaviour to something more well defined, as we see fit. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Thu Aug 9 16:22:45 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Aug 2018 12:22:45 -0400 Subject: [openssl-project] Removal of NULL checks In-Reply-To: <20180809.175311.836050178334040993.levitte@openssl.org> References: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> <20180809.175311.836050178334040993.levitte@openssl.org> Message-ID: <20180809162245.GD14409@straasha.imrryr.org> On Thu, Aug 09, 2018 at 05:53:11PM +0200, Richard Levitte wrote: > I think we need to be a bit more nuanced in our views. Bug fixes are > potentially behaviour changes (for example, I recently got through a > PR that added a stricter check of EVP_PKEY_asn1_new() input; see #6880 > (*)). We went too far too quickly in the transition from 1.0.2 to 1.1.0, e.g. by needlessly renaming some functions without providing the legacy names (even as deprecated aliases) and by not adding to 1.0.2 the new accessors required for compatibility with 1.1.0. Mostly that could have been done (and could still be done) via new macros in headers that add 1.1.0 accessors to 1.0.2: #if OPENSSL_API_COMPAT >= 0x10100000UL #define EVP_MD_CTX_new() EVP_MD_CTX_create() ... #endif As a result many applications that need to support both 1.0.2 and 1.1.0 (whichever is available) had to waste effort to create the requisite #ifdefs, wrapper functions, ... If we keep doing that, everyone will be using LibreSSL or another alternative. We must not casually change APIs. Especially because of our documentation deficit, which results in users learning about our interfaces via experimentation or reading the source. If we must change an interface, and *can* do it by introducing a new function (that we adequately document), that must be the way forward. And *furthermore*, we can't remove the deprecated interface until the new function has been in multiple stable releases. Indeed to promote adoption, such new functions (when simple enough) should be considered for inclusion in the extant stable releases, making it easy to migrate from old to new. > "But this is how it has worked so far!" Yeah? Still undefined behaviour. Blaming the user for changes in undefined behaviour does not get us more happy users. > I think we're doing ourselves a disservice if we get too stuck by > behaviour that can only be reasonably derived by reading the source > code rather than the docs. I think we're doing our users and ourselves a disservice if we're too casual about API changes. We can only get away with major incompatibilities like those between 1.0.2 and 1.1.0 once. If we keep doing that, we'll lose the application base. > So there's a choice, and if we accept that NULL is valid input the the > safestack functions, we should document it. If not, then sk == NULL > is still mostly undefined, and crashes are therefore as expected as > anything else. If the functions previously returned an error, they must continue to do that barring overwhelming reasons to make a change. > However, caution isn't a bad thing. I think that as part of a minor > version upgrade, removing existing NULL checks may be a bit rad. > However, I'd say that for the next major version, we're free to change > an undefined behaviour to something more well defined, as we > see fit. No, we need a greater emphasis on backwards compatibility, and introduce API changes more slowly, over multiple releases that carry old and new APIs, and we must not change the behaviour of existing functions without renaming them, except when the current behaviour is clearly a bug. It needs to be possible to recompile and run without auditing code. The worst kind of incompatibilities are those that are not reported by the compiler, and are only found at runtime, possibly under unusual conditions. -- Viktor. From levitte at openssl.org Thu Aug 9 16:40:14 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 09 Aug 2018 18:40:14 +0200 (CEST) Subject: [openssl-project] Removal of NULL checks In-Reply-To: <20180809162245.GD14409@straasha.imrryr.org> References: <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> <20180809.175311.836050178334040993.levitte@openssl.org> <20180809162245.GD14409@straasha.imrryr.org> Message-ID: <20180809.184014.374008581275243885.levitte@openssl.org> In message <20180809162245.GD14409 at straasha.imrryr.org> on Thu, 9 Aug 2018 12:22:45 -0400, Viktor Dukhovni said: openssl-users> It needs to be possible to recompile and run without auditing code. openssl-users> The worst kind of incompatibilities are those that are not reported openssl-users> by the compiler, and are only found at runtime, possibly under unusual openssl-users> conditions. So in this particular case, such as unchecked calls of sk_ functions, including sk_TYPE_new(), just to discover later that "oops, the elements we thought we inserted aren't there"? ;-) Either way, sk == NULL will not be reported by the compiler, will only be found at runtime, possibly under unusual conditions. The only difference is exactly how the user gets to find out in runtime; 1) mysterious failures because the stack that should contain n elements is really empty and unfillable, or 2) an immediate crash. Either way, the application authors will have to learn to check their stack pointers. The real difference is how much they will have to scratch their heads to figure out what went wrong. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From viktor at dukhovni.org Thu Aug 9 16:52:56 2018 From: viktor at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Aug 2018 12:52:56 -0400 Subject: [openssl-project] Removal of NULL checks In-Reply-To: <20180809.184014.374008581275243885.levitte@openssl.org> References: <8ACBEBBF-F4A2-469F-BB5B-3564A24DC9B8@dukhovni.org> <20180809.175311.836050178334040993.levitte@openssl.org> <20180809162245.GD14409@straasha.imrryr.org> <20180809.184014.374008581275243885.levitte@openssl.org> Message-ID: <20180809165255.GG14409@straasha.imrryr.org> On Thu, Aug 09, 2018 at 06:40:14PM +0200, Richard Levitte wrote: > In message <20180809162245.GD14409 at straasha.imrryr.org> on Thu, 9 Aug 2018 12:22:45 -0400, Viktor Dukhovni said: > > openssl-users> It needs to be possible to recompile and run without auditing code. > openssl-users> The worst kind of incompatibilities are those that are not reported > openssl-users> by the compiler, and are only found at runtime, possibly under unusual > openssl-users> conditions. > > So in this particular case, such as unchecked calls of sk_ functions, > including sk_TYPE_new(), just to discover later that "oops, the > elements we thought we inserted aren't there"? ;-) The NULL checks were returning an error, not silently failing to add the element. > Either way, sk == NULL will not be reported by the compiler, will only > be found at runtime, possibly under unusual conditions. Code that tested for the error and avoided a crash would absent NULL checks crash (in unexpected cases). The existing code should be assumed to be correctly written for the current library behaviour. What happens to already broken code is of little interest. > The only > difference is exactly how the user gets to find out in runtime; 1) > mysterious failures because the stack that should contain n elements > is really empty and unfillable, or 2) an immediate crash. This is simply wrong I'm afraid. The NULL checks in question returned an *error* (rather than crash) that the application should check. Applications that are not doing their own NULL check and expect us to do it for them, can check for return value. This makes possible more concise code: X509 *x; STACK_OF(X509) *s; ... /* Allocate 's' and initialize with x as first element */ if (sk_X509_push(s = sk_X509_new(NULL), x) < 0) { /* error */ } /* s is stack holding x */ ... -- Viktor. From levitte at openssl.org Thu Aug 9 17:12:18 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 09 Aug 2018 19:12:18 +0200 (CEST) Subject: [openssl-project] Removal of NULL checks In-Reply-To: <20180809165255.GG14409@straasha.imrryr.org> References: <20180809162245.GD14409@straasha.imrryr.org> <20180809.184014.374008581275243885.levitte@openssl.org> <20180809165255.GG14409@straasha.imrryr.org> Message-ID: <20180809.191218.1524646642772249515.levitte@openssl.org> In message <20180809165255.GG14409 at straasha.imrryr.org> on Thu, 9 Aug 2018 12:52:56 -0400, Viktor Dukhovni said: viktor> On Thu, Aug 09, 2018 at 06:40:14PM +0200, Richard Levitte wrote: viktor> > In message <20180809162245.GD14409 at straasha.imrryr.org> on Thu, 9 Aug 2018 12:22:45 -0400, Viktor Dukhovni said: viktor> > viktor> > openssl-users> It needs to be possible to recompile and run without auditing code. viktor> > openssl-users> The worst kind of incompatibilities are those that are not reported viktor> > openssl-users> by the compiler, and are only found at runtime, possibly under unusual viktor> > openssl-users> conditions. viktor> > viktor> > So in this particular case, such as unchecked calls of sk_ functions, viktor> > including sk_TYPE_new(), just to discover later that "oops, the viktor> > elements we thought we inserted aren't there"? ;-) viktor> viktor> The NULL checks were returning an error, not silently failing to viktor> add the element. I said *unchecked* calls of sk_ functions. viktor> > Either way, sk == NULL will not be reported by the compiler, will only viktor> > be found at runtime, possibly under unusual conditions. viktor> viktor> Code that tested for the error and avoided a crash would absent viktor> NULL checks crash (in unexpected cases). The existing code should viktor> be assumed to be correctly written for the current library behaviour. viktor> What happens to already broken code is of little interest. Code that is correctly written should check the value returned from sk_TYPE_new(), no? viktor> > The only viktor> > difference is exactly how the user gets to find out in runtime; 1) viktor> > mysterious failures because the stack that should contain n elements viktor> > is really empty and unfillable, or 2) an immediate crash. viktor> viktor> This is simply wrong I'm afraid. The NULL checks in question viktor> returned an *error* (rather than crash) that the application should viktor> check. Applications that are not doing their own NULL check and viktor> expect us to do it for them, can check for return value. This viktor> makes possible more concise code: viktor> viktor> X509 *x; viktor> STACK_OF(X509) *s; viktor> viktor> ... viktor> /* Allocate 's' and initialize with x as first element */ viktor> if (sk_X509_push(s = sk_X509_new(NULL), x) < 0) { viktor> /* error */ viktor> } I would regard that code incorrectly written, because it doesn't check the value returned from sk_X509_new(NULL) (i.e. it doesn't properly check for possible errors). Correctly written code would be written like this: X509 *x; STACK_OF(X509) *s; ... /* Allocate 's' and initialize with x as first element */ if ((s = sk_X509_new(NULL)) == NULL || sk_X509_push(s, x) < 0) { /* error */ } However, if we actually want people to be able not to check if the stack they wanted to allocate actually got allocated, the correct course of action would be to make that a defined behaviour, i.e. fix the docs accordingly. I find it weird, however, that in this particular case, we would expect users not to check if a stack was actually allocated, when such checks is actually correct behaviour, for example on stuff returned by OPENSSL_malloc(), EVP_PKEY_CTX_new() etc etc etc. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Thu Aug 9 17:16:35 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Aug 2018 13:16:35 -0400 Subject: [openssl-project] Removal of NULL checks In-Reply-To: <20180809.191218.1524646642772249515.levitte@openssl.org> References: <20180809162245.GD14409@straasha.imrryr.org> <20180809.184014.374008581275243885.levitte@openssl.org> <20180809165255.GG14409@straasha.imrryr.org> <20180809.191218.1524646642772249515.levitte@openssl.org> Message-ID: <20180809171635.GJ14409@straasha.imrryr.org> On Thu, Aug 09, 2018 at 07:12:18PM +0200, Richard Levitte wrote: > viktor> X509 *x; > viktor> STACK_OF(X509) *s; > viktor> > viktor> ... > viktor> /* Allocate 's' and initialize with x as first element */ > viktor> if (sk_X509_push(s = sk_X509_new(NULL), x) < 0) { > viktor> /* error */ > viktor> } > > I would regard that code incorrectly written, because it doesn't check > the value returned from sk_X509_new(NULL) (i.e. it doesn't properly > check for possible errors). Correctly written code would be written > like this: It is correctly written *given* the existing NULL checks, and the fact that our API is under-documented. > However, if we actually want people to be able not to check if the > stack they wanted to allocate actually got allocated, the correct > course of action would be to make that a defined behaviour, i.e. fix > the docs accordingly. Yes, we should document the existing behaviour in preference to changing it. Changing the behaviour of existing functions should require a compelling reason to do that. -- Viktor. From paul.dale at oracle.com Thu Aug 9 21:23:07 2018 From: paul.dale at oracle.com (Paul Dale) Date: Thu, 9 Aug 2018 14:23:07 -0700 (PDT) Subject: [openssl-project] Removal of NULL checks In-Reply-To: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> References: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> Message-ID: Rich wrote: > Real code often doesn't check return values. Even ours. :( Could we consider adding a lot more __owur tags to functions to encourage this? As an API change it would have to wait for a major release. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Salz, Rich [mailto:rsalz at akamai.com] Sent: Thursday, 9 August 2018 11:49 PM To: openssl-project at openssl.org Subject: Re: [openssl-project] Removal of NULL checks > it's NULL. Now imagine that this stack was some kind of deny list. If > entry producer didn't pay attention to error when creating stack and > putting things into it, consumer would be led to belief that there is > nothing to deny and let through the requests that are supposed to be > denied. This is another reason why I am opposed to NULL checks. > Oh! Triggering factor was quite a number of unchecked pushes in apps. Real code often doesn't check return values. Even ours. :( _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From openssl-users at dukhovni.org Thu Aug 9 23:03:25 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Aug 2018 19:03:25 -0400 Subject: [openssl-project] Removal of NULL checks In-Reply-To: References: <5B80A672-229D-4A48-90E1-11EC7AD7B548@akamai.com> Message-ID: <20180809230324.GN14409@straasha.imrryr.org> On Thu, Aug 09, 2018 at 02:23:07PM -0700, Paul Dale wrote: > > Real code often doesn't check return values. Even ours. :( > > Could we consider adding a lot more __owur tags to functions to encourage this? > > As an API change it would have to wait for a major release. This is sometimes a good idea, for sufficiently important functions. This sort of change generates compiler warnings, and is easily addressed without breaking compatibility with older library versions. We should not overuse __owur in marginal cases. -- Viktor. From matt at openssl.org Fri Aug 10 08:43:26 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 10 Aug 2018 09:43:26 +0100 Subject: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3 In-Reply-To: <80b47d16-e4b1-beaa-f42f-575b7e90bddd@openssl.org> References: <2881167d-8450-f6c7-0109-4836a166b4d7@openssl.org> <80b47d16-e4b1-beaa-f42f-575b7e90bddd@openssl.org> Message-ID: <0fd28204-e279-1271-4d3b-9cb0ffca035d@openssl.org> On 09/08/18 10:31, Matt Caswell wrote: > I think perhaps a vote is the only way forward then. Does this vote text > seem reasonable? > > "We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as > discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3 > PSKs) then we should disable TLSv1.3." > > If the vote fails then we will, by default, stick with the status quo > (which is effectively option 2). If it passes then that is option 1. > I went ahead and started this vote. I'll report back with the results as soon as we have them. Matt From rsalz at akamai.com Sat Aug 11 13:37:07 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 11 Aug 2018 13:37:07 +0000 Subject: [openssl-project] TLS 1.3 and the release Message-ID: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> You probably know by now that TLS 1.3 was just released as RFC 8446; https://www.rfc-editor.org/info/rfc8446 This note is just trying to forestall a number of question threads. Our release plan called for one final beta (there were various draft-interop things to take out and some other little nits) and then the official release. We have had no discussion of changing that plan. Matt has already prepared a PR (the number escapes me), and there are a couple of open issues we still have to resolve. If all goes well, however, the final beta should begin very soon. Thanks to everyone in the OpenSSL community for your help and support! -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Aug 11 13:42:22 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 11 Aug 2018 15:42:22 +0200 (CEST) Subject: [openssl-project] TLS 1.3 and the release In-Reply-To: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> References: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> Message-ID: <20180811.154222.2141826982723565227.levitte@openssl.org> In message <641FEB77-064E-4A49-A30B-41EDF127999F at akamai.com> on Sat, 11 Aug 2018 13:37:07 +0000, "Salz, Rich" said: rsalz> Matt has already prepared a PR (the number escapes me) https://github.com/openssl/openssl/pull/6741 -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Sat Aug 11 13:50:07 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 11 Aug 2018 13:50:07 +0000 Subject: [openssl-project] FW: Certificate fractional time processing in upcoming openssl releases In-Reply-To: References: <29872ED8-F864-4C44-BF2A-817AD7738799@akamai.com> Message-ID: <24774466-3F03-4374-AE6A-271823DB3836@akamai.com> FYI. Quietly ignoring fractional seconds makes sense to me. From: David McGrew Date: Saturday, August 11, 2018 at 9:45 AM To: Rich Salz , "Barry Fussell (bfussell)" Cc: "Marty Loy (mloyjr)" , "Jonathan Felten (jfelten)" , "Bill Sulzen (bsulzen)" bsulzen at cisco.com Subject: Re: Certificate fractional time processing in upcoming openssl releases Hi Barry and Rich, Thanks for this. I think that having the rejection of fractional seconds be part of the ??strict? option makes sense. As I understand it, there are fielded certs with fractional seconds in GeneralizedTime, which violates the RFC5280 profile but doesn?t introduce any vulnerability. That RFC aims to promote interoperability by making a profile of X509 formats and semantics, and fractional seconds is only formatting, and not semantics. So it seems counter to the spirit of the RFC to prevent openSSL from being able to interoperate with certs issued by IAIK or whatever noncompliant systems. Thanks, David From: "Salz, Rich" > Date: Friday, August 10, 2018 at 12:24 PM To: "Barry Fussell (bfussell)" > Cc: "Marty Loy (mloyjr)" >, "Jonathan Felten (jfelten)" >, mcgrew >, "Bill Sulzen (bsulzen)" > Subject: Re: Certificate fractional time processing in upcoming openssl releases Please post to openssl-project at openssl.org It?s a moderated list, but the posting will get approved very quickly. From: "Barry Fussell (bfussell)" > Date: Friday, August 10, 2018 at 9:34 AM To: Rich Salz > Cc: "Marty Loy (mloyjr)" >, "Jonathan Felten (jfelten)" >, David McGrew >, "Bill Sulzen (bsulzen)" > Subject: Certificate fractional time processing in upcoming openssl releases Rich, My team was recently made aware of a change in the time comparison logic in openssl to adhere to RFC5280 requirements . This change will be in the upcoming 1.0.2p and 1.1.0i releases. We?ve had discussions regarding the impact to legacy devices in the field and feel the change could be detrimental if enabled by default. We've seen fractional time used in many cases, for example the IAIK crypto library generated fractional times for quite a while. I believe the issue with the IAIK library has been fixed, but products still have those certs embedded in them today. In reading the discussion linked below it seems the only impetus for this change was to meet RFC5280, not that allowing fractional times was any specific vulnerability. https://github.com/openssl/openssl/issues/2620 Is there any option for this going forward, removal, compile-time enabled or part of the strict checks ? Thanks ! Barry Fussell [http://www.cisco.com/web/europe/images/email/signature/tomorrow_anthem_H.png] Barry Fussell Technical Leader Security & Trust Organization bfussell at cisco.com Phone: +1 919 392 2920 Cisco Systems, Inc. 7025-2 Kit Creek Road Research Triangle Park, NC 27709 United States Cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here for Company Registration Information. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 7272 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 954 bytes Desc: image002.jpg URL: From openssl-users at dukhovni.org Sat Aug 11 15:50:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 11 Aug 2018 11:50:48 -0400 Subject: [openssl-project] FW: Certificate fractional time processing in upcoming openssl releases In-Reply-To: <24774466-3F03-4374-AE6A-271823DB3836@akamai.com> References: <29872ED8-F864-4C44-BF2A-817AD7738799@akamai.com> <24774466-3F03-4374-AE6A-271823DB3836@akamai.com> Message-ID: <20180811155048.GB55133@straasha.imrryr.org> On Sat, Aug 11, 2018 at 01:50:07PM +0000, Salz, Rich wrote: > FYI. Quietly ignoring fractional seconds makes sense to me. Ditto. -- Viktor. From openssl-users at dukhovni.org Sat Aug 11 21:10:55 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 11 Aug 2018 17:10:55 -0400 Subject: [openssl-project] ABI change tracking Message-ID: I just ran into: https://abi-laboratory.pro/index.php?view=timeline&l=openssl Perhaps you've all seen this site already, but if not, enjoy! FWIW, OpenSSL 1.1.1/master are looking fine. Just some SM2-related symbol churn, which does not affect the stable ABI. -- Viktor. From kurt at roeckx.be Sun Aug 12 21:53:22 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 12 Aug 2018 23:53:22 +0200 Subject: [openssl-project] Forthcoming OpenSSL releases In-Reply-To: <21222dfe-5d7a-2702-b2bf-021bdc7d6881@openssl.org> References: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> <20180807144420.GA26225@roeckx.be> <21222dfe-5d7a-2702-b2bf-021bdc7d6881@openssl.org> Message-ID: <20180812215321.GA4866@roeckx.be> On Tue, Aug 07, 2018 at 04:52:28PM +0200, Andy Polyakov wrote: > >>> Forthcoming OpenSSL releases > >>> ============================ > >> > >> I have some RSA hardening fixes in pipeline... > > > > Do you suggest we wait with a release on that, or can we just put > > it in the next release? > > I should be able to pull it off in before release. What I'm saying is > that it would probably be appropriate to review them as they appear. Is it #6915 you're talking about? I'm not sure we're going to be able to properly review that before the releases of 1.0.2 and 1.1.0. Kurt From appro at openssl.org Mon Aug 13 08:31:51 2018 From: appro at openssl.org (Andy Polyakov) Date: Mon, 13 Aug 2018 10:31:51 +0200 Subject: [openssl-project] Forthcoming OpenSSL releases In-Reply-To: <20180812215321.GA4866@roeckx.be> References: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> <5d69837e-a8e3-f9b8-58ad-dc57d4d1b8f8@openssl.org> <20180807144420.GA26225@roeckx.be> <21222dfe-5d7a-2702-b2bf-021bdc7d6881@openssl.org> <20180812215321.GA4866@roeckx.be> Message-ID: <79ca0157-2421-ecdb-fe5e-ae5b34d63ba3@openssl.org> >>>>> Forthcoming OpenSSL releases >>>>> ============================ >>>> >>>> I have some RSA hardening fixes in pipeline... >>> >>> Do you suggest we wait with a release on that, or can we just put >>> it in the next release? >> >> I should be able to pull it off in before release. What I'm saying is >> that it would probably be appropriate to review them as they appear. > > Is it #6915 you're talking about? Updates to blinding are coming shortly. From matt at openssl.org Mon Aug 13 13:00:47 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Aug 2018 14:00:47 +0100 Subject: [openssl-project] Releases tomorrow Message-ID: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> Just a reminder that we are doing the 1.0.2p and 1.1.0i releases tomorrow so I will be freezing the repo later this afternoon. If you still have PRs to merge for the release please get them in asap! Thanks Matt From kurt at roeckx.be Mon Aug 13 13:20:17 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 13 Aug 2018 15:20:17 +0200 Subject: [openssl-project] Releases tomorrow In-Reply-To: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> References: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> Message-ID: <20180813132016.GA24688@roeckx.be> On Mon, Aug 13, 2018 at 02:00:47PM +0100, Matt Caswell wrote: > Just a reminder that we are doing the 1.0.2p and 1.1.0i releases > tomorrow so I will be freezing the repo later this afternoon. If you > still have PRs to merge for the release please get them in asap! Any plans for the -pre9? Kurt From matt at openssl.org Mon Aug 13 14:07:02 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Aug 2018 15:07:02 +0100 Subject: [openssl-project] Releases tomorrow In-Reply-To: <20180813132016.GA24688@roeckx.be> References: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> <20180813132016.GA24688@roeckx.be> Message-ID: <89de40e8-f8b5-2dcf-d377-08b1413624b6@openssl.org> On 13/08/18 14:20, Kurt Roeckx wrote: > On Mon, Aug 13, 2018 at 02:00:47PM +0100, Matt Caswell wrote: >> Just a reminder that we are doing the 1.0.2p and 1.1.0i releases >> tomorrow so I will be freezing the repo later this afternoon. If you >> still have PRs to merge for the release please get them in asap! > > Any plans for the -pre9? Before we can do pre9 I think we need to resolve the following: - "Updates for RFC8446 (the final TLSv1.3 version)" (PR 6741) needs to be merged. I have the required approval, just giving Rich some time to see if he has any further comments. - The PSK compat issue needs to be resolved (awaiting the results of the OMC vote) - I think the ca app usability improvements for EdDSA (PR 6901) should go in (I have initial approval, awaiting a reconfirm from Viktor) - If we're going to make any changes for issue 6904 (broken pipe for clients that only write/server that only reads), then we should do that - We should resolve issue 6933 (implicit pha enablement breaks existing apps) - I'm working on a fix for that now. I'm unavailable this Thursday/Friday, so I'm thinking with all of the above its going to be next week before we can get a release out. Perhaps Tuesday 21st August? Matt > > > Kurt > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From matt at openssl.org Mon Aug 13 16:11:20 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Aug 2018 17:11:20 +0100 Subject: [openssl-project] Please freeze the repo Message-ID: Please could someone freeze the repo for me? $ ssh openssl-git at git.openssl.org freeze openssl matt Thanks Matt From mark at awe.com Mon Aug 13 16:15:09 2018 From: mark at awe.com (Mark J Cox) Date: Mon, 13 Aug 2018 17:15:09 +0100 Subject: [openssl-project] Please freeze the repo In-Reply-To: References: Message-ID: done. On Mon, Aug 13, 2018 at 5:11 PM, Matt Caswell wrote: > Please could someone freeze the repo for me? > > $ ssh openssl-git at git.openssl.org freeze openssl matt > > Thanks > > Matt > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project From appro at openssl.org Mon Aug 13 16:49:43 2018 From: appro at openssl.org (Andy Polyakov) Date: Mon, 13 Aug 2018 18:49:43 +0200 Subject: [openssl-project] Please freeze the repo In-Reply-To: References: Message-ID: It would be appropriate to merge https://github.com/openssl/openssl/pull/6916 (1.0.2, commit message would need adjustment for merged from) and https://github.com/openssl/openssl/pull/6596 (1.1.0, was marked "pending for 2nd" but it's apparently ready). From matt at openssl.org Mon Aug 13 19:41:16 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Aug 2018 20:41:16 +0100 Subject: [openssl-project] Please freeze the repo In-Reply-To: References: Message-ID: <0dedcce8-d7c7-9a6a-9aec-d0fd9f8ffade@openssl.org> On 13/08/18 17:49, Andy Polyakov wrote: > It would be appropriate to merge > https://github.com/openssl/openssl/pull/6916 (1.0.2, commit message > would need adjustment for merged from) and This one appears to be not quite as ready as first thought. > https://github.com/openssl/openssl/pull/6596 (1.1.0, was marked "pending > for 2nd" but it's apparently ready). I merged this one. Matt > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From rsalz at akamai.com Tue Aug 14 01:50:39 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Aug 2018 01:50:39 +0000 Subject: [openssl-project] Releases tomorrow In-Reply-To: <89de40e8-f8b5-2dcf-d377-08b1413624b6@openssl.org> References: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> <20180813132016.GA24688@roeckx.be> <89de40e8-f8b5-2dcf-d377-08b1413624b6@openssl.org> Message-ID: <7FBC07C7-2853-469F-A818-19CE62811628@akamai.com> > - "Updates for RFC8446 (the final TLSv1.3 version)" (PR 6741) needs to be merged. I have the required approval, just giving Rich some time to see if he has any further comments. Thanks, I'm good. > - If we're going to make any changes for issue 6904 (broken pipe for clients that only write/server that only reads), then we should do that Yeah, I don't like the library messing with signals tho. From openssl-users at dukhovni.org Tue Aug 14 05:34:30 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 14 Aug 2018 01:34:30 -0400 Subject: [openssl-project] Releases tomorrow In-Reply-To: <89de40e8-f8b5-2dcf-d377-08b1413624b6@openssl.org> References: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> <20180813132016.GA24688@roeckx.be> <89de40e8-f8b5-2dcf-d377-08b1413624b6@openssl.org> Message-ID: <20180814053430.GC28851@straasha.imrryr.org> On Mon, Aug 13, 2018 at 03:07:02PM +0100, Matt Caswell wrote: > - I think the ca app usability improvements for EdDSA (PR 6901) should > go in (I have initial approval, awaiting a reconfirm from Viktor) I already did that. Go ahead and merge. -- Viktor. From kurt at roeckx.be Tue Aug 14 10:05:06 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 14 Aug 2018 12:05:06 +0200 Subject: [openssl-project] Releases tomorrow In-Reply-To: <7FBC07C7-2853-469F-A818-19CE62811628@akamai.com> References: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> <20180813132016.GA24688@roeckx.be> <89de40e8-f8b5-2dcf-d377-08b1413624b6@openssl.org> <7FBC07C7-2853-469F-A818-19CE62811628@akamai.com> Message-ID: <20180814100505.GA11674@roeckx.be> On Tue, Aug 14, 2018 at 01:50:39AM +0000, Salz, Rich wrote: > > - If we're going to make any changes for issue 6904 (broken pipe for > clients that only write/server that only reads), then we should do that > > Yeah, I don't like the library messing with signals tho. I don't think it's about signals, but about write() returning EPIPE (or ECONNRESET). Kurt From matt at openssl.org Tue Aug 14 10:07:54 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Aug 2018 11:07:54 +0100 Subject: [openssl-project] Releases tomorrow In-Reply-To: <20180814100505.GA11674@roeckx.be> References: <834d61f1-55b5-afdf-bc5d-74dcadb561e6@openssl.org> <20180813132016.GA24688@roeckx.be> <89de40e8-f8b5-2dcf-d377-08b1413624b6@openssl.org> <7FBC07C7-2853-469F-A818-19CE62811628@akamai.com> <20180814100505.GA11674@roeckx.be> Message-ID: On 14/08/18 11:05, Kurt Roeckx wrote: > On Tue, Aug 14, 2018 at 01:50:39AM +0000, Salz, Rich wrote: >>> - If we're going to make any changes for issue 6904 (broken pipe for >> clients that only write/server that only reads), then we should do that >> >> Yeah, I don't like the library messing with signals tho. > > I don't think it's about signals, but about write() returning > EPIPE (or ECONNRESET). > Right - the proposed solution does nothing with signals. That is still for the app to handle. PR 6944 just introduces some special handling for the EPIPE error response when trying to send NewSessionTickets. Matt From rsalz at akamai.com Tue Aug 14 12:16:25 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Aug 2018 12:16:25 +0000 Subject: [openssl-project] Fractional seconds, etc. Message-ID: <5CB6CA43-D332-4EBF-8778-FFE1F4ADB64A@akamai.com> I think we should revert https://github.com/openssl/openssl/pull/2668 The stricter RFC compliance turns out to impact many certs embedded in devices. Some estimates had thousands to millions. It affects interop with IAIK and Bouncy Castle. I looked at the code, and tried to figure out how to just relax the fractional second code, but it wasn?t obvious. There is also a testcase that would need to be modified. And finally, it?s not clear that the seconds are the only compatibility issue we would be introducing. Unfortunately, this turns out to be a big breaking change, and doesn?t seem right for a dot release. Anyone feel otherwise? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Aug 14 12:18:54 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Aug 2018 12:18:54 +0000 Subject: [openssl-project] Fractional seconds, etc. Message-ID: It is unfortunate that this thread started too late for the 1.0.2p release. From: Rich Salz Reply-To: "openssl-project at openssl.org" Date: Tuesday, August 14, 2018 at 8:17 AM To: "openssl-project at openssl.org" Subject: [openssl-project] Fractional seconds, etc. I think we should revert https://github.com/openssl/openssl/pull/2668 The stricter RFC compliance turns out to impact many certs embedded in devices. Some estimates had thousands to millions. It affects interop with IAIK and Bouncy Castle. I looked at the code, and tried to figure out how to just relax the fractional second code, but it wasn?t obvious. There is also a testcase that would need to be modified. And finally, it?s not clear that the seconds are the only compatibility issue we would be introducing. Unfortunately, this turns out to be a big breaking change, and doesn?t seem right for a dot release. Anyone feel otherwise? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Aug 14 12:47:12 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 14 Aug 2018 14:47:12 +0200 Subject: [openssl-project] Fractional seconds, etc. In-Reply-To: <5CB6CA43-D332-4EBF-8778-FFE1F4ADB64A@akamai.com> References: <5CB6CA43-D332-4EBF-8778-FFE1F4ADB64A@akamai.com> Message-ID: <20180814124712.GA16568@roeckx.be> On Tue, Aug 14, 2018 at 12:16:25PM +0000, Salz, Rich wrote: > I think we should revert https://github.com/openssl/openssl/pull/2668 > > The stricter RFC compliance turns out to impact many certs embedded in devices. Some estimates had thousands to millions. It affects interop with IAIK and Bouncy Castle. > > I looked at the code, and tried to figure out how to just relax the fractional second code, but it wasn?t obvious. There is also a testcase that would need to be modified. And finally, it?s not clear that the seconds are the only compatibility issue we would be introducing. > > Unfortunately, this turns out to be a big breaking change, and doesn?t seem right for a dot release. This seems to have been done in both the 1.0.2 and 1.1.0 after the release. Do you want to revert it in both branches, but keep it in 1.1.1? Or only revert it in 1.0.2? Kurt From openssl at openssl.org Tue Aug 14 13:23:48 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 14 Aug 2018 13:23:48 +0000 Subject: [openssl-project] OpenSSL version 1.0.2p published Message-ID: <20180814132348.GA566@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.0.2p 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.2p 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.2p 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.2p.tar.gz Size: 5338192 SHA1 checksum: f34b5322e92415755c7d58bf5d0d5cf37666382c SHA256 checksum: 50a98e07b1a89eb8f6a99477f262df71c6fa7bef77df4dc83025a2845c827d00 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2p.tar.gz openssl sha256 openssl-1.0.2p.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlty0pMACgkQ2cTSbQ5g RJGQoQf/TjfR+u6Hx2jdABRi6Vyi3T+VlGbHh8xyCP4l5c+JCqPMfxlKz/PF0Cbb 6KwIlc/2dUZZtCQOSITESxmI+xuuPWrwkSKilYetdqxe2ULWtCtDYDru/BgLASn7 M477ANTznqYoKC69vgbbiC0zYS1SdTbdw+agq1Ps+bLHk2GcbiVqRMMzTgvUqnD9 JdmTtAI4mVKJbiLejXz9c4I2Rii9MYTS1QKCpSdFg9irpNjRqLsieEwEoJ6m5eka rVkS567eT4IF1gXLYZeC03FWABUY0PcY9ZO2PhtfuyCKa0Y3dhlIkP8btMAmQAUQ JiIgeN2523E4DEWy4aAnOgsFqagvHQ== =aHv+ -----END PGP SIGNATURE----- From openssl at openssl.org Tue Aug 14 13:24:18 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 14 Aug 2018 13:24:18 +0000 Subject: [openssl-project] OpenSSL version 1.1.0i published Message-ID: <20180814132418.GA773@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.0i 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.0i 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.0-notes.html OpenSSL 1.1.0i 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.0i.tar.gz Size: 5453234 SHA1 checksum: 6713f8b083e4c0b0e70fd090bf714169baf3717c SHA256 checksum: ebbfc844a8c8cc0ea5dc10b86c9ce97f401837f3fa08c17b2cdadc118253cf99 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0i.tar.gz openssl sha256 openssl-1.1.0i.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAltyztkACgkQ2cTSbQ5g RJE10gf6At9Ash5MVfgFwq03wqB0LGraQzSSKqAoraAZEgs2rTYGIaWY0HDTmeKf Ul35obSd5fsJ4ZyaIuL6zdFadlf0HkyYCcuZvl/GcPRB3BjiWrLcIyqJzL+HR3vc p6rxXAYAM1RV/u4+6OJ6LCh3UEB68yBL1mF1Gj2lwQNKxpIZsq+RxLD9Q9SZirzU eVgCiAeMfGY1FcCFuKlHxdowxE7IEveq56aRHFY2OLXS2NXp/KL0lfzeK0JSkCv9 0O4MLuNJoTNdIuYvElyiFWdpSauhh7Fx3wR2sv+3Z7Chm0XdKYDgiFEaPkCc+RYN nGk8eAsGEqP7eefHmMGXYVsA72PtgA== =Cpov -----END PGP SIGNATURE----- From rsalz at akamai.com Tue Aug 14 13:25:36 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Aug 2018 13:25:36 +0000 Subject: [openssl-project] Fractional seconds, etc. In-Reply-To: <20180814124712.GA16568@roeckx.be> References: <5CB6CA43-D332-4EBF-8778-FFE1F4ADB64A@akamai.com> <20180814124712.GA16568@roeckx.be> Message-ID: > This seems to have been done in both the 1.0.2 and 1.1.0 after the release. Do you want to revert it in both branches, but keep it in 1.1.1? Or only revert it in 1.0.2? Keep the existing behavior for 1.0.2, 1.1.0 and 1.1.1. Sadly. And fix in a future release (I would re-open the PR and tag it) From matt at openssl.org Tue Aug 14 13:29:02 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Aug 2018 14:29:02 +0100 Subject: [openssl-project] Please freeze the repo In-Reply-To: References: Message-ID: Release is done and the repo is unfrozen. Thanks again to Richard for all the help. Matt On 13/08/18 17:15, Mark J Cox wrote: > done. > > On Mon, Aug 13, 2018 at 5:11 PM, Matt Caswell wrote: >> Please could someone freeze the repo for me? >> >> $ ssh openssl-git at git.openssl.org freeze openssl matt >> >> Thanks >> >> 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 Tue Aug 14 13:53:12 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Aug 2018 13:53:12 +0000 Subject: [openssl-project] Fractional seconds, etc. In-Reply-To: References: <5CB6CA43-D332-4EBF-8778-FFE1F4ADB64A@akamai.com> <20180814124712.GA16568@roeckx.be> Message-ID: <5A3FF2EC-15D3-45D1-A0C5-D55CD275FD06@akamai.com> I mean keep the *previous* behavior. ?On 8/14/18, 9:25 AM, "Salz, Rich" wrote: > This seems to have been done in both the 1.0.2 and 1.1.0 after the release. Do you want to revert it in both branches, but keep it in 1.1.1? Or only revert it in 1.0.2? Keep the existing behavior for 1.0.2, 1.1.0 and 1.1.1. Sadly. And fix in a future release (I would re-open the PR and tag it) _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From Matthias.St.Pierre at ncp-e.com Tue Aug 14 13:55:13 2018 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Tue, 14 Aug 2018 15:55:13 +0200 Subject: [openssl-project] Fractional seconds, etc. In-Reply-To: <20180814124712.GA16568@roeckx.be> References: <5CB6CA43-D332-4EBF-8778-FFE1F4ADB64A@akamai.com> <20180814124712.GA16568@roeckx.be> Message-ID: <5e4403a5-9da5-6ab2-2d19-c08e683264d4@ncp-e.com> Note: There was a reason why Emilias pull request #2668 was backported to 1.0.2, see github #6182: It was done to fix issue #4915. So if possible we should not revert it entirely but just try to relax the fractional seconds part. ??? https://github.com/openssl/openssl/pull/6182 ??? https://github.com/openssl/openssl/issues/4915 Matthias On 14.08.2018 14:47, Kurt Roeckx wrote: > On Tue, Aug 14, 2018 at 12:16:25PM +0000, Salz, Rich wrote: >> I think we should revert https://github.com/openssl/openssl/pull/2668 >> >> The stricter RFC compliance turns out to impact many certs embedded in devices. Some estimates had thousands to millions. It affects interop with IAIK and Bouncy Castle. >> >> I looked at the code, and tried to figure out how to just relax the fractional second code, but it wasn?t obvious. There is also a testcase that would need to be modified. And finally, it?s not clear that the seconds are the only compatibility issue we would be introducing. >> >> Unfortunately, this turns out to be a big breaking change, and doesn?t seem right for a dot release. > This seems to have been done in both the 1.0.2 and 1.1.0 after the > release. Do you want to revert it in both branches, but keep it in > 1.1.1? Or only revert it in 1.0.2? > > > Kurt > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project From bfussell at cisco.com Fri Aug 10 16:33:35 2018 From: bfussell at cisco.com (Barry Fussell (bfussell)) Date: Fri, 10 Aug 2018 16:33:35 +0000 Subject: [openssl-project] Change to fractional time processing in cert verify Message-ID: <3902d2580e624551930a549e03bad268@XCH-ALN-004.cisco.com> My team was recently made aware of a change in the time comparison logic in openssl to adhere to RFC5280 requirements . This change will be in the upcoming 1.0.2p and 1.1.0i releases. We've had discussions regarding the impact to legacy devices in the field and feel the change could be detrimental if enabled by default. We've seen fractional time used in many cases, for example the IAIK crypto library generated fractional times for quite a while. I believe the issue with the IAIK library has been fixed, but products still have those certs embedded in them today. In reading the discussion linked below it seems the only impetus for this change was to meet RFC5280, not that allowing fractional times was any specific vulnerability. https://github.com/openssl/openssl/issues/2620 Is there any option for this going forward, removal, compile-time enabled or part of the strict checks ? Thanks ! Barry Fussell [http://www.cisco.com/web/europe/images/email/signature/tomorrow_anthem_H.png] Barry Fussell Technical Leader Security & Trust Organization bfussell at cisco.com Phone: +1 919 392 2920 Cisco Systems, Inc. 7025-2 Kit Creek Road Research Triangle Park, NC 27709 United States Cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here for Company Registration Information. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 7270 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 952 bytes Desc: image002.jpg URL: From bfussell at cisco.com Mon Aug 13 21:14:10 2018 From: bfussell at cisco.com (Barry Fussell (bfussell)) Date: Mon, 13 Aug 2018 21:14:10 +0000 Subject: [openssl-project] Certificate fractional time processing in upcoming openssl releases Message-ID: As you might imagine we've continued investigating the overall impact. I've been told that in addition to IAIK that Bouncy Castle had similar issues. We are also aware of customers that will be impacted by the upcoming releases if certificates with fractional time fails to verify. I think it's important to maintain interoperability even in the event that there are minor profile violations. If there is anything I can do to help move this forward please let me know. Thanks ! Barry [http://www.cisco.com/web/europe/images/email/signature/tomorrow_anthem_H.png] Barry Fussell Technical Leader Security & Trust Organization bfussell at cisco.com Phone: +1 919 392 2920 Cisco Systems, Inc. 7025-2 Kit Creek Road Research Triangle Park, NC 27709 United States Cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here for Company Registration Information. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 7270 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 952 bytes Desc: image004.jpg URL: From matt at openssl.org Tue Aug 14 19:20:55 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Aug 2018 20:20:55 +0100 Subject: [openssl-project] Fwd: Request for comments on 'Certificate Management Protocol (CMP, RFC 4210) extension #681'" In-Reply-To: References: Message-ID: I went to approve this post, but I don't see it in the pending queue. Not sure why not - so forwarding this anyway. Please see below. Matt -------- Forwarded Message -------- Subject: Request for comments on 'Certificate Management Protocol (CMP, RFC 4210) extension #681'" Date: Tue, 14 Aug 2018 17:27:33 +0000 From: Brockhaus, Hendrik To: openssl-project at openssl.org CC: matt at openssl.org , levitte at openssl.org , rsalz at openssl.org , Peylo, Martin (Nokia - FI/Espoo) , von Oheimb, David Hi Back in 2007 Nokia started developing a CMP client based on OpenSSL that is currently in use in LTE infrastructure components. Siemens joined in the project some years ago to extend and utilize the code for further industrial use cases. We are aware that a lot of other users of this implementation. Right from the beginning it was the goal of the project to contribute the code upstream OpenSSL some time, see RT item #3101, GitHub issue #5926 and pull request #6811. Integrating CMPforOpenSSL would make things much easier for all people using it already and also for those who use OpenSSL to automate their certificate management based on CMP. The footprint of the code is about 17.000 lines of code plus test and configuration data. There are unit tests and a large amount of interoperability test (with EJBCA and Insta CA). These tests can provide initial confidence in the functionality and quality of the implementation. In the past months we already got some feedback supporting the contribution. To get the contribution reviewed and merged by the project we know that there will be considerable effort needed on both sides. Therefore we'd like to understand the opinion of the group of committers and OMC members if this contribution should be integrated with OpenSSL. Martin, David, and Hendrik Ps.: I will be out of the office the next weeks; Martin and David are available to follow up on this discussion. With best regards, Hendrik Brockhaus Siemens AG Corporate Technology Research and Development for Digitalization and Automation Security Architecture CT RDA ITS SEA-DE Otto-Hahn-Ring 6 81739 Muenchen, Germany Tel.: +49 89 636-633672 Mobile: +49 174 1517765 mailto:hendrik.brockhaus at siemens.com www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 From matt at openssl.org Wed Aug 15 13:30:14 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Aug 2018 14:30:14 +0100 Subject: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3 In-Reply-To: <0fd28204-e279-1271-4d3b-9cb0ffca035d@openssl.org> References: <2881167d-8450-f6c7-0109-4836a166b4d7@openssl.org> <80b47d16-e4b1-beaa-f42f-575b7e90bddd@openssl.org> <0fd28204-e279-1271-4d3b-9cb0ffca035d@openssl.org> Message-ID: On 10/08/18 09:43, Matt Caswell wrote: > > > On 09/08/18 10:31, Matt Caswell wrote: > >> I think perhaps a vote is the only way forward then. Does this vote text >> seem reasonable? >> >> "We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as >> discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3 >> PSKs) then we should disable TLSv1.3." >> >> If the vote fails then we will, by default, stick with the status quo >> (which is effectively option 2). If it passes then that is option 1. >> > > I went ahead and started this vote. I'll report back with the results as > soon as we have them. The vote results are in: +1: 0 votes 0: 2 votes -1: 5 votes Therefore this vote fails. This means we will stick with the status quo, and the PSK compatibility will be retained. Matt From davidben at google.com Wed Aug 15 13:35:19 2018 From: davidben at google.com (David Benjamin) Date: Wed, 15 Aug 2018 08:35:19 -0500 Subject: [openssl-project] Certificate fractional time processing in upcoming openssl releases In-Reply-To: References: Message-ID: On Tue, Aug 14, 2018 at 2:17 PM Barry Fussell (bfussell) wrote: > As you might imagine we?ve continued investigating the overall impact. > I?ve been told > > that in addition to IAIK that Bouncy Castle had similar issues. We are > also aware of > > customers that will be impacted by the upcoming releases if certificates > with fractional > > time fails to verify. > When you say Bouncy Castle has similar issues, do you mean that Bouncy Castle additionally tolerates such things, or that Bouncy Castle also generates non-compliant certificates? The former is not, in itself, a reason to accept them certificates in OpenSSL. If the latter, do you have a link to a bug filed with BouncyCastle? Whether or not OpenSSL accepts it, Bouncy Castle should be fixed to match RFC 5280 going forward. Likewise, do you have plans to fix the issue in your implementation? I haven't confirmed this, but I don't believe Chrome or Firefox would accept such certificates today. > I think it?s important to maintain interoperability even in the event that > there are > > minor profile violations. If there is anything I can do to help move this > forward > > please let me know. > While this may indeed be a case where OpenSSL must accept non-compliant inputs, that is not good advice for implementations to follow in general. This is part of the common interpretation of Postel's Law ("..., be liberal in what you accept"), which has not fared well, particularly in the security space. See this document which describes the problems with this approach. https://tools.ietf.org/html/draft-iab-protocol-maintenance-00 > Thanks ! > > > > Barry > > > > > > > > > > [image: image002.jpg] > > > > *Barry Fussell* > Technical Leader > Security & Trust Organization > bfussell at cisco.com > Phone: *+1 919 392 2920 <(919)%20392-2920>* > > *Cisco Systems, Inc.* > 7025-2 Kit Creek Road > Research Triangle Park, NC 27709 > United States > Cisco.com > > > > [image: image004.jpg]Think before you print. > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by > reply email and delete all copies of this message. > > Please click here > for > Company Registration Information. > > > > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 7270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 952 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Aug 15 15:46:37 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 15 Aug 2018 11:46:37 -0400 Subject: [openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3 Message-ID: <56A0286B-8A30-4F0E-8CA0-4FF2D0F4DBCD@dukhovni.org> When I configure a client with a legacy TLS 1.2 protocol exclusion, e.g. by setting SSL_OP_NO_TLSv1_2 (rather than the new min/max version interface), as a result of the new TLS 1.3 protocol suport configurations that previously negotiated "up to" TLS 1.1, now fail when communicating with a TLS 1.3 server: $ posttls-finger -c -p '!TLSv1.2' "[127.0.0.1]" posttls-finger: SSL_connect error to 127.0.0.1[127.0.0.1]:25: -1 posttls-finger: warning: TLS library problem: error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:../openssl/ssl/statem/statem_lib.c:1939: If I then also explicitly disable "TLSv1.3" the connection succeeds: $ posttls-finger -c -lmay -Lsummary -p '!TLSv1.2:!TLSv1.3' "[127.0.0.1]" posttls-finger: Anonymous TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits) I think this counts as a regression, the client should notice that it implicitly disabled TLS 1.3, and therefore not react to the server's version sentinel by aborting the connection. Thoughts? -- Viktor. From matt at openssl.org Wed Aug 15 15:50:59 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Aug 2018 16:50:59 +0100 Subject: [openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3 In-Reply-To: <56A0286B-8A30-4F0E-8CA0-4FF2D0F4DBCD@dukhovni.org> References: <56A0286B-8A30-4F0E-8CA0-4FF2D0F4DBCD@dukhovni.org> Message-ID: On 15/08/18 16:46, Viktor Dukhovni wrote: > When I configure a client with a legacy TLS 1.2 protocol exclusion, > e.g. by setting SSL_OP_NO_TLSv1_2 (rather than the new min/max > version interface), as a result of the new TLS 1.3 protocol > suport configurations that previously negotiated "up to" TLS 1.1, > now fail when communicating with a TLS 1.3 server: > > $ posttls-finger -c -p '!TLSv1.2' "[127.0.0.1]" > posttls-finger: SSL_connect error to 127.0.0.1[127.0.0.1]:25: -1 > posttls-finger: warning: TLS library problem: error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:../openssl/ssl/statem/statem_lib.c:1939: > > If I then also explicitly disable "TLSv1.3" the connection succeeds: > > $ posttls-finger -c -lmay -Lsummary -p '!TLSv1.2:!TLSv1.3' "[127.0.0.1]" > posttls-finger: Anonymous TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits) > > I think this counts as a regression, the client should notice that > it implicitly disabled TLS 1.3, and therefore not react to the > server's version sentinel by aborting the connection. Thoughts? > Hmm. Yes we should probably handle this scenario. Can you open a github issue? Matt From openssl-users at dukhovni.org Wed Aug 15 16:08:09 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 15 Aug 2018 12:08:09 -0400 Subject: [openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3 In-Reply-To: References: <56A0286B-8A30-4F0E-8CA0-4FF2D0F4DBCD@dukhovni.org> Message-ID: <9B6CA264-2B77-4CA0-A88C-10F969E09919@dukhovni.org> > On Aug 15, 2018, at 11:50 AM, Matt Caswell wrote: >> >> I think this counts as a regression, the client should notice that >> it implicitly disabled TLS 1.3, and therefore not react to the >> server's version sentinel by aborting the connection. Thoughts? >> > > Hmm. Yes we should probably handle this scenario. Can you open a github > issue? https://github.com/openssl/openssl/issues/6964 -- Viktor. From matt at openssl.org Wed Aug 15 16:24:26 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Aug 2018 17:24:26 +0100 Subject: [openssl-project] Fwd: Request for comments on 'Certificate Management Protocol (CMP, RFC 4210) extension #681'" In-Reply-To: References: Message-ID: <2c338a16-3b4a-d3d0-b56b-3332fafe4eba@openssl.org> On 14/08/18 20:20, Matt Caswell wrote: > Hi > > Back in 2007 Nokia started developing a CMP client based on OpenSSL that > is currently in use in LTE infrastructure components. Siemens joined in > the project some years ago to extend and utilize the code for further > industrial use cases. We are aware that a lot of other users of this > implementation. > > Right from the beginning it was the goal of the project to contribute > the code upstream OpenSSL some time, see RT item #3101, GitHub issue > #5926 and pull request #6811. > Integrating CMPforOpenSSL would make things much easier for all people > using it already and also for those who use OpenSSL to automate their > certificate management based on CMP. > > The footprint of the code is about 17.000 lines of code plus test and > configuration data. > There are unit tests and a large amount of interoperability test (with > EJBCA and Insta CA). These tests can provide initial confidence in the > functionality and quality of the implementation. > > In the past months we already got some feedback supporting the > contribution. To get the contribution reviewed and merged by the project > we know that there will be considerable effort needed on both sides. > Therefore we'd like to understand the opinion of the group of committers > and OMC members if this contribution should be integrated with OpenSSL. I'm of the view that this would be a useful addition to OpenSSL. However the effort required to review this will be significant, and it does not contribute towards the priority of the next release after 1.1.1 (i.e. FIPS). Therefore I'd like to hear the opinions of the committers on this. Is this something we should be spending time reviewing (and for the contributors to get it into shape)? Are there volunteers to help review? It may be helpful for us to hold an OMC vote on this to get a view up front whether to spend the time on it. But I'd like to hear feedback first. Matt > > Martin, David, and Hendrik > > > Ps.: I will be out of the office the next weeks; Martin and David are > available to follow up on this discussion. > > > With best regards, > Hendrik Brockhaus > > Siemens AG > Corporate Technology > Research and Development for Digitalization and Automation > Security Architecture > CT RDA ITS SEA-DE > Otto-Hahn-Ring 6 > 81739 Muenchen, Germany Tel.: +49 89 636-633672 > Mobile: +49 174 1517765 > mailto:hendrik.brockhaus at siemens.com > > www.siemens.com/ingenuityforlife > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and > Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, > Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered > offices: Berlin and Munich, Germany; Commercial registries: Berlin > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > From levitte at openssl.org Fri Aug 17 11:55:13 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 17 Aug 2018 13:55:13 +0200 (CEST) Subject: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? Message-ID: <20180817.135513.218041365083823947.levitte@openssl.org> At first sight, if you search through github issues and PRs by filtering on the "1.1.1" milestone or the "1,1,1" label, it looks like a fairly small amount of work left. However, there's been a move done that I think has lead us astray; any issue or PR that had the milestone "1.1.1" and were determined to be applicable to 1.1.0 as well (i.e. not being a 1.1.1 only milestone, and I agree with that assessment) were changed to the milestone "Assessed" *with no further labeling*. Unfortunately, judging from activity, it seems the "Assessed" milestone has in large part become "the 'ignore for now'" bin... I believe that we need to go through those issues and PRs and make an actual assessment, i.e. label the appropriately, and for anything that's a bug in current 1.1.1 code (*), they need to be fixed before the release. At this moment, I count 132 issues and PRs in the "Assessed" milestone with no further labeling. Personally, I see this as a showstopper re a release on Tuesday, but I think it's on all of us to come to an agreement, that is unless we actually do label and fix everything that needs fixing 'til Monday evening (Euro time)... Cheers, Richard (*) I'm sure some of the issues and PRs in this milestone are 1.1.0 only or 1.0.2 only. They can safely be ignored for the moment, but still need to be labeled as such. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Fri Aug 17 16:29:09 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 17 Aug 2018 18:29:09 +0200 Subject: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: <20180817.135513.218041365083823947.levitte@openssl.org> References: <20180817.135513.218041365083823947.levitte@openssl.org> Message-ID: <20180817162909.GA10354@roeckx.be> On Fri, Aug 17, 2018 at 01:55:13PM +0200, Richard Levitte wrote: > Personally, I see this as a showstopper re a release on Tuesday You mean a beta release? Kurt From levitte at openssl.org Fri Aug 17 16:39:54 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 17 Aug 2018 18:39:54 +0200 (CEST) Subject: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: <20180817162909.GA10354@roeckx.be> References: <20180817.135513.218041365083823947.levitte@openssl.org> <20180817162909.GA10354@roeckx.be> Message-ID: <20180817.183954.684446492314586162.levitte@openssl.org> In message <20180817162909.GA10354 at roeckx.be> on Fri, 17 Aug 2018 18:29:09 +0200, Kurt Roeckx said: kurt> On Fri, Aug 17, 2018 at 01:55:13PM +0200, Richard Levitte wrote: kurt> > Personally, I see this as a showstopper re a release on Tuesday kurt> kurt> You mean a beta release? ... D'oh. For some reason, I got mixed up and imagined a live release on Tuesday. So ok, not a showstopper per se, even though I would have *liked* to see as much of the applicable issues fixed and PRs (and that includes those I'm talking about) applied as possible. However, I think we need to go over the "Assessed" milestone stuff and make an actual assessment on them (i.e. labeling them correctly). The final release will probably not be very far away, and I'd hate to have to call showstopper again by then. See this thread as an early warning ;-) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaduk at mit.edu Fri Aug 17 16:44:41 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 17 Aug 2018 11:44:41 -0500 Subject: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: <20180817.183954.684446492314586162.levitte@openssl.org> References: <20180817.135513.218041365083823947.levitte@openssl.org> <20180817162909.GA10354@roeckx.be> <20180817.183954.684446492314586162.levitte@openssl.org> Message-ID: <20180817164440.GP40887@kduck.kaduk.org> On Fri, Aug 17, 2018 at 06:39:54PM +0200, Richard Levitte wrote: > In message <20180817162909.GA10354 at roeckx.be> on Fri, 17 Aug 2018 18:29:09 +0200, Kurt Roeckx said: > > kurt> On Fri, Aug 17, 2018 at 01:55:13PM +0200, Richard Levitte wrote: > kurt> > Personally, I see this as a showstopper re a release on Tuesday > kurt> > kurt> You mean a beta release? > > ... > > D'oh. For some reason, I got mixed up and imagined a live release on > Tuesday. > > So ok, not a showstopper per se, even though I would have *liked* to > see as much of the applicable issues fixed and PRs (and that includes > those I'm talking about) applied as possible. > > However, I think we need to go over the "Assessed" milestone stuff and > make an actual assessment on them (i.e. labeling them correctly). The > final release will probably not be very far away, and I'd hate to have > to call showstopper again by then. I agree. And, if we make a bunch of (bugfix) changes between a beta release and the scheduled final release, it may be more appropriate to do another beta than to do a final release with "many" (vaguely defined) changes since the last beta. -Ben > See this thread as an early warning ;-) From Matthias.St.Pierre at ncp-e.com Sat Aug 18 13:09:50 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 18 Aug 2018 13:09:50 +0000 Subject: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: <20180817.135513.218041365083823947.levitte@openssl.org> References: <20180817.135513.218041365083823947.levitte@openssl.org> Message-ID: <0b7d888082e84a07abb8959816de145c@Ex13.ncp.local> > I believe that we need to go through those issues and PRs and make an > actual assessment, i.e. label the appropriately, and for anything > that's a bug in current 1.1.1 code (*), they need to be fixed before > the release. If it's something which can be postponed until after the release, should it be labelled 'after 1.1.1.' or moved to the 'Post 1.1.1' milestone or both? I have to admit that I still don't quite understand the different semantics of the label vs. the milestone. Matthias From matt at openssl.org Mon Aug 20 09:04:58 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Aug 2018 10:04:58 +0100 Subject: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: <20180817164440.GP40887@kduck.kaduk.org> References: <20180817.135513.218041365083823947.levitte@openssl.org> <20180817162909.GA10354@roeckx.be> <20180817.183954.684446492314586162.levitte@openssl.org> <20180817164440.GP40887@kduck.kaduk.org> Message-ID: <7c944d20-04f5-f21f-735a-829e9772c47e@openssl.org> On 17/08/18 17:44, Benjamin Kaduk wrote: > On Fri, Aug 17, 2018 at 06:39:54PM +0200, Richard Levitte wrote: >> In message <20180817162909.GA10354 at roeckx.be> on Fri, 17 Aug 2018 18:29:09 +0200, Kurt Roeckx said: >> >> kurt> On Fri, Aug 17, 2018 at 01:55:13PM +0200, Richard Levitte wrote: >> kurt> > Personally, I see this as a showstopper re a release on Tuesday >> kurt> >> kurt> You mean a beta release? >> >> ... >> >> D'oh. For some reason, I got mixed up and imagined a live release on >> Tuesday. >> >> So ok, not a showstopper per se, even though I would have *liked* to >> see as much of the applicable issues fixed and PRs (and that includes >> those I'm talking about) applied as possible. >> >> However, I think we need to go over the "Assessed" milestone stuff and >> make an actual assessment on them (i.e. labeling them correctly). The >> final release will probably not be very far away, and I'd hate to have >> to call showstopper again by then. > > I agree. And, if we make a bunch of (bugfix) changes between a beta > release and the scheduled final release, it may be more appropriate to do > another beta than to do a final release with "many" (vaguely defined) > changes since the last beta. I don't really see why an issue that is currently in 1.1.0 should prevent us from issuing 1.1.1 with the same issue. 1.1.0 has been out for sometime now. Any truly serious issues should have been already fixed. That's not to say we should just ignore 1.1.0 issues - of course we should try and fix them. It's just that I don't see a dependency on fixing those issues for releasing 1.1.1. That at least was the thinking that went into the reclassification of many issues to "Assessed". Matt > > -Ben > >> See this thread as an early warning ;-) > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From matt at openssl.org Mon Aug 20 16:01:08 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Aug 2018 17:01:08 +0100 Subject: [openssl-project] Please freeze the repo Message-ID: <4dda24b5-b33a-276d-e30e-6464d2c58ed5@openssl.org> Please could someone freeze the repo for me for tomorrow's release: ssh openssl-git at git.openssl.org freeze openssl matt Thanks Matt From bernd.edlinger at hotmail.de Mon Aug 20 17:00:04 2018 From: bernd.edlinger at hotmail.de (Bernd Edlinger) Date: Mon, 20 Aug 2018 17:00:04 +0000 Subject: [openssl-project] Please freeze the repo In-Reply-To: <4dda24b5-b33a-276d-e30e-6464d2c58ed5@openssl.org> References: <4dda24b5-b33a-276d-e30e-6464d2c58ed5@openssl.org> Message-ID: Hi Matt, The repo should be frozen now. Bernd. On 08/20/18 18:01, Matt Caswell wrote: > Please could someone freeze the repo for me for tomorrow's release: > > ssh openssl-git at git.openssl.org freeze openssl matt > > Thanks > > Matt > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From paul.dale at oracle.com Mon Aug 20 23:03:13 2018 From: paul.dale at oracle.com (Paul Dale) Date: Mon, 20 Aug 2018 16:03:13 -0700 (PDT) Subject: [openssl-project] Is this still relevant to OpenSSL? Message-ID: Abstract: This work provides a systematic analysis of primality testing under adversarial conditions, where the numbers being tested for primality are not generated randomly, but instead provided by a possibly malicious party.... https://eprint.iacr.org/2018/749 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 kurt at roeckx.be Tue Aug 21 07:25:29 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 21 Aug 2018 09:25:29 +0200 Subject: [openssl-project] Is this still relevant to OpenSSL? In-Reply-To: References: Message-ID: <20180821072529.GA25012@roeckx.be> On Mon, Aug 20, 2018 at 04:03:13PM -0700, Paul Dale wrote: > Abstract: This work provides a systematic analysis of primality testing under adversarial conditions, where the numbers being tested for primality are not generated randomly, but instead provided by a possibly malicious party.... > > https://eprint.iacr.org/2018/749 We got an early copy of that paper. What that paper mostly says is that we didn't properly document the amount of rounds required in case you can't trust the input, the documentation has been changed to make that more clear. Related to that, since that paper we have increased the number of Miller-Rabin rounds, but that work started before we saw that paper. As result of that paper I've started working on the Lucas prime test, for which there is an open PR. I intend to create a Bailie-PSW test after 1.1.1. Kurt From openssl at openssl.org Tue Aug 21 12:36:02 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 21 Aug 2018 12:36:02 +0000 Subject: [openssl-project] OpenSSL version 1.1.1 pre release 9 published Message-ID: <20180821123602.GA29908@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1 pre release 9 (beta) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The beta release 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.1-pre9.tar.gz Size: 8411103 SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7 SHA256 checksum: 95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre9.tar.gz openssl sha256 openssl-1.1.1-pre9.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----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlt8Ah8ACgkQ2cTSbQ5g RJGYTAgAm4xPeNBGKAsmA9eoRm8FkQHew1zhf9G2P677n26+JKwoUBx7O6c/zhKV c9wP5xjvDl3KlUNw3gga2URIE95wj4RGMOcLUxWEVci+oR7luRXDocJKcAfppLcl 50T4OKL/5tqtAodI700t42SlA4EWyZIv+Kt5YMzQnkbbelGqFA8Loi1yDks+JwWU 2xlx4ukAvCNUuHvKIs85QaRi5PSWRZHE4o49ijP+ynUSxSqjGTLpeW+Ij6pHOH+e 2rKAScmx1Ll3ZK50dVnlWif6H7hjftWclqbNXrGy76SUQjmmzi1vxAm8ftmgUZEP qXxGwJpfpCirNBHPSXeaMSe4thZeCw== =etGy -----END PGP SIGNATURE----- From matt at openssl.org Tue Aug 21 13:21:15 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Aug 2018 14:21:15 +0100 Subject: [openssl-project] Please freeze the repo In-Reply-To: References: <4dda24b5-b33a-276d-e30e-6464d2c58ed5@openssl.org> Message-ID: <06fd8987-3517-0c32-8af8-47507dbd0fa6@openssl.org> The repository is now unfrozen and the release is complete. Thanks to Tim for all the help. Matt On 20/08/18 18:00, Bernd Edlinger wrote: > Hi Matt, > > The repo should be frozen now. > > Bernd. > > On 08/20/18 18:01, Matt Caswell wrote: >> Please could someone freeze the repo for me for tomorrow's release: >> >> ssh openssl-git at git.openssl.org freeze openssl matt >> >> Thanks >> >> 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 kurt at roeckx.be Tue Aug 21 20:15:01 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 21 Aug 2018 22:15:01 +0200 Subject: [openssl-project] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <20180821123602.GA29908@openssl.org> References: <20180821123602.GA29908@openssl.org> Message-ID: <20180821201501.GA12684@roeckx.be> On Tue, Aug 21, 2018 at 12:36:02PM +0000, OpenSSL wrote: > > OpenSSL version 1.1.1 pre release 9 (beta) I've uploaded that version to Debian unstable, so it should get more testers now. Kurt From Matthias.St.Pierre at ncp-e.com Wed Aug 22 10:47:40 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 22 Aug 2018 10:47:40 +0000 Subject: [openssl-project] Is this still relevant to OpenSSL? In-Reply-To: References: Message-ID: <8f7a2901ca9e439384b4389e0b912bba@Ex13.ncp.local> > https://eprint.iacr.org/2018/749 Side note: I like the reference to Jane Austen in the paper's title: > Prime and Prejudice: Primality Testing Under Adversarial Conditions Matthias From matt at openssl.org Wed Aug 22 16:10:00 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Aug 2018 17:10:00 +0100 Subject: [openssl-project] Final release date for 1.1.1 Message-ID: I'd like to propose that we target Tuesday 11th September as the final release date for 1.1.1. Next week there is a big meeting about the next OpenSSL release, and specifically FIPS support. This means that I, and others on the OMC, will have limited time to deal with any 1.1.1 issues. Our early beta cycles were all 2 weeks in length. But 2 weeks would put us on Tuesday 4th September - just 2 days after I return from the above FIPS meeting which doesn't give sufficient time to deal with the remaining issues (and any new ones that are identified in the meantime). Tuesday 11th gives us a whole extra week to finish off anything that is outstanding. BTW, please review the 1.1.1 open issues list: https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.1 Anything you can do to move those to "closed" would be very helpful. Also please review the open 1.1.1 PRs: https://github.com/openssl/openssl/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.1.1 Thoughts? Matt From tjh at openssl.org Thu Aug 23 00:42:00 2018 From: tjh at openssl.org (Tim Hudson) Date: Thu, 23 Aug 2018 10:42:00 +1000 Subject: [openssl-project] New OMC Member and New Committers Message-ID: Welcome to Paul Dale (OMC) , Paul Yang and Nicola Tuveri (Commiters). See the blog post at https://www.openssl.org/blog/blog/2018/08/22/updates/ Thanks, Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: