From paul.dale at oracle.com Mon Nov 2 02:08:12 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 2 Nov 2020 12:08:12 +1000 Subject: Project direction In-Reply-To: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> References: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> Message-ID: <65185E11-A533-4503-8BDB-A83449C94227@oracle.com> This came in privately from Michael Richardson and is forwarded with permission: > If you don't grow the user base, you decline. > As long as the old APIs do not go away too quickly, or the new APIs are > obvious refactors, then it won't be such a problem. > > In general, I think that there are way too many APIs, and the documentation > is poorly organized by what it does rather than what things it does it to > (more OOP). > I tried to collect notes at one point, I had other priorities. > > And I still have a pull request which is waiting for me to validate that it > works on VAX/VMS. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 30 Oct 2020, at 9:43 am, Dr Paul Dale wrote: > > At the OTC call on Tuesday Tim raise a point about the future direction of the project. I was tasked with bringing this to the OMC for consideration. > > The question was should we design our APIs to ease the pain existing users of OpenSSL or should we be trying to attract new users. > The idea being that supporting existing users means not changing the existing API, whereas catering to new users means working towards a new fresh consistent API. > > This is all in the context of function naming, argument ordering, cleanup for beta 1. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > From christian.heinrich at cmlh.id.au Mon Nov 2 03:24:38 2020 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Mon, 2 Nov 2020 14:24:38 +1100 Subject: Project direction In-Reply-To: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> References: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> Message-ID: Dr Dale, On Fri, 30 Oct 2020 at 10:45, Dr Paul Dale wrote: > The question was should we design our APIs to ease the pain existing > users of OpenSSL or should we be trying to attract new users. > The idea being that supporting existing users means not changing the > existing API, whereas catering to new users means working towards > a new fresh consistent API. As far as I am aware the competition isn't much better than us ?\_(?)_/? "LibreSSL was great as alternative when Heartbleed first emerged, but LibreSSL development has lagged way behind OpenSSL to the point that OpenSSL 1.1.1 is miles ahead of LibreSSL in performance" to quote https://community.centminmod.com/threads/openssl-or-libressl-in-mid-2020.19810/ "There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project." to quote https://www.chromium.org/Home/chromium-security/boringssl Maybe we should define the problems that new end users experience during onboarding instead and address those first? -- Regards, Christian Heinrich http://cmlh.id.au/contact From matt at openssl.org Mon Nov 2 12:54:50 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 2 Nov 2020 12:54:50 +0000 Subject: Monthly Status Report (October) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Fixed DHX parameter encoding (they were incorrectly being encoded using PKCS3 Parameters). Also extended the encode/decode tests as part of this. - Active participant in the interviewing and recruitment process for the "Administrator and Manager" position - Ongoing participation in the regular OTC meetings - Ongoing participation in regular FIPS sponsor meetings - Removed CMS specific code out of the algorithm implementations and removed key downgrades - Deprecated EVP_PKEY_set1_tls_encodedpoint() as well as the get version. Implemented replacements with more generic names. - Concentrated all deprecated API usage in libssl in one file - Fixed an issue with the SSL_SECOP_TMP_DH security operation which was defined to take an EVP_PKEY, but was actually sending a DH object in one instance. - Performed the alpha 7 release - Created WIP to do the DH deprecation - Fixed an issue that was causing a test failure in a no-dh build - Fixed the deprecation macros to allow "empty" deprecation macros to be passed as macro arguments - Created PR to change the default key generation type for DH and DSA - Fixed an issue where we weren't calling SSLfatal on an error path in libssl - Created PR to convert dhparam so that it no longer needs to use low level APIs - Created PR to remove all instances of low-level DH use in libssl - Fixed some missed usage of DEFINE_LHASH_OF() that meant there were compile failures on some platforms Matt From rwfranks at acm.org Mon Nov 2 15:51:58 2020 From: rwfranks at acm.org (Dick Franks) Date: Mon, 2 Nov 2020 15:51:58 +0000 Subject: Project direction In-Reply-To: References: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> Message-ID: On Mon, 2 Nov 2020 at 10:47, Christian Heinrich < christian.heinrich at cmlh.id.au> wrote: > > On Fri, 30 Oct 2020 at 10:45, Dr Paul Dale wrote: > > The question was should we design our APIs to ease the pain existing > > users of OpenSSL or should we be trying to attract new users. > > The idea being that supporting existing users means not changing the > > existing API, whereas catering to new users means working towards > > a new fresh consistent API. > > As far as I am aware the competition isn't much better than us ?\_(?)_/? > As a user mainly interested in the libcrypto library component, OpenSSL is far better than the competition. However, there are 1189 reasons to think is not perfect. LibreSSL not only lacks performance but also behind on the functionality front (no Ed25529, Ed448, SHA3). Whatever aspirations it may have had at the start have long since evaporated and it is now a poor relation of OpenSSL 1.1.0 BoringSSL has declared itself not to be a competitor. > Maybe we should define the problems that new end users experience > during onboarding instead and address those first? > Better documentation would help enormously. --RWF -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Mon Nov 2 15:56:08 2020 From: kaduk at mit.edu (Benjamin Kaduk) Date: Mon, 2 Nov 2020 07:56:08 -0800 Subject: Project direction In-Reply-To: References: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> Message-ID: <20201102155608.GY39170@kduck.mit.edu> On Mon, Nov 02, 2020 at 03:51:58PM +0000, Dick Franks wrote: > On Mon, 2 Nov 2020 at 10:47, Christian Heinrich < > > > > Maybe we should define the problems that new end users experience > > during onboarding instead and address those first? > > > > Better documentation would help enormously. Would that take the form of ensuring that each public API has a man page, or a general "here's how to get started with " with examples, or something else? Thanks, Ben From mcr at sandelman.ca Mon Nov 2 16:12:38 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 02 Nov 2020 11:12:38 -0500 Subject: Project direction In-Reply-To: <20201102155608.GY39170@kduck.mit.edu> References: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> <20201102155608.GY39170@kduck.mit.edu> Message-ID: <6901.1604333558@localhost> Benjamin Kaduk wrote: >> On Mon, 2 Nov 2020 at 10:47, Christian Heinrich < >> >> >> > Maybe we should define the problems that new end users experience >> > during onboarding instead and address those first? >> > >> >> Better documentation would help enormously. > Would that take the form of ensuring that each public API has a man page, > or a general "here's how to get started with " with > examples, or something else? Most of the APIs have a man page, but the man pages are often not that useful. They might explain how to use the call, but not always: * why I should use this call? * how to get the various inputs for the call. There are many manpages which explain the {A,B,C,D}_get_{X,Y,Z}() calls. And while this is a nice convenience, as they are rather similar, the result lacks much of the context needed above. I would like a man page for each *object* that OpenSSL has. Tell me how to make the object, how to free it, how to manipulate it, what the expected lifetime (to use the Rust term) for the object is. Please also tell me what it's a pre-requisite for. The sectional and version organization of the web site is a bit wonky. We need links from the 0.9.8 version of the man pages to the "most recent", as the older pages get better Google SEO. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matt at openssl.org Mon Nov 2 16:56:42 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 2 Nov 2020 16:56:42 +0000 Subject: Fwd: Project direction In-Reply-To: References: Message-ID: <4eee413a-ff81-59ee-c355-fd47b2fa493c@openssl.org> Forwarding this to openssl-project from openssl-users. Please keep the discussion on the openssl-project list! Note: Although openssl-project is a moderated list, I am one of the moderators and will let through posts that are clearly relevant. Matt -------- Forwarded Message -------- Subject: Re: Project direction Date: Mon, 2 Nov 2020 16:51 +0000 (GMT Standard Time) From: Angus Robertson - Magenta Systems Ltd Reply-To: angus at magsys.co.uk To: openssl-users at openssl.org > The idea being that supporting existing users means not changing > the existing API, whereas catering to new users means working > towards a new fresh consistent API. OpenSSL has been in use for getting on for 20 years (I think) and may still be in use in another 20 years, so can not stay still to make life easy for old projects, it has to evolve for new projects, as it does. But any changes should be clearly documented and should not require the use of third party sites like ABI to discover new APIs and changes to old ones. Major changes are usually in the changelog, but can be hard to find when updating from a much earlier release. There should really be detailed articles about upgrading from any long term release to the latest release, with simple lists of all exports or macros removed or added, or whose use has changed. Also, there is an assumption OpenSSL is only used by other C developers, by the use of public macros that are not usable in any other language. BoringSSL replaced macros with exports and OpenSSL should consider doing the same. Currently changing a macro to an export is rarely documented, so it's hard for those that have rewritten macros in other languages to know something will be broken. There needs to be more task oriented documentation, for instance collecting the APIs needed to create a CSR or certificate, using APIs rather than command line tools which is where much of the documentation currently resides. For instance there is no documentation about building a stack of extensions to add SANs to requests and certificates so a lot of research is needed to adds SANs to a certificate. Angus From mcr at sandelman.ca Mon Nov 2 18:23:55 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 02 Nov 2020 13:23:55 -0500 Subject: Project direction (fwd) Michael Richardson: Re: Project direction Message-ID: <7026.1604341435@localhost> An embedded message was scrubbed... From: Michael Richardson Subject: Re: Project direction Date: Mon, 02 Nov 2020 13:19:49 -0500 Size: 3133 URL: From angus at magsys.co.uk Mon Nov 2 19:58:00 2020 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Mon, 2 Nov 2020 19:58 +0000 (GMT Standard Time) Subject: Project direction Message-ID: > My claim is that much of the "applications" should be removed > from the core system, and should be re-implemented in a cleaner > way using the APIs. > I.e. into a separate git repo with it's own release schedule. > > They should serve as exemplars for using the APIs, which they are > often are not. > > In particular, the way that many things are only doable via > "configuration file" is a serious problem. Agree, to create X509 SANs you need to understand the application, but that gets very confusing since half of it is getting command line and config file input, even harder when you don't understand C. You end up using obscure APIs like GENERAL_NAME_set0_value for which there is no documentation, because there seems nothing better to use to create the stack of extensions. But it was satisfying when it all worked and I had a CA component. OpenSSL is really aimed at two markets, developers using the API and admins using the applications, it would be easier for both groups if the help was separate. Angus From mcr at sandelman.ca Mon Nov 2 22:16:46 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 02 Nov 2020 17:16:46 -0500 Subject: Project direction In-Reply-To: References: Message-ID: <4322.1604355406@localhost> Angus Robertson - Magenta Systems Ltd wrote: > OpenSSL is really aimed at two markets, developers using the API and > admins using the applications, it would be easier for both groups if > the help was separate. I think that the "admins using the application" has never been a target. While people build CAs using the shell scripts, my impression is that this has been a discouraged activity. This is one reason I'd like the tools split off into it's own git repo, so that it could evolve separately. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ergzay at gmail.com Mon Nov 2 22:25:56 2020 From: ergzay at gmail.com (Ergzay) Date: Mon, 2 Nov 2020 14:25:56 -0800 Subject: Project direction Message-ID: On Nov 2, 2020, at 2:16 PM, Michael Richardson wrote: > Angus Robertson - Magenta Systems Ltd wrote: > > OpenSSL is really aimed at two markets, developers using the API and > > admins using the applications, it would be easier for both groups if > > the help was separate. > I think that the "admins using the application" has never been a target. > While people build CAs using the shell scripts, my impression is that this > has been a discouraged activity. > This is one reason I'd like the tools split off into it's own git repo, > so that it could evolve separately. Even if it was actually the case that "admins using the application" have never been the target, that is the primary use case as indicated by questions on *overflow (eg stack overflow) sites. You can find very few popular posts on said sites. This is also the case when searching on google. Try googling "how do I X in Openssl" and you'll get many articles discussing how to achieve various tasks using the command line tools. The majority of users of openssl are actually users of the openssl applications. From matt at openssl.org Tue Nov 3 11:56:33 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Nov 2020 11:56:33 +0000 Subject: OTC VOTE: DH Generation Message-ID: <04adb945-f07e-9cb5-b512-d41a221d6598@openssl.org> Background to the vote: The OTC meeting today had an extensive discussion on the issues raised in PR #13228. The code in master uses FIPS186-4 for key and parameter generation by default. In 1.1.1 and before we used PKCS#3 generation. This causes a number of backwards compatibility breaks as discussed in that PR. The proposed solution that was discussed is to support a number of different modes for parameter generation: - PKCS#3 - PKCS#3 compatible named groups (e.g. "generating" parameters for 2048 bit DH would actually just select an existing 2048-bit named group based on safe primes that is compatible for use with PKCS#3 DH) - FIPS186-2 - FIPS186-4 In the default provider we would default to using PKCS#3 generation for the DH key type, whilst in the FIPS provider we would use PKCS#3 compatible named groups. For parameter validation we will similarly allow a validation mode to be set depending on whether we are expecting PKCS#3, PKCS#3 compatible named groups, FIPS186-4 etc. The vote text is as follows: topic: For DH Generation, the OTC accepts the following resolution: * Quad-state generation: - PKCS #3; - named groups only; - FIPS 186-2 generation or - FIPS 186-4 generation. * For default provider: - change back to PKCS #3 generation as the default and - allow changing to FIPS 186-2, FIPS 186-4 or named groups. * For FIPS provider: - choose a known safe prime group as default (rejecting non-standard lengths) and - allow a change to FIPS 186-4 generation. * For parameter validation in FIPS: - accept if a named group; - run FIPS 186-4 validation if DHX key, otherwise reject. * For key validation: if a named group, do just partial key validation. * For validation more generally, allow a validation mode to be set. Proposed by Matt Caswell Public: yes opened: 2020-11-03 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim [+1] Richard [ 0] Shane [+1] Tomas [+1] Kurt [+1] Matthias [ 0] Nicola [+1] From matt at openssl.org Tue Nov 3 12:11:27 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Nov 2020 12:11:27 +0000 Subject: OTC VOTE: EVP_PKEY private/public key components Message-ID: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Background to the vote: The OTC meeting today discussed the problems raised by issue #12612. In summary the problem is that there has been a long standing, widespread and documented assumption that an EVP_PKEY with a private key will always also have the public key component. In spite of this it turns out that in the EC implementation in 1.1.1 it was perfectly possible to create an EVP_PKEY with only a private key and no public key - and it was also possible to use such an EVP_PKEY in a signing operation. The current 3.0 code in master introduced an explicit check (in line with the long held assumption) that the public key was present and rejected keys where this was not the case. This caused a backwards compatibility break for some users (as discussed at length in #12612). The OTC discussed a proposal that we should relax our conceptual model in this regards and conceptually allow EVP_PKEYs to exist that only have the private component without the public component - although individual algorithm implementations may still require both. It is possible to automatically generate the public component from the private for many algorithms, although this may come at a performance and (potentially) a security cost. The proposal discussed was that while relaxing the conceptual model, most of the existing implementations would still require both. The EC implementation would be relaxed however. This essentially gives largely compatible behaviour between 1.1.1 and 3.0. The vote text is as follows: topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: * relax the conceptual model to allow private keys to exist without public components; * all implementations apart from EC require the public component to be present; * relax implementation for EC key management to allow private keys that do not contain public keys and * our decoders unconditionally generate the public key (where possible). Proposed by Matt Caswell Public: yes opened: 2020-11-03 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim [ ] Richard [+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [-1] From paul.dale at oracle.com Wed Nov 4 03:52:29 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 4 Nov 2020 13:52:29 +1000 Subject: Proposed OMC vote: drop -crypt option from passwd app Message-ID: <10204C32-1020-4D4F-A471-F21B94C4F8AF@oracle.com> Proposed vote text: Remove the -crypt option from the passwd app. The rationale behind this is that this is a very old, long broken algorithm and that supporting it is difficult using non-deprecated calls. This is a breaking change and requires OMC approval. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Nov 4 03:56:07 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 4 Nov 2020 13:56:07 +1000 Subject: Proposed OMC vote to remove C source output from apps Message-ID: <28F936A4-71F4-444C-8D32-C38EC37D97CF@oracle.com> Proposed vote text: Remove -C option from the dhparam, dsaparam, ecparam and x509 apps. This is a breaking change and requires OMC approval. The rationale is that it is easier to not support this using the EVP calls and there is some doubt that the options are used anymore. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Nov 4 08:53:16 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 4 Nov 2020 08:53:16 +0000 Subject: Proposed OMC vote: drop -crypt option from passwd app In-Reply-To: <10204C32-1020-4D4F-A471-F21B94C4F8AF@oracle.com> References: <10204C32-1020-4D4F-A471-F21B94C4F8AF@oracle.com> Message-ID: I already proposed this and dropping the "-C" option back in October but I neglected to follow it up with actually starting the vote. https://mta.openssl.org/pipermail/openssl-project/2020-October/002366.html https://mta.openssl.org/pipermail/openssl-project/2020-October/002367.html I see no reason to delay this further so I will start these votes now. Matt On 04/11/2020 03:52, Dr Paul Dale wrote: > Proposed vote text: > > Remove the -crypt option from the passwd app. > > > The rationale behind this is that this is a very old, long broken > algorithm and that supporting it is difficult using non-deprecated > calls. ?This is a breaking change and requires OMC approval. > > > Pauli > --? > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations? > Phone +61 7 3031 7217 > Oracle Australia > > > > From matt at openssl.org Thu Nov 5 10:48:50 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 5 Nov 2020 10:48:50 +0000 Subject: Repo frozen Message-ID: <09392180-9a16-0ad7-9584-08a1b8f00400@openssl.org> Please note that the repo is currently frozen due to the forthcoming alpha 8 release later today. Matt From openssl at openssl.org Thu Nov 5 14:34:17 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 5 Nov 2020 14:34:17 +0000 Subject: OpenSSL version 3.0.0-alpha8 published Message-ID: <20201105143416.GA8468@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 8 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 8 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha8.tar.gz Size: 14011376 SHA1 checksum: a6063ebb15b4e600b60fbb50b3102c6f2e3438ff SHA256 checksum: a6c7b618a6a37cf0cebbc583b49e6d22d86e2d777e60173433eada074c32eea4 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha8.tar.gz openssl sha256 openssl-3.0.0-alpha8.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl+kBlYACgkQ2cTSbQ5g RJHOmQgAhqFZMut75DD4WChUdbwnlt+liy4SBVq+uG5zxSX8ayyiWoxkaQxMrI55 eyYWkLc05imDlM6dPgQQnBbLgDBUj6lPPN3bzAu/jPNC8Wk+9zwPdwLxKKnbMnoX gHGVFEuAJeILT6jldQwyHL1O+YV0KFANZE09jt/jBqaMtnT8pcVgxe+9txLtWVPw zLnh+t2Z9Pzhi8jz9I7LArVqgYOrnHHrFs1plzqz6YkTXCahGAoP5wtKFL1AS9eo J3EPrLNpLcYjLJWAt6kIgIP6J7pBxmqp5411b1dKAqSzNd6RTm8N11YNOP6lDCy9 28Mu393UJc5I8GvB+taGs8oMXxQCIQ== =Zocb -----END PGP SIGNATURE----- From matt at openssl.org Thu Nov 5 14:40:22 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 5 Nov 2020 14:40:22 +0000 Subject: Repo frozen In-Reply-To: <09392180-9a16-0ad7-9584-08a1b8f00400@openssl.org> References: <09392180-9a16-0ad7-9584-08a1b8f00400@openssl.org> Message-ID: The release has been done and repo is now unfrozen. Matt On 05/11/2020 10:48, Matt Caswell wrote: > Please note that the repo is currently frozen due to the forthcoming > alpha 8 release later today. > > Matt > From paul.dale at oracle.com Fri Nov 6 00:54:35 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 6 Nov 2020 10:54:35 +1000 Subject: Proposed OMC by law vote Message-ID: <9820EF96-A92E-4493-AE20-7937F8BEFDAE@oracle.com> Proposed vote text: Accept the by law changes proposed in #207. Comment: https://github.com/openssl/web/pull/207 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.heinrich at cmlh.id.au Fri Nov 6 06:49:58 2020 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Fri, 6 Nov 2020 17:49:58 +1100 Subject: Project direction In-Reply-To: References: <5AC4D5D6-F58C-4C97-BAD6-2F6D2F73BEF7@oracle.com> Message-ID: Richard, On Mon, 2 Nov 2020 at 10:47, Christian Heinrich wrote: > Maybe we should define the problems that new end users experience > during onboarding instead and address those first? On Tue, 3 Nov 2020 at 02:52, Dick Franks wrote: > Better documentation would help enormously. I would recommend first approaching John Viega, Matt Messier, Pravir Chandra et al to update https://www.oreilly.com/library/view/network-security-with/059600270X/ based on their reader's feedback since this book hasn't been updated since 2002. Ivan Risti? would also add value as https://www.feistyduck.com/books/openssl-cookbook/ was recently updated (March 2016) and teaches https://www.feistyduck.com/training/the-best-ssl-and-tls-training-in-the-world too. -- Regards, Christian Heinrich http://cmlh.id.au/contact From ivan.ristic at gmail.com Fri Nov 6 10:28:46 2020 From: ivan.ristic at gmail.com (Ivan Ristic) Date: Fri, 6 Nov 2020 10:28:46 +0000 Subject: OpenSSL Cookbook is being updated soon Message-ID: Apologies for starting a new thread, but I had no previous message to reply to. Matt alerted me to the mention of OpenSSL Cookbook here and I was previously not on this list. I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed the 3rd edition. This time I had Matt help me as a technical reviewer and that led to many improvements. We're currently updating our web site and will release the new edition as soon as that's done. The 3rd edition required many changes because of TLS 1.3. Now that it's done, going forward I will aim for continuous updates as needed. Additionally, we wish to make the content more useful by splitting it into smaller chunks. At the moment, it's presented as one page per chapter, which is not ideal. We will look into this at some point after the release. If you'd like to see the 3rd edition before it's officially out, you can actually get it immediately by registering for an account here https://www.feistyduck.com/account/register If you already have an account, it should be offered to you at the bottom of the library page https://www.feistyduck.com/library/ I would certainly welcome any thoughts about the content and the possible improvements. The scope is generally command-line usage. -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Nov 9 16:20:18 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 9 Nov 2020 16:20:18 +0000 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: 0 > -----Original Message----- > From: openssl-project On Behalf Of Matt Caswell > Sent: Tuesday, November 3, 2020 1:11 PM > To: openssl-project at openssl.org > Subject: OTC VOTE: EVP_PKEY private/public key components > > Background to the vote: > > The OTC meeting today discussed the problems raised by issue #12612. In > summary the problem is that there has been a long standing, widespread > and documented assumption that an EVP_PKEY with a private key will > always also have the public key component. > > In spite of this it turns out that in the EC implementation in 1.1.1 it > was perfectly possible to create an EVP_PKEY with only a private key and > no public key - and it was also possible to use such an EVP_PKEY in a > signing operation. > > The current 3.0 code in master introduced an explicit check (in line > with the long held assumption) that the public key was present and > rejected keys where this was not the case. This caused a backwards > compatibility break for some users (as discussed at length in #12612). > > The OTC discussed a proposal that we should relax our conceptual model > in this regards and conceptually allow EVP_PKEYs to exist that only have > the private component without the public component - although individual > algorithm implementations may still require both. > > It is possible to automatically generate the public component from the > private for many algorithms, although this may come at a performance and > (potentially) a security cost. > > The proposal discussed was that while relaxing the conceptual model, > most of the existing implementations would still require both. The EC > implementation would be relaxed however. This essentially gives largely > compatible behaviour between 1.1.1 and 3.0. > > The vote text is as follows: > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > * relax the conceptual model to allow private keys to exist without public > components; > * all implementations apart from EC require the public component to be > present; > * relax implementation for EC key management to allow private keys that > do not > contain public keys and > * our decoders unconditionally generate the public key (where possible). > > Proposed by Matt Caswell > Public: yes > opened: 2020-11-03 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [ ] > Richard [+1] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From tjh at cryptsoft.com Tue Nov 10 07:57:22 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Tue, 10 Nov 2020 17:57:22 +1000 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: -1 As I said in the OTC meeting, I agree we should change the conceptual model to not require a private key to be a super-set of a public key; however I do not think we should introduce key-type specific behaviour in this area - i.e. if it makes sense to change the model then it should apply equally to (for example) RSA keys as to EC keys. Tim. On Tue, Nov 10, 2020 at 2:20 AM Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > 0 > > > -----Original Message----- > > From: openssl-project On Behalf > Of Matt Caswell > > Sent: Tuesday, November 3, 2020 1:11 PM > > To: openssl-project at openssl.org > > Subject: OTC VOTE: EVP_PKEY private/public key components > > > > Background to the vote: > > > > The OTC meeting today discussed the problems raised by issue #12612. In > > summary the problem is that there has been a long standing, widespread > > and documented assumption that an EVP_PKEY with a private key will > > always also have the public key component. > > > > In spite of this it turns out that in the EC implementation in 1.1.1 it > > was perfectly possible to create an EVP_PKEY with only a private key and > > no public key - and it was also possible to use such an EVP_PKEY in a > > signing operation. > > > > The current 3.0 code in master introduced an explicit check (in line > > with the long held assumption) that the public key was present and > > rejected keys where this was not the case. This caused a backwards > > compatibility break for some users (as discussed at length in #12612). > > > > The OTC discussed a proposal that we should relax our conceptual model > > in this regards and conceptually allow EVP_PKEYs to exist that only have > > the private component without the public component - although individual > > algorithm implementations may still require both. > > > > It is possible to automatically generate the public component from the > > private for many algorithms, although this may come at a performance and > > (potentially) a security cost. > > > > The proposal discussed was that while relaxing the conceptual model, > > most of the existing implementations would still require both. The EC > > implementation would be relaxed however. This essentially gives largely > > compatible behaviour between 1.1.1 and 3.0. > > > > The vote text is as follows: > > > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > > * relax the conceptual model to allow private keys to exist without > public > > components; > > * all implementations apart from EC require the public component to be > > present; > > * relax implementation for EC key management to allow private keys that > > do not > > contain public keys and > > * our decoders unconditionally generate the public key (where possible). > > > > Proposed by Matt Caswell > > Public: yes > > opened: 2020-11-03 > > closed: 2020-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [+1] > > Mark [ ] > > Pauli [+1] > > Viktor [ ] > > Tim [ ] > > Richard [+1] > > Shane [+1] > > Tomas [+1] > > Kurt [ ] > > Matthias [ ] > > Nicola [-1] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Tue Nov 10 16:15:16 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 10 Nov 2020 18:15:16 +0200 Subject: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check` Message-ID: ## Background As part of the discussion in [issue #8435], it was highlighted that both in 1.1.1 and master we are missing tests to validate decoded SM2 keys. The `openssl pkey -check` (or `pkey -pubcheck` to validate only the public key component) command allows to explicitly execute the validation checks, while on regular operations (e.g., using `pkeyutl` or `dgst`) no validation of the input keys is normally done (probably by design). In [PR 13359] I am adding new tests, using `openssl pkey -check` to validate specific key corner cases, for P-256 as an exemplar for EC keys and for SM2 keys. Unfortunately `openssl pkey -check` behavior currently shows the result of the validation only in the text output, so parsing of `stdout` would require measuring the test results. In the PR I am proposing to change the behavior of `openssl pkey` so that an early exit is triggered if `-check` or `-pubcheck` validation fails, exiting with a failure exit status: [apps/pkey.c changes]. This is a breaking change in the behavior of `openssl pkey` and the reason why I am planning to raise a vote to approve this change. Note that during our OTC meeting today it was proposed as an alternative to have a more generic vote on approving this kind of change in general for all similar situations across all the apps. While I am not opposed to such a decision, I am afraid having such a generic vote might be quite difficult: - I am not sure I can express in a clear and unambiguous what are the conditions to fall within "similar situations", making such a decision hard to execute in practical terms; - I personally cannot commit to execute such vote across all apps and all relevant conditions: doing so requires extensive review of the apps logic in parsing the CLI switches, of conformity with existing documentation and an exploration of existing use patterns in the user codebase to see what are the expectations and estimate the impact of such changes. It would also require writing an extensive battery of tests to ensure we behave as documented/expected across apps and CLI switches. - The amount of work to which we would commit after such a generic decision, and the impact it could have on the behavior consistency w.r.t. 3.0 and 1.1.1, would make me think such a decision is more in the realm of strategic objectives, for which an OMC vote would be more appropriate. For these reasons, at this time, I am opting to propose an OTC vote on the single case of the behavior change of `pkey -check`/`pkey -pubcheck` rather than a more generic one, and I will let others decide if a more generic vote is also required/appropriate and if it can be framed exclusively within the technical prerogatives of the OTC decision process. ## Proposed vote text Change the behavior of `pkey -check` and `pkey -pubcheck` in 3.0 to trigger an early exit if validation fails, returning a failure exit status to the parent process. --- Please leave feedback relevant to the proposed vote text and the scope of the vote. In absence of feedback I plan to open the actual vote in 24h. Cheers, Nicola --- [issue #8435]: [PR 13359]: [apps/pkey.c changes]: From matt at openssl.org Wed Nov 11 09:10:47 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Nov 2020 09:10:47 +0000 Subject: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check` In-Reply-To: References: Message-ID: <3bc5805a-ea19-c41b-549c-f1058db137b8@openssl.org> I have no problem with the proposal or the vote text. I only wonder whether, as a breaking change an OMC vote is required? Or is an OTC vote sufficient? Matt On 10/11/2020 16:15, Nicola Tuveri wrote: > ## Background > > As part of the discussion in [issue #8435], it was highlighted that both > in 1.1.1 and master we are missing tests to validate decoded SM2 keys. > The `openssl pkey -check` (or `pkey -pubcheck` to validate only the > public key component) command allows to explicitly execute the > validation checks, while on regular operations (e.g., using `pkeyutl` or > `dgst`) no validation of the input keys is normally done (probably by > design). > > In [PR 13359] I am adding new tests, using `openssl pkey -check` to > validate specific key corner cases, for P-256 as an exemplar for EC keys > and for SM2 keys. > Unfortunately `openssl pkey -check` behavior currently shows the result > of the validation only in the text output, so parsing of `stdout` would > require measuring the test results. > In the PR I am proposing to change the behavior of `openssl pkey` so > that an early exit is triggered if `-check` or `-pubcheck` validation > fails, exiting with a failure exit status: [apps/pkey.c changes]. > > This is a breaking change in the behavior of `openssl pkey` and the > reason why I am planning to raise a vote to approve this change. > > Note that during our OTC meeting today it was proposed as an alternative > to have a more generic vote on approving this kind of change in general > for all similar situations across all the apps. > While I am not opposed to such a decision, I am afraid having such a > generic vote might be quite difficult: > > - I am not sure I can express in a clear and unambiguous what are the > conditions to fall within "similar situations", making such a > decision hard to execute in practical terms; > - I personally cannot commit to execute such vote across all apps and > all relevant conditions: doing so requires extensive review of the > apps logic in parsing the CLI switches, of conformity with existing > documentation and an exploration of existing use patterns in the user > codebase to see what are the expectations and estimate the impact of > such changes. It would also require writing an extensive battery of > tests to ensure we behave as documented/expected across apps and CLI > switches. > - The amount of work to which we would commit after such a generic > decision, and the impact it could have on the behavior consistency > w.r.t. 3.0 and 1.1.1, would make me think such a decision is more in > the realm of strategic objectives, for which an OMC vote would be more > appropriate. > > For these reasons, at this time, I am opting to propose an OTC vote on > the single case of the behavior change of `pkey -check`/`pkey -pubcheck` > rather than a more generic one, and I will let others decide if a more > generic vote is also required/appropriate and if it can be framed > exclusively within the technical prerogatives of the OTC decision > process. > > ## Proposed vote text > > Change the behavior of `pkey -check` > and `pkey -pubcheck` in 3.0 to trigger an > early exit if validation fails, returning a > failure exit status to the parent process. > > --- > > Please leave feedback relevant to the proposed vote text and the scope > of the vote. > In absence of feedback I plan to open the actual vote in 24h. > > > > Cheers, > > Nicola > > --- > > [issue #8435]: > [PR 13359]: > [apps/pkey.c changes]: > > From nic.tuv at gmail.com Wed Nov 11 09:16:01 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 11 Nov 2020 11:16:01 +0200 Subject: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check` In-Reply-To: <3bc5805a-ea19-c41b-549c-f1058db137b8@openssl.org> References: <3bc5805a-ea19-c41b-549c-f1058db137b8@openssl.org> Message-ID: That is a very good point I completely missed! Would you be available do "adopt" my vote and raise it as an OMC vote? Nicola On Wed, Nov 11, 2020, 11:10 Matt Caswell wrote: > I have no problem with the proposal or the vote text. I only wonder > whether, as a breaking change an OMC vote is required? Or is an OTC vote > sufficient? > > Matt > > > On 10/11/2020 16:15, Nicola Tuveri wrote: > > ## Background > > > > As part of the discussion in [issue #8435], it was highlighted that both > > in 1.1.1 and master we are missing tests to validate decoded SM2 keys. > > The `openssl pkey -check` (or `pkey -pubcheck` to validate only the > > public key component) command allows to explicitly execute the > > validation checks, while on regular operations (e.g., using `pkeyutl` or > > `dgst`) no validation of the input keys is normally done (probably by > > design). > > > > In [PR 13359] I am adding new tests, using `openssl pkey -check` to > > validate specific key corner cases, for P-256 as an exemplar for EC keys > > and for SM2 keys. > > Unfortunately `openssl pkey -check` behavior currently shows the result > > of the validation only in the text output, so parsing of `stdout` would > > require measuring the test results. > > In the PR I am proposing to change the behavior of `openssl pkey` so > > that an early exit is triggered if `-check` or `-pubcheck` validation > > fails, exiting with a failure exit status: [apps/pkey.c changes]. > > > > This is a breaking change in the behavior of `openssl pkey` and the > > reason why I am planning to raise a vote to approve this change. > > > > Note that during our OTC meeting today it was proposed as an alternative > > to have a more generic vote on approving this kind of change in general > > for all similar situations across all the apps. > > While I am not opposed to such a decision, I am afraid having such a > > generic vote might be quite difficult: > > > > - I am not sure I can express in a clear and unambiguous what are the > > conditions to fall within "similar situations", making such a > > decision hard to execute in practical terms; > > - I personally cannot commit to execute such vote across all apps and > > all relevant conditions: doing so requires extensive review of the > > apps logic in parsing the CLI switches, of conformity with existing > > documentation and an exploration of existing use patterns in the user > > codebase to see what are the expectations and estimate the impact of > > such changes. It would also require writing an extensive battery of > > tests to ensure we behave as documented/expected across apps and CLI > > switches. > > - The amount of work to which we would commit after such a generic > > decision, and the impact it could have on the behavior consistency > > w.r.t. 3.0 and 1.1.1, would make me think such a decision is more in > > the realm of strategic objectives, for which an OMC vote would be more > > appropriate. > > > > For these reasons, at this time, I am opting to propose an OTC vote on > > the single case of the behavior change of `pkey -check`/`pkey -pubcheck` > > rather than a more generic one, and I will let others decide if a more > > generic vote is also required/appropriate and if it can be framed > > exclusively within the technical prerogatives of the OTC decision > > process. > > > > ## Proposed vote text > > > > Change the behavior of `pkey -check` > > and `pkey -pubcheck` in 3.0 to trigger an > > early exit if validation fails, returning a > > failure exit status to the parent process. > > > > --- > > > > Please leave feedback relevant to the proposed vote text and the scope > > of the vote. > > In absence of feedback I plan to open the actual vote in 24h. > > > > > > > > Cheers, > > > > Nicola > > > > --- > > > > [issue #8435]: > > [PR 13359]: > > [apps/pkey.c changes]: > > < > https://github.com/openssl/openssl/pull/13359/files#diff-810c047ab642e686cab85b16802e9190bbc9f2f9bfce8a55fb8d6b744caa9091 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Nov 11 09:16:28 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 11 Nov 2020 19:16:28 +1000 Subject: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check` In-Reply-To: <3bc5805a-ea19-c41b-549c-f1058db137b8@openssl.org> References: <3bc5805a-ea19-c41b-549c-f1058db137b8@openssl.org> Message-ID: An OMC vote deeming that adding error checks like this are or are not considered breaking changes. My view is that detecting an error condition and returning an error code is a bug fix rather than a breaking change. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 11 Nov 2020, at 7:10 pm, Matt Caswell wrote: > > I have no problem with the proposal or the vote text. I only wonder > whether, as a breaking change an OMC vote is required? Or is an OTC vote > sufficient? > > Matt > > > On 10/11/2020 16:15, Nicola Tuveri wrote: >> ## Background >> >> As part of the discussion in [issue #8435], it was highlighted that both >> in 1.1.1 and master we are missing tests to validate decoded SM2 keys. >> The `openssl pkey -check` (or `pkey -pubcheck` to validate only the >> public key component) command allows to explicitly execute the >> validation checks, while on regular operations (e.g., using `pkeyutl` or >> `dgst`) no validation of the input keys is normally done (probably by >> design). >> >> In [PR 13359] I am adding new tests, using `openssl pkey -check` to >> validate specific key corner cases, for P-256 as an exemplar for EC keys >> and for SM2 keys. >> Unfortunately `openssl pkey -check` behavior currently shows the result >> of the validation only in the text output, so parsing of `stdout` would >> require measuring the test results. >> In the PR I am proposing to change the behavior of `openssl pkey` so >> that an early exit is triggered if `-check` or `-pubcheck` validation >> fails, exiting with a failure exit status: [apps/pkey.c changes]. >> >> This is a breaking change in the behavior of `openssl pkey` and the >> reason why I am planning to raise a vote to approve this change. >> >> Note that during our OTC meeting today it was proposed as an alternative >> to have a more generic vote on approving this kind of change in general >> for all similar situations across all the apps. >> While I am not opposed to such a decision, I am afraid having such a >> generic vote might be quite difficult: >> >> - I am not sure I can express in a clear and unambiguous what are the >> conditions to fall within "similar situations", making such a >> decision hard to execute in practical terms; >> - I personally cannot commit to execute such vote across all apps and >> all relevant conditions: doing so requires extensive review of the >> apps logic in parsing the CLI switches, of conformity with existing >> documentation and an exploration of existing use patterns in the user >> codebase to see what are the expectations and estimate the impact of >> such changes. It would also require writing an extensive battery of >> tests to ensure we behave as documented/expected across apps and CLI >> switches. >> - The amount of work to which we would commit after such a generic >> decision, and the impact it could have on the behavior consistency >> w.r.t. 3.0 and 1.1.1, would make me think such a decision is more in >> the realm of strategic objectives, for which an OMC vote would be more >> appropriate. >> >> For these reasons, at this time, I am opting to propose an OTC vote on >> the single case of the behavior change of `pkey -check`/`pkey -pubcheck` >> rather than a more generic one, and I will let others decide if a more >> generic vote is also required/appropriate and if it can be framed >> exclusively within the technical prerogatives of the OTC decision >> process. >> >> ## Proposed vote text >> >> Change the behavior of `pkey -check` >> and `pkey -pubcheck` in 3.0 to trigger an >> early exit if validation fails, returning a >> failure exit status to the parent process. >> >> --- >> >> Please leave feedback relevant to the proposed vote text and the scope >> of the vote. >> In absence of feedback I plan to open the actual vote in 24h. >> >> >> >> Cheers, >> >> Nicola >> >> --- >> >> [issue #8435]: > >> [PR 13359]: > >> [apps/pkey.c changes]: >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Wed Nov 11 09:22:22 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 11 Nov 2020 10:22:22 +0100 Subject: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check` In-Reply-To: References: <3bc5805a-ea19-c41b-549c-f1058db137b8@openssl.org> Message-ID: <0f3923e69e624394b0048c477addcf2ee9472b55.camel@redhat.com> Yep, frankly the current behavior of the app in regards to failing -check/-pubcheck does not make that much sense and really looks more like a bug than anything else. If the user does not care about the failure of the check and want to proceed with other actions, nothing stops them from just not specifying the check/pubcheck option. Tomas On Wed, 2020-11-11 at 19:16 +1000, Dr Paul Dale wrote: > An OMC vote deeming that adding error checks like this are or are not > considered breaking changes. > > My view is that detecting an error condition and returning an error > code is a bug fix rather than a breaking change. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > > On 11 Nov 2020, at 7:10 pm, Matt Caswell wrote: > > > > I have no problem with the proposal or the vote text. I only > > wonder > > whether, as a breaking change an OMC vote is required? Or is an OTC > > vote > > sufficient? > > > > Matt > > > > > > On 10/11/2020 16:15, Nicola Tuveri wrote: > > > ## Background > > > > > > As part of the discussion in [issue #8435], it was highlighted > > > that both > > > in 1.1.1 and master we are missing tests to validate decoded SM2 > > > keys. > > > The `openssl pkey -check` (or `pkey -pubcheck` to validate only > > > the > > > public key component) command allows to explicitly execute the > > > validation checks, while on regular operations (e.g., using > > > `pkeyutl` or > > > `dgst`) no validation of the input keys is normally done > > > (probably by > > > design). > > > > > > In [PR 13359] I am adding new tests, using `openssl pkey -check` > > > to > > > validate specific key corner cases, for P-256 as an exemplar for > > > EC keys > > > and for SM2 keys. > > > Unfortunately `openssl pkey -check` behavior currently shows the > > > result > > > of the validation only in the text output, so parsing of `stdout` > > > would > > > require measuring the test results. > > > In the PR I am proposing to change the behavior of `openssl pkey` > > > so > > > that an early exit is triggered if `-check` or `-pubcheck` > > > validation > > > fails, exiting with a failure exit status: [apps/pkey.c changes]. > > > > > > This is a breaking change in the behavior of `openssl pkey` and > > > the > > > reason why I am planning to raise a vote to approve this change. > > > > > > Note that during our OTC meeting today it was proposed as an > > > alternative > > > to have a more generic vote on approving this kind of change in > > > general > > > for all similar situations across all the apps. > > > While I am not opposed to such a decision, I am afraid having > > > such a > > > generic vote might be quite difficult: > > > > > > - I am not sure I can express in a clear and unambiguous what are > > > the > > > conditions to fall within "similar situations", making such a > > > decision hard to execute in practical terms; > > > - I personally cannot commit to execute such vote across all apps > > > and > > > all relevant conditions: doing so requires extensive review of > > > the > > > apps logic in parsing the CLI switches, of conformity with > > > existing > > > documentation and an exploration of existing use patterns in the > > > user > > > codebase to see what are the expectations and estimate the > > > impact of > > > such changes. It would also require writing an extensive battery > > > of > > > tests to ensure we behave as documented/expected across apps and > > > CLI > > > switches. > > > - The amount of work to which we would commit after such a > > > generic > > > decision, and the impact it could have on the behavior > > > consistency > > > w.r.t. 3.0 and 1.1.1, would make me think such a decision is > > > more in > > > the realm of strategic objectives, for which an OMC vote would > > > be more > > > appropriate. > > > > > > For these reasons, at this time, I am opting to propose an OTC > > > vote on > > > the single case of the behavior change of `pkey -check`/`pkey > > > -pubcheck` > > > rather than a more generic one, and I will let others decide if a > > > more > > > generic vote is also required/appropriate and if it can be framed > > > exclusively within the technical prerogatives of the OTC decision > > > process. > > > > > > ## Proposed vote text > > > > > > Change the behavior of `pkey -check` > > > and `pkey -pubcheck` in 3.0 to trigger an > > > early exit if validation fails, returning a > > > failure exit status to the parent process. > > > > > > --- > > > > > > Please leave feedback relevant to the proposed vote text and the > > > scope > > > of the vote. > > > In absence of feedback I plan to open the actual vote in 24h. > > > > > > > > > > > > Cheers, > > > > > > Nicola > > > > > > --- > > > > > > [issue #8435]: < > > > https://urldefense.com/v3/__https://github.com/openssl/openssl/issues/8435__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvrBSYf2E$ > > > > > > > [PR 13359]: < > > > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvd5hDbWk$ > > > > > > > [apps/pkey.c changes]: > > > < > > > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359/files*diff-810c047ab642e686cab85b16802e9190bbc9f2f9bfce8a55fb8d6b744caa9091__;Iw!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDv8zOO9ys$ > > > > > > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From nic.tuv at gmail.com Wed Nov 11 10:11:46 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 11 Nov 2020 12:11:46 +0200 Subject: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check` In-Reply-To: References: <3bc5805a-ea19-c41b-549c-f1058db137b8@openssl.org> Message-ID: I could see reasons to vote negatively for such a resolution in generic terms if I was voting on it: often the OpenSSL apps are part of critical PKI procedures and scripts. Such scripts might very well rely on the fact that this or that openssl command does not return a failure exit status in certain cases even if it reports the failure in its output or that as a side effect of reporting a failure some output file is not produced or created empty. A breaking change in such context can be strategically very bad for the project, with unintentional negative publicity consequences. A one by one decision on the mailing list would ring more bells and potentially trigger feedback about things that are going to be broken we were not aware of, compared to a silent change in a PR based on the generic decision, that could either inform the vote to decide to adopt different technical solutions or make the new breaking behavior opt-in, or give an opportunity to give more visibility to a breaking change and adapt the critical scripts and procedures to the new behavior before mayhem happens. Also the formulating a decision with "error checks like this" (or a more formal text description) has the risk of being difficult to apply: it shifts the responsibility of deciding if the case is similar enough onto the reviewers of the individual PR. Anyway, I agree that general or specific there should be an OMC vote about this rather than an OTC vote: I'll drop my OTC vote proposal and wait for a OMC resolution on the matter. Can someone from the OMC take the initiative to propose the OMC vote that they believe is the more appropriate and move this forward? (can that person also covert the OTC hold label I put on #13359 into an OMC hold label?) Cheers, Nicola On Wed, Nov 11, 2020, 11:16 Dr Paul Dale wrote: > An OMC vote deeming that adding error checks like this are or are not > considered breaking changes. > > My view is that detecting an error condition and returning an error code > is a bug fix rather than a breaking change. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 11 Nov 2020, at 7:10 pm, Matt Caswell wrote: > > I have no problem with the proposal or the vote text. I only wonder > whether, as a breaking change an OMC vote is required? Or is an OTC vote > sufficient? > > Matt > > > On 10/11/2020 16:15, Nicola Tuveri wrote: > > ## Background > > As part of the discussion in [issue #8435], it was highlighted that both > in 1.1.1 and master we are missing tests to validate decoded SM2 keys. > The `openssl pkey -check` (or `pkey -pubcheck` to validate only the > public key component) command allows to explicitly execute the > validation checks, while on regular operations (e.g., using `pkeyutl` or > `dgst`) no validation of the input keys is normally done (probably by > design). > > In [PR 13359] I am adding new tests, using `openssl pkey -check` to > validate specific key corner cases, for P-256 as an exemplar for EC keys > and for SM2 keys. > Unfortunately `openssl pkey -check` behavior currently shows the result > of the validation only in the text output, so parsing of `stdout` would > require measuring the test results. > In the PR I am proposing to change the behavior of `openssl pkey` so > that an early exit is triggered if `-check` or `-pubcheck` validation > fails, exiting with a failure exit status: [apps/pkey.c changes]. > > This is a breaking change in the behavior of `openssl pkey` and the > reason why I am planning to raise a vote to approve this change. > > Note that during our OTC meeting today it was proposed as an alternative > to have a more generic vote on approving this kind of change in general > for all similar situations across all the apps. > While I am not opposed to such a decision, I am afraid having such a > generic vote might be quite difficult: > > - I am not sure I can express in a clear and unambiguous what are the > conditions to fall within "similar situations", making such a > decision hard to execute in practical terms; > - I personally cannot commit to execute such vote across all apps and > all relevant conditions: doing so requires extensive review of the > apps logic in parsing the CLI switches, of conformity with existing > documentation and an exploration of existing use patterns in the user > codebase to see what are the expectations and estimate the impact of > such changes. It would also require writing an extensive battery of > tests to ensure we behave as documented/expected across apps and CLI > switches. > - The amount of work to which we would commit after such a generic > decision, and the impact it could have on the behavior consistency > w.r.t. 3.0 and 1.1.1, would make me think such a decision is more in > the realm of strategic objectives, for which an OMC vote would be more > appropriate. > > For these reasons, at this time, I am opting to propose an OTC vote on > the single case of the behavior change of `pkey -check`/`pkey -pubcheck` > rather than a more generic one, and I will let others decide if a more > generic vote is also required/appropriate and if it can be framed > exclusively within the technical prerogatives of the OTC decision > process. > > ## Proposed vote text > > Change the behavior of `pkey -check` > and `pkey -pubcheck` in 3.0 to trigger an > early exit if validation fails, returning a > failure exit status to the parent process. > > --- > > Please leave feedback relevant to the proposed vote text and the scope > of the vote. > In absence of feedback I plan to open the actual vote in 24h. > > > > Cheers, > > Nicola > > --- > > [issue #8435]: < > https://urldefense.com/v3/__https://github.com/openssl/openssl/issues/8435__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvrBSYf2E$ > > > [PR 13359]: < > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvd5hDbWk$ > > > [apps/pkey.c changes]: > < > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359/files*diff-810c047ab642e686cab85b16802e9190bbc9f2f9bfce8a55fb8d6b744caa9091__;Iw!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDv8zOO9ys$ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Wed Nov 11 14:14:02 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 11 Nov 2020 16:14:02 +0200 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: In light of recently working more closely to `EVP_PKEY_check()` I would add to the discussion on this vote that it is not entirely true that we were not enforcing the keypair assumption and that the current strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t. some uses that work in 1.1.1. In particular in 1.1.1, the key created as depicted in #12612 that triggered this discussion (Matt posted a useful reproducer among the first comments), is indeed capable of signing in the used pattern, but the pattern is conveniently omitting the validation pass that should be required in any serious use of the API. `EVP_PKEY_check()` (https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html) is one of the many places in 1.1.1 where both the documentation and the behavior assume that an `EVP_PKEY` object is a keypair. Even in the version used by the user that posted the issue, running `EVP_PKEY_check()` on the created key would have revealed that the user was abusing the API. The "lack of enforcement" argument, that was partially at the base of formulating the vote text as it is, and conditioned our votes, seems to me an intentional design choice, as part of preferring the usage pattern "validate once, and reuse many times": for performance reasons we are not running `EVP_PKEY_check()` on every single key loaded from a PEM file or created by the user, but there is an assumption that the user did validate at least once the key material using `EVP_PKEY_check()` or `openssl pkey -check`. So enforcement was never lacking, but it was relegated together with more expensive checks, into functions that the user should execute at least once, possibly according to well documented security policies concerning the management of key material in transit and at rest. Omitting the `EVP_PKEY_check()` in the reproducer and the user application, would for example allow me to write a DoS attack: the secret scalar could easily be hand-picked to trigger an endless loop in the sign operation. -- Nicola On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell wrote: > > Background to the vote: > > The OTC meeting today discussed the problems raised by issue #12612. In > summary the problem is that there has been a long standing, widespread > and documented assumption that an EVP_PKEY with a private key will > always also have the public key component. > > In spite of this it turns out that in the EC implementation in 1.1.1 it > was perfectly possible to create an EVP_PKEY with only a private key and > no public key - and it was also possible to use such an EVP_PKEY in a > signing operation. > > The current 3.0 code in master introduced an explicit check (in line > with the long held assumption) that the public key was present and > rejected keys where this was not the case. This caused a backwards > compatibility break for some users (as discussed at length in #12612). > > The OTC discussed a proposal that we should relax our conceptual model > in this regards and conceptually allow EVP_PKEYs to exist that only have > the private component without the public component - although individual > algorithm implementations may still require both. > > It is possible to automatically generate the public component from the > private for many algorithms, although this may come at a performance and > (potentially) a security cost. > > The proposal discussed was that while relaxing the conceptual model, > most of the existing implementations would still require both. The EC > implementation would be relaxed however. This essentially gives largely > compatible behaviour between 1.1.1 and 3.0. > > The vote text is as follows: > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > * relax the conceptual model to allow private keys to exist without public > components; > * all implementations apart from EC require the public component to be > present; > * relax implementation for EC key management to allow private keys that > do not > contain public keys and > * our decoders unconditionally generate the public key (where possible). > > Proposed by Matt Caswell > Public: yes > opened: 2020-11-03 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [ ] > Richard [+1] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] From shane.lontis at oracle.com Wed Nov 11 21:55:18 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Thu, 12 Nov 2020 07:55:18 +1000 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: <61151243-4F87-493B-87E6-DFF75CEB9B8E@oracle.com> Key assurance really depends on what you are doing, so I don't think this is quite true. For example if you generate a key using a valid algorithm (that is validated by a lab), then there is already an assurance that the key is valid without needing to run EVP_PKEY_check(). There are many operations that don't need EVP_PKEY_check, but they may need a sub check such as EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or EVP_PKEY_pairwise_check (or some combination of those). Keys (and certs) that are received from another entity should be validated unless there is some other mechanism for establishing that the key is trusted. > On 12 Nov 2020, at 12:14 am, Nicola Tuveri wrote: > > In light of recently working more closely to `EVP_PKEY_check()` I > would add to the discussion on this vote that it is not entirely true > that we were not enforcing the keypair assumption and that the current > strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t. > some uses that work in 1.1.1. > > In particular in 1.1.1, the key created as depicted in #12612 that > triggered this discussion (Matt posted a useful reproducer among the > first comments), is indeed capable of signing in the used pattern, but > the pattern is conveniently omitting the validation pass that should > be required in any serious use of the API. > > `EVP_PKEY_check()` > (https://urldefense.com/v3/__https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html__;!!GqivPVa7Brio!PdWuiQz52CFt9zZk9s6He6IimqtSPbLrvJ1ck_RKJIydCE80FY4lRl-WD8v1m4r6Zg$ ) is > one of the many places in 1.1.1 where both the documentation and the > behavior assume that an `EVP_PKEY` object is a keypair. > Even in the version used by the user that posted the issue, running > `EVP_PKEY_check()` on the created key would have revealed that the > user was abusing the API. > > The "lack of enforcement" argument, that was partially at the base of > formulating the vote text as it is, and conditioned our votes, seems > to me an intentional design choice, as part of preferring the usage > pattern "validate once, and reuse many times": for performance reasons > we are not running `EVP_PKEY_check()` on every single key loaded from > a PEM file or created by the user, but there is an assumption that the > user did validate at least once the key material using > `EVP_PKEY_check()` or `openssl pkey -check`. > So enforcement was never lacking, but it was relegated together with > more expensive checks, into functions that the user should execute at > least once, possibly according to well documented security policies > concerning the management of key material in transit and at rest. > > Omitting the `EVP_PKEY_check()` in the reproducer and the user > application, would for example allow me to write a DoS attack: the > secret scalar could easily be hand-picked to trigger an endless loop > in the sign operation. > > > -- > > Nicola > > > > On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell wrote: >> >> Background to the vote: >> >> The OTC meeting today discussed the problems raised by issue #12612. In >> summary the problem is that there has been a long standing, widespread >> and documented assumption that an EVP_PKEY with a private key will >> always also have the public key component. >> >> In spite of this it turns out that in the EC implementation in 1.1.1 it >> was perfectly possible to create an EVP_PKEY with only a private key and >> no public key - and it was also possible to use such an EVP_PKEY in a >> signing operation. >> >> The current 3.0 code in master introduced an explicit check (in line >> with the long held assumption) that the public key was present and >> rejected keys where this was not the case. This caused a backwards >> compatibility break for some users (as discussed at length in #12612). >> >> The OTC discussed a proposal that we should relax our conceptual model >> in this regards and conceptually allow EVP_PKEYs to exist that only have >> the private component without the public component - although individual >> algorithm implementations may still require both. >> >> It is possible to automatically generate the public component from the >> private for many algorithms, although this may come at a performance and >> (potentially) a security cost. >> >> The proposal discussed was that while relaxing the conceptual model, >> most of the existing implementations would still require both. The EC >> implementation would be relaxed however. This essentially gives largely >> compatible behaviour between 1.1.1 and 3.0. >> >> The vote text is as follows: >> >> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: >> * relax the conceptual model to allow private keys to exist without public >> components; >> * all implementations apart from EC require the public component to be >> present; >> * relax implementation for EC key management to allow private keys that >> do not >> contain public keys and >> * our decoders unconditionally generate the public key (where possible). >> >> Proposed by Matt Caswell >> Public: yes >> opened: 2020-11-03 >> closed: 2020-mm-dd >> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) >> >> Matt [+1] >> Mark [ ] >> Pauli [+1] >> Viktor [ ] >> Tim [ ] >> Richard [+1] >> Shane [+1] >> Tomas [+1] >> Kurt [ ] >> Matthias [ ] >> Nicola [-1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Nov 11 22:32:12 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 12 Nov 2020 08:32:12 +1000 Subject: Vote results: remove -crypt option from passwd and C source output options Message-ID: <8AC1CE73-AE7B-4F72-AF15-E77052A48F93@oracle.com> Vote: Drop from 3.0 support for the '-crypt' option from the passwd application For: 6, Against: 0, Abstain: 0, Didn?t vote: 1 The vote passes. Vote: Drop from 3.0 support for the C code output options from the applications where the use of deprecated APIs is required For: 4, Against: 0, Abstain: 2, Didn?t vote: 1 The vote passes. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia From nic.tuv at gmail.com Wed Nov 11 22:34:53 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 12 Nov 2020 00:34:53 +0200 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <61151243-4F87-493B-87E6-DFF75CEB9B8E@oracle.com> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> <61151243-4F87-493B-87E6-DFF75CEB9B8E@oracle.com> Message-ID: Usually the labs provide assurances on the key generation and the other cryptographic operations, including validation, but have special provisions to avoid providing assurances on key serialization and deserialization. This seems particularly true in the context of the FIPS validation for OpenSSL, where the encoders/decoders are outside the scope of the FIPS module and of validation. The issue that triggered this discussion is particularly an issue of encoding/decoding: the user application uses a custom format, and that is the reason why the `EVP_PKEY` object is built from an `EC_KEY` object built from scratch. The application has only these ways to validate if the created `EVP_PKEY` object is valid from a programmer's perspective AND as a cryptographic object: - EVP_PKEY_check (check an EVP_PKEY keypair) - EVP_PKEY_public_check (check an EVP_PKEY pubkey, or just the public component of an EVP_PKEY keypair) - EVP_PKEY_param_check (check an EVP_PKEY params object, or just the params component of an EVP_PKEY keypair or pubkey) By design the consistency checks and validation checks are omitted unless these functions are called, and there is no EVP_PKEY_private_check. To me this proves that what was described as a "breaking change" in 3.0 with strict EC keymgmt, is instead a programmer error in the application that abused the API with an incomplete initialization, which would have been detected if the dedicated validation functions were called appropriately. Even if the security policies that apply to the users of that application wouldn't require to validate the cryptographic properties of the key every time they are loaded because of external processes and assurances, the developers of the application would have discovered they were abusing the API if they tried validating the half-initialized objects even just in development builds, which in my opinion debunks the "lack of enforcement" argument that partially supported the discussion that led to this vote. In light of this I would dare say that: a) the current "strict" state of EC keymgmt in 3.0 does not represent a "breaking change" w.r.t 1.1.1, as it only catches existing API abuses that were catched in 1.1.1, if only the half-initialized objects were validated b) relaxing the "keypair assumption" for EVP_PKEY objects is entirely a new feature Neither of these points makes the vote "invalid", but they could change some of the casted votes, and they would strengthen my -1 in a -2 if it were an option. -- Nicola P.S. For the record, given that I expressed this mostly in the virtual meetings rather than in the discussion thread in the mailing list, while from these emails it might seem like I hate with fiery rage the idea of relaxing the keypair assumption, this is not really the case. My main concern is changing this deeply rooted and pervasive assumption in the timeframe of the 3.0 release, and with (IMO) insufficient test coverage to make sure that we can transition to a more relaxed model without introducing defects that could translate into security risks. On Wed, Nov 11, 2020 at 11:58 PM SHANE LONTIS wrote: > > Key assurance really depends on what you are doing, so I don't think this is quite true. > For example if you generate a key using a valid algorithm (that is validated by a lab), then there is already an assurance that the key is valid without needing to run EVP_PKEY_check(). > > There are many operations that don't need EVP_PKEY_check, but they may need a sub check such as > EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or EVP_PKEY_pairwise_check (or some combination of those). > Keys (and certs) that are received from another entity should be validated unless there is some other mechanism for establishing that the key is trusted. > > > On 12 Nov 2020, at 12:14 am, Nicola Tuveri wrote: > > In light of recently working more closely to `EVP_PKEY_check()` I > would add to the discussion on this vote that it is not entirely true > that we were not enforcing the keypair assumption and that the current > strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t. > some uses that work in 1.1.1. > > In particular in 1.1.1, the key created as depicted in #12612 that > triggered this discussion (Matt posted a useful reproducer among the > first comments), is indeed capable of signing in the used pattern, but > the pattern is conveniently omitting the validation pass that should > be required in any serious use of the API. > > `EVP_PKEY_check()` > (https://urldefense.com/v3/__https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html__;!!GqivPVa7Brio!PdWuiQz52CFt9zZk9s6He6IimqtSPbLrvJ1ck_RKJIydCE80FY4lRl-WD8v1m4r6Zg$ ) is > one of the many places in 1.1.1 where both the documentation and the > behavior assume that an `EVP_PKEY` object is a keypair. > Even in the version used by the user that posted the issue, running > `EVP_PKEY_check()` on the created key would have revealed that the > user was abusing the API. > > The "lack of enforcement" argument, that was partially at the base of > formulating the vote text as it is, and conditioned our votes, seems > to me an intentional design choice, as part of preferring the usage > pattern "validate once, and reuse many times": for performance reasons > we are not running `EVP_PKEY_check()` on every single key loaded from > a PEM file or created by the user, but there is an assumption that the > user did validate at least once the key material using > `EVP_PKEY_check()` or `openssl pkey -check`. > So enforcement was never lacking, but it was relegated together with > more expensive checks, into functions that the user should execute at > least once, possibly according to well documented security policies > concerning the management of key material in transit and at rest. > > Omitting the `EVP_PKEY_check()` in the reproducer and the user > application, would for example allow me to write a DoS attack: the > secret scalar could easily be hand-picked to trigger an endless loop > in the sign operation. > > > -- > > Nicola > > > > On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell wrote: > > > Background to the vote: > > The OTC meeting today discussed the problems raised by issue #12612. In > summary the problem is that there has been a long standing, widespread > and documented assumption that an EVP_PKEY with a private key will > always also have the public key component. > > In spite of this it turns out that in the EC implementation in 1.1.1 it > was perfectly possible to create an EVP_PKEY with only a private key and > no public key - and it was also possible to use such an EVP_PKEY in a > signing operation. > > The current 3.0 code in master introduced an explicit check (in line > with the long held assumption) that the public key was present and > rejected keys where this was not the case. This caused a backwards > compatibility break for some users (as discussed at length in #12612). > > The OTC discussed a proposal that we should relax our conceptual model > in this regards and conceptually allow EVP_PKEYs to exist that only have > the private component without the public component - although individual > algorithm implementations may still require both. > > It is possible to automatically generate the public component from the > private for many algorithms, although this may come at a performance and > (potentially) a security cost. > > The proposal discussed was that while relaxing the conceptual model, > most of the existing implementations would still require both. The EC > implementation would be relaxed however. This essentially gives largely > compatible behaviour between 1.1.1 and 3.0. > > The vote text is as follows: > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > * relax the conceptual model to allow private keys to exist without public > components; > * all implementations apart from EC require the public component to be > present; > * relax implementation for EC key management to allow private keys that > do not > contain public keys and > * our decoders unconditionally generate the public key (where possible). > > Proposed by Matt Caswell > Public: yes > opened: 2020-11-03 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [ ] > Richard [+1] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] > > From matt at openssl.org Thu Nov 12 09:36:52 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Nov 2020 09:36:52 +0000 Subject: SM2 asymmetric encryption In-Reply-To: References: Message-ID: <4169403d-63ed-f31c-98da-8e580175879f@openssl.org> I realised I forgot to report back on the results of this vote. Subsequent to the vote starting we actually implemented this anyway, and therefore we unanimously decided to vote this proposal down: For: 0, Against: 7, Abstain: 0, No vote: 0 Matt On 14/09/2020 09:18, Matt Caswell wrote: > Currently, 1.1.1 supports SM2 asymmetric encryption. Real world use of > this is currently believed to be low (IIUC it is mainly useful for SM2 > in TLS, which we don't current support). A discussion in PR #12536 is > proposing to drop this feature from 3.0 (possibly to re-introduce it in > some later release). This was mentioned on this list by me in this post: > > https://mta.openssl.org/pipermail/openssl-project/2020-August/002138.html > > No feedback has been received on that point. It was also discussed at > the recent OMC f2f (although no vote was held on the issue). Since > dropping this support is a breaking change it requires an OMC vote to > approve it. I'm proposing this vote wording: > > "Support for SM2 asymmetric encryption should be dropped from OpenSSL 3.0" > > Please let me know any thoughts on the vote wording (or any other > thoughts on the topic). Otherwise I plan to start this vote soon. > > Matt > From rwfranks at acm.org Wed Nov 11 18:48:40 2020 From: rwfranks at acm.org (Dick Franks) Date: Wed, 11 Nov 2020 18:48:40 +0000 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: On Wed, 11 Nov 2020 at 14:14, Nicola Tuveri wrote: > > In particular in 1.1.1, the key created as depicted in #12612 that > triggered this discussion (Matt posted a useful reproducer among the > first comments), is indeed capable of signing in the used pattern, but > the pattern is conveniently omitting the validation pass that should > be required in any serious use of the API. > The private key is a random or pseudo-random 256-bit integer. How do you propose to "validate" that? > `EVP_PKEY_check()` > (https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html) is > one of the many places in 1.1.1 where both the documentation and the > behavior assume that an `EVP_PKEY` object is a keypair. > Even in the version used by the user that posted the issue, running > `EVP_PKEY_check()` on the created key would have revealed that the > user was abusing the API. > I was not "abusing the API" as you put it, merely pointing out that the public key is not a required item for performing ECDSA signature generation. This is a mathematical fact of life that you are going to have to learn to live with. > >8 > > Omitting the `EVP_PKEY_check()` in the reproducer and the user > application, would for example allow me to write a DoS attack: the > secret scalar could easily be hand-picked to trigger an endless loop > in the sign operation. > Nonsense. Each iteration involves a new PRN, which by definition you cannot predict. --RWF -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Thu Nov 12 10:33:13 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 12 Nov 2020 12:33:13 +0200 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: On Thu, Nov 12, 2020 at 11:42 AM Dick Franks wrote: > > On Wed, 11 Nov 2020 at 14:14, Nicola Tuveri wrote: >> >> >> In particular in 1.1.1, the key created as depicted in #12612 that >> triggered this discussion (Matt posted a useful reproducer among the >> first comments), is indeed capable of signing in the used pattern, but >> the pattern is conveniently omitting the validation pass that should >> be required in any serious use of the API. > > > The private key is a random or pseudo-random 256-bit integer. > How do you propose to "validate" that? For ECDSA it's not a a random or pseudo-random 256-bit integer: it's a random or pseudo-random integer `k`, with `1 <= k < n`, not all 256-bit integers fit into this definition for a 256-bit prime `n` (where `n` is the order of the generator point for the curve. Validating the private key guarantees that the input private scalar is within the correct range. Sidenote: I don't know how the software in question does keygen, if it is happening outside of OpenSSL or not, but validating the key generation step is also crucial, because the random integer generation should have a uniform distribution over the whole range without any biases. >> >> `EVP_PKEY_check()` >> (https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html) is >> one of the many places in 1.1.1 where both the documentation and the >> behavior assume that an `EVP_PKEY` object is a keypair. >> Even in the version used by the user that posted the issue, running >> `EVP_PKEY_check()` on the created key would have revealed that the >> user was abusing the API. > > > I was not "abusing the API" as you put it, merely pointing out that the public key is not a required item for performing ECDSA signature generation. This is a mathematical fact of life that you are going to have to learn to live with. > If the documentation of the API says that an `EVP_PKEY` must include a full keypair, and the functions to validate a manually initialized `EVP_PKEY` object enforce this, then I stand by my assessment that writing software that intentionally initializes a non-compliant `EVP_PKEY` object which would not pass validation functions of the API (where the documented assumption is enforced) configures as an "API abuse" from a programming point of view. I agree that performing an ECDSA signature generation does not require the public key, and that would be reason in favor of relaxing the assumption. I am not saying it is wrong to want to generate signatures only with the private key, I am saying that it does not fit well with the OpenSSL API design (and with most other cryptographic libraries, not just OpenSSL forks, that also have similar "keypair assumptions"). A counter argument to yours is that ECDSA signature verification requires only the public component, and it is a mathematical fact of life that knowledge of the private component in this case implies knowledge of the public component. A user of a cryptographic library can therefore expect that an abstract key object embedding knowledge of the private key is capable of being used in operations requiring knowledge of the public component, including ECDSA signature verification. Computing the public component on demand only when such operation is requested is a sub-optimal design choice from both performance and security points of views, and robust cryptographic libraries have to deal with it. We can reach different compromises, relaxing the documented assumption as this vote proposes, and then offering API functions for the most generic use cases and specialized API functions for specific use cases like yours. I'm not arguing against doing that moving forward, I am arguing about categorizing the current strict behavior of EC keymgmt in 3.0 as a "breaking change" and considering the current use pattern of the reproducer in #12612 against 1.1.1 as "supported" in the current LTS release. >> >> Omitting the `EVP_PKEY_check()` in the reproducer and the user >> application, would for example allow me to write a DoS attack: the >> secret scalar could easily be hand-picked to trigger an endless loop >> in the sign operation. > > > Nonsense. Each iteration involves a new PRN, which by definition you cannot predict. ~~~sh ; which openssl; openssl version /usr/bin/openssl OpenSSL 1.1.1f 31 Mar 2020 ; cat > /tmp/p256_invalid.pem -----BEGIN PRIVATE KEY----- MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/////AAAAAP////// ////vOb6racXnoTzucrC/GMlUQ== -----END PRIVATE KEY----- ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem Key is invalid Detailed error: point at infinity Private-Key: (256 bit) priv: ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff: ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63: 25:51 pub: 00 ASN1 OID: prime256v1 NIST CURVE: P-256 ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32 ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash -out /tmp/sig.der # here is the infinite loop ~~~ -- Nicola From kurt at roeckx.be Sun Nov 15 21:36:54 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 15 Nov 2020 22:36:54 +0100 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: <20201115213654.GA33562@roeckx.be> On Tue, Nov 03, 2020 at 12:11:27PM +0000, Matt Caswell wrote: > > The proposal discussed was that while relaxing the conceptual model, > most of the existing implementations would still require both. The EC > implementation would be relaxed however. This essentially gives largely > compatible behaviour between 1.1.1 and 3.0. > > The vote text is as follows: > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > * relax the conceptual model to allow private keys to exist without public > components; > * all implementations apart from EC require the public component to be > present; > * relax implementation for EC key management to allow private keys that > do not > contain public keys and > * our decoders unconditionally generate the public key (where possible). > > Proposed by Matt Caswell > Public: yes > opened: 2020-11-03 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) So I think being compatible with what 1.1.1 does is important. And what the text does is try to make rules for what 1.1.1 does, but as far as I understand it, it's not really describing what 1.1.1 does. I think we should just fix the regressions. For fixing the regressions we don't need a vote. You can argue that that would violate some rule or model that some people think we have, but clearly we didn't have it. So I'm voting -1. Kurt From beldmit at gmail.com Mon Nov 16 08:37:24 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 16 Nov 2020 11:37:24 +0300 Subject: Job Change Message-ID: Dear colleagues, If everything is OK, I join the RedHat team on December 1. As it's planned now, I join the department where Tomas Mraz works. I strongly suppose that being an OpenSSL committer was a significant argument for the RedHat to send me an offer, and hope I'll be able to continue my activity as a committer. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Sat Nov 14 21:45:35 2020 From: rwfranks at acm.org (Dick Franks) Date: Sat, 14 Nov 2020 21:45:35 +0000 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: On Thu, 12 Nov 2020 at 10:33, Nicola Tuveri wrote: > > >8 > > > The private key is a random or pseudo-random 256-bit integer. > > How do you propose to "validate" that? > > For ECDSA it's not a a random or pseudo-random 256-bit integer: it's a > random or pseudo-random integer `k`, with `1 <= k < n`, not all > 256-bit integers fit into this definition for a 256-bit prime `n` > (where `n` is the order of the generator point for the curve. > Validating the private key guarantees that the input private scalar is > within the correct range. > The key generator is responsible for that, not the signer. > > Sidenote: I don't know how the software in question does keygen, if it > is happening outside of OpenSSL or not, but validating the key > generation step is also crucial, because the random integer generation > should have a uniform distribution over the whole range without any > biases. > If you do not know how the keys are generated, it is obvious that you have not read #12612 > > > > I was not "abusing the API" as you put it, merely pointing out that the > public key is not a required item for performing ECDSA signature > generation. This is a mathematical fact of life that you are going to have > to learn to live with. > > > > I agree that performing an ECDSA signature generation does not require > the public key, and that would be reason in favor of relaxing the > assumption. > So why do you persist in arguing against it? > I am not saying it is wrong to want to generate signatures only with > the private key, I am saying that it does not fit well with the > OpenSSL API design (and with most other cryptographic libraries, not > just OpenSSL forks, that also have similar "keypair assumptions"). > If OpenSSL API design conflicts with the well-understood requirements of EC cryptography, then OpenSSL will need to change, because the mathematics certainly is not going to change. > > A counter argument to yours is that ECDSA signature verification > requires only the public component, and it is a mathematical fact of > life that knowledge of the private component in this case implies > knowledge of the public component. > So what? > A user of a cryptographic library can therefore expect that an > abstract key object embedding knowledge of the private key is capable > of being used in operations requiring knowledge of the public > component, including ECDSA signature verification. > If I know the private key, I have no need at all to verify a signature using the public key. > Computing the public component on demand only when such operation is > requested is a sub-optimal design choice from both performance and > security points of views, and robust cryptographic libraries have to > deal with it. > Agree > We can reach different compromises, relaxing the documented assumption > as this vote proposes, and then offering API functions for the most > generic use cases and specialized API functions for specific use cases > like yours. I'm not arguing against doing that moving forward, I am > arguing about categorizing the current strict behavior of EC keymgmt > in 3.0 as a "breaking change" and considering the current use pattern > of the reproducer in #12612 against 1.1.1 as "supported" in the > current LTS release. > #12612 reports a change which breaks code that runs on every version from 1.0.1 to 3.0.0-alpha5. > > >> > >> Omitting the `EVP_PKEY_check()` in the reproducer and the user > >> application, would for example allow me to write a DoS attack: the > >> secret scalar could easily be hand-picked to trigger an endless loop > >> in the sign operation. > There exists no private key value which will cause the EVP_sign operation to enter an endless loop. The operation will always return a result, which may not be useful if it is impossible to generate the corresponding public key. > ~~~sh > ; which openssl; openssl version > /usr/bin/openssl > OpenSSL 1.1.1f 31 Mar 2020 > ; cat > /tmp/p256_invalid.pem > -----BEGIN PRIVATE KEY----- > MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/////AAAAAP////// > ////vOb6racXnoTzucrC/GMlUQ== > -----END PRIVATE KEY----- > ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem > Key is invalid > Detailed error: point at infinity > Private-Key: (256 bit) > priv: > ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff: > ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63: > 25:51 > pub: > 00 > ASN1 OID: prime256v1 > NIST CURVE: P-256 > ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32 > ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash > -out /tmp/sig.der > # here is the infinite loop > ~~~ > > ROFL! --RWF -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbrumley at gmail.com Mon Nov 16 13:11:43 2020 From: bbrumley at gmail.com (Billy Brumley) Date: Mon, 16 Nov 2020 15:11:43 +0200 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: >> > The private key is a random or pseudo-random 256-bit integer. >> > How do you propose to "validate" that? >> >> For ECDSA it's not a a random or pseudo-random 256-bit integer: it's a >> random or pseudo-random integer `k`, with `1 <= k < n`, not all >> 256-bit integers fit into this definition for a 256-bit prime `n` >> (where `n` is the order of the generator point for the curve. >> Validating the private key guarantees that the input private scalar is >> within the correct range. > > > The key generator is responsible for that, not the signer. Maybe in your use case. But not everyone's. >> > I was not "abusing the API" as you put it, merely pointing out that the public key is not a required item for performing ECDSA signature generation. This is a mathematical fact of life that you are going to have to learn to live with. Everybody knows the math fact already. There's no sense in repeating it. Even other software projects like BoringSSL, MbedTLS, etc know this, yet still compute the public key when it's missing. I don't have a strong opinion about that either way, but pointing out some middle school math and claiming that's the end of the argument is not constructive. And IMO you are indeed "abusing the API" or we wouldn't be having this conversation. You have a niche use case, and rolling your own key format, and now changes are biting you, so you're speaking up. (And quite rudely, I might add. Please remember that many OpenSSL contributors, including myself and Nicola, are volunteering their time.) > There exists no private key value which will cause the EVP_sign operation to enter an endless loop. > The operation will always return a result, which may not be useful if it is impossible to generate the corresponding public key. I honestly don't understand. You're wrong, and the PoC shows it. (The infinite loop is my PoC btw, so if you want to discuss it please feel free to do so with me directly.) BBB From levitte at openssl.org Mon Nov 16 16:48:37 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 16 Nov 2020 17:48:37 +0100 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <20201115213654.GA33562@roeckx.be> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> <20201115213654.GA33562@roeckx.be> Message-ID: <87v9e5b63e.wl-levitte@openssl.org> On Sun, 15 Nov 2020 22:36:54 +0100, Kurt Roeckx wrote: > > On Tue, Nov 03, 2020 at 12:11:27PM +0000, Matt Caswell wrote: > > > > The proposal discussed was that while relaxing the conceptual model, > > most of the existing implementations would still require both. The EC > > implementation would be relaxed however. This essentially gives largely > > compatible behaviour between 1.1.1 and 3.0. > > > > The vote text is as follows: > > > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > > * relax the conceptual model to allow private keys to exist without public > > components; > > * all implementations apart from EC require the public component to be > > present; > > * relax implementation for EC key management to allow private keys that > > do not > > contain public keys and > > * our decoders unconditionally generate the public key (where possible). > > > > Proposed by Matt Caswell > > Public: yes > > opened: 2020-11-03 > > closed: 2020-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > So I think being compatible with what 1.1.1 does is important. > And what the text does is try to make rules for what 1.1.1 does, > but as far as I understand it, it's not really describing what > 1.1.1 does. > > I think we should just fix the regressions. For fixing the > regressions we don't need a vote. The vote includes exactly the items needed to fix the regression. In reality, this is already mostly fixed, because all our new decoders will reconstruct the public key exactly the same way the old backends did, because they all call the exact same d2i_{TYPE}PrivateKey() internally, which do the actual work. The only actual work remaining to fix the regression is to relax the EC keymgmt import function to accept receiving a private key without the public key. It doesn't actually need to regenerate a public key either. That will allow a construct similar to the one that was reported in #12612. In practical terms, that doesn't sound like very hard work. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Mon Nov 16 16:53:04 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 16 Nov 2020 17:53:04 +0100 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> <61151243-4F87-493B-87E6-DFF75CEB9B8E@oracle.com> Message-ID: <87tutpb5vz.wl-levitte@openssl.org> On Wed, 11 Nov 2020 23:34:53 +0100, Nicola Tuveri wrote: > > By design the consistency checks and validation checks are omitted > unless these functions are called, and there is no > EVP_PKEY_private_check. Just a small point, this is in master: $ grep private_check include/openssl/evp.h int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx); Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Nov 16 17:15:53 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Nov 2020 17:15:53 +0000 Subject: Introducing Paul Nelson Message-ID: You may recall that some while ago we posted a blog where we were looking for an Administrator and Manager to help run the project: https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ I am delighted to be able to tell you that we have appointed Paul Nelson to this position. He is starting in the role today. I will let him introduce himself once he has managed to get his email access sorted! I'd like to welcome Paul to the project! Matt From levitte at openssl.org Mon Nov 16 17:44:09 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 16 Nov 2020 18:44:09 +0100 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: <87sg99b3iu.wl-levitte@openssl.org> Er, Nicola, I'm unsure how that endless loop has anything to do with the presence or the absence of a public key, as it happens in ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at all. Your check does say that the key you have there is invalid, but that would rather be because from that private key and group, it seems that d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed infinity as I understand it. You can see that for yourself with a breakpoint at d2i_ECPrivateKey(), step down to about line 1042 (current OpenSSL_1_1_1-stable, btw), and simply look: (gdb) p *ret->pub_key $16 = {meth = 0x7ffff7f0dc00 , curve_name = 415, X = 0x5555556450f0, Y = 0x555555645090, Z = 0x5555556450b0, Z_is_one = 0} (gdb) p *ret->pub_key->Z $17 = {d = 0x555555641170, top = 0, dmax = 4, neg = 0, flags = 1} (gdb) p *ret->pub_key->X $18 = {d = 0x555555641ec0, top = 4, dmax = 4, neg = 0, flags = 1} (gdb) p *ret->pub_key->Y $19 = {d = 0x555555641e40, top = 4, dmax = 4, neg = 0, flags = 1} (ret->pub_key->Z->top == 0, that's a bignum zero) That still has no impact on the infinite loop as far as I can see, but that may be an indication that something else is wrong with that private key. It's also possible that if there are conditions that may cause an infinite loop, that is a bug in itself that needs a fix. I believe this loop is due for a raised issue, unless there already is one. (if there isn't, I wonder why) Cheers, Richard On Thu, 12 Nov 2020 11:33:13 +0100, Nicola Tuveri wrote: > > > Nonsense. Each iteration involves a new PRN, which by definition you cannot predict. > > ~~~sh > ; which openssl; openssl version > /usr/bin/openssl > OpenSSL 1.1.1f 31 Mar 2020 > ; cat > /tmp/p256_invalid.pem > -----BEGIN PRIVATE KEY----- > MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/////AAAAAP////// > ////vOb6racXnoTzucrC/GMlUQ== > -----END PRIVATE KEY----- > ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem > Key is invalid > Detailed error: point at infinity > Private-Key: (256 bit) > priv: > ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff: > ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63: > 25:51 > pub: > 00 > ASN1 OID: prime256v1 > NIST CURVE: P-256 > ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32 > ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash > -out /tmp/sig.der > # here is the infinite loop > ~~~ -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From nic.tuv at gmail.com Mon Nov 16 17:45:45 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 16 Nov 2020 19:45:45 +0200 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <87tutpb5vz.wl-levitte@openssl.org> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> <61151243-4F87-493B-87E6-DFF75CEB9B8E@oracle.com> <87tutpb5vz.wl-levitte@openssl.org> Message-ID: It exists in master but not in 1.1.1 or previous: the incomplete EVP_PKEY object of #12612 in previous versions would have failed validation, where its correctness as a math entity and as a programming object is tested. That is why I am baffled by the use of "regression" to describe this issue, and the reason why I commented on the "lack of enforcement" argument. Cheers, Nicola On Mon, Nov 16, 2020, 18:53 Richard Levitte wrote: > On Wed, 11 Nov 2020 23:34:53 +0100, > Nicola Tuveri wrote: > > > > By design the consistency checks and validation checks are omitted > > unless these functions are called, and there is no > > EVP_PKEY_private_check. > > Just a small point, this is in master: > > $ grep private_check include/openssl/evp.h > int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx); > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Mon Nov 16 18:06:51 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 16 Nov 2020 20:06:51 +0200 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <87sg99b3iu.wl-levitte@openssl.org> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> <87sg99b3iu.wl-levitte@openssl.org> Message-ID: The issue with that key is that the secret scalar `k` is equal to `n` (where `n` is the order of the generator point `G`), while for EC keys the validity range is `1 <= k < n`. If the scalar `k` is equal to `n`, it means that the associated pubkey is `k*G` = `n*G` = `0*G mod n` = `P_infinity`. The pubkey generation in the `d2i_` routines is correctly being triggered because the PEM file I generated only includes the secret scalar: if we did not catch the point at infinity validating the public component we would reach the private component validity checks and we would trigger the private scalar range check. The infinite loop happens not because of the public component (that as we know is not touched during signature generation) but because the secret scalar is effectively congruent to `0 mod n` in the computation to generate the `s` value of the signature. I would not classify this as a bug, but as a programmer error: the user is using an invalid key (this has nothing to do with the "keypair assumption", literally `k` is a value out of range according to the relevant spec). Input key material should be validated: if not at each run (for performance reason), once after it has been serialized to disk and protected with proper measures to ensure the validated key material is not tampered with (or leaked). If we consider this a bug, or a potential DoS attack vector, we would likely fix it by running validation of the `EVP_PKEY` object on load (and with some caching mechanism to validate keys created manually via `EC_KEY` objects): this would once again reveal that the use pattern in #12612 was invalid to begin with, as the validity checks were enforcing the "keypair assumption" in 1.1.1 and previous versions. Nicola On Mon, Nov 16, 2020 at 7:44 PM Richard Levitte wrote: > > Er, Nicola, I'm unsure how that endless loop has anything to do with > the presence or the absence of a public key, as it happens in > ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at > all. > > Your check does say that the key you have there is invalid, but that > would rather be because from that private key and group, it seems that > d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed > infinity as I understand it. You can see that for yourself with a > breakpoint at d2i_ECPrivateKey(), step down to about line 1042 > (current OpenSSL_1_1_1-stable, btw), and simply look: > > (gdb) p *ret->pub_key > $16 = {meth = 0x7ffff7f0dc00 , curve_name = 415, X = 0x5555556450f0, > Y = 0x555555645090, Z = 0x5555556450b0, Z_is_one = 0} > (gdb) p *ret->pub_key->Z > $17 = {d = 0x555555641170, top = 0, dmax = 4, neg = 0, flags = 1} > (gdb) p *ret->pub_key->X > $18 = {d = 0x555555641ec0, top = 4, dmax = 4, neg = 0, flags = 1} > (gdb) p *ret->pub_key->Y > $19 = {d = 0x555555641e40, top = 4, dmax = 4, neg = 0, flags = 1} > > (ret->pub_key->Z->top == 0, that's a bignum zero) > > That still has no impact on the infinite loop as far as I can see, but > that may be an indication that something else is wrong with that > private key. > > It's also possible that if there are conditions that may cause an > infinite loop, that is a bug in itself that needs a fix. > > I believe this loop is due for a raised issue, unless there already is > one. > (if there isn't, I wonder why) > > Cheers, > Richard > > On Thu, 12 Nov 2020 11:33:13 +0100, > Nicola Tuveri wrote: > > > > > Nonsense. Each iteration involves a new PRN, which by definition you cannot predict. > > > > ~~~sh > > ; which openssl; openssl version > > /usr/bin/openssl > > OpenSSL 1.1.1f 31 Mar 2020 > > ; cat > /tmp/p256_invalid.pem > > -----BEGIN PRIVATE KEY----- > > MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/////AAAAAP////// > > ////vOb6racXnoTzucrC/GMlUQ== > > -----END PRIVATE KEY----- > > ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem > > Key is invalid > > Detailed error: point at infinity > > Private-Key: (256 bit) > > priv: > > ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff: > > ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63: > > 25:51 > > pub: > > 00 > > ASN1 OID: prime256v1 > > NIST CURVE: P-256 > > ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32 > > ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash > > -out /tmp/sig.der > > # here is the infinite loop > > ~~~ > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ From nic.tuv at gmail.com Mon Nov 16 18:10:24 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 16 Nov 2020 20:10:24 +0200 Subject: Introducing Paul Nelson In-Reply-To: References: Message-ID: That's great news! Welcome Paul! Nicola On Mon, Nov 16, 2020 at 7:15 PM Matt Caswell wrote: > > You may recall that some while ago we posted a blog where we were > looking for an Administrator and Manager to help run the project: > > https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ > > I am delighted to be able to tell you that we have appointed Paul Nelson > to this position. He is starting in the role today. I will let him > introduce himself once he has managed to get his email access sorted! > > I'd like to welcome Paul to the project! > > Matt > From levitte at openssl.org Mon Nov 16 18:51:34 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 16 Nov 2020 19:51:34 +0100 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> <87sg99b3iu.wl-levitte@openssl.org> Message-ID: <87pn4db0eh.wl-levitte@openssl.org> This is what I read: - the key in p256_invalid.pem is invalid in other ways than merely the lack of the public key in the file. (the public key is *not* lacking in run-time in this example, since d2i_ECPrivateKey() autogenerates it, which happens before it's checked or used) - you confirmed that the public key isn't really relevant for this problem, apart from triggering a check error that's really emanating from some other invalid data. This does not, however, demonstrate what happens when the EVP_PKEY holds an EC_KEY that lacks a public key, because in run-time, it in fact does *not* lack a public key. So while that's an interesting discussion, it doesn't really demonstrate your concerns about this vote. BTW, regarding checking, I did a bit of an experiment; I removed the autogeneration of the public key from d2i_ECPrivateKey(), and relaxed ec_key_simple_check_key() so it only checks eckey->pub_key if it's actually present... and of course removeed a few eckey->pub_key NULL checks along the way. EVP_PKEY_check still fails, but now with the detailed error "wrong order", which sounds perfectly reasonable considering your description, so it looks to me like the invalidity of the key can be caught either way. From a contents point of view, p256_invalid.pem is actually perfectly valid, or you would have gotten ASN1 errors when trying to load it. Cheers, Richard P.S. I'd like to pause the debate at this point... it looks like we're getting back into locked positions, and I'm not keen on continuing under those conditions. On Mon, 16 Nov 2020 19:06:51 +0100, Nicola Tuveri wrote: > > The issue with that key is that the secret scalar `k` is equal to `n` > (where `n` is the order of the generator point `G`), while for EC keys > the validity range is `1 <= k < n`. > > If the scalar `k` is equal to `n`, it means that the associated pubkey > is `k*G` = `n*G` = `0*G mod n` = `P_infinity`. > The pubkey generation in the `d2i_` routines is correctly being > triggered because the PEM file I generated only includes the secret > scalar: if we did not catch the point at infinity validating the > public component we would reach the private component validity checks > and we would trigger the private scalar range check. > > The infinite loop happens not because of the public component (that as > we know is not touched during signature generation) but because the > secret scalar is effectively congruent to `0 mod n` in the computation > to generate the `s` value of the signature. > > I would not classify this as a bug, but as a programmer error: the > user is using an invalid key (this has nothing to do with the "keypair > assumption", literally `k` is a value out of range according to the > relevant spec). > Input key material should be validated: if not at each run (for > performance reason), once after it has been serialized to disk and > protected with proper measures to ensure the validated key material is > not tampered with (or leaked). > > > If we consider this a bug, or a potential DoS attack vector, we would > likely fix it by running validation of the `EVP_PKEY` object on load > (and with some caching mechanism to validate keys created manually via > `EC_KEY` objects): this would once again reveal that the use pattern > in #12612 was invalid to begin with, as the validity checks were > enforcing the "keypair assumption" in 1.1.1 and previous versions. > > > Nicola > > On Mon, Nov 16, 2020 at 7:44 PM Richard Levitte wrote: > > > > Er, Nicola, I'm unsure how that endless loop has anything to do with > > the presence or the absence of a public key, as it happens in > > ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at > > all. > > > > Your check does say that the key you have there is invalid, but that > > would rather be because from that private key and group, it seems that > > d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed > > infinity as I understand it. You can see that for yourself with a > > breakpoint at d2i_ECPrivateKey(), step down to about line 1042 > > (current OpenSSL_1_1_1-stable, btw), and simply look: > > > > (gdb) p *ret->pub_key > > $16 = {meth = 0x7ffff7f0dc00 , curve_name = 415, X = 0x5555556450f0, > > Y = 0x555555645090, Z = 0x5555556450b0, Z_is_one = 0} > > (gdb) p *ret->pub_key->Z > > $17 = {d = 0x555555641170, top = 0, dmax = 4, neg = 0, flags = 1} > > (gdb) p *ret->pub_key->X > > $18 = {d = 0x555555641ec0, top = 4, dmax = 4, neg = 0, flags = 1} > > (gdb) p *ret->pub_key->Y > > $19 = {d = 0x555555641e40, top = 4, dmax = 4, neg = 0, flags = 1} > > > > (ret->pub_key->Z->top == 0, that's a bignum zero) > > > > That still has no impact on the infinite loop as far as I can see, but > > that may be an indication that something else is wrong with that > > private key. > > > > It's also possible that if there are conditions that may cause an > > infinite loop, that is a bug in itself that needs a fix. > > > > I believe this loop is due for a raised issue, unless there already is > > one. > > (if there isn't, I wonder why) > > > > Cheers, > > Richard > > > > On Thu, 12 Nov 2020 11:33:13 +0100, > > Nicola Tuveri wrote: > > > > > > > Nonsense. Each iteration involves a new PRN, which by definition you cannot predict. > > > > > > ~~~sh > > > ; which openssl; openssl version > > > /usr/bin/openssl > > > OpenSSL 1.1.1f 31 Mar 2020 > > > ; cat > /tmp/p256_invalid.pem > > > -----BEGIN PRIVATE KEY----- > > > MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/////AAAAAP////// > > > ////vOb6racXnoTzucrC/GMlUQ== > > > -----END PRIVATE KEY----- > > > ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem > > > Key is invalid > > > Detailed error: point at infinity > > > Private-Key: (256 bit) > > > priv: > > > ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff: > > > ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63: > > > 25:51 > > > pub: > > > 00 > > > ASN1 OID: prime256v1 > > > NIST CURVE: P-256 > > > ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32 > > > ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash > > > -out /tmp/sig.der > > > # here is the infinite loop > > > ~~~ > > > > -- > > Richard Levitte levitte at openssl.org > > OpenSSL Project http://www.openssl.org/~levitte/ > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From nic.tuv at gmail.com Mon Nov 16 19:09:25 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 16 Nov 2020 21:09:25 +0200 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <87pn4db0eh.wl-levitte@openssl.org> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> <87sg99b3iu.wl-levitte@openssl.org> <87pn4db0eh.wl-levitte@openssl.org> Message-ID: I will only answer what I see as new points in your last email, to avoid repeating ourselves. Validity of a serialized key: - ASN.1 validity says little about the validity of the key, as ASN.1 cannot enforce limits on the private scalar range - validity as a serialized EC key requires that in addition to be valid ASN.1, other criteria are satisfied: - (this is assuming a named curve, with explicit parameters things get more involved, as we need to validate those before looking at private and public components) - private scalar is in the prescribed range for the curve - if optional public component is present, the public key encoding matches the SECG standard in one of the supported compression formats - if optional public component is present, the public key point belongs to the curve - if optional public component is present, the public key point belongs to the prime subgroup of the curve (this collapses into the previous point only if the cofactor for this curve is 1) - if optional public component is present, the public key point matches `k*G` I confirm what you saw in your experiments, the validity checks (if invoked!) catch these corner cases (I did similar experiments when preparing the EC part of #13359). The fact that you had to alter `ec_key_simple_check_key()` to skip the public component validation, which is necessary also in 1.1.1 and earlier, is the reason why I raised this side discussion on key validation, as disproving the "lack of enforcement" argument: but I posted this on the public openssl-project list only after verifying we did not have gaping security holes. Nicola On Mon, Nov 16, 2020 at 8:51 PM Richard Levitte wrote: > > This is what I read: > > - the key in p256_invalid.pem is invalid in other ways than merely the > lack of the public key in the file. > (the public key is *not* lacking in run-time in this example, since > d2i_ECPrivateKey() autogenerates it, which happens before it's > checked or used) > > - you confirmed that the public key isn't really relevant for this > problem, apart from triggering a check error that's really emanating > from some other invalid data. > > This does not, however, demonstrate what happens when the EVP_PKEY > holds an EC_KEY that lacks a public key, because in run-time, it in > fact does *not* lack a public key. So while that's an interesting > discussion, it doesn't really demonstrate your concerns about this > vote. > > BTW, regarding checking, I did a bit of an experiment; I removed the > autogeneration of the public key from d2i_ECPrivateKey(), and relaxed > ec_key_simple_check_key() so it only checks eckey->pub_key if it's > actually present... and of course removeed a few eckey->pub_key NULL > checks along the way. EVP_PKEY_check still fails, but now with the > detailed error "wrong order", which sounds perfectly reasonable > considering your description, so it looks to me like the invalidity > of the key can be caught either way. > > From a contents point of view, p256_invalid.pem is actually perfectly > valid, or you would have gotten ASN1 errors when trying to load it. > > Cheers, > Richard > > P.S. I'd like to pause the debate at this point... it looks like > we're getting back into locked positions, and I'm not keen on > continuing under those conditions. > > On Mon, 16 Nov 2020 19:06:51 +0100, > Nicola Tuveri wrote: > > > > The issue with that key is that the secret scalar `k` is equal to `n` > > (where `n` is the order of the generator point `G`), while for EC keys > > the validity range is `1 <= k < n`. > > > > If the scalar `k` is equal to `n`, it means that the associated pubkey > > is `k*G` = `n*G` = `0*G mod n` = `P_infinity`. > > The pubkey generation in the `d2i_` routines is correctly being > > triggered because the PEM file I generated only includes the secret > > scalar: if we did not catch the point at infinity validating the > > public component we would reach the private component validity checks > > and we would trigger the private scalar range check. > > > > The infinite loop happens not because of the public component (that as > > we know is not touched during signature generation) but because the > > secret scalar is effectively congruent to `0 mod n` in the computation > > to generate the `s` value of the signature. > > > > I would not classify this as a bug, but as a programmer error: the > > user is using an invalid key (this has nothing to do with the "keypair > > assumption", literally `k` is a value out of range according to the > > relevant spec). > > Input key material should be validated: if not at each run (for > > performance reason), once after it has been serialized to disk and > > protected with proper measures to ensure the validated key material is > > not tampered with (or leaked). > > > > > > If we consider this a bug, or a potential DoS attack vector, we would > > likely fix it by running validation of the `EVP_PKEY` object on load > > (and with some caching mechanism to validate keys created manually via > > `EC_KEY` objects): this would once again reveal that the use pattern > > in #12612 was invalid to begin with, as the validity checks were > > enforcing the "keypair assumption" in 1.1.1 and previous versions. > > > > > > Nicola > > > > On Mon, Nov 16, 2020 at 7:44 PM Richard Levitte wrote: > > > > > > Er, Nicola, I'm unsure how that endless loop has anything to do with > > > the presence or the absence of a public key, as it happens in > > > ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at > > > all. > > > > > > Your check does say that the key you have there is invalid, but that > > > would rather be because from that private key and group, it seems that > > > d2i_ECPrivateKey() generates a public key with Z == 0, which is indeed > > > infinity as I understand it. You can see that for yourself with a > > > breakpoint at d2i_ECPrivateKey(), step down to about line 1042 > > > (current OpenSSL_1_1_1-stable, btw), and simply look: > > > > > > (gdb) p *ret->pub_key > > > $16 = {meth = 0x7ffff7f0dc00 , curve_name = 415, X = 0x5555556450f0, > > > Y = 0x555555645090, Z = 0x5555556450b0, Z_is_one = 0} > > > (gdb) p *ret->pub_key->Z > > > $17 = {d = 0x555555641170, top = 0, dmax = 4, neg = 0, flags = 1} > > > (gdb) p *ret->pub_key->X > > > $18 = {d = 0x555555641ec0, top = 4, dmax = 4, neg = 0, flags = 1} > > > (gdb) p *ret->pub_key->Y > > > $19 = {d = 0x555555641e40, top = 4, dmax = 4, neg = 0, flags = 1} > > > > > > (ret->pub_key->Z->top == 0, that's a bignum zero) > > > > > > That still has no impact on the infinite loop as far as I can see, but > > > that may be an indication that something else is wrong with that > > > private key. > > > > > > It's also possible that if there are conditions that may cause an > > > infinite loop, that is a bug in itself that needs a fix. > > > > > > I believe this loop is due for a raised issue, unless there already is > > > one. > > > (if there isn't, I wonder why) > > > > > > Cheers, > > > Richard > > > > > > On Thu, 12 Nov 2020 11:33:13 +0100, > > > Nicola Tuveri wrote: > > > > > > > > > Nonsense. Each iteration involves a new PRN, which by definition you cannot predict. > > > > > > > > ~~~sh > > > > ; which openssl; openssl version > > > > /usr/bin/openssl > > > > OpenSSL 1.1.1f 31 Mar 2020 > > > > ; cat > /tmp/p256_invalid.pem > > > > -----BEGIN PRIVATE KEY----- > > > > MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCD/////AAAAAP////// > > > > ////vOb6racXnoTzucrC/GMlUQ== > > > > -----END PRIVATE KEY----- > > > > ; openssl pkey -check -text -noout -in /tmp/p256_invalid.pem > > > > Key is invalid > > > > Detailed error: point at infinity > > > > Private-Key: (256 bit) > > > > priv: > > > > ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:ff: > > > > ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:63: > > > > 25:51 > > > > pub: > > > > 00 > > > > ASN1 OID: prime256v1 > > > > NIST CURVE: P-256 > > > > ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32 > > > > ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash > > > > -out /tmp/sig.der > > > > # here is the infinite loop > > > > ~~~ > > > > > > -- > > > Richard Levitte levitte at openssl.org > > > OpenSSL Project http://www.openssl.org/~levitte/ > > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Mon Nov 16 20:07:37 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 16 Nov 2020 20:07:37 +0000 Subject: OpenSSL Cookbook is being updated soon In-Reply-To: References: Message-ID: <510f9d72ff25441e9945a974feea3187@ncp-e.com> Ivan, thank you very much for giving us the opportunity to preview your next publication of the OpenSSL cookbook. Even if your mail was unanswered (until know), I?m sure your announcement did not go unnoticed. I would like to take the opportunity to thank you for your continuous efforts during the past years to provide the OpenSSL community with an excellent introduction to the OpenSSL command line tool. It has always been available as a free download and is a valuable source of information for your user base. And it?s excellent news that there is an update coming. Enough reasons IMHO to propose you as an ?OpenSSL Team member h.c.? if such a role would already exist in our bylaws (maybe we should add it ?). Regards, Matthias @openssl/committers: please take the time to take a look at the preprint and provide your feedback. From: openssl-project On Behalf Of Ivan Ristic Sent: Friday, November 6, 2020 11:29 AM To: openssl-project at openssl.org Subject: OpenSSL Cookbook is being updated soon Apologies for starting a new thread, but I had no previous message to reply to. Matt alerted me to the mention of OpenSSL Cookbook here and I was previously not on this list. I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed the 3rd edition. This time I had Matt help me as a technical reviewer and that led to many improvements. We're currently updating our web site and will release the new edition as soon as that's done. The 3rd edition required many changes because of TLS 1.3. Now that it's done, going forward I will aim for continuous updates as needed. Additionally, we wish to make the content more useful by splitting it into smaller chunks. At the moment, it's presented as one page per chapter, which is not ideal. We will look into this at some point after the release. If you'd like to see the 3rd edition before it's officially out, you can actually get it immediately by registering for an account here https://www.feistyduck.com/account/register If you already have an account, it should be offered to you at the bottom of the library page https://www.feistyduck.com/library/ I would certainly welcome any thoughts about the content and the possible improvements. The scope is generally command-line usage. -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Mon Nov 16 20:08:50 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 16 Nov 2020 20:08:50 +0000 Subject: OpenSSL Cookbook is being updated soon In-Reply-To: <510f9d72ff25441e9945a974feea3187@ncp-e.com> References: <510f9d72ff25441e9945a974feea3187@ncp-e.com> Message-ID: typo: ?your user base? -> ?our user base? From: openssl-project On Behalf Of Dr. Matthias St. Pierre Sent: Monday, November 16, 2020 9:08 PM To: Ivan Ristic ; openssl-project at openssl.org Subject: RE: OpenSSL Cookbook is being updated soon Ivan, thank you very much for giving us the opportunity to preview your next publication of the OpenSSL cookbook. Even if your mail was unanswered (until know), I?m sure your announcement did not go unnoticed. I would like to take the opportunity to thank you for your continuous efforts during the past years to provide the OpenSSL community with an excellent introduction to the OpenSSL command line tool. It has always been available as a free download and is a valuable source of information for your user base. And it?s excellent news that there is an update coming. Enough reasons IMHO to propose you as an ?OpenSSL Team member h.c.? if such a role would already exist in our bylaws (maybe we should add it ?). Regards, Matthias @openssl/committers: please take the time to take a look at the preprint and provide your feedback. From: openssl-project > On Behalf Of Ivan Ristic Sent: Friday, November 6, 2020 11:29 AM To: openssl-project at openssl.org Subject: OpenSSL Cookbook is being updated soon Apologies for starting a new thread, but I had no previous message to reply to. Matt alerted me to the mention of OpenSSL Cookbook here and I was previously not on this list. I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed the 3rd edition. This time I had Matt help me as a technical reviewer and that led to many improvements. We're currently updating our web site and will release the new edition as soon as that's done. The 3rd edition required many changes because of TLS 1.3. Now that it's done, going forward I will aim for continuous updates as needed. Additionally, we wish to make the content more useful by splitting it into smaller chunks. At the moment, it's presented as one page per chapter, which is not ideal. We will look into this at some point after the release. If you'd like to see the 3rd edition before it's officially out, you can actually get it immediately by registering for an account here https://www.feistyduck.com/account/register If you already have an account, it should be offered to you at the bottom of the library page https://www.feistyduck.com/library/ I would certainly welcome any thoughts about the content and the possible improvements. The scope is generally command-line usage. -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From nelsonlogic at icloud.com Tue Nov 17 21:46:47 2020 From: nelsonlogic at icloud.com (Paul Nelson) Date: Tue, 17 Nov 2020 15:46:47 -0600 Subject: Introducing Paul Nelson In-Reply-To: References: Message-ID: I am very happy to join the OpenSSL community and to be working with so many talented developers. I understand what a valuable and necessary contribution you all have made and are making to the global world economy. Before coming to OpenSSL, I was the chief technology officer at Thursby Software Systems. My team developed a smart card application for iOS and Android for the US government and military. We used OpenSSL FIPS for these applications. I am familiar with using OpenSSL as a developer and with public key encryption in general. Our solution for the US Navy Reserve was probably the first bring your own device (BYOD) project to obtain an authority to operate issued by the Navy Cyber command. OpenSSL was an invaluable part of that accomplishment! That said, I plan to use my experience managing software development lifecycles, delivering quality products and managing customer expectations to add value to your hard work. On the personal side, I live in Arlington Texas just west of Dallas. I enjoy driving my Jeep on the trails here in Texas. This is a recursive activity where you build the Jeep, drive it, break it and fix it. Then do it all again for more fun. I am married with three grown children and quite a few grandchildren. Paul Nelson > On Nov 16, 2020, at 11:15 AM, Matt Caswell wrote: > > You may recall that some while ago we posted a blog where we were > looking for an Administrator and Manager to help run the project: > > https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ > > I am delighted to be able to tell you that we have appointed Paul Nelson > to this position. He is starting in the role today. I will let him > introduce himself once he has managed to get his email access sorted! > > I'd like to welcome Paul to the project! > > Matt > From matt at openssl.org Wed Nov 18 14:50:42 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 18 Nov 2020 14:50:42 +0000 Subject: OTC VOTE: DH Generation In-Reply-To: <04adb945-f07e-9cb5-b512-d41a221d6598@openssl.org> References: <04adb945-f07e-9cb5-b512-d41a221d6598@openssl.org> Message-ID: On 03/11/2020 11:56, Matt Caswell wrote: > The vote text is as follows: > > topic: For DH Generation, the OTC accepts the following resolution: > * Quad-state generation: > - PKCS #3; > - named groups only; > - FIPS 186-2 generation or > - FIPS 186-4 generation. > * For default provider: > - change back to PKCS #3 generation as the default and > - allow changing to FIPS 186-2, FIPS 186-4 or named groups. > * For FIPS provider: > - choose a known safe prime group as default (rejecting non-standard > lengths) and > - allow a change to FIPS 186-4 generation. > * For parameter validation in FIPS: > - accept if a named group; > - run FIPS 186-4 validation if DHX key, otherwise reject. > * For key validation: if a named group, do just partial key validation. > * For validation more generally, allow a validation mode to be set. This vote has now closed: accepted: yes (for: 7, against: 0, abstained: 2, not voted: 2) Matt From dev at ddvo.net Thu Nov 19 17:12:01 2020 From: dev at ddvo.net (David von Oheimb) Date: Thu, 19 Nov 2020 18:12:01 +0100 Subject: Introducing Paul Nelson In-Reply-To: References: Message-ID: Hi Paul, a warm welcome also from my side. Great that you are strengthening the team, unloading work in particular from Matt and Richard. I'm the OpenSSL team member who joined most recently before you, after getting invited to become a Committer in January, while contributing a heavy load of certificate management code and on this occasion also many related small extensions and more or less general fixes. I'm using this occasion to drop in the same way as you did a few lines on my background also to the other project members, as these might be of interest for them, too. I had started using OpenSSL also quite a number of years back, mostly on the command line, in particular with a PKCS#11 engine for using the CardOS-based Siemens employee ID card - thus kind of related with your use case at the US Navy.? At Siemens Corporate Technology I also had a major project with Boeing Phantom Works on secure airplane software update. My current focus is PKI-related development, research, consulting, and standardization. On the personal side, I live with my small family just east of Munich, Bavaria, Germany. I love mountaineering and photography, and since 1.5 years my wife and me have become happy campervan users, which combines well with our base being pretty close to the Alps. Cheers, ??? David -- +------------------------------------------------------------------<><-+ | Dr. David von Oheimb Senior Key Expert Research Scientist | | Siemens T RDA CST SEA-DE Phone: +49 89 636 631118 | | Otto-Hahn-Ring 6 Fax : +49 89 636 48000 | | D-81739 M?nchen, Germany EMail: David.von.Oheimb at siemens.com | | http://scd.siemens.de/db4/lookUp?tcgid=Z000ECRO http://ddvo.net/ | +----------------------------------------------------------------------+ On 17.11.20 22:46, Paul Nelson wrote: > I am very happy to join the OpenSSL community and to be working with so many talented developers. I understand what a valuable and necessary contribution you all have made and are making to the global world economy. > > Before coming to OpenSSL, I was the chief technology officer at Thursby Software Systems. My team developed a smart card application for iOS and Android for the US government and military. We used OpenSSL FIPS for these applications. I am familiar with using OpenSSL as a developer and with public key encryption in general. Our solution for the US Navy Reserve was probably the first bring your own device (BYOD) project to obtain an authority to operate issued by the Navy Cyber command. OpenSSL was an invaluable part of that accomplishment! > > That said, I plan to use my experience managing software development lifecycles, delivering quality products and managing customer expectations to add value to your hard work. > > On the personal side, I live in Arlington Texas just west of Dallas. I enjoy driving my Jeep on the trails here in Texas. This is a recursive activity where you build the Jeep, drive it, break it and fix it. Then do it all again for more fun. I am married with three grown children and quite a few grandchildren. > > Paul Nelson > >> On Nov 16, 2020, at 11:15 AM, Matt Caswell wrote: >> >> You may recall that some while ago we posted a blog where we were >> looking for an Administrator and Manager to help run the project: >> >> https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/ >> >> I am delighted to be able to tell you that we have appointed Paul Nelson >> to this position. He is starting in the role today. I will let him >> introduce himself once he has managed to get his email access sorted! >> >> I'd like to welcome Paul to the project! >> >> Matt >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Nov 20 09:36:06 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 20 Nov 2020 09:36:06 +0000 Subject: Fwd: Welcome to Travis CI! Message-ID: This got caught in the moderation queue for the openssl-commits email list. Forwarding here since it looks like it may have significant consequences for us (as pointed out in previous discussions). Matt -------- Forwarded Message -------- Subject: Welcome to Travis CI! Date: Fri, 20 Nov 2020 09:28:37 +0000 From: Travis CI Reply-To: Travis CI Support To: openssl-commits at openssl.org Travis CI Logo Welcome to Travis CI, OpenSSL! You are on Free. You have 10,000 credits left - these will begin counting down automatically as soon as you run your first build. You can use your credits to build on both private and open-source repositories using Linux, macOS, and Windows OS. Use the `Sign up now` button below to sign up for a bigger plan to ensure the builds for your private repositories continue uninterrupted. If you're building open-source public repositories and want to signup for an open-source plan, please contact Travis CI. Build Crane You have 10,000 Credits left for building on Travis CI! To ensure uninterrupted service, sign up for a suitable plan before you run out of credits. *Note: *You must be an *owner of the account* to sign up for a subscription. SIGN UP NOW Thank you and have a great day! *The Travis CI Team* Twitter Logo Have any questions? We're here to help. Travis CI Footer Logo Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy Jacops | Contact: contact at travis-ci.org | Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gem?? ?27 a Umsatzsteuergesetz: DE282002648 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Nov 23 23:32:18 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 23 Nov 2020 23:32:18 +0000 Subject: OTC VOTE: EVP_PKEY private/public key components In-Reply-To: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> References: <380411b8-c592-4443-8419-c734853e4b9f@openssl.org> Message-ID: <75092a8e-948d-be75-90ad-a223ac058f55@openssl.org> This vote is now closed. Viktor's vote was a little unclear but I interpreted it as a -1 in recording the votes. accepted: yes (for: 5, against: 4, abstained: 1, not voted: 1) Matt On 03/11/2020 12:11, Matt Caswell wrote: > Background to the vote: > > The OTC meeting today discussed the problems raised by issue #12612. In > summary the problem is that there has been a long standing, widespread > and documented assumption that an EVP_PKEY with a private key will > always also have the public key component. > > In spite of this it turns out that in the EC implementation in 1.1.1 it > was perfectly possible to create an EVP_PKEY with only a private key and > no public key - and it was also possible to use such an EVP_PKEY in a > signing operation. > > The current 3.0 code in master introduced an explicit check (in line > with the long held assumption) that the public key was present and > rejected keys where this was not the case. This caused a backwards > compatibility break for some users (as discussed at length in #12612). > > The OTC discussed a proposal that we should relax our conceptual model > in this regards and conceptually allow EVP_PKEYs to exist that only have > the private component without the public component - although individual > algorithm implementations may still require both. > > It is possible to automatically generate the public component from the > private for many algorithms, although this may come at a performance and > (potentially) a security cost. > > The proposal discussed was that while relaxing the conceptual model, > most of the existing implementations would still require both. The EC > implementation would be relaxed however. This essentially gives largely > compatible behaviour between 1.1.1 and 3.0. > > The vote text is as follows: > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > * relax the conceptual model to allow private keys to exist without public > components; > * all implementations apart from EC require the public component to be > present; > * relax implementation for EC key management to allow private keys that > do not > contain public keys and > * our decoders unconditionally generate the public key (where possible). > > Proposed by Matt Caswell > Public: yes > opened: 2020-11-03 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [ ] > Richard [+1] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] > From nic.tuv at gmail.com Tue Nov 24 11:51:44 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 24 Nov 2020 13:51:44 +0200 Subject: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix Message-ID: Background ---------- This follows up on a [previous proposal] that was abandoned in favor of an OMC vote on the behavior change introduced in [PR#13359]. Within today's OTC meeting this was further discussed with the attending members that also sit in the OMC. The suggestion was to improve the separation of the OTC and OMC domains here, by having a more generic OTC vote to qualify as bug fixes the changes to let any OpenSSL app return an (early) failure exit status when a called function fails. The idea is that, if we agree on this technical definition, then no OMC vote to allow a behavior change in the apps would be required in general, unless, on a case-by-case basis, the "OMC hold" process is invoked for whatever reason on the specific bug fix, triggering the usual OMC decision process. Proposed vote text ------------------ In the context of the OpenSSL apps, we qualify as bug fixes the changes to return a failure exit status when a called function fails unrecoverably. Even when these bug fixes change the apps behavior triggering early exits (compared to previous versions of the apps), as bug fixes, they do not qualify as behavior changes that require an explicit OMC approval. [previous proposal]: https://www.mail-archive.com/openssl-project at openssl.org/msg02241.html [PR#13359]: https://github.com/openssl/openssl/pull/13359 From kurt at roeckx.be Tue Nov 24 17:18:55 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 24 Nov 2020 18:18:55 +0100 Subject: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix In-Reply-To: References: Message-ID: <20201124171855.GA732563@roeckx.be> On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote: > Background > ---------- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > Proposed vote text > ------------------ > > In the context of the OpenSSL apps, we qualify as bug fixes the > changes to return a failure exit status when a called function > fails unrecoverably. I'm not sure the unrecoverably should be there. I think this was about verifying is a public or private key was valid. If such a function returns it's not valid, I don't call that an unrecoverable error. But I do expect the application to return an error exit code. An other example is s_client, which ignores verification errors by default. You can change that behaviour with -verify_return_error. If you do that, s_client will actually exit with return value 1 in case of a verification error. Kurt From nic.tuv at gmail.com Tue Nov 24 17:33:06 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 24 Nov 2020 19:33:06 +0200 Subject: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix In-Reply-To: <20201124171855.GA732563@roeckx.be> References: <20201124171855.GA732563@roeckx.be> Message-ID: Uhm, thanks Kurt! I think you have a point here, "unrecoverably" might be a poor choice. Do you have a proposal to qualify these cases in general? Or a better way to rephrase it? I wasn't happy with "In the context of the OpenSSL apps, we qualify as bug fixes the changes to return a failure exit status when a called function fails." (i.e., omitting unrecoverably or a better term): it is not uncommon to have function failures that are intended to be handled, taking a different course of action. @tjh, as the main driver of a more generic vote like this, do you have a better vote text proposal? Nicola On Tue, Nov 24, 2020, 19:18 Kurt Roeckx wrote: > > On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote: > > Background > > ---------- > > > > This follows up on a [previous proposal] that was abandoned in favor of > > an OMC vote on the behavior change introduced in [PR#13359]. > > Within today's OTC meeting this was further discussed with the attending > > members that also sit in the OMC. > > > > The suggestion was to improve the separation of the OTC and OMC domains > > here, by having a more generic OTC vote to qualify as bug fixes the > > changes to let any OpenSSL app return an (early) failure exit status > > when a called function fails. > > > > The idea is that, if we agree on this technical definition, then no OMC > > vote to allow a behavior change in the apps would be required in > > general, unless, on a case-by-case basis, the "OMC hold" process is > > invoked for whatever reason on the specific bug fix, triggering the > > usual OMC decision process. > > > > Proposed vote text > > ------------------ > > > > In the context of the OpenSSL apps, we qualify as bug fixes the > > changes to return a failure exit status when a called function > > fails unrecoverably. > > I'm not sure the unrecoverably should be there. I think this was > about verifying is a public or private key was valid. If such a > function returns it's not valid, I don't call that an > unrecoverable error. But I do expect the application to return an > error exit code. > > An other example is s_client, which ignores verification errors by > default. You can change that behaviour with -verify_return_error. If > you do that, s_client will actually exit with return value 1 in case > of a verification error. > > > Kurt > > From nic.tuv at gmail.com Tue Nov 24 20:29:43 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 24 Nov 2020 22:29:43 +0200 Subject: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix In-Reply-To: References: <20201124171855.GA732563@roeckx.be> Message-ID: Off-list I received a suggestion to use "unhandled" (thanks again!). I am not sure about it (I actually originally discarded in my first draft of this proposal) because I am afraid that talking of "unhandled return value" from a function might be misinterpreted as cases in which we are ignoring the return value of a callee or in which we are not considering the whole set of possible return values. Anyway, now that I disclaimed my doubts about it, I would submit to your consideration this alternative to the original vote text: In the context of the OpenSSL apps, we qualify as bug fixes the changes to return a failure exit status when a called function fails with an unhandled return value. Even when these bug fixes change the apps behavior triggering early exits (compared to previous versions of the apps), as bug fixes, they do not qualify as behavior changes that require an explicit OMC approval. Would this be preferable to the original proposal? Cheers, Nicola On Tue, Nov 24, 2020 at 7:33 PM Nicola Tuveri wrote: > > Uhm, thanks Kurt! I think you have a point here, "unrecoverably" might > be a poor choice. > > Do you have a proposal to qualify these cases in general? Or a better > way to rephrase it? > > I wasn't happy with "In the context of the OpenSSL apps, we qualify as > bug fixes the changes to return a failure exit status when a called > function fails." (i.e., omitting unrecoverably or a better term): it > is not uncommon to have function failures that are intended to be > handled, taking a different course of action. > > > @tjh, as the main driver of a more generic vote like this, do you have > a better vote text proposal? > > > Nicola > > > On Tue, Nov 24, 2020, 19:18 Kurt Roeckx wrote: > > > > On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote: > > > Background > > > ---------- > > > > > > This follows up on a [previous proposal] that was abandoned in favor of > > > an OMC vote on the behavior change introduced in [PR#13359]. > > > Within today's OTC meeting this was further discussed with the attending > > > members that also sit in the OMC. > > > > > > The suggestion was to improve the separation of the OTC and OMC domains > > > here, by having a more generic OTC vote to qualify as bug fixes the > > > changes to let any OpenSSL app return an (early) failure exit status > > > when a called function fails. > > > > > > The idea is that, if we agree on this technical definition, then no OMC > > > vote to allow a behavior change in the apps would be required in > > > general, unless, on a case-by-case basis, the "OMC hold" process is > > > invoked for whatever reason on the specific bug fix, triggering the > > > usual OMC decision process. > > > > > > Proposed vote text > > > ------------------ > > > > > > In the context of the OpenSSL apps, we qualify as bug fixes the > > > changes to return a failure exit status when a called function > > > fails unrecoverably. > > > > I'm not sure the unrecoverably should be there. I think this was > > about verifying is a public or private key was valid. If such a > > function returns it's not valid, I don't call that an > > unrecoverable error. But I do expect the application to return an > > error exit code. > > > > An other example is s_client, which ignores verification errors by > > default. You can change that behaviour with -verify_return_error. If > > you do that, s_client will actually exit with return value 1 in case > > of a verification error. > > > > > > Kurt > > > > From felix.buenemann at gmail.com Wed Nov 25 20:17:13 2020 From: felix.buenemann at gmail.com (=?utf-8?Q?Felix_B=C3=BCnemann?=) Date: Wed, 25 Nov 2020 21:17:13 +0100 Subject: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS Message-ID: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> This proposal is a result of the discussion on GitHub PR #12369: https://github.com/openssl/openssl/pull/12369 Matt Caswell has agreed to raise the vote with the OMC. Please provide any feedback you have on the wording, so it can be Integrated into the original at: https://gist.github.com/ee30b5c8f52e030629dc2de95f81d8b1 ---------- OMC VOTE: macOS ARM64 Support in OpenSSL 1.1.1 LTS Background to the vote: Apple has recently released new Mac computers that are powered by their own ARMv8 compatible SoC called the Apple Silicon M1 or short M1. This chip is an evolution of their previous ARM chips in the A series, most similar to the A14 used in the latest generations of iPhones and iPads, but with a chip configuration like the iPad Pro. Since this is a CPU architecture that was previously used by iOS devices, it is already well supported by OpenSSL including various assembly optimizations. In order to support it on macOS on the current stable version OpenSSL 1.1.1, a new build target needs to be added to the build configuration script, which has been proposed and discussed in PR #12369 [1]. This is a problem, because the OpenSSL LTS rules state that only bug fixes and security fixes are accepted into the stable codebase. It is also unique cause it requires no code changes to support a new platform. Since OpenSSL 3.0 is still in alpha and because the code is very low impact, with only eight lines of configuration, I would like to ask the OMC to make and exception to the rule in this case. It is important that this patch is accepted upstream, because there is a good amount of uncertainty for maintainers in downstream projects like Homebrew, the most popular package manager for macOS, about keeping out of tree patches for security sensitive software like OpenSSL. Accepting the patch gives these maintainers the certainty, that it is safe to use and removes the need vor various downstream projects to maintain the patch. This is also important since I've seen multiple variations of the patch in the wild that didn't actually work as intended, due to being incorrectly ported from the master branch - leading to working, but fully unoptimized builds. I would also ask to make this decision independent of the ongoing proposal for LTS+ releases by Matt Caswell, that would allow for adding new platforms with greater changes to the codebase. I think it has a much bigger scope and is likely going to take some time to get right. This should be seen as one time exception and is not intended as a precedent for future cases, which should be covered by the LTS+ proposal. [1] https://github.com/openssl/openssl/pull/12369 The vote text is as follows: topic: Regarding inclusion of macOS ARM64 Support in OpenSSL 1.1.1 LTS: The OMC accepts the required configuration change, making an exception to the LTS rule that prevents adding new platforms. Proposed by Felix Buenemann -- Regards, Felix Buenemann From openssl at openssl.org Thu Nov 26 15:33:49 2020 From: openssl at openssl.org (OpenSSL) Date: Thu, 26 Nov 2020 15:33:49 +0000 Subject: OpenSSL version 3.0.0-alpha9 published Message-ID: <20201126153349.GA19701@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 9 released ==================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 9 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha9.tar.gz Size: 14058484 SHA1 checksum: 9b5faa69485659407583fd653f8064fb425fc0c4 SHA256 checksum: 5762545c972d5e48783c751d3188ac19f6f9154ee4899433ba15f01c56b3eee6 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha9.tar.gz openssl sha256 openssl-3.0.0-alpha9.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl+/wWAACgkQ2cTSbQ5g RJGGWQgAr12trYLeMYhAMzTnfQXOv+M16DrJyPZoyZyVNee3rcmOUA18Uiiji45F BlauG3D/ShIJZ4zMs/jjVRnc/MqAZBphgO4Ow0XlFl+fkqess9hk/buerNZs9lbu Xp/yRPO8d9hTB3ni1VPnaFlnRGKVZydR7p0s2b5j/ps6o0OVKwBxjFnX3Lr9loPs HkiXZMdmZp2woTJc+Ch5KCzpZcVAWs14v6ZgKsMLIxkD3iU1NjSacR4AAEdwhd4m 4X3GSOMTzHniOWEGaRKJM8nYiaKyajnq386re5wsqK1J6EqRTQ73QgXhK0Ge1lC0 Eh9Mmg/7ajFmjLThcWqJVgy2m+9/Gw== =t8pi -----END PGP SIGNATURE----- From kurt at roeckx.be Thu Nov 26 17:57:17 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 26 Nov 2020 18:57:17 +0100 Subject: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS In-Reply-To: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> References: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> Message-ID: <20201126175717.GA869939@roeckx.be> On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix B?nemann wrote: > > It is also unique cause it requires no code changes to support a new platform. In a previous discussion we have talked about when a platform can be added in an LTS release. I think that in general if it's only configuration changes and there is a very low risk that it's going to have issues requiring other changes, we should allow it. Kurt From felix.buenemann at gmail.com Fri Nov 27 11:42:44 2020 From: felix.buenemann at gmail.com (=?utf-8?Q?Felix_B=C3=BCnemann?=) Date: Fri, 27 Nov 2020 12:42:44 +0100 Subject: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS In-Reply-To: <20201126175717.GA869939@roeckx.be> References: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> <20201126175717.GA869939@roeckx.be> Message-ID: Hi Kurt, > Am 26.11.2020 um 18:57 schrieb Kurt Roeckx : > > On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix B?nemann wrote: >> >> It is also unique cause it requires no code changes to support a new platform. > > In a previous discussion we have talked about when a platform can > be added in an LTS release. I think that in general if it's only > configuration changes and there is a very low risk that it's going > to have issues requiring other changes, we should allow it. Do you have a link to that discussion? If there is a prior example where this has happened I should also remove the statement that it is a unique case and mention the prior incident instead. > Kurt Regards, Felix Buenemann From kurt at roeckx.be Fri Nov 27 12:01:38 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 27 Nov 2020 13:01:38 +0100 Subject: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS In-Reply-To: References: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> <20201126175717.GA869939@roeckx.be> Message-ID: <20201127120138.GK113184@roeckx.be> On Fri, Nov 27, 2020 at 12:42:44PM +0100, Felix B?nemann wrote: > Hi Kurt, > > > Am 26.11.2020 um 18:57 schrieb Kurt Roeckx : > > > > On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix B?nemann wrote: > >> > >> It is also unique cause it requires no code changes to support a new platform. > > > > In a previous discussion we have talked about when a platform can > > be added in an LTS release. I think that in general if it's only > > configuration changes and there is a very low risk that it's going > > to have issues requiring other changes, we should allow it. > > Do you have a link to that discussion? It was in one of our online meetings, that resulted in the LTS+ proposal. > If there is a prior example where this has happened I should also remove the > statement that it is a unique case and mention the prior incident instead. As far as I know, there are no examples where we have allowed adding a platform in the stable release branch. Kurt From matt at openssl.org Fri Nov 27 17:15:13 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 Nov 2020 17:15:13 +0000 Subject: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS In-Reply-To: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> References: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> Message-ID: On 25/11/2020 20:17, Felix B?nemann wrote: > Regarding inclusion of macOS ARM64 Support in OpenSSL 1.1.1 LTS: > > The OMC accepts the required configuration change, making an exception to the > LTS rule that prevents adding new platforms. I'm about to raise this vote, but I plan to tweak this wording to instead say: Regarding inclusion of macOS ARM64 Support in OpenSSL 1.1.1 LTS: The OMC accepts the required configuration change, making an exception to the rule that prevents adding new platforms to stable releases. This is just to make it a little more accurate. New platforms are counted as new features, and the rule is that we do not add new features to stable releases. The rule is not specific to an LTS release - its any stable release. Matt From matt at openssl.org Fri Nov 27 17:24:29 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 Nov 2020 17:24:29 +0000 Subject: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS In-Reply-To: References: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> Message-ID: On 27/11/2020 17:15, Matt Caswell wrote: > > > On 25/11/2020 20:17, Felix B?nemann wrote: >> Regarding inclusion of macOS ARM64 Support in OpenSSL 1.1.1 LTS: >> >> The OMC accepts the required configuration change, making an exception to the >> LTS rule that prevents adding new platforms. > > I'm about to raise this vote, but I plan to tweak this wording to > instead say: > > Regarding inclusion of macOS ARM64 Support in OpenSSL 1.1.1 LTS: > The OMC accepts the required configuration change, making an exception > to the rule that prevents adding new platforms to stable releases. > > > This is just to make it a little more accurate. New platforms are > counted as new features, and the rule is that we do not add new features > to stable releases. The rule is not specific to an LTS release - its any > stable release. I've started the vote. I'll report back once we have an answer. Matt From matt at openssl.org Mon Nov 30 11:38:53 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 30 Nov 2020 11:38:53 +0000 Subject: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS In-Reply-To: References: <736D4E58-D515-4FE8-8465-55F2E5DE0054@gmail.com> Message-ID: On 27/11/2020 17:24, Matt Caswell wrote: > > > On 27/11/2020 17:15, Matt Caswell wrote: >> >> >> On 25/11/2020 20:17, Felix B?nemann wrote: >>> Regarding inclusion of macOS ARM64 Support in OpenSSL 1.1.1 LTS: >>> >>> The OMC accepts the required configuration change, making an exception to the >>> LTS rule that prevents adding new platforms. >> >> I'm about to raise this vote, but I plan to tweak this wording to >> instead say: >> >> Regarding inclusion of macOS ARM64 Support in OpenSSL 1.1.1 LTS: >> The OMC accepts the required configuration change, making an exception >> to the rule that prevents adding new platforms to stable releases. >> >> >> This is just to make it a little more accurate. New platforms are >> counted as new features, and the rule is that we do not add new features >> to stable releases. The rule is not specific to an LTS release - its any >> stable release. > > I've started the vote. I'll report back once we have an answer. This vote has now closed. It passed: accepted: yes (for: 6, against: 1, abstained: 0, not voted: 0) Matt From nic.tuv at gmail.com Mon Nov 30 12:03:15 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 30 Nov 2020 14:03:15 +0200 Subject: OTC VOTE: Fixing missing failure exit status is a bug fix Message-ID: Vote background --------------- This follows up on a [previous proposal] that was abandoned in favor of an OMC vote on the behavior change introduced in [PR#13359]. Within today's OTC meeting this was further discussed with the attending members that also sit in the OMC. The suggestion was to improve the separation of the OTC and OMC domains here, by having a more generic OTC vote to qualify as bug fixes the changes to let any OpenSSL app return an (early) failure exit status when a called function fails. The idea is that, if we agree on this technical definition, then no OMC vote to allow a behavior change in the apps would be required in general, unless, on a case-by-case basis, the "OMC hold" process is invoked for whatever reason on the specific bug fix, triggering the usual OMC decision process. [previous proposal]: [PR#13359]: Vote text --------- topic: In the context of the OpenSSL apps, the OTC qualifies as bug fixes the changes to return a failure exit status when a called function fails with an unhandled return value. Even when these bug fixes change the apps behavior triggering early exits (compared to previous versions of the apps), as bug fixes, they do not qualify as behavior changes that require an explicit OMC approval. Proposed by Nicola Tuveri Public: yes opened: 2020-11-30 From nic.tuv at gmail.com Mon Nov 30 12:08:50 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Mon, 30 Nov 2020 14:08:50 +0200 Subject: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix In-Reply-To: References: <20201124171855.GA732563@roeckx.be> Message-ID: I just opened the vote using the latest version of the vote text proposed in this thread. Here is the link to the vote: https://www.mail-archive.com/openssl-project at openssl.org/msg02286.html Cheers, Nicola On Tue, Nov 24, 2020 at 10:29 PM Nicola Tuveri wrote: > > Off-list I received a suggestion to use "unhandled" (thanks again!). > > I am not sure about it (I actually originally discarded in my first > draft of this proposal) because I am afraid that talking of "unhandled > return value" from a function might be misinterpreted as cases in > which we are ignoring the return value of a callee or in which we are > not considering the whole set of possible return values. > > Anyway, now that I disclaimed my doubts about it, I would submit to > your consideration this alternative to the original vote text: > > In the context of the OpenSSL apps, we qualify as bug fixes the > changes to return a failure exit status when a called function > fails with an unhandled return value. > Even when these bug fixes change the apps behavior triggering > early exits (compared to previous versions of the apps), as bug > fixes, they do not qualify as behavior changes that require an > explicit OMC approval. > > > Would this be preferable to the original proposal? > > > Cheers, > > Nicola > > On Tue, Nov 24, 2020 at 7:33 PM Nicola Tuveri wrote: > > > > Uhm, thanks Kurt! I think you have a point here, "unrecoverably" might > > be a poor choice. > > > > Do you have a proposal to qualify these cases in general? Or a better > > way to rephrase it? > > > > I wasn't happy with "In the context of the OpenSSL apps, we qualify as > > bug fixes the changes to return a failure exit status when a called > > function fails." (i.e., omitting unrecoverably or a better term): it > > is not uncommon to have function failures that are intended to be > > handled, taking a different course of action. > > > > > > @tjh, as the main driver of a more generic vote like this, do you have > > a better vote text proposal? > > > > > > Nicola > > > > > > On Tue, Nov 24, 2020, 19:18 Kurt Roeckx wrote: > > > > > > On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote: > > > > Background > > > > ---------- > > > > > > > > This follows up on a [previous proposal] that was abandoned in favor of > > > > an OMC vote on the behavior change introduced in [PR#13359]. > > > > Within today's OTC meeting this was further discussed with the attending > > > > members that also sit in the OMC. > > > > > > > > The suggestion was to improve the separation of the OTC and OMC domains > > > > here, by having a more generic OTC vote to qualify as bug fixes the > > > > changes to let any OpenSSL app return an (early) failure exit status > > > > when a called function fails. > > > > > > > > The idea is that, if we agree on this technical definition, then no OMC > > > > vote to allow a behavior change in the apps would be required in > > > > general, unless, on a case-by-case basis, the "OMC hold" process is > > > > invoked for whatever reason on the specific bug fix, triggering the > > > > usual OMC decision process. > > > > > > > > Proposed vote text > > > > ------------------ > > > > > > > > In the context of the OpenSSL apps, we qualify as bug fixes the > > > > changes to return a failure exit status when a called function > > > > fails unrecoverably. > > > > > > I'm not sure the unrecoverably should be there. I think this was > > > about verifying is a public or private key was valid. If such a > > > function returns it's not valid, I don't call that an > > > unrecoverable error. But I do expect the application to return an > > > error exit code. > > > > > > An other example is s_client, which ignores verification errors by > > > default. You can change that behaviour with -verify_return_error. If > > > you do that, s_client will actually exit with return value 1 in case > > > of a verification error. > > > > > > > > > Kurt > > > > > > From paul.dale at oracle.com Mon Nov 30 12:21:26 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 30 Nov 2020 22:21:26 +1000 Subject: OTC VOTE: Fixing missing failure exit status is a bug fix In-Reply-To: References: Message-ID: <8A32F515-FD67-442C-99C2-F33FB51C6D49@oracle.com> +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 30 Nov 2020, at 10:03 pm, Nicola Tuveri wrote: > > Vote background > --------------- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > [previous proposal]: > > [PR#13359]: > > > > Vote text > --------- > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug > fixes the changes to return a failure exit status when a called > function fails with an unhandled return value. > Even when these bug fixes change the apps behavior triggering > early exits (compared to previous versions of the apps), as bug > fixes, they do not qualify as behavior changes that require an > explicit OMC approval. > Proposed by Nicola Tuveri > Public: yes > opened: 2020-11-30 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Nov 30 13:01:13 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 30 Nov 2020 13:01:13 +0000 Subject: OTC VOTE: Fixing missing failure exit status is a bug fix In-Reply-To: References: Message-ID: +1 > -----Original Message----- > From: openssl-project On Behalf Of Nicola Tuveri > Sent: Monday, November 30, 2020 1:03 PM > To: OpenSSL Project > Subject: OTC VOTE: Fixing missing failure exit status is a bug fix > > Vote background > --------------- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > [previous proposal]: > > [PR#13359]: > > > > Vote text > --------- > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug > fixes the changes to return a failure exit status when a called > function fails with an unhandled return value. > Even when these bug fixes change the apps behavior triggering > early exits (compared to previous versions of the apps), as bug > fixes, they do not qualify as behavior changes that require an > explicit OMC approval. > Proposed by Nicola Tuveri > Public: yes > opened: 2020-11-30 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From tmraz at redhat.com Mon Nov 30 15:01:47 2020 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 30 Nov 2020 16:01:47 +0100 Subject: OTC VOTE: Fixing missing failure exit status is a bug fix In-Reply-To: References: Message-ID: +1 On Mon, 2020-11-30 at 14:03 +0200, Nicola Tuveri wrote: > Vote background > --------------- > > This follows up on a [previous proposal] that was abandoned in favor > of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the > attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC > domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no > OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > [previous proposal]: > < > https://www.mail-archive.com/openssl-project at openssl.org/msg02241.html > > > [PR#13359]: > > > > Vote text > --------- > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug > fixes the changes to return a failure exit status when a > called > function fails with an unhandled return value. > Even when these bug fixes change the apps behavior triggering > early exits (compared to previous versions of the apps), as > bug > fixes, they do not qualify as behavior changes that require an > explicit OMC approval. > Proposed by Nicola Tuveri > Public: yes > opened: 2020-11-30 -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tjh at cryptsoft.com Mon Nov 30 18:23:24 2020 From: tjh at cryptsoft.com (Tim Hudson) Date: Tue, 1 Dec 2020 04:23:24 +1000 Subject: OTC VOTE: Fixing missing failure exit status is a bug fix In-Reply-To: References: Message-ID: +1 On Mon, 30 Nov 2020, 10:03 pm Nicola Tuveri, wrote: > Vote background > --------------- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > [previous proposal]: > > [PR#13359]: > > > > Vote text > --------- > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug > fixes the changes to return a failure exit status when a called > function fails with an unhandled return value. > Even when these bug fixes change the apps behavior triggering > early exits (compared to previous versions of the apps), as bug > fixes, they do not qualify as behavior changes that require an > explicit OMC approval. > Proposed by Nicola Tuveri > Public: yes > opened: 2020-11-30 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Nov 30 20:39:38 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 30 Nov 2020 21:39:38 +0100 Subject: OTC VOTE: Fixing missing failure exit status is a bug fix In-Reply-To: References: Message-ID: <871rgatw8l.wl-levitte@openssl.org> +1 On Mon, 30 Nov 2020 13:03:15 +0100, Nicola Tuveri wrote: > > Vote background > --------------- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > [previous proposal]: > > [PR#13359]: > > > > Vote text > --------- > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug > fixes the changes to return a failure exit status when a called > function fails with an unhandled return value. > Even when these bug fixes change the apps behavior triggering > early exits (compared to previous versions of the apps), as bug > fixes, they do not qualify as behavior changes that require an > explicit OMC approval. > Proposed by Nicola Tuveri > Public: yes > opened: 2020-11-30 > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From shane.lontis at oracle.com Mon Nov 30 21:55:10 2020 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Mon, 30 Nov 2020 13:55:10 -0800 (PST) Subject: OTC VOTE: Fixing missing failure exit status is a bug fix In-Reply-To: References: Message-ID: +1 > On 30 Nov 2020, at 10:03 pm, Nicola Tuveri wrote: > > Vote background > --------------- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > [previous proposal]: > > [PR#13359]: > > > > Vote text > --------- > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug > fixes the changes to return a failure exit status when a called > function fails with an unhandled return value. > Even when these bug fixes change the apps behavior triggering > early exits (compared to previous versions of the apps), as bug > fixes, they do not qualify as behavior changes that require an > explicit OMC approval. > Proposed by Nicola Tuveri > Public: yes > opened: 2020-11-30 -------------- next part -------------- An HTML attachment was scrubbed... URL: