From pauli at openssl.org Mon Mar 1 00:08:52 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Mon, 1 Mar 2021 10:08:52 +1000 Subject: Monthly Status - February Message-ID: <46776347-a22e-a430-85ef-dcc365467304@openssl.org> Significant activities throughout February were: * Deprecation of RAND_METHOD and associated fallout * no-cache builds work and multitude of problems that fell out of this * Fixing a DRBG problem reported by the FIPS lab to do with entropy input * Investigation of DRBG incorrect output issue * Add EVP_xxx_CTX_gettable_params and EVP_xxx_CTX_settable_params calls * Improvements to the MAC API * Improvements to the KDF API * Improvement to the RAND API In addition were minor pull requests, reviewing, OMC and OTC business, et al. Pauli -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Mar 2 10:20:30 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 2 Mar 2021 10:20:30 +0000 Subject: OTC VOTE: Change behaviour of EVP_PKEY_get0/EVP_PKEY_get1 functions Message-ID: topic: EVP_PKEY_get0 functions will return a cached copy of the legacy key, and will be changed to return const. EVP_PKEY_get1 functions work as per EVP_PKEY_get0 but are not const returns and up the reference count Comment: See PR #14319 for background Proposed by Matt Caswell Public: yes opened: 2021-03-02 closed: 2021-02-02 accepted: yes (for: 7, against: 0, abstained: 0, not voted: 4) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [+1] From matt at openssl.org Tue Mar 2 12:43:12 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 2 Mar 2021 12:43:12 +0000 Subject: Monthly Status Report (February) Message-ID: <06c0fca7-9eca-fe5f-9f17-712f345a7b54@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, support customer issues, CLA submissions, handling security reports, etc., key activities this month: - Completed and pushed the PR to remove compile time algorithm checks from libssl - Removed some TODO(OpenSSL1.2) references - Removed a DSA related TODO - Created a patch for the CipherUpdate overflow issue (CVE-2021-23840) - Wrote the security advisory for CVE-2021-23839/CVE-2021-23840/CVE-23841 - Deprecated the SRP APIs - Sprint planning for the Hydrogen sprint - Created a patch for the X509_issuer_and_serial_hash() issue (CVE-2021-23841) - Manged and performed the 1.1.1j and 1.0.2y security releases - Fixed "openssl dhparam -check" - Investigated memory allocation issue in OPENSSL_cleanup() - Fixed issues with the pem2der decoder where the type of thing we are loading could be forgotten when moving to the next decoder in the chain. - PR to duplicate the file and func error string to avoid a crash where a provider gets unloaded with errors still on the stack - Added documentation for all the remaining symbols that have been added since 1.1.1 but were still undocumented - Performed the alpha12 release - Fixed mingw build failure - Fixed an issue where a lock was held in ossl_namemap_doall_names while calling a user callback - Sprint planning for the Helium sprint - Implemented PR to cache legacy keys in an EVP_PKEY instead of downgrading it - Significant ongoing work to investigate 1.1.1 test failures when run against the 3.0 libraries Matt From tomas at openssl.org Tue Mar 2 17:16:53 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 02 Mar 2021 18:16:53 +0100 Subject: Monthly Status Report (February 2021) Message-ID: My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - reviews of various PRs: - I've reviewed about 70 PRs this month - Major PRs reviewed: - 3.0 alpha 12 release review - PROV: Add SM2 encoders and decoders, as well as support functionality #14028 - test/recipes: split 81_test_cmp_cli.t, add test using -engine loader_attic #13551 - Refactor x509_vfy.c for code cleanup #13070 - Remove compile time algorithm checks from libssl #13916 - Deprecate SRP #14132 - OSSL_PARAM: Correct the assumptions on the UTF8 string length #14168 - Add EVP_PKEY_public_check_quick. #14206 - EVP: Implement data-driven translation between known ctrl and OSSL_PARAMs #13913 - Add context gettable and settable calls #14240 - Make i2d_PublicKey() work with provider side EC EVP_PKEYs #14291 - submitted 18 PRs: - In particular: - speed: Always use the EVP APIs for speed measurements #14228 - Deprecated EVP_PKEY_CTX_get0_dh_kdf_ukm() and EVP_PKEY_CTX_get0_ecdh_kdf_ukm() #14279 - Various cleanups related to EVP_PKEY_CTX_ctrl related TODOs #14290 - EVP_PKEY_CTX_get/settable_params: pass provider operation context #14338 - Deprecate BN_pseudo_rand() and BN_pseudo_rand_range() #14080 - Make PROV_R_ reason codes public and do some cleanup of them #14086 - dsa_check: Perform simple parameter check if seed is not available #14148 - Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY #14155 Tomas From kurt at roeckx.be Wed Mar 3 18:48:23 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 3 Mar 2021 19:48:23 +0100 Subject: OTC VOTE: Change behaviour of EVP_PKEY_get0/EVP_PKEY_get1 functions In-Reply-To: References: Message-ID: On Tue, Mar 02, 2021 at 10:20:30AM +0000, Matt Caswell wrote: > topic: EVP_PKEY_get0 functions will return a cached copy of the legacy key, > and > will be changed to return const. EVP_PKEY_get1 functions work as per > EVP_PKEY_get0 but are not const returns and up the reference count > Comment: See PR #14319 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-03-02 > closed: 2021-02-02 It closed before it was opened. I'm voting 0. Kurt From matt at openssl.org Tue Mar 9 10:24:32 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 9 Mar 2021 10:24:32 +0000 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve Message-ID: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This should be documented. Proposed by Matt Caswell Public: yes opened: 2021-03-09 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [ 0] Kurt [ ] Matthias [ ] Nicola [-1] From matt at openssl.org Tue Mar 9 10:25:50 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 9 Mar 2021 10:25:50 +0000 Subject: OTC VOTE: EVP init functions and the provider interface Message-ID: <0d5c6d89-7230-e96c-eb4f-090e8025a295@openssl.org> topic: EVP init functions take an OSSL_PARAM array to set parameters and this should be reflected in the equivalent provider interface. Proposed by Matt Caswell Public: yes opened: 2021-03-09 closed: 2021-03-09 accepted: yes (for: 5, against: 0, abstained: 2, not voted: 4) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim [+1] Richard [ 0] Shane [+1] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [+0] From tomas at openssl.org Tue Mar 9 11:29:30 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 09 Mar 2021 12:29:30 +0100 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve In-Reply-To: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> References: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> Message-ID: <692756c803b456930bfb4ded3e24ed2edb9ca159.camel@openssl.org> For OTC members - please note that this vote is not closed, so your vote counts if you have not voted yet! :D On Tue, 2021-03-09 at 10:24 +0000, Matt Caswell wrote: > topic: In 3.0 it will not be possible to use SM2 with a non-SM2 > curve. This > should be documented. > Proposed by Matt Caswell > Public: yes > opened: 2021-03-09 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [+1] > Richard [+1] > Shane [+1] > Tomas [ 0] > Kurt [ ] > Matthias [ ] > Nicola [-1] > From nic.tuv at gmail.com Tue Mar 9 13:57:32 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 9 Mar 2021 15:57:32 +0200 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve In-Reply-To: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> References: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> Message-ID: It is tangent to the vote in itself, but I'd like to highlight that in part this vote is motivated by getting rid of cases where there is a need to convert between compatible key types (e.g. SM2 & EC, DH & DHX). The vote of this text does not cover it, but another use case that we will likely lose in 3.0 when this vote passes is using ECDH/ECDSA over the curve identified by the SM2 OID. It's likely another niche use, not relevant for any production system, but it is creating a precedent where OpenSSL accepts that the SM2 standard overrides the SECG standard. In 1.1.1 we do _default_ to decode a key serialized as "SECG EC over the SM2 OID curve" as a SM2 key, but we are not preventing developers from creating an EC key object over that curve, nor an SM2 key object over any other curve (serialization of such "weird" key objects would be identical, deserialization would require an explicit set_alias call to mutate from the default type). With the changes proposed as a corollary to this vote that were discussed on the last OTC meeting, we would remove this ability: we could maybe still create an ephemeral "EC over SM2 OID" key object but there would be no way to deserialize one. I would instead prefer to vote on requiring for 3.0 a mechanism to "convert" key types: an EVP_PKEY_todata function to mirror EVP_PKEY_fromdata. It will be then up to the individual keymgmt of the source key object to decide if it can be exported to OSSL_PARAMs, and to the receiving keymgmt on which fromdata is called to determine if the input OSSL_PARAMs are valid to create a proper key object. Yes, we would still have a breaking change (set_alias needs to be replaced by the todata/fromdata dance) but we wouldn't lose functionality. Such a mechanism could be useful also beyond the current problem of key conversions within the builtin providers, and allow future proofing and interoperability between different providers that might end up using different names for compatible key types (for whatever reason it might happen). Nicola On Tue, Mar 9, 2021, 12:24 Matt Caswell wrote: > topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This > should be documented. > Proposed by Matt Caswell > Public: yes > opened: 2021-03-09 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [+1] > Viktor [ ] > Tim [+1] > Richard [+1] > Shane [+1] > Tomas [ 0] > Kurt [ ] > Matthias [ ] > Nicola [-1] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Mar 9 17:07:36 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 9 Mar 2021 18:07:36 +0100 Subject: OTC VOTE: EVP init functions and the provider interface In-Reply-To: <0d5c6d89-7230-e96c-eb4f-090e8025a295@openssl.org> References: <0d5c6d89-7230-e96c-eb4f-090e8025a295@openssl.org> Message-ID: On Tue, Mar 09, 2021 at 10:25:50AM +0000, Matt Caswell wrote: > topic: EVP init functions take an OSSL_PARAM array to set parameters and > this > should be reflected in the equivalent provider interface. I need more information than the vote text to be able to vote on this. Kurt From matt at openssl.org Tue Mar 9 17:22:09 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 9 Mar 2021 17:22:09 +0000 Subject: OTC VOTE: EVP init functions and the provider interface In-Reply-To: References: <0d5c6d89-7230-e96c-eb4f-090e8025a295@openssl.org> Message-ID: This is related to the discussion in PR #14383. It has already been decided to add OSSL_PARAM arrays as an argument to the various EVP "init" functions. During the implementation of that there were differing views about whether this same change should be reflected in the core<->provider interface, i.e. so that the provider init functions would also take OSSL_PARAM arrays. The alternative was to have the libcrypto implementation of the init functions call the provider init and the provider set_params calls separately. Matt On 09/03/2021 17:07, Kurt Roeckx wrote: > On Tue, Mar 09, 2021 at 10:25:50AM +0000, Matt Caswell wrote: >> topic: EVP init functions take an OSSL_PARAM array to set parameters and >> this >> should be reflected in the equivalent provider interface. > > I need more information than the vote text to be able to vote on > this. > > > Kurt > From kurt at roeckx.be Tue Mar 9 18:06:40 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 9 Mar 2021 19:06:40 +0100 Subject: OTC VOTE: EVP init functions and the provider interface In-Reply-To: <0d5c6d89-7230-e96c-eb4f-090e8025a295@openssl.org> References: <0d5c6d89-7230-e96c-eb4f-090e8025a295@openssl.org> Message-ID: On Tue, Mar 09, 2021 at 10:25:50AM +0000, Matt Caswell wrote: > topic: EVP init functions take an OSSL_PARAM array to set parameters and > this > should be reflected in the equivalent provider interface. +1 Kurt From kurt at roeckx.be Tue Mar 9 18:50:55 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 9 Mar 2021 19:50:55 +0100 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve In-Reply-To: References: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> Message-ID: On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote: > It is tangent to the vote in itself, but I'd like to highlight that in part > this vote is motivated by getting rid of cases where there is a need to > convert between compatible key types (e.g. SM2 & EC, DH & DHX). > > The vote of this text does not cover it, but another use case that we will > likely lose in 3.0 when this vote passes is using ECDH/ECDSA over the curve > identified by the SM2 OID. > > It's likely another niche use, not relevant for any production system, but > it is creating a precedent where OpenSSL accepts that the SM2 standard > overrides the SECG standard. > > In 1.1.1 we do _default_ to decode a key serialized as "SECG EC over the > SM2 OID curve" as a SM2 key, but we are not preventing developers from > creating an EC key object over that curve, nor an SM2 key object over any > other curve (serialization of such "weird" key objects would be identical, > deserialization would require an explicit set_alias call to mutate from the > default type). > > With the changes proposed as a corollary to this vote that were discussed > on the last OTC meeting, we would remove this ability: we could maybe still > create an ephemeral "EC over SM2 OID" key object but there would be no way > to deserialize one. > > > I would instead prefer to vote on requiring for 3.0 a mechanism to > "convert" key types: an EVP_PKEY_todata function to mirror > EVP_PKEY_fromdata. > It will be then up to the individual keymgmt of the source key object to > decide if it can be exported to OSSL_PARAMs, and to the receiving keymgmt > on which fromdata is called to determine if the input OSSL_PARAMs are valid > to create a proper key object. > Yes, we would still have a breaking change (set_alias needs to be replaced > by the todata/fromdata dance) but we wouldn't lose functionality. > > Such a mechanism could be useful also beyond the current problem of key > conversions within the builtin providers, and allow future proofing and > interoperability between different providers that might end up using > different names for compatible key types (for whatever reason it might > happen). This text does not seem to help me to make a vote, it seems I just get more questions. The EVP_PKEY_set_alias_type() manpage says that SM2 use the same encoding an ECDSA. I assume that during deserialization we don't know if we should create an ECDSA key or an SM2 key, because we don't look at the OID when deserializing and always create an ECDSA key. My understanding is that there is code that needs to know an SM2 key is stored in that object, and is not looking at the OID, but instead looks at what the pkey type is. My suggested fix for that would be to make the deserialization smarter so it sets the correct pkey type base on the OID. Assuming that we can get an SM2 key, I currently fail to see why ECDSA or ECDH wouldn't work with them, but I know very little about SM2. I also don't understand what the vote is really about. Can 1.1.1 do SM2 on one of the nist curves? Kurt From nic.tuv at gmail.com Wed Mar 10 03:44:22 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Wed, 10 Mar 2021 05:44:22 +0200 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve In-Reply-To: References: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> Message-ID: Yes, in 1.1.1j the following is possible: - SM2 cryptosystem operations over the "SM2 curve" - SM2 cryptosystem operations over arbitrary curve (including NIST ones) - ECDSA/ECDH cryptosystem operations over the "SM2 curve" (See attached patches to verify this is the case in the tests) They require an explicit call to `EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2);` or `EVP_PKEY_set_alias_type(pkey, EVP_PKEY_EC);`, to pick respectively SM2 cryptosystem operations or ECDSA/ECDH cryptosystem operations. In 3.0, we want to get rid of `EVP_PKEY_set_alias_type()` and make the "type" of a key object immutable: this will be a breaking change for applications that were using SM2 in 1.1.1. This vote is, in addition, about removing existing functionality: doing SM2 stuff over non-SM2 curves (and, somewhat implicitly, also about doing ECDSA/DH-stuff over the "SM2 curve"). I'd prefer to retain the functionality, accessible programmatically, to create an EC keymgmt object over the "SM2 curve" as well as an SM2 keymgmt object over any arbitrary curve. (Hence my -1 in this vote). I'd also like to have a separate vote, when we will formalize that key types are immutable, to require a `EVP_PKEY_todata()` mechanism to mirror the `EVP_PKEY_fromdata()` mechanism, so that while key types remain immutable, there will be a convenient way for us and our users to export a key object from a keymgmt and import it into another keymgmt, letting provider implementations define what is exported and if the exported data is compatible with what is expected on import. ## Serialized SM2-related keys Regarding serialization/deserialization of SM2-related keys: at the standard level SM2 reuses the format for standard EC keys, including the "outer" OID for the key type which is "id-ecPublicKey"; it also defines an OID to be used for the (currently) only curve that is recommended for use by the SM2 standard. This OID (`1.2.156.10197.1.301` ) is also a bit weird: it's labeled as `"SM2" elliptic curve cryptography` and it's not a leaf node in the OID tree, among the children there are `.1` for `SM2-1 Digital Signature Algorithm`, `.3` for `"SM2-3" public key encryption` and `.101` for `"wapip192v1"` (which seems to be another SM2 curve, but I never found where it is actually used); but because most implementations (including OpenSSL) use `1.2.156.10197.1.301` to indicate the SM2-recommended 256-bit prime curve some projects (notably gmSSL) refer to at as `sm2p256v1`. At the same time, from the available SM2 standards , while `sm2p256v1` is currently the only recommended curve, nothing prevents using other elliptic curves: in theory both prime and binary curves are allowed, and IIRC also explicit parameter ones. Overall the current scenario of how SM2 OIDs are assigned/used, combined with the fact that the SM2 standard reuses the same serialization format defined by SECG for regular ECDSA/ECDH keys, makes it impossible to distinguish between a key for the SM2 cryptosystems or for the ECDSA/DH cryptosystems. In 1.1.1j, when deserializing with `PEM_read_PrivateKey()` this key: ~~~ -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqBHM9VAYItBG0wawIBAQQgOYffNMmrl1T1HVVC wijmHL5xn9vm/IeLWfLnA/NJwgehRANCAAQsIGyWbZl+m04MHFOf47z/Z06Yyr69 ZjZZoyJviFyj/9mx4B8Mjs2ranuRjykBF6SdIcLD+c6AqZ9cvs2V4m2R -----END PRIVATE KEY----- 0:d=0 hl=3 l= 135 cons: SEQUENCE 3:d=1 hl=2 l= 1 prim: INTEGER :00 6:d=1 hl=2 l= 19 cons: SEQUENCE 8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 17:d=2 hl=2 l= 8 prim: OBJECT :sm2 27:d=1 hl=2 l= 109 prim: OCTET STRING 0000 - 30 6b 02 01 01 04 20 39-87 df 34 c9 ab 97 54 f5 0k.... 9..4...T. 0010 - 1d 55 42 c2 28 e6 1c be-71 9f db e6 fc 87 8b 59 .UB.(...q......Y 0020 - f2 e7 03 f3 49 c2 07 a1-44 03 42 00 04 2c 20 6c ....I...D.B.., l 0030 - 96 6d 99 7e 9b 4e 0c 1c-53 9f e3 bc ff 67 4e 98 .m.~.N..S....gN. 0040 - ca be bd 66 36 59 a3 22-6f 88 5c a3 ff d9 b1 e0 ...f6Y."o.\..... 0050 - 1f 0c 8e cd ab 6a 7b 91-8f 29 01 17 a4 9d 21 c2 .....j{..)....!. 0060 - c3 f9 ce 80 a9 9f 5c be-cd 95 e2 6d 91 ......\....m. ~~~ we create an EVP_PKEY object with `{ .type = 408 (= EVP_PKEY_EC, "id-ecPublicKey"), .save_type = 408 }`. If used via EVP functions in this form, this will be used as a regular EC key, computing ECDSA/ECDH. After an explicit call to `EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2))`, the EVP_PKEY object reads `{ .type = 1172 (= EVP_PKEY_SM2, "SM2"), .save_type = 408 }`, and using EVP functions will result in using this as a key for the SM2 cryptosystems (e.g. SM2DSA). In 3.0, as of 3e6a0d5738, our DECODER implementation is able to distinguish on the inner curve OID, so parsing the PEM above results in a key object belonging to the SM2 keymgmt. Because `EVP_PKEY_set_alias_type()` is not supported, in current 3.0 it is hard (if not impossible) to flexibly use EC/SM2 keys as in 1.1.1, but it is still possible to do something with ephemeral keys (e.g. one can initialize an SM2 keygen EVP_PKEY_CTX and set P-521 as the curve, which ultimately delivers an SM2 key object over an arbitrary curve that can be used, for example, for SM2DSA operations as demonstrated by 0001-drop-3.0.0-test-SM2DSA-and-SM2ENC-DEC-over-NIST-P-52.patch). Nicola On Tue, Mar 9, 2021 at 8:50 PM Kurt Roeckx wrote: > On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote: > > It is tangent to the vote in itself, but I'd like to highlight that in > part > > this vote is motivated by getting rid of cases where there is a need to > > convert between compatible key types (e.g. SM2 & EC, DH & DHX). > > > > The vote of this text does not cover it, but another use case that we > will > > likely lose in 3.0 when this vote passes is using ECDH/ECDSA over the > curve > > identified by the SM2 OID. > > > > It's likely another niche use, not relevant for any production system, > but > > it is creating a precedent where OpenSSL accepts that the SM2 standard > > overrides the SECG standard. > > > > In 1.1.1 we do _default_ to decode a key serialized as "SECG EC over the > > SM2 OID curve" as a SM2 key, but we are not preventing developers from > > creating an EC key object over that curve, nor an SM2 key object over any > > other curve (serialization of such "weird" key objects would be > identical, > > deserialization would require an explicit set_alias call to mutate from > the > > default type). > > > > With the changes proposed as a corollary to this vote that were discussed > > on the last OTC meeting, we would remove this ability: we could maybe > still > > create an ephemeral "EC over SM2 OID" key object but there would be no > way > > to deserialize one. > > > > > > I would instead prefer to vote on requiring for 3.0 a mechanism to > > "convert" key types: an EVP_PKEY_todata function to mirror > > EVP_PKEY_fromdata. > > It will be then up to the individual keymgmt of the source key object to > > decide if it can be exported to OSSL_PARAMs, and to the receiving keymgmt > > on which fromdata is called to determine if the input OSSL_PARAMs are > valid > > to create a proper key object. > > Yes, we would still have a breaking change (set_alias needs to be > replaced > > by the todata/fromdata dance) but we wouldn't lose functionality. > > > > Such a mechanism could be useful also beyond the current problem of key > > conversions within the builtin providers, and allow future proofing and > > interoperability between different providers that might end up using > > different names for compatible key types (for whatever reason it might > > happen). > > This text does not seem to help me to make a vote, it seems I just > get more questions. > > The EVP_PKEY_set_alias_type() manpage says that SM2 use the same > encoding an ECDSA. I assume that during deserialization we don't > know if we should create an ECDSA key or an SM2 key, because we > don't look at the OID when deserializing and always create an > ECDSA key. My understanding is that there is code that needs to > know an SM2 key is stored in that object, and is not looking at > the OID, but instead looks at what the pkey type is. My suggested > fix for that would be to make the deserialization smarter so it > sets the correct pkey type base on the OID. > > Assuming that we can get an SM2 key, I currently fail to see why > ECDSA or ECDH wouldn't work with them, but I know very little > about SM2. > > I also don't understand what the vote is really about. Can 1.1.1 > do SM2 on one of the nist curves? > > > Kurt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-drop-test-SM2DSA-and-SM2ENC-DEC-over-NIST-P-521-curv.patch Type: text/x-patch Size: 2284 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-drop-test-ECDSA-over-SM2-curve.patch Type: text/x-patch Size: 2155 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-drop-3.0.0-test-SM2DSA-and-SM2ENC-DEC-over-NIST-P-52.patch Type: text/x-patch Size: 2903 bytes Desc: not available URL: From kurt at roeckx.be Thu Mar 11 10:48:42 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 11 Mar 2021 11:48:42 +0100 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve In-Reply-To: References: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> Message-ID: On Wed, Mar 10, 2021 at 05:44:22AM +0200, Nicola Tuveri wrote: > Yes, in 1.1.1j the following is possible: > > - SM2 cryptosystem operations over the "SM2 curve" > - SM2 cryptosystem operations over arbitrary curve (including NIST ones) > - ECDSA/ECDH cryptosystem operations over the "SM2 curve" Is there any reason why we want to support the last 2? > In 3.0, we want to get rid of `EVP_PKEY_set_alias_type()` and make the > "type" of a key object immutable: this will be a breaking change for > applications that were using SM2 in 1.1.1. I assume that's because they got the wrong type when reading a file with that, but it's unclear to me what they should do instead. What I see is: - We'll change the parser so it sets the correct type and there is no need to change the type - Your proposal where you need to export it, and import it again using a different type, making it very complicated to work with SM2. Kurt From rsalz at akamai.com Thu Mar 11 12:25:34 2021 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Mar 2021 12:25:34 +0000 Subject: TLS intro testing Message-ID: <28DC7ACE-BD20-4875-A5E0-D372E9B0C80A@akamai.com> https://github.com/xvzcf/tls-interop-runner : The TLS Interop Test Runner aims to test interoperability between implementations of TLS by running various tests involving clients and servers drawn from differing implementations. It is fashioned after the QUIC Interop Runner. This is built on Go. Slides are at: https://datatracker.ietf.org/meeting/110/materials/slides-110-tls-tls-interop-runner-00 Video presentation at https://youtu.be/pXLFfrG-2N8?t=300 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Mar 11 14:19:58 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 11 Mar 2021 14:19:58 +0000 Subject: OpenSSL version 3.0.0-alpha13 published Message-ID: <20210311141958.GA6775@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 13 released ===================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 13 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-alpha13.tar.gz Size: 14211501 SHA1 checksum: 754aab6dc677668255fec676c6340a3a191e8135 SHA256 checksum: c88cbb9d330b4daa3dbb5af1ed511d5062253291a56e09fd17e9ac013a20f8a3 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha13.tar.gz openssl sha256 openssl-3.0.0-alpha13.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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBKH2UACgkQ2cTSbQ5g RJGU0gf9F6POd8koanFFrOBR9BlnlZyhFqYgn0s0404f4FIv0ntX9ClJ/GU4CruD hch4riFzD4uGtX9vpEHMs6cdWmMQmaoQendH0kIbHqLubxm3R51S8L5sIxQRnc0B pXDEteafEPd8jQyZmcg5Hd0aQI1Ju7hw3B9H/0C8JkPbSyfP7XOanWJJh9dinOEb HpswBhQWNmY6OwyIv9mmJQ+BtEbTXrADpMTsBWH1s84oQ8xT64e3Jzkwyx4DDnBi dKDYJjhjAV6mm7GVTBgT3nier3p9CgvbmViMRf1RNbwOpX7lhd+VgWN0QfvOF2dT rKbOZXDnSjbTt2lDr4VvOY+8B870/g== =1LTf -----END PGP SIGNATURE----- From kurt at roeckx.be Tue Mar 16 09:52:22 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 16 Mar 2021 10:52:22 +0100 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve In-Reply-To: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> References: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> Message-ID: On Tue, Mar 09, 2021 at 10:24:32AM +0000, Matt Caswell wrote: > topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This > should be documented. +1 Kurt From matt at openssl.org Tue Mar 16 10:08:58 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Mar 2021 10:08:58 +0000 Subject: OTC VOTE: Disallow SM2 with a non-SM2 curve In-Reply-To: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> References: <24a22199-1ad7-4c88-6ce2-0720d6d88fb3@openssl.org> Message-ID: <7a7cd7dc-6c6a-2e60-bc0a-00a9226b7013@openssl.org> This vote has now closed: accepted: yes (for: 7, against: 1, abstained: 1, not voted: 2) Matt On 09/03/2021 10:24, Matt Caswell wrote: > topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This > ?????? should be documented. > Proposed by Matt Caswell > Public: yes > opened: 2021-03-09 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ? Matt?????? [+1] > ? Mark?????? [? ] > ? Pauli????? [+1] > ? Viktor???? [? ] > ? Tim??????? [+1] > ? Richard??? [+1] > ? Shane????? [+1] > ? Tomas????? [ 0] > ? Kurt?????? [? ] > ? Matthias?? [? ] > ? Nicola???? [-1] > From matt at openssl.org Tue Mar 16 10:10:01 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Mar 2021 10:10:01 +0000 Subject: OTC VOTE: Add a description field to OSSL_ALGORITHM Message-ID: <9ac81768-0698-f75d-17f9-e3cf3a585dc0@openssl.org> topic: Add a description field to the OSSL_ALGORITHM structure Comment: See Issue #14514 for background Proposed by Matt Caswell Public: yes opened: 2021-03-16 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [ ] Pauli [-1] Viktor [ ] Tim [ ] Richard [+1] Shane [ 0] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [+1] From matt at openssl.org Mon Mar 22 09:18:12 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 22 Mar 2021 09:18:12 +0000 Subject: Forthcoming OpenSSL release Message-ID: <25278da8-52f1-d282-5767-24beddb72254@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1k. This release will be made available on Thursday 25th March 2021 between 1300-1700 UTC. OpenSSL 1.1.1k is a security-fix release. The highest severity issue fixed in this release is HIGH: https://www.openssl.org/policies/secpolicy.html#high Yours The OpenSSL Project Team From matt at openssl.org Tue Mar 23 09:12:40 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Mar 2021 09:12:40 +0000 Subject: OTC VOTE: Add a description field to OSSL_ALGORITHM In-Reply-To: <9ac81768-0698-f75d-17f9-e3cf3a585dc0@openssl.org> References: <9ac81768-0698-f75d-17f9-e3cf3a585dc0@openssl.org> Message-ID: <2bff745d-7b38-d49e-d3cd-7a1a0d05472c@openssl.org> This vote has now closed: accepted: yes (for: 5, against: 1, abstained: 1, not voted: 4) On 16/03/2021 10:10, Matt Caswell wrote: > topic: Add a description field to the OSSL_ALGORITHM structure > Comment: See Issue #14514 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-03-16 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ? Matt?????? [+1] > ? Mark?????? [? ] > ? Pauli????? [-1] > ? Viktor???? [? ] > ? Tim??????? [? ] > ? Richard??? [+1] > ? Shane????? [ 0] > ? Tomas????? [+1] > ? Kurt?????? [? ] > ? Matthias?? [? ] > ? Nicola???? [+1] From kurt at roeckx.be Tue Mar 23 18:10:46 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 23 Mar 2021 19:10:46 +0100 Subject: OTC VOTE: Add a description field to OSSL_ALGORITHM In-Reply-To: <2bff745d-7b38-d49e-d3cd-7a1a0d05472c@openssl.org> References: <9ac81768-0698-f75d-17f9-e3cf3a585dc0@openssl.org> <2bff745d-7b38-d49e-d3cd-7a1a0d05472c@openssl.org> Message-ID: On Tue, Mar 23, 2021 at 09:12:40AM +0000, Matt Caswell wrote: > This vote has now closed: > > accepted: yes (for: 5, against: 1, abstained: 1, not voted: 4) It seems unclear to me that you can close the vote at this time. The result is not clear, the 4 people who didn't vote can vote -1 in which case it doesn't pass. The vote period is between 7 and 14 days, but no close date was specified as required by the bylaws. I think we normally use 14 days. Anyway, voting -1. Kurt > On 16/03/2021 10:10, Matt Caswell wrote: > > topic: Add a description field to the OSSL_ALGORITHM structure > > Comment: See Issue #14514 for background > > Proposed by Matt Caswell > > Public: yes > > opened: 2021-03-16 > > closed: 2021-mm-dd > > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > > > ? Matt?????? [+1] > > ? Mark?????? [? ] > > ? Pauli????? [-1] > > ? Viktor???? [? ] > > ? Tim??????? [? ] > > ? Richard??? [+1] > > ? Shane????? [ 0] > > ? Tomas????? [+1] > > ? Kurt?????? [? ] > > ? Matthias?? [? ] > > ? Nicola???? [+1] From matt at openssl.org Tue Mar 23 19:02:58 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Mar 2021 19:02:58 +0000 Subject: OTC VOTE: Add a description field to OSSL_ALGORITHM In-Reply-To: References: <9ac81768-0698-f75d-17f9-e3cf3a585dc0@openssl.org> <2bff745d-7b38-d49e-d3cd-7a1a0d05472c@openssl.org> Message-ID: <1f5b69fc-3b44-1240-a553-75e1ba180185@openssl.org> On 23/03/2021 18:10, Kurt Roeckx wrote: > On Tue, Mar 23, 2021 at 09:12:40AM +0000, Matt Caswell wrote: >> This vote has now closed: >> >> accepted: yes (for: 5, against: 1, abstained: 1, not voted: 4) > > It seems unclear to me that you can close the vote at this time. > The result is not clear, the 4 people who didn't vote can vote -1 > in which case it doesn't pass. > > The vote period is between 7 and 14 days, but no close date was > specified as required by the bylaws. I think we normally use > 14 days. > > Anyway, voting -1. Oops - my apologies. A maths error adding up the required votes to check if it had passed. I was about to reopen it - but we've had one other vote since then as well. So, it really is closed now, and it still passes: accepted: yes (for: 6, against: 2, abstained: 1, not voted: 2) Matt > > > Kurt > >> On 16/03/2021 10:10, Matt Caswell wrote: >>> topic: Add a description field to the OSSL_ALGORITHM structure >>> Comment: See Issue #14514 for background >>> Proposed by Matt Caswell >>> Public: yes >>> opened: 2021-03-16 >>> closed: 2021-mm-dd >>> accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) >>> >>> ? Matt?????? [+1] >>> ? Mark?????? [? ] >>> ? Pauli????? [-1] >>> ? Viktor???? [? ] >>> ? Tim??????? [? ] >>> ? Richard??? [+1] >>> ? Shane????? [ 0] >>> ? Tomas????? [+1] >>> ? Kurt?????? [? ] >>> ? Matthias?? [? ] >>> ? Nicola???? [+1] > From openssl at openssl.org Thu Mar 25 13:57:18 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 Mar 2021 13:57:18 +0000 Subject: OpenSSL version 1.1.1k published Message-ID: <20210325135718.GA5803@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1k released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1k of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1k is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1k.tar.gz Size: 9823400 SHA1 checksum: bad9dc4ae6dcc1855085463099b5dacb0ec6130b SHA256 checksum: 892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1k.tar.gz openssl sha256 openssl-1.1.1k.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBckA0ACgkQ2cTSbQ5g RJE5lwgArWHJ+bjtnno8MtRH22cC4YjvDvTtwKsm2ESDKPnNMtMVDM/GUF3g9R5L 4H5WTWNCGFiQ/GqCIsty0tcV3NFMqKLBtl/5rm4+SQ+EG6oyKvjDBOOhwOoVS6Wy Kam+sM+6u444JY0GjKxjXKwFLGZKhtetXH1kMbi5rZw/5ln+DOh+NfyAN6YxPfOD KSV5K3sEA98ppeyE4ac+06lllXOZ8LfTGSxRojiQ08e6MkXDkWC2Vq5C963mm4Tk 1rmJTN3w3DoFh0IuZdTiCQzqUmam+jb3g8S95yKR7pjfydfbCtmkgIVAXFJ2UJR2 rUu1Sv19POSyy39WUnNb9s2PtoviTw== =f54Z -----END PGP SIGNATURE----- From openssl at openssl.org Thu Mar 25 14:03:24 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 Mar 2021 14:03:24 +0000 Subject: OpenSSL Security Advisory Message-ID: <20210325140324.GA8266@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [25 March 2021] ========================================= CA certificate check bypass with X509_V_FLAG_X509_STRICT (CVE-2021-3450) ======================================================================== Severity: High The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. This issue was reported to OpenSSL on 18th March 2021 by Benjamin Kaduk from Akamai and was discovered by Xiang Ding and others at Akamai. The fix was developed by Tom?? Mr?z. NULL pointer deref in signature_algorithms processing (CVE-2021-3449) ===================================================================== Severity: High An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. This issue was reported to OpenSSL on 17th March 2021 by Nokia. The fix was developed by Peter K?stle and Samuel Sapalski from Nokia. Note ==== OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20210325.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBcl6sACgkQ2cTSbQ5g RJGvnAgAtG6I7rfokDC9E5yB26KC3k0Vasfq5iH/aZz0CNRyOokWJBUyyNIVjqr0 2eZP7VsQT7zRM+tgh9c8MwH3FIghtpwJRJls4qZDHKoXts7JH4Ul4NLPd546x7xA GcKNwTD4NkZbTqtZ72NTgliInzrj0MCC8jqQrIIkcAIleGNzvZ0f64jdE+vBXoqX M2FOhWiA/JkAKtB3W7pthIt25qkOwHbrpTy+UUp/S5QD779NJ/EOYcsOFBRfLZiP gA6QILuW2L55lhG6Y2u+nVE3UI2hqd2hGgSAvDIPr2lVJxq0LQpgHca7Gj5bfIRo GLDz7n0FhN6n7NBqetP+nlHmYivcSg== =XIXK -----END PGP SIGNATURE----- From kurt at roeckx.be Tue Mar 30 09:24:10 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 30 Mar 2021 11:24:10 +0200 Subject: OTC VOTE: EVP_PKEY types are immutable once set Message-ID: Hi, I just found this in votes.txt, it looks like it was not mailed to the list as required. topic: EVP_PKEY types are immutable once set. Types cannot be changed once set. To move from one type to another compatible type will require export/import. Comment: This will result in breaking changes compared to previous releases. Proposed by Tim Public: yes opened: 2021-03-23 closed: 2021-03-23 accepted: yes (for: 6, against: 0, abstained: 0, not voted: 5) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] # 2021-03-23 Nicola [+1] # 2021-03-30 I'm voting +1 on this. Kurt From pauli at openssl.org Wed Mar 31 09:57:23 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 31 Mar 2021 19:57:23 +1000 Subject: Monthly Status - March Message-ID: <424c13a3-413b-b6fd-9053-381ca41af93f@openssl.org> Significant activities throughout February were: * Add OSSL_PARAM arguments to the initialisation calls for all algorithms. * Figured out algorithm life cycles, produced diagrams and state descriptions. * Wrote up the life cycles for KDF, MAC and RAND (the "new" algorithm types). * Separated OSSL_CORE_BIO and BIO and fixed a number of bugs along the way. * Improved the fake RAND used by some of the test suite. * Fixed a threading problem with the for all loaded function. * Checked all the do all functions for potential threading problems. * Added a no-legacy build to the CI loop. * Planning for the pathway towards the FIPS validation and 3.0. * Fixed over fifty issues identified by Coverity. * Implemented the X509_PUBKEY_dup function and fixed bugs exposed by this. * Fixed a concurrent access problem in SSL_CTX_new. * Investigated, but haven't yet fixed, a threading problem in EVP_fetch with the default library context. In addition were minor pull requests, reviewing, OMC and OTC business, et al. Pauli -------------- next part -------------- An HTML attachment was scrubbed... URL: