OpenSSL Security Advisory [corrected CVE id]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL Security Advisory [16th May 2024]
=
Excessive time spent checking DSA keys and parameters (CVE-2024-4603)
=
Severity: Low
Issue summary: Checking excessively long DSA keys or parameters may be very
slow.
Impact summary: Applications that use the functions EVP_PKEY_param_check()
or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
various checks on DSA parameters. Some of those computations take a long time
if the modulus ("p" parameter) is too large.
Trying to use a very large modulus is slow and OpenSSL will not allow using
public keys with a modulus which is over 10,000 bits in length for signature
verification. However the key and parameter check functions do not limit
the modulus size when performing the checks.
An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()
and supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
These functions are not called by OpenSSL itself on untrusted DSA keys so
only applications that directly call these functions may be vulnerable.
Also vulnerable are the OpenSSL pkey and pkeyparam command line applications
when using the "-check" option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue.
OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit 53ea0648 (for 3.3),
commit da343d06 (for 3.2), commit 9c39b385 (for 3.1) and commit 3559e868
(for 3.0) in the OpenSSL git repository.
OSSfuzz first detected and automatically reported this issue on 13th February
2024 using a fuzzer recently added to OpenSSL written by Kurt Roeckx. The fix
was developed by Tomas Mraz.
General Advisory Notes
==
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20240516.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-
iQIzBAEBCAAdFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmZGLbUACgkQUnRmohyn
nm27iRAAkvc/HNdfAY3l6kBJ2GVUbvPLODxFhzpei5DW1JxUojQwPXe3cXZlBs9D
PDtw85WX4IPULvcrq7BeGxOs4hDR1xkUfzr/5b0t7a9olFy1oYE/and0qpQx3AzP
eS7O9b001ssXtAs43aO6S4H0L5+3lRXPnLhyDfeh4odty4fbSIP8apLXtmaTKt6P
hdm+JLJdrx92aKjraKBcc1YKl2HgCBNRsxBnimKJzZGZVokUZsF0mIZ/G1SZVs0J
W4usEF1JuRD2vAUWcSDU92tZd0Bkz55SjVC7NVPqvqSUAo04f3LhZj1c7rMjSD5p
zjbG6c4PiCC08LRCHRtZUu56Kp1tBYy+X7zZrzDiPF1R/TY9pYYA1JKS6EvbBb/d
8IB3cxeeTzW0StnuxKmOchrMsGJtizh9hGIhy7yzjbQ8oMkhcRsUlbZDQwiHvCUk
qgXP2v0pnqBmVEBfqCBvUOKAy19XMVOUH69JBsuMEPIKzx2k7Y5QvVKZNq3DtboA
lOc0zkfLbtXrNZFDUDqpq2megmVbVlTw619NQE51jN/LPzo7b+fdw1cHTTnQE2Gt
rSQYZnklb0fmfQQJOl4HpCK16SfVebPYU4hRDJ1Yqk6jcClFbit1F7Fz6Ypjv4nM
iTOJAAoat2jQhmqg2VTpuUQGjRMAADvKlpABL4dTYCvJv6RMXTk=
=Efz1
-END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL Security Advisory [16th May 2024]
=
Excessive time spent checking DSA keys and parameters (CVE-2023-3446)
=
Severity: Low
Issue summary: Checking excessively long DSA keys or parameters may be very
slow.
Impact summary: Applications that use the functions EVP_PKEY_param_check()
or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
various checks on DSA parameters. Some of those computations take a long time
if the modulus ("p" parameter) is too large.
Trying to use a very large modulus is slow and OpenSSL will not allow using
public keys with a modulus which is over 10,000 bits in length for signature
verification. However the key and parameter check functions do not limit
the modulus size when performing the checks.
An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()
and supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
These functions are not called by OpenSSL itself on untrusted DSA keys so
only applications that directly call these functions may be vulnerable.
Also vulnerable are the OpenSSL pkey and pkeyparam command line applications
when using the "-check" option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue.
OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit 53ea0648 (for 3.3),
commit da343d06 (for 3.2), commit 9c39b385 (for 3.1) and commit 3559e868
(for 3.0) in the OpenSSL git repository.
OSSfuzz first detected and automatically reported this issue on 13th February
2024 using a fuzzer recently added to OpenSSL written by Kurt Roeckx. The fix
was developed by Tomas Mraz.
General Advisory Notes
==
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20240516.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-
iQIzBAEBCAAdFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmZGJOMACgkQUnRmohyn
nm3/cg/+JJtAXf0cyAEoDbPX3mTygHN1U3dqpCVFPMwYi23Bqce33wqXrXZqBxsF
m9IM3KRFHsdoArt1q1WWPGpMGLVColq56JwkjGzpaKjooLrb0cEbt6vKp5oepUCW
cv1ieLF5Z5dvYrWfgiO1mu5r88SY6OLCmxJdPIWMgTrgd1+h7AtzGF+olTgLHovp
qEQUNhCYax6RLaFtqcPY6eHuxlH6ARuERPJaPxasv6bPi8VQfYQ349G7ks4adgw9
b0I0qt/wZuGa0p/rpZ99Ev1VAFo9iOxcB8Vftm4nQzBfjCsieKcX+cM7aTnLPUjR
RFr/KmAGY9RcRFOI6UT2xemLP5xb4A3/wgeLjdPbWDeZ5eBe2nvOE07ndHZYxQIC
AxTMVFlWgcVpu2bDEHuhiNvYMW+AZYAfsN2jEOBl13SjN4ty9uLt/KMtM0Dp7p0J
KiDTTaGgX3jlEUt6gy/X314rEeCn5rNrupOfeQNPKnzdlInjP0yKvxF/boXDfQa3
KM7Sp+eZb674n2c83CuUPVfdIF2jmzm6VdB8a4zIAYoiPyw0HljayzPhAuUBhgOO
Q9nrooNs3+aZm/UXEcs0V0X+LPz7+w22z3aQ220sRYuQuZYNkvEfRi+yRzkqqoPd
0Bs7VAdzs6WryLWabkRmfTFagQ9UT9LtXsR+7h6P0By3ps8MaaU=
=DJFm
-END PGP SIGNATURE-
Re: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal review process
Hi Shane, can you please cast the vote in the GH issue linked? Tomas On Tue, 2022-11-15 at 20:40 +, Shane Lontis wrote: > Vote [+1] > I view this as a bug fix. > From: openssl-project on behalf > of Nicola Tuveri > Sent: Wednesday, November 16, 2022 1:00 AM > To: OpenSSL Project > Subject: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to > normal review process > > Topic: Accept PR #19681 in 3.1 subject to normal review process > Comment: Fundamentally OTC must decide if in the 3.1 release we > should > honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and > default to UNCOMPRESSED) in our provider implementations, > and > apply corresponding changes for handling legacy keys. > Proposed by: Nicola Tuveri > Issue link: > https://urldefense.com/v3/__https://github.com/openssl/technical-policies/issues/59__;!!ACWV5N9M2RV99hQ!OqxV4GXROeksWaZKdnkB2ZxFaBT1TMeCLMYCMBN_CfR0LiFEzx5F_7W1GJsGD8ObcYVsuXTdGuyPaZKP$ > Public: yes > Opened: 2022-11-15 > Closed: -MM-DD > Accepted: yes/no (for: X, against: Y, abstained: Z, not voted: W) > > Dmitry [ ] > Matt [ ] > Pauli [ ] > Tim [ ] > Hugo [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] -- Tomáš Mráz, OpenSSL
Re: PGP signature on OpenSSL 1.1.1s
Hi, the FAQ is misleading, we'll change it. Thanks for the heads up, Tomas Mraz, OpenSSL On Wed, 2022-11-02 at 19:55 -0700, Francois Marier wrote: > Hi, > > I noticed that you signed the OpenSSL 1.1.1s but you are not actually > listed as a member of the OMC > (https://www.openssl.org/community/omc.html). > > I was looking at the FAQ (https://www.openssl.org/docs/faq.html) > regarding checking the PGP signature on release tarballs and it > states > that releases will be signed by an OMC member's key. > > Is the OMC page out-of-date, or is the FAQ misleading? > > Francois > -- Tomáš Mráz, OpenSSL
[otc/technical-policies] 290d95: Record Kurt's post-closing vote
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 290d95d9a567f3bd647331d09bad374bf3a75bd5 https://github.openssl.org/otc/technical-policies/commit/290d95d9a567f3bd647331d09bad374bf3a75bd5 Author: Tomas Mraz Date: 2022-10-18 (Tue, 18 Oct 2022) Changed paths: M votes/vote-20221018-accept-pr19400.txt Log Message: --- Record Kurt's post-closing vote
[otc/technical-policies] b2beca: Record Tim's post-closing vote
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: b2becad268931d274046999e2511638fb3a52eee https://github.openssl.org/otc/technical-policies/commit/b2becad268931d274046999e2511638fb3a52eee Author: Tomas Mraz Date: 2022-10-18 (Tue, 18 Oct 2022) Changed paths: M votes/vote-20221018-accept-pr19400.txt Log Message: --- Record Tim's post-closing vote
[otc/technical-policies] 471413: Add vote for accepting PR #19400
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 471413fa8d409043847f00b8062ddacc3aef5ec7 https://github.openssl.org/otc/technical-policies/commit/471413fa8d409043847f00b8062ddacc3aef5ec7 Author: Tomas Mraz Date: 2022-10-18 (Tue, 18 Oct 2022) Changed paths: A votes/vote-20221018-accept-pr19400.txt Log Message: --- Add vote for accepting PR #19400
OTC VOTE: Accept PR #19400 in master and 3.0 subject to normal review process
https://github.com/openssl/technical-policies/issues/56 This vote was immediately closed as the outcome was determined during the OTC meeting already. -- Tomáš Mráz, OpenSSL
Re: OMC VOTE: selection and handling for SHA1 and RIMPEMD160
On Wed, 2022-10-12 at 11:00 -0400, Viktor Dukhovni wrote: > On Wed, Oct 12, 2022 at 03:35:19PM +0200, Richard Levitte wrote: > > > Topic: Provider selection and handling for SHA1 and RIPEMD160 > > should be identical > > given the current understanding of algorithm specific > > security issues. > > Shouldn't real-world usage be taken into account. SHA1 is widely > used, > and even has important use-cases that aren't going away and where > collision resistance is not a major concern, e.g. NSEC3 in DNSSEC > where it is used for light obfuscation, not cryptographic signing. > > I am not aware of any extant protocols that rely on RIPEMD160. I > think > that strictly looking at security margins is misguided, real world > usage > needs to inform any such decision, and users should be able to easily > keep SHA1 without bringing RIPEMD160 along for the ride. There is one widespread "protocol" relying on RIPEMD160 - Bitcoin. -- Tomáš Mráz, OpenSSL
[otc/technical-policies] 3d519e: Vote vote-20220906-autocompute-pubkey.txt is closed
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 3d519e6578b618d4e764dc3454c9c43ab75a1276 https://github.openssl.org/otc/technical-policies/commit/3d519e6578b618d4e764dc3454c9c43ab75a1276 Author: Tomas Mraz Date: 2022-09-21 (Wed, 21 Sep 2022) Changed paths: M votes/vote-20220906-autocompute-pubkey.txt Log Message: --- Vote vote-20220906-autocompute-pubkey.txt is closed
OTC VOTE: Automatically compute public key on import if missing
Topic: For all currently implemented algorithms, where it is possible, if the public key component is missing when a key is imported into a provider, the public key component should be computed. Proposed by: Tomas Mraz Issue link: https://github.com/openssl/technical-policies/issues/54 Public: yes Opened: 2022-09-06 Closed: Accepted: yes/no (for: , against: , abstained: , not voted: ) Dmitry [ 0] Matt [ ] Pauli [+1] Tim[ ] Richard[ 0] Shane [+1] Tomas [ 0] Kurt [ ] Matthias [+1] Nicola [+1] -- Tomáš Mráz, OpenSSL
[otc/technical-policies] 63bb6a: Add Vote: Automatically compute public key on impo...
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 63bb6a57ff738afdbe0db569b3338baa5731b4a1 https://github.openssl.org/otc/technical-policies/commit/63bb6a57ff738afdbe0db569b3338baa5731b4a1 Author: Tomas Mraz Date: 2022-09-06 (Tue, 06 Sep 2022) Changed paths: A votes/vote-20220906-autocompute-pubkey.txt Log Message: --- Add Vote: Automatically compute public key on import if missing
[otc/technical-policies] c0550c: Add memory functions, fix return value formatting
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: c0550c7a5865db7caba662413f1ce928334db95f https://github.openssl.org/otc/technical-policies/commit/c0550c7a5865db7caba662413f1ce928334db95f Author: Todd Short Date: 2022-08-10 (Wed, 10 Aug 2022) Changed paths: M policies/coding-style.md Log Message: --- Add memory functions, fix return value formatting Reviewed-by: Matt Caswell Reviewed-by: Paul Dale Reviewed-by: Tomas Mraz
Monthly Status Report (July 2022)
My key activities this month were: - triage of newly reported issues, investigating bugs, and responding to public github and customer questions - participation on the meetings - participation on QUIC design and implementation - this month reviewing various design and implementation PRs from other contractors - reviews of various PRs: - I've reviewed about 85 PRs this month - Notable PRs reviewed: - "Reserve" the method store when constructing methods #18153 - Pre-declare all core dispatch table functions, and fix the internal ones #18198 - Add BIO_s_dgram_mem() #18596 - Implement AES-GCM-SIV (RFC8452) #18693 - QUIC Frame Encoding and Decoding Functions #18795 - Clean gcm128 #18835 - submitted 7 PRs: - In particular: - SSL object refactoring using SSL_CONNECTION object #18612 - For known safe primes use the minimum key length according to RFC 7919 #18793 - Fix regression from GCM mode refactoring #18903 - ec_kmgmt.c: Do not crash when getting OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY #18902 I also took 1 day off this month and there were 2 days of public holidays in the Czech Republic. -- Tomáš Mráz, OpenSSL
Re: Re-arrange the library structure - Re: CMP is a subproject?
Just moving things around in the source tree does not achieve much so without the actual splitting the functionality out of the libcrypto does not make sense to me. Maybe it could be seen as a preparation step for the split out. However yes, it was a misunderstanding IMO that we would want to split it completely out of the main OpenSSL project tree. I do not think this is necessary or even desirable. However as many applications do not need this functionality it would be useful to have it as a separate shared library so loading libcrypto is less expensive. Still I think this is a 4.0 project. Tomas On Fri, 2022-07-08 at 09:00 +0200, David von Oheimb wrote: > On 07.07.22 23:02, Tim Hudson wrote: > > > I do not think this makes sense at this stage at all. > > One of the key elements people are looking for when contributing > > code is the distribution vector of getting including in default OS > > distributions and standard builds. > I fully agree. > To avoid any misunderstandings on what I wrote before: > My proposal (possibly in difference to Dmitry's) was and still is > not to move any functionality out of the OpenSSL main repository, > but to re-arrange the library structure (likely by splitting > libcrypto into two or more libraries) to better reflect the code > layering. > Expected benefits: > * improve clarity of the software component structure > * slightly alleviate development and maintenance > * reduce binary code footprint in case just the crypto core or just > TLS (including crypto) is needed > Expected drawbacks: > * any re-structuring requires more or less work > * some so far internal crypto interfaces that are used by the more > application-level code need to be exported > * applications that also require the more high-level capabilities > will need to link with more libraries > We may also consider splitting the existing libcrypto just virtually, > e.g., into two code directories (say, crypto/ and crypto/apps/, which > includes CMS, CMP, OCSP, HTTP, TS, etc.) > plus an actual library (say, libapps) that is more application-level > and includes everything that requires both TLS any crypto features, > such as HTTPS and part of (or even all of) apps/lib/. > This likely would provide a better pros/cons ratio than actually > splitting up libcrypto. > > > > This is something we could look at tackling in a future major > > release - but even then it faces challenges to be workable for the > > desired outcome (broad distribution of capability). > With just re-arranging the code into three (or more, rather than so > far two) OpenSSL libraries, there will be no issue with capability > because nothing is lost for OpenSSL users. > In particular, as Tomas wrote, the openssl app will continue to > provide everything that it did before. > > David > > > > On Thu, 7 July 2022, 18:48 Tomas Mraz, wrote: > > > > > OpenSSL Project list should be used instead of the committers > > > list for > > > such discussions. > > > > > > I do not think it would be good idea to do any such splitting > > > before a > > > major release development is being started (i.e., 4.0). > > > > > > The openssl application could depend on that application > > > library(ies). > > > > > > Tomas > > > > > > On Wed, 2022-07-06 at 09:32 +0200, David von Oheimb wrote: > > > > > > > Yes, there are number of components that should better be moved > > > > out of the core crypto library into a more application-level > > > > one. > > > > As I wrote three days ago, though my email got stuck in > > > > mailing list moderation: > > > > > > > > Forwarded Message > > > > Subject: Re: CMP is a subproject? > > > > Date: Sun, 3 Jul 2022 22:50:06 +0200 > > > > From: David von Oheimb > > > > To: Dmitry Belyavsky , List of openssl > > > > committers > > > > > > > > Dear all, > > > > thanks Dmitry for sharing this thought. > > > > In a sense it is an instance of a more general suggestion I > > > > gave > > > > * back in 2017: Introducing an application-level library for > > > > the CLI and OpenSSL-based applications #4992 > > > > * and in 2020: Improve overall OpenSSL library structure > > > > #13440 > > > > which pertains also to CMS, HTTP, OCSP, TS, and maybe further > > > > more application-level component(s) of libcrypto like CT. > > > > The CMP imple
Re: CMP is a subproject?
OpenSSL Project list should be used instead of the committers list for such discussions. I do not think it would be good idea to do any such splitting before a major release development is being started (i.e., 4.0). The openssl application could depend on that application library(ies). Tomas On Wed, 2022-07-06 at 09:32 +0200, David von Oheimb wrote: > Yes, there are number of components that should better be moved out > of the core crypto library into a more application-level one. > As I wrote three days ago, though my email got stuck in mailing list > moderation: > > Forwarded Message Subject: Re: CMP is a > subproject? Date: Sun, 3 Jul 2022 22:50:06 +0200 From: David von > Oheimb To: Dmitry Belyavsky > , List of openssl committers > > Dear all, thanks Dmitry for sharing this thought. > In a sense it is an instance of a more general suggestion I gave > * back in 2017: Introducing an application-level library for the > CLI and OpenSSL-based applications #4992 > * and in 2020: Improve overall OpenSSL library structure #13440 > which pertains also to CMS, HTTP, OCSP, TS, and maybe further more > application-level component(s) of libcrypto like CT. > The CMP implementation does not rely on libssl, but it does heavily > rely on libcrypto and relies on some of its internals. > The same holds for HTTP, and likely this also holds for CMS, OCSP, > TS, and CT. > David > > > On 06.07.22 07:25, Dr Paul Dale wrote: > > > I'd support such a change. Our stability policy won't without an > > exception. > > > > There are a lot more things that could be moved out IMO. > > > > > > Pauli > > > > > > On 6/7/22 15:22, Benjamin Kaduk wrote: > > > > > On Sun, Jul 03, 2022 at 09:51:23PM +0200, Dmitry Belyavsky wrote: > > > > > > > Dear colleagues, > > > > > > > > With all respect to David's efforts - isn't it worth turning > > > > CMP into a > > > > separate library in OpenSSL (and probably into a separate > > > > repo)? I remember > > > > there was a separate PR in this direction. > > > I think I found https://github.com/openssl/openssl/issues/16358 > > > just now, > > > but maybe there are others. > > > > > > > > > > It looks like CMP heavily relies on libcrypto/libssl, but I'm > > > > not sure it > > > > requires an integration - and, last but not least, has its own > > > > life cycle. > > > > Several years ago this seemed a good rationale both to me and > > > > to the > > > > OpenSSL team to separate a GOST engine. > > > It looks like there was some discussion in > > > https://github.com/openssl/openssl/pull/6811 that suggests that > > > having > > > apps/cmp.c functionality was a key motivation for pulling in > > > everything to > > > libcrypto itself, but I'm not sure how far the conversation of > > > in-OpenSSL > > > vs standalond project really went at that time. I don't think I > > > have > > > anything to add to that discussion other than what you say above. > > > > > > -Ben > > > -- Tomáš Mráz, OpenSSL
Monthly Status Report (June 2022)
My key activities this month were: - triage of newly reported issues, investigating bugs, and responding to questions - participation on the meetings - Youtrack workflow refinements - participation on QUIC design and implementation - reviews of various PRs: - I've reviewed about 80 PRs this month - Notable PRs reviewed: - Priority queue #18274 - Make OSSL_LIB_CTX_load_config thread safe #18331 - providers/implementations/exchange/kdf_exch.c: Fix kdf_derive() #18533 - Add a DTLS next epoch test #18601 - Check for invalid PSS params before writing and use fixed width integer type in DER writer #18615 - submitted 20 PRs: - In particular: - Update expired SCT certificates #18444 - Use as small dh key size as possible to support the security #18480 - Fix BN_mod_exp_consttime so it does not produce unreduced result #18510 - The flag "decoded-from-explicit" must be imp/exportable #18609 - Initial prototype for SSL object refactoring #18612 - Avoid including decoder/encoder/store headers into fips module #18630 I also took 1 day off this month. -- Tomáš Mráz, OpenSSL
[otc/technical-policies] 5d6505: Record vote vote-20220525-branch-policy.txt
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 5d65055f79ca30d391ea93610d223329edd7e366 https://github.openssl.org/otc/technical-policies/commit/5d65055f79ca30d391ea93610d223329edd7e366 Author: Tomas Mraz Date: 2022-06-08 (Wed, 08 Jun 2022) Changed paths: A votes/vote-20220525-branch-policy.txt Log Message: --- Record vote vote-20220525-branch-policy.txt
[otc/technical-policies] 7392c4: Add Branch policy proposal
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 7392c4e2954d1bfa1e49690cfe0c217f8f8441bc https://github.openssl.org/otc/technical-policies/commit/7392c4e2954d1bfa1e49690cfe0c217f8f8441bc Author: Tomas Mraz Date: 2022-06-08 (Wed, 08 Jun 2022) Changed paths: A policies/branch-policy.md Log Message: --- Add Branch policy proposal
[otc/technical-policies] 4f867f: Record vote vote-20220525-release-requirements.txt
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 4f867fc4de78aeaa0442ece71f62942adf675fdb https://github.openssl.org/otc/technical-policies/commit/4f867fc4de78aeaa0442ece71f62942adf675fdb Author: Tomas Mraz Date: 2022-06-06 (Mon, 06 Jun 2022) Changed paths: A votes/vote-20220525-release-requirements.txt Log Message: --- Record vote vote-20220525-release-requirements.txt
[otc/technical-policies] c3454d: Add Release Requirements Policy
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: c3454d50a53e809abc739cf0bc8d82c71a33c43b https://github.openssl.org/otc/technical-policies/commit/c3454d50a53e809abc739cf0bc8d82c71a33c43b Author: Tomas Mraz Date: 2022-06-06 (Mon, 06 Jun 2022) Changed paths: A policies/release-requirements.md Log Message: --- Add Release Requirements Policy Fixes #22
[otc/technical-policies] 7d344f: Record vote vote-20220525-coding-style-names.txt
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 7d344fda44d172bbd0c28e52b336ca3c102b7a3b https://github.openssl.org/otc/technical-policies/commit/7d344fda44d172bbd0c28e52b336ca3c102b7a3b Author: Tomas Mraz Date: 2022-06-02 (Thu, 02 Jun 2022) Changed paths: A votes/vote-20220525-coding-style-names.txt Log Message: --- Record vote vote-20220525-coding-style-names.txt
Monthly Status Report (May 2022)
My key activities this month were:
- triage of newly reported issues, investigating bugs, and responding
to questions
- participation on the meetings
- Youtrack workflow experimentation and proposal
- participation on QUIC design and implementation
- preparation of Technical Policies changes proposals
- reviews of various PRs:
- I've reviewed more than 80 PRs this month
- Notable PRs reviewed:
- X509{,_LOOKUP}: Improve distinction between not found and
fatal/internal error #14417
- Make configuration (and therefore builds) leaner
#16378
- Clear method store / query cache confusion
#18151
- tls: ban SSL3, TLS1, TLS1.1 and DTLS1.0 at security level one and
above #18236
- Non-locale dependent OPENSSL_strcasecmp #18344
- QUIC wire format support #18382
- http_client.c: trace HTTP requests and responses when enabled
#18386
- submitted 15 PRs:
- In particular:
- Fix build on OPENSSL_SYS_TANDEM and older POSIXes
#18241
- Add design requirements for QUIC packet demuxer #18249
- Add a testcase for OSSL_PROVIDER_unload() being fully effective
#18254
- OPENSSL_strcasecmp build, cleanup, and initialization fixes
#18282
- Always try to construct methods as new provider might be added
#18269
- QUIC empty protocol implementation #18307
- ossl_namemap_name2_num: Avoid unnecessary OPENSSL_strndup().
#18341
- High level overview of QUIC Implementation #18406
I also took 1 day off this month.
--
Tomáš Mráz, OpenSSL
[otc/technical-policies] 3ecc6f: Record vote vote-20220518-coding-style-expressions...
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 3ecc6feb0d69a306db05b394d155e5b727527c65 https://github.openssl.org/otc/technical-policies/commit/3ecc6feb0d69a306db05b394d155e5b727527c65 Author: Tomas Mraz Date: 2022-05-31 (Tue, 31 May 2022) Changed paths: A votes/vote-20220518-coding-style-expressions-r2.txt Log Message: --- Record vote vote-20220518-coding-style-expressions-r2.txt
[otc/technical-policies] ddbdc4: Record vote vote-20220518-coding-style-whitespace.txt
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: ddbdc4236e87cf03d5b3705a704b929d454a1ae6 https://github.openssl.org/otc/technical-policies/commit/ddbdc4236e87cf03d5b3705a704b929d454a1ae6 Author: Tomas Mraz Date: 2022-05-31 (Tue, 31 May 2022) Changed paths: A votes/vote-20220518-coding-style-whitespace.txt Log Message: --- Record vote vote-20220518-coding-style-whitespace.txt
Vote: Add Release Requirements Policy
Topic: Add Release Requirements Policy at commit 1845646 This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/40 Public: yes Opened: 2022-05-25 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Vote: Add Branch Policy
I am sorry for sending a duplicate mail - this time with the correct Subject. Topic: Add Branch Policy at commit 10bea43 This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/7 Public: yes Opened: 2022-05-25 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Vote: coding-style.md: add various rules on names
Topic: Add Branch Policy at commit 10bea43 This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/7 Public: yes Opened: 2022-05-25 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Vote: coding-style.md: add various rules on names
Topic: coding-style.md: add various rules on names at commit 5a3b1ac This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/48 Public: yes Opened: 2022-05-25 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
[otc/technical-policies] 65f342: Just adjust README.md to use reference links
Branch: refs/heads/master Home: https://github.openssl.org/otc/technical-policies Commit: 65f342840ec7cdb3e599e3705db70b3bfbbe398e https://github.openssl.org/otc/technical-policies/commit/65f342840ec7cdb3e599e3705db70b3bfbbe398e Author: Tomas Mraz Date: 2022-05-19 (Thu, 19 May 2022) Changed paths: M README.md Log Message: --- Just adjust README.md to use reference links
Vote: coding-style.md: add various rules on spaces, lines, and comments
Topic: coding-style.md: add various rules on spaces, lines, and comments at commit fcecd20 This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/47 Public: yes Opened: 2022-05-18 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Vote: coding-style.md: add various rules for writing C expressions - r2
Topic: coding-style.md: add various rules for writing C expressions - r2 at commit 2dc5c2b This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/46 Public: yes Opened: 2022-05-18 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Vote: Add vote announcement to voting procedure
Topic: Add vote announcement to voting procedure at commit 0737de7 This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/45 Public: yes Opened: 2022-05-09 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Vote: Add a process for minor policy edits
Topic: Add a process for minor policy edits at commit 4d65590 This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/42 Public: yes Opened: 2022-05-03 Closed: Accepted: (for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Vote: coding-style.md: add various rules for writing C expressions
Topic: coding-style.md: add various rules for writing C expressions at commit f2ae669 This will become an official OTC policy. Proposed by: Tomas Issue link: https://github.com/openssl/technical-policies/pull/39 Public: yes Opened: 2022-05-03 Closed: Accepted:(for: , against: , abstained: , not voted: ) Dmitry [ ] Matt [ ] Pauli [ ] Tim[ ] Richard[ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ] OTC members, please vote, -- Tomáš Mráz, OpenSSL
Monthly Status Report (April 2022)
My key activities this month were: - triage of newly reported issues, investigating bugs, and responding to questions - participation on the meetings - Martin's onboarding - participation on QUIC design, planning - preparation of Technical Policies changes proposals - reviews of various PRs: - I've reviewed about 50 PRs this month - Notable PRs reviewed: - CMS sign digest #15348 - KTLS: TLS 1.3 receive offload #17942 - OPENSSL_strcasecmp #18069 - OPENSSL_strcasecmp for 3.0 #18103 - submitted 13 PRs: - In particular: - ossl_dh_check_priv_key: Do not fail on private keys without q #18099 - Avoid undefined behavior of provided macs on EVP_MAC reinitialization #18100 - evp_md_init_internal: Avoid reallocating algctx if digest unchanged #18105 There were also 2 days of national holidays (Easter) and I took one additional day off. -- Tomáš Mráz, OpenSSL
VOTE: Accept PR #17998 into master and 3.0 branches
There is a vote opened for the subject at: https://github.com/openssl/technical-policies/issues/41 -- Tomáš Mráz, OpenSSL
Initial congestion control API design
Please review the initial congestion control API design proposal at [1]. This will be an internal API for MVP in 3.1 release. [1] https://github.com/openssl/openssl/pull/18018 -- Tomáš Mráz, OpenSSL
Monthly Status Report (March 2022)
My key activities this month were: - triage of newly reported issues, investigating bugs, and responding to questions - participation on the meetings - cooperation with Mark and Tim on the hiring process - participation on QUIC design, proposal for congestion control pluggable algorithm API - participation on the CVE-2022-0778 handling including the release review - reviews of various PRs: - I've reviewed more than 80 PRs this month - Notable PRs reviewed: - Add TFO support to socket BIO and s_client/s_server #8962 - enable CMS sign/verify for provider-implemented PKEYs #17733 - Add ASYNC_set_mem_functions ASYNC_get_mem_functions #17762 - adding external oqsprovider testing #17832 - Add SSL_kDHEPSK and SSL_kECDHEPSK as PFS ciphersuites for SECLEVEL >= 3 #17763 - EVP_MD performance fix (refcount cache contention) #17857 - Remove statistics tracking from LHASH #17935 - Decoder resolution performance optimizations #17921 - submitted 15 PRs: - In particular: - The PRs for all the branches handling CVE-2022-0778 - Replace handling of negative verification result with SSL_set_retry_verify() #17825 - DH: Make padding always on when X9.42 KDF is used #17859 - tls_process_server_hello: Disallow repeated HRR #17936 - Import only named params into FIPS module #17998 -- Tomáš Mráz, OpenSSL
Re: Auto github PR script and 3.0
I went through them and in the end decided that they are closed correctly as there was enough pinging on them already. Tomas On Mon, 2022-03-14 at 10:37 +, Mark J Cox wrote: > Unfortunately the autocloses happened due to the bug now fixed[1]. > But they can always be reopened again. > > [1] > https://github.com/iamamoose/openssl-metrics/commit/49927d122e39d0a534e82f4a611fc9a06e84a95b > > Mark > > On Mon, 14 Mar 2022 at 10:35, Tomas Mraz wrote: > > > > On Mon, 2022-03-14 at 10:29 +, Mark J Cox wrote: > > > We have a script that runs daily and makes sure things needing > > > action > > > for OTC/OMC are pinged if they get old. It also autocloses issues > > > where it was waiting for the reporter with no action, or waiting > > > for > > > a > > > NDA for a significant amount of time. > > > > > > Because 3.0 wasn't out, it ignored everything with the "post > > > 3.0.0" > > > milestone. It's time to turn off that exception. However > > > looking at > > > the PR list this will cause a large number of PR's to change > > > state: > > > > > > It will ping OMC about 4 stale issues waiting for OMC > > > It will ping OTC about 14 stale issues waiting for OTC > > > It will ping committers about 12 stale issues waiting for > > > committers > > > It will close 5 issues waiting for the creator to make changes > > > >90 > > > days > > > It will close 4 issues waiting for a CLA for >180 days > > > > > > Any objections to this, or a preferred time in the future to make > > > the > > > change? > > > > I would not autoclose the issues to be autoclosed - IMO the script > > should just ping at least once and autoclose only after a week or > > so, > > if there is no update. > > > > -- > > Tomáš Mráz, OpenSSL > > > > -- Tomáš Mráz, OpenSSL
Re: Auto github PR script and 3.0
On Mon, 2022-03-14 at 10:29 +, Mark J Cox wrote: > We have a script that runs daily and makes sure things needing action > for OTC/OMC are pinged if they get old. It also autocloses issues > where it was waiting for the reporter with no action, or waiting for > a > NDA for a significant amount of time. > > Because 3.0 wasn't out, it ignored everything with the "post 3.0.0" > milestone. It's time to turn off that exception. However looking at > the PR list this will cause a large number of PR's to change state: > > It will ping OMC about 4 stale issues waiting for OMC > It will ping OTC about 14 stale issues waiting for OTC > It will ping committers about 12 stale issues waiting for committers > It will close 5 issues waiting for the creator to make changes >90 > days > It will close 4 issues waiting for a CLA for >180 days > > Any objections to this, or a preferred time in the future to make the > change? I would not autoclose the issues to be autoclosed - IMO the script should just ping at least once and autoclose only after a week or so, if there is no update. -- Tomáš Mráz, OpenSSL
Monthly Status Report (February 2022)
My key activities this month were: - triage of newly reported issues, investigating bugs, and responding to questions - participation on the meetings - cooperation with Mark and Tim on the hiring process - onboarding of Daniel Fiala - studied QUIC implementations (ngtcp2, msquic) - reviews of various PRs: - I've reviewed about 60 PRs this month - Notable PRs reviewed: - add SSL_get0_iana_groups() & SSL_client_hello_get_extension_order() #16910 - Fix EVP todata and fromdata when used with selection of EVP_PKEY_PUBLIC_KEY #17200 - evp cipher: cache key and IV lengths in the context #17543 - Tests for do_updatedb (Issue 13944), alternate suggestion #17645 - submitted 4 PRs: - In particular: - Replace size check with more meaningful pubkey check #17630 - Test the FIPS provider from openssl-3.0 branch with the master and vice versa #17671 - Add back check for the DH public key size #17678 I took 4 days of vacation in February. -- Tomáš Mráz, OpenSSL
Vote results: Undeprecate OPENSSL_VERSION_NUMBER macro and OpenSSL_version_num() function
Topic: Undeprecate OPENSSL_VERSION_NUMBER macro and OpenSSL_version_num() function in the documentation in 3.0 branch Proposed by: Tomáš Mráz Issue link: https://github.com/openssl/technical-policies/issues/26 Public: yes Opened: 2022-02-08 Closed: 2022-02-08 Accepted: yes (for: 6, against: 0, abstained: 1, not voted:3) Dmitry [+1] Matt [+1] Pauli [+1] Tim [ ] Richard [ 0] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] Nicola [ ] -- Tomáš Mráz, OpenSSL
Monthly Status Report (January 2022)
My key activities this month were: - triage of newly reported issues, investigating bugs, and responding to questions - participation on the OTC meetings - cooperation with Mark and Tim on job interviews with candidates, scheduling things, etc. - reviews of various PRs: - I've reviewed about 70 PRs this month - Notable PRs reviewed: - OSSL_STORE: Prevent spurious error during loading private keys #15283 - Fix CMP mock server w.r.t. use of reference certificate for KUR and RR #16050 - Fix malloc failure handling of X509_ALGOR_set0() #16251 - property: use a stack to efficiently convert index to string #17325 - Fix Decoder, Encoder and Store loader fetching #17459 - Fix invalid malloc failures in PEM_write_bio_PKCS8PrivateKey*() #17507 - submitted 15 PRs: - In particular: - Check that we imported a key when using EVP_PKEY_fromdata with EVP_PKEY_KEYPAIR #17408 - EVP_PKEY_fromdata(): Do not return newly allocated pkey on failure #17411 - EVP_PKEY_derive_set_peer_ex: Export the peer key to proper keymgmt #17425 - Properly return error on EVP_PKEY_CTX_set_dh_nid and EVP_PKEY_CTX_set_dhx_rfc5114 #17498 - store_result: Add fallback for fetching the keymgmt from the store provider #17554 -- Tomáš Mráz, OpenSSL
OTC vote for Coding style policy
The OTC vote for this policy proposal has now started. OTC members please cast your votes here: https://github.com/openssl/technical-policies/pull/16 -- Tomáš Mráz, OpenSSL
Monthly Status Report (December 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - participation on the OTC meetings - participation on the QUIC design meetings - cooperation with Mark and Tim on advertising the new job positions and handling the candidates - reviews of various PRs: - I've reviewed about 55 PRs this month - Notable PRs reviewed: - Provide CPU RNG Support for 64 Bit Arm CPUs #15361 - Fix EVP_PKEY_eq() to be possible to use with strictly private keys #16705 - property: use a stack to efficiently convert index to string #17325 - submitted 12 PRs: - In particular: - Fix passphrase prompt in the PVK encoder #17181 - context_init: Fix cleanup in error handling #17294 - Avoid shortening the maximum password size when pem_password_cb calls UI #17320 There was 1 day national holiday and I took additional 5 days off for the Christmas and New Year. -- Tomáš Mráz, OpenSSL
Re: OTC VOTE: Accept PR #16705 into 3.0
On Tue, 2021-12-07 at 19:18 +0100, Kurt Roeckx wrote: > On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote: > > topic: Accept PR #16705 into 3.0 subject to the normal review > > process > > -1 > > From what I understand, this breaks our provider API. Providers > that work with 3.0.0 will not work when that PR is applied, and > providers that do the same implementation as that PR will not work > with 3.0.0. That might be something that can be fixed in the PR. > > We might want to make changes like that, but we clearly need better > rules for when it's acceptable to make such change, and how to make > sure it's compatible. Kurt, can you please explain why do you think this breaks the provider API compatibility with 3.0.0? I do not see any such breakage possible from the PR. -- 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.]
Monthly Status Report (November 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - participation on the OTC meetings - participation on the QUIC design meetings - created proposal for API changes allowed in minor releases - finally succeeded in ordering the HPE Proliant server via the SpaceNET - reviews of various PRs: - I've reviewed about 65 PRs this month - Notable PRs reviewed: - BIO_s_connect(): Enable BIO_gets() #16030 - X509: Fix handling of AKID and SKID extensions according to configuration #16342 - Add integer overflow helper functions #16930 - Fix some threading issues #16980 - Support different R_BITS lengths for KBKDF #17063 - Avoid loading of a dynamic engine twice #17073 - submitted 7 PRs: - In particular: - do_sigver_init: Allow reinitialization of an existing operation. #16964 - Add null digest implementation to the default provider #17016 - d2i_PublicKey: Make it work with EC parameters in a provided key #17065 There was 1 day national holiday and I was also somewhat slowed down by getting the COVID19 disease. Fortunately it was quite light but it impacted my work anyway. -- 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.]
OTPC #10 Policy on API compatibility in minor releases
This proposal adds policy on API changes allowed in minor releases. https://github.com/openssl/technical-policies/pull/10 TL;DR: No changes except additions are allowed in minor releases. -- 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.]
Vote on the Stable Release Updates Policy
The vote for the Stable Release Updates Policy has been started now: https://github.com/openssl/technical-policies/pull/8 OTC members, please cast your votes in the pull request. -- 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.]
OTPC#8 Stable Release Updates Policy
This proposal adds a policy on changes allowed in stable releases. https://github.com/openssl/technical-policies/pull/8 -- 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.]
OTPC#7 Branch Policy
This is a draft of the branch policy for starting the discussion. There are two alternative proposals for additional development branches - a feature branch and next-minor branch. https://github.com/openssl/technical-policies/pull/7 -- 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.]
OTC VOTE: Accept openssl/technical-policies PR#2 - Voting Process Proposal (closed)
topic: Accept openssl/technical-policies PR#2 - the policy change process proposal as of commit 5740178. This will become an official OTC policy. comment: This changes the voting procedure for public OTC votes to use the pull requests and issues on the openssl/technical-policies repository instead of the openssl-project mailing list. Proposed by Tomáš Mráz Public: yes opened: 2021-11-09 closed: 2021-11-09 accepted: yes (for: 8, against: 0, abstained: 0, not voted: 2) Dmitry [+1] Matt [+1] Pauli [+1] Tim[+1] Richard[+1] Shane [ ] Tomas [+1] Kurt [ ] Matthias [+1] Nicola [+1]
Re: OTPC#2 The Public Voting Procedure of OTC proposal
This proposal was not discussed during an OTC meeting. However the PR is 15 days old so we could vote now. Does anyone want to discuss this during a meeting or is it uncontroversial enough to be voted on right now? Tomas On Tue, 2021-10-19 at 17:12 +0200, Tomas Mraz wrote: > https://github.com/openssl/technical-policies/pull/2 > > Overview > > > This proposal adds a new policy to replace the existing public voting > procedure. The private voting procedure is kept as is. > > The reason > -- > > The reason for the proposal is to modernize the procedure to avoid > the requirement to use the e-mail for casting the votes and to avoid > piling up the recorded votes in a single votes.txt file. > -- 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.]
Re: OTC VOTE: Accept Policy change process proposal
The vote is now closed. It passed with: accepted: yes (for: 9, against: 0, abstained: 0, not voted: 1) I'll now merge the PR and the policy change process is now an official OTC policy. Tomas On Tue, 2021-11-02 at 12:00 +0100, Tomas Mraz wrote: > There are already enough votes to close this one, so I intend to > close > the vote tomorrow. > > Tomas > > > On Mon, 2021-11-01 at 11:23 +0100, Tomas Mraz wrote: > > topic: Accept openssl/technical-policies PR#1 - the policy change > > process proposal as of commit 3bccdf6. This will become an official > > OTC > > policy. > > > > comment: This will implement the formal policy change process so we > > can > > introduce and amend further policies as set by OTC via a public > > process. > > > > Proposed by Tomáš Mráz > > Public: yes > > opened: 2021-11-01 > > closed: 2021-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Dmitry [ ] > > Matt [ ] > > Pauli [ ] > > Tim [ ] > > Richard [ ] > > Shane [ ] > > Tomas [+1] > > Kurt [ ] > > Matthias [ ] > > Nicola [ ] > > > > > > > -- 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.]
Monthly Status Report (October 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - created proposal for OTC policy change process - created proposal for OTC voting process - created proposal for release branching policy - trying to find German or Czech reseller willing to sell us HPE Proliant server - reviews of various PRs: - I've reviewed about 50 PRs this month - Notable PRs reviewed: - Fix ssl_free() and thus BIO_free() to respect BIO_NOCLOSE #16688 - EVP: Reverse the fetch logic in all pkey using functionality #16725 - Fix miscellaneous engine problems #16846 - Fix short buffer handling #16789 - submitted 12 PRs: - In particular: - test: fetching proper signature provider for non-exportable keys #16764 I had also 1 day off and there was 1 day national holiday. -- 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.]
Re: OTC VOTE: Accept Policy change process proposal
There are already enough votes to close this one, so I intend to close the vote tomorrow. Tomas On Mon, 2021-11-01 at 11:23 +0100, Tomas Mraz wrote: > topic: Accept openssl/technical-policies PR#1 - the policy change > process proposal as of commit 3bccdf6. This will become an official > OTC > policy. > > comment: This will implement the formal policy change process so we > can > introduce and amend further policies as set by OTC via a public > process. > > Proposed by Tomáš Mráz > Public: yes > opened: 2021-11-01 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [ ] > Matt [ ] > Pauli [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > > -- 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.]
OTC VOTE: Accept Policy change process proposal
topic: Accept openssl/technical-policies PR#1 - the policy change process proposal as of commit 3bccdf6. This will become an official OTC policy. comment: This will implement the formal policy change process so we can introduce and amend further policies as set by OTC via a public process. Proposed by Tomáš Mráz Public: yes opened: 2021-11-01 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Dmitry [ ] Matt [ ] Pauli [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [+1] Kurt [ ] Matthias [ ] Nicola [ ]
OTPC#2 The Public Voting Procedure of OTC proposal
https://github.com/openssl/technical-policies/pull/2 Overview This proposal adds a new policy to replace the existing public voting procedure. The private voting procedure is kept as is. The reason -- The reason for the proposal is to modernize the procedure to avoid the requirement to use the e-mail for casting the votes and to avoid piling up the recorded votes in a single votes.txt file. -- 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.]
OTPC#1 Policy change process proposal
https://github.com/openssl/technical-policies/pull/1 Overview This proposal provides the process on submitting, editing, finalizing, and approving the changes of the technical policies of the OpenSSL project (i.e., those policies governed by OTC). The reason -- The reason for the proposal is that OTC intends to formalize its work a little and to create multiple new technical policies for the project. The process should be open for external input and review. This proposal tries to achieve these goals. OTPC = OpenSSL Technical Policy Change -- 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.]
Monthly Status Report (September 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - studying the QUIC RFCs (8999-9002) - studying code (and documentation) of picoquic, ngtcp2, and LSQUIC libraries - infrastructure planning - release review of the 3.0.0 release - reviews of various PRs: - I've reviewed about 70 PRs this month - Notable PRs reviewed: - obj: make the OBJ_ calls thread safe #15713 - kdf: add PIN verification key KDF to providers #15968 - Fix OSSL_STORE 'file:' scheme implementation so it ignores objects in PEM files that the user isn't interested in #16466 - submitted 8 PRs: - In particular: - Last minute NEWS and CHANGES entries for the 3.0 release #16533 - providers: Do not use global EVP_CIPHERs and EVP_MDs #16600 I had also 2 days off. -- 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.]
Release stability proposal to be discussed at OTC
I've prepared this release stability proposal addition to the existing release policy document: https://docs.google.com/document/d/1UFkXiwsmfK-xYpXQfv0HEUKmAbSxxcK25y5s3fAIIzQ/edit?usp=sharing This is just a starting point for further discussion, please feel free to add any comments to the document linked above. I'll also copy the proposed clauses to be added here for tl;dr: - Only bug fixes including fixes for security issues and documentation additions are allowed in stable releases. (The exception above for platform additions to LTS branches still applies.) - A stable release is a patch release from an existing supported minor release branch. - A bug fix is a fix of functionality of the libraries, modules, applications, or the build system that (all or any items might apply): makes the functionality conforming with the existing documentation makes the documentation conforming with the existing behavior of the software - A bug fix is also a fix for an unexpected behavior (not explicitly documented in one way or another) of the software when such unexpected behavior is a security vulnerability. - A bug fix might also be a fix for an unexpected behavior (not explicitly documented in one way or another) where there is no reasonable use-case that might depend on the unexpected behavior. - A documentation addition allowed in stable releases is any addition to the documentation that documents the existing behavior of the software. I.e., the documentation additions in stable releases cannot add new API contract constraints, or implicitly create new bugs in the software by documenting behavior that is different from the existing behavior of the software. -- 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.]
Meeting link for today's OTC meeting
Hi all, as Matt will not be available today for the OTC meeting we will use the following link for the OTC meeting: https://meet.google.com/oah-kxuu-mct I am sorry for the late notice. Regards, Tomáš
Re: OTC vote: include Keccak digests in OpenSSL
On Tue, 2021-09-21 at 18:32 +0200, Kurt Roeckx wrote: > On Tue, Sep 21, 2021 at 07:14:51PM +1000, Dr Paul Dale wrote: > > Accept PR#16594 into master subject to the normal review process > > > > > > > > This doesn't meet the "is a standard" requirement but it is in use > > and we > > have the implementation. It just isn't exposed. > > Can you describe where it is in use? > Citation from the issue #13033 linked from the PR: "Ethereum and after it many cryptographic applications use the original pre-NIST variant of SHA3-256, these days named keccak256, where the delimiter byte is 0x1 rather than 0x6." -- 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.]
Milestones to choose from when OTC starts review of Post 3.0.0
I've added a few new milestones to choose from during triage when OTC starts reviewing Post 3.0.0 items in GitHub. 3.0.1 milestone is a milestone for consideration and affirmation if something is a blocker for the 3.0.1 release. (An issue/PR is a blocker if 'triaged: OTC evaluated' label is applied.) 3.1.0 milestone is a milestone for consideration and affirmation if something is a blocker for the 3.1.0 release. Post 3.1.0 milestone is a milestone for items which we do not want in 3.1.0 but they are not breaking API/ABI so they do not need to be postponed to the 4.0 release. -- 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.]
Blog post about Let's Encrypt root certificate expiration and OpenSSL 1.0.2
I've written a blog post to explain the situation with the old Let's Encrypt root certificate expiration which will happen on 2021-09-30 and the behavior of OpenSSL 1.0.2 with that root certificate. Please read, if interested: https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ Regards, -- 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.]
Freeze
I've frozen the repository for the final OpenSSL 3.0 release on Tuesday. Regards, -- 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.]
Monthly Status Report (August 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - sysadmin: fixing disabled CLA check on GitHub PRs - moved the script from discontinued license.openssl.org to status.openssl.org - continued studying the Buildbot documentation - reviews of various PRs: - I've reviewed about 50 PRs this month - Notable PRs reviewed: - Fix d2i_ECPKParameters_fp and i2d_ECPKParameters_fp macroes #16355 and #12457 - Add a specialised TLS 1.3 KDF implementation #16203 - Fix s390x AES OFB/CFB cipher implementation on updating IV #16291 and #16292 - aes-wrap: improve error handling #16391 - Fix leak if config run multiple times #16425 - Ensure that we check the ASN.1 type of an "otherName" before using it #16443 - Rationalize provider locking #16469 - submitted 20 PRs: - In particular: - Windows, VMS: Do install_fips on install if fips is enabled #16208 - Prevent recursive call of OPENSSL_INIT_LOAD_CONFIG #16210 - Multiple fixes for getting pub key from legacy DH PKEY #16253 - rsa: Try legacy encoding functions for pubkey #16289 - EVP_DigestSign/VerifyFinal: Duplicate the pctx to allow multiple calls #16422 - Make the -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION pass tests #16433 and #16441 I had also 1 full week time off. -- 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.]
Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process
-1 post closing of the vote for the record Tomas On Tue, 2021-08-17 at 14:19 +0100, Matt Caswell wrote: > topic: Accept PR#16286 into 3.0 subject to the normal review process > Proposed by Shane Lontis > Public: yes > opened: 2021-08-17 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [ ] > Matt [-1] > Pauli [+1] > Tim [ 0] > Richard [+1] > Shane [+1] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] -- 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.]
Re: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1
This vote is now closed: closed: 2021-08-13 accepted: yes (for: 5, against: 3, abstained: 1, not voted: 1) Tomas On Tue, 2021-08-10 at 11:53 +0100, Matt Caswell wrote: > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [+1] > Matt [+1] > Pauli [ ] > Tim [-1] > Richard [ ] > Shane [-1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] -- 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.]
Re: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1
As this vote is still ongoing I am going to somewhat promote its case. I really suspect that many applications albeit somewhat special ones will be broken by this change. So although the change can be surely viewed as a bug fix it is IMO wrong that it was merged to the 1.1.1 branch. Although there might be security implications of exporting an incomplete/broken DER encoding, no concrete security issue was presented that exists unless this bug is fixed. On Tue, 2021-08-10 at 11:53 +0100, Matt Caswell wrote: > topic: Revert the commits merged from PR #16027 in 1.1.1 > Comment: Refer to issue #16266 for background > Proposed by Tomas Mraz > Public: yes > opened: 2021-08-10 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Dmitry [+1] > Matt [+1] > Pauli [ ] > Tim [-1] > Richard [ ] > Shane [-1] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [-1] -- 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.]
Monthly Status Report (July 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - re-triage of issues/PRs without triaged labels with closing obsolete issues - participation on the meetings - studied the OpenSSL sysadmin documentation - started studying the Buildbot documentation - reviews of various PRs: - I've reviewed about 50 PRs this month - Notable PRs reviewed: - PROV & STORE: Don't decode keys in the 'file:' store loader #15981 - Avoid calling EVP_get_XXXbyname when legacy isn't relevant #16022 - ASN.1: Refuse to encode to DER if non-optional items are missing [3.0] #16036 - EVP: Add EVP_PKEY_get0_provider() and EVP_PKEY_CTX_get0_provider() #16063 - Fix custom EVP_PKEY_METHODs #16118 - submitted 15 PRs: - In particular: - fips module header inclusion fine-tunning #15974 - Split bignum code out of the sparcv9cap.c #16019 - Allow RSA signature operations with RSA_NO_PADDING #16068 - Signature algos: allow having identical digest in params #16076 - Fix potential problems with EVP_PKEY_CTX_new() with engine set #16137 I had also 1 full week time off. -- 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.]
Re: OTC VOTE: Accept PR 16128
+1 it is a safe change and it improves consistency On Thu, 2021-07-22 at 13:51 +0100, Matt Caswell wrote: > topic: Accept PR 16128 in 3.0 subject to our normal review process > Proposed by Matt Caswell > Public: yes > opened: 2021-07-22 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Pauli [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] -- 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.]
Re: OTC VOTE: Remove ERR_GET_FUNC in 3.0
For the record I am voting +1. Tomas On Wed, 2021-07-07 at 19:04 +0200, Kurt Roeckx wrote: > On Tue, Jul 06, 2021 at 10:26:13AM +0100, Matt Caswell wrote: > > topic: Remove ERR_GET_FUNC in 3.0 > > Proposed by Nicola Tuveri > > Public: yes > > opened: 2021-07-06 > > closed: 2021-07-06 > > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 2) > > There seem to be no good solutions here, so I'm voting 0. -- 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.]
Monthly Status Report (June 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - re-triage of issues/PRs in Assessed milestone completed, the milestone is now closed - participation on the meetings - reviews of various PRs: - I've reviewed more than 100 PRs this month - Notable PRs reviewed: - Decoding PKCS#8: separate decoding of encrypted and unencrypted PKCS#8 #15498 - s390x: EVP_CipherInit_ex sequences lead to wrong results #15521 - DECODER & ENCODER: use property definitions instead of getting implementation parameters #15570 - Refactor XXX_do_all_provided() to behave like XXX_fetch() #15604 - property: improve ossl_property_find_property() function #15614 - Add a generic SubjectPublicKeyInfo decoder #15662 - Add various OBJ functions as callbacks #15681 - Don't hold any locks while calling the provider init function #15854 - property: add locking to the property string database #15871 - ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt #15933 - submitted 24 PRs: - In particular: - Move libssl related defines used by fips provider to prov_ssl.h #15609 - X509_digest_sig: Handle RSA-PSS and EDDSA certificates #15618 - Elimination of some sources not needed in the FIPS_MODULE #15622 - Do not duplicate symbols between libcrypto and libssl in static builds #15714 - Multiple PRs fixing build and test issues on AIX - Only the fips module dependencies are relevant for fips.module.sources #15903 - Multiple fixes related to reading PEM key files #15949 -- 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.]
Monthly Status Report (May 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - re-triage of issues/PRs in Post 1.1.1 and Assessed milestones - participation on the meetings - reviews of various PRs: - I've reviewed more than 100 PRs this month - Notable PRs reviewed: - FIPS module checksums: add scripts and Makefile rule #8871 - Add BIO_new_from_core_bio() to the public API #15072 - Alpha 16 release - PSK and key_share compliance fixes for RFC 8446 #14749 - Export/import flags for FFC params changed to seperate fields. #15210 - HTTP: Implement persistent connections (keep-alive) etc. #15053 - Init the child providers immediately on creation of the child libctx #15270 - EVP: Modify EVP_PKEY_export() to handle legacy EVP_PKEYs #15293 - Disable client-initiated renegotiation by default #15184 - checksum: include header files in the checksumming output #15365 - Rework how providers/fipsmodule.cnf is produced, and have a separate test/fipsmodule.cnf #15436 - Update Cipher documentation. #15416 - submitted 29 PRs: - In particular: - Multiple PRs for FIPS checksum CI job fine tunnings - Replace EVP_PKEY_supports_digest_nid #15198 - Allow arbitrary digests with ECDSA and DSA #15220 - Add some basic Windows builds to the Windows CI workflow #15349 and follow-up Enable FIPS in the Windows CI 64 bit shared build and fix related issues #15550 - Rename all getters to use get/get0 in name #15405 - Deprecate old style BIO callback calls #15440 - Fix possible infinite loop in pem_read_bio_key_decoder() #15441 -- 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.]
Re: OTC VOTE: Set PR 13817 milestone to Post 3.0
This vote is now closed. accepted: yes (for: 2, against: 0, abstained: 7, not voted: 2) On Thu, 2021-04-22 at 23:28 +0200, Kurt Roeckx wrote: > On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote: > > topic: Set PR 13817 milestone to Post 3.0 > > 0 > > > Kurt > -- 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.]
Monthly Status Report (April 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - AppVeyor reconfiguration to run only on pushes to master - reviews of various PRs: - I've reviewed about 90 PRs this month - Notable PRs reviewed: - Configure/Makefile: fix some FIPS installation issues #13684 - Add library context and property query support into the PKCS12 APIs #14434 - Add OIDs among algorithm names + don't go via NIDs when fetching an algorithm from a ASN1_OBJECT #14498 - Fix d2i_PrivateKey() and PEM_X509_INFO_read_bio_ex() etc. loading private keys #14647 - Add OSSL_ALGORITHM description field + API to use them #14656 - Only enable KTLS if it is explicitly configured #14799 - Alpha 14 release - Store some FIPS global variables in the FIPS_GLOBAL structure #14814 - ENCODER & DECODER: Allow decoder implementations to specify "carry on" #14834 - Fix dh_rfc5114 option in genpkey. #14883 - Alpha 15 release - STORE: Use the 'expect' param to limit the amount of decoders used #15066 - submitted 30 PRs: - In particular: - Deprecate the EVP_PKEY controls for CMS and PKCS#7 #14760 - Implement provider-side keymgmt_dup function #14793 - Detect low-level engine based keys #14859 - Add type_name member to provided methods and use it #14898 - Prefer fetch over get_digestby... or get_cipherby... where appropriate #15028 - Implement pem_read_key directly through OSSL_DECODER #15045 - Correct the SM2 handling of DIGEST and DIGEST_SIZE parameters #15074 - Add -latomic to threads enabled 32bit linux builds #15086 - Make the -inform option to be respected if possible #15100 -- 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.]
Re: OTC VOTE: Reject PR#14759
-1 On Tue, 2021-04-20 at 13:23 +0300, Nicola Tuveri wrote: > Following up on > https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html > we had a discussion on this during last week OTC meeting, and opened > a vote limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening > it officially today with a clean slate. > -- 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.]
Re: OTC VOTE: Set issue 11164 milestone to Post 3.0
The vote has been closed already during the meeting. On Tue, 2021-04-20 at 12:15 +0200, Tomas Mraz wrote: > topic: Set issue 11164 milestone to Post 3.0 > Proposed by Tim Hudson > Public: yes > opened: 2021-04-20 > closed: 2021-04-20 > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[+1] > Richard[+1] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [+1] > Nicola [-1] > > -- 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.]
OTC VOTE: Set PR 13817 milestone to Post 3.0
topic: Set PR 13817 milestone to Post 3.0 Proposed by Tim Hudson Public: yes opened: 2021-04-20 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ 0] Mark [ ] Pauli [ ] Viktor [ ] Tim[+1] Richard[ 0] Shane [+1] Tomas [ 0] Kurt [ ] Matthias [ 0] Nicola [ 0]
OTC VOTE: Set issue 11164 milestone to Post 3.0
topic: Set issue 11164 milestone to Post 3.0 Proposed by Tim Hudson Public: yes opened: 2021-04-20 closed: 2021-04-20 accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) Matt [+1] Mark [ ] Pauli [ ] Viktor [ ] Tim[+1] Richard[+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] Nicola [-1]
Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)
There is no need to have 2 votes. We'll just vote on the policy and the PR close/rework/whatever comes out of the policy vote. On Fri, 2021-04-09 at 14:24 +0300, Nicola Tuveri wrote: > I agree with what Tomàš said, and that is the reason why I convoluted > them in a single vote: we need to merge or reject the PR based on a > policy, but if we do 2 separate votes we risk to create delays in the > already quite loaded development cycles left! > > Nicola > > On Fri, Apr 9, 2021, 10:53 Tomas Mraz wrote: > > On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > > > > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > > > Proposed vote text > > > > == > > > > > > > > Do not merge PR#14759, prevent declaring properties > > similar to > > > > `blinding=yes` or `consttime=yes` in our implementations > > and > > > > discourage 3rd parties from adopting similar designs. > > > > > > I think this vote tries to cover too much ground in a single > > vote. I > > > would prefer to see a simple vote of "Do not merge PR#14759" > > > *possibly* > > > followed up by separate votes on what our own policies should be > > for > > > provider implementations, and what we should or should not > > encourage > > > 3rd > > > parties to do. > > > > I disagree partially. IMO we should primarily have a policy vote > > and > > the closing or merging of PR#14759 should come out of it naturally. > > -- 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.]
Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)
I do not think we should retriage this. There needs to be just a policy vote. Depending on the policy vote outcome the PR will have to be either: - merged if the policy vote does not pass or passes and the PR does not conflict with it - dropped if the policy vote passes and says that we do not want any information on blinding in form of a property - adjusted and merged if the policy vote passes and says that we want some information on blinding in form of a property but it needs to be done differently (such as having no-blinding property or whatever) The policy vote should happen before beta1. The eventual rework should not take much time so I do not worry about that. Implicitly, if the vote passes and says we do not want blinding property in any form, the original issue as triaged by OTC will be closed. There is no need for extra decision making process on that. Tomas On Fri, 2021-04-09 at 14:27 +0300, Nicola Tuveri wrote: > But I am not opposed to separate the 2 votes if that is perceived as > better and we are ready to deal with the possible delays introduced > in the development. > > I am not entirely sure if this PR can be retriaged by OTC as not- > blocking for the beta release, but that could also be an option to > buy more time while we define a policy and then vote to accept or > reject based on that. > > Nicola > > On Fri, Apr 9, 2021, 14:24 Nicola Tuveri wrote: > > I agree with what Tomàš said, and that is the reason why I > > convoluted them in a single vote: we need to merge or reject the PR > > based on a policy, but if we do 2 separate votes we risk to create > > delays in the already quite loaded development cycles left! > > > > Nicola > > > > On Fri, Apr 9, 2021, 10:53 Tomas Mraz wrote: > > > On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > > > > > > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > > > > Proposed vote text > > > > > == > > > > > > > > > > Do not merge PR#14759, prevent declaring properties > > > similar to > > > > > `blinding=yes` or `consttime=yes` in our implementations > > > and > > > > > discourage 3rd parties from adopting similar designs. > > > > > > > > I think this vote tries to cover too much ground in a single > > > vote. I > > > > would prefer to see a simple vote of "Do not merge PR#14759" > > > > *possibly* > > > > followed up by separate votes on what our own policies should > > > be for > > > > provider implementations, and what we should or should not > > > encourage > > > > 3rd > > > > parties to do. > > > > > > I disagree partially. IMO we should primarily have a policy vote > > > and > > > the closing or merging of PR#14759 should come out of it > > > naturally. > > > -- 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.]
Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)
On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > Proposed vote text > > == > > > > Do not merge PR#14759, prevent declaring properties similar to > > `blinding=yes` or `consttime=yes` in our implementations and > > discourage 3rd parties from adopting similar designs. > > I think this vote tries to cover too much ground in a single vote. I > would prefer to see a simple vote of "Do not merge PR#14759" > *possibly* > followed up by separate votes on what our own policies should be for > provider implementations, and what we should or should not encourage > 3rd > parties to do. I disagree partially. IMO we should primarily have a policy vote and the closing or merging of PR#14759 should come out of it naturally. -- 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.]
Monthly Status Report (March 2021)
My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - participated on the openssl-1.1.1k security release by reviewing and doing the CVE-2021-3450 fix - reviews of various PRs: - I've reviewed about 90 PRs this month - Major PRs reviewed: - Stop using EVP_PKEY in encoders and decoders #14314 - Make 'tests' depend on a generated 'providers/fipsmodule.cnf' #14320 - Add testing for non-default library context into evp_extra_test #14478 - ESS for TSP and CAdES-BES: Correct logic of ts_check_signing_certs() relating cert IDs to chain members #14503 - KDF life-cycle documentation #14522 - Fix Coverity resource leaks #14596 - Fix DER reading from stdin for BIO_f_readbuffer #14599 - HTTP: Fix method_POST param by moving it to OSSL_HTTP_REQ_CTX_set_request_line() #14699 - submitted 31 PRs: - In particular: - TODO cleanups in test, ssl, and providers directories #14367 - Another set of TODO 3.0 cleanups - this time mostly in crypto #14404 - CI: add job with external tests (temporarily krb5 and gost_engine only) #14416 - Change default algorithms in PKCS12_create() and PKCS12_set_mac() #14450 - Do not call RAND_get0_public from within the FIPS provider initialization #14497 - Make EVP_PKEY_missing_parameters work properly on provided RSA keys #14511 - Added functions for printing EVP_PKEYs to FILE * #14577 - Implement EVP_PKEY_dup() function #14624 - EVP_PKCS82PKEY: Create provided keys if possible #14659 - Cleanups related to legacy nid support #14703 - Add "save-parameters" encoder parameter #14746 - Provider side decoder API documentation #14756 -- 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.]
Re: OTC VOTE: Disallow SM2 with a non-SM2 curve
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 +, 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] >
Monthly Status Report (February 2021)
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
Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely
The vote is now closed: topic: The RSA_SSLV23_PADDING and related functions should be completely removed from OpenSSL 3.0 code. Proposed by Tomas Mraz Public: yes opened: 2021-02-23 closed: 2021-02-28 accepted: yes (for: 6, against: 0, abstained: 5, not voted: 0) Tomas
Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely
On Wed, 2021-02-24 at 19:59 -0200, Viktor Dukhovni wrote: > Is there an open pull request for this? No there isn't yet, but Rich Salz was working on deprecation of this and he is willing to change the PR to do removal instead. > > On Feb 23, 2021, at 8:21 AM, Tomas Mraz wrote: > > > > topic: The RSA_SSLV23_PADDING and related functions should be > > completely removed from OpenSSL 3.0 code. > > > > comment: The padding mode and the related functions (which are > > already > > deprecated in the current master branch) is useless outside of > > SSLv2 > > support. We do not support SSLv2 and we do not expect anybody using > > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > I am inclined to vote yes on general grounds, but my concern is > whether > this might then cause some downstream consumers of OpenSSL to fail to > compile (things like Python bindings to OpenSSL, Net::SSLeay, ...) > > It may be prudent to leave some stub functions in place that just > return errors, if they're currently exposed in various tools, and > likely unused, but would still cause some pain to the downstream > API maintainers if entirely removed. > > Are there any such functions exposed by popular toolkits? I did not do any serious research but I know that M2Crypto provides such bindings. So there definitely are cases where the various bindings implementations will have to be adjusted. I do not see that as a reason to block the removal as the bindings really will have to be adjusted for 3.0 for other reasons anyway. We do not promise 100% API compatibility with 1.1.1. Also in case of the M2Crypto bindings they will already fail with 1.1.1 because they tested for the incorrect behavior that was fixed by the recent related CVE fix. Tomas
Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely
+1 from me of course On Tue, 2021-02-23 at 11:21 +0100, Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are > already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > >
OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely
topic: The RSA_SSLV23_PADDING and related functions should be completely removed from OpenSSL 3.0 code. comment: The padding mode and the related functions (which are already deprecated in the current master branch) is useless outside of SSLv2 support. We do not support SSLv2 and we do not expect anybody using OpenSSL 3.0 to try to support SSLv2 by calling those functions. Proposed by Tomas Mraz. public: yes opened: 2021-02-23
Re: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters.
We discussed that within the call. We did not add the 'optional' word because the meaning of it is convoluted with the parameter being really optional (as in fn(a, b, ...)). That the caller can pass NULL as OSSL_PARAM array pointer is already implicit. On Tue, 2021-02-02 at 11:28 +, Dr. Matthias St. Pierre wrote: > +1 > > I recall that in our discussion the OSSL_PARAM array pointer was > intended to be optional, > i.e., NULL pointers allowed. Maybe the word 'optional' should be > added as follows? > >EVP init functions should accept an *optional* OSSL_PARAM array to > set parameters. > > > > -Original Message- > > From: openssl-project On > > Behalf Of Dr Paul Dale > > Sent: Tuesday, February 2, 2021 10:18 AM > > To: openssl-project@openssl.org > > Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM > > array to set parameters. > > > > topic: EVP init functions should accept an OSSL_PARAM array to set > > parameters. > > comment: This will mostly avoid calling the equivalent set_param > > call. > > Proposed by pauli. > > Public: yes > > opened: 2020-02-02 > > closed: 2020-02-02 > > accepted: yes (for: 8, against: 0, abstained: 1, not voted: 2) -- 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.]
Monthly Status Report (January 2021)
My key activities this month were:
- triage of newly reported issues and responding to questions
- participation on the OTC meetings
- reviews of various PRs:
- I've reviewed about 80 PRs this month, merged many of them submitted by 3rd
party
contributors
- Major PRs reviewed:
- 3.0 alpha 11 release review
- Update CMP doc on cert and key sources and extend use of PKCS#10 input
#13841
- Deprecate EVP_KEY_new_CMAC_key #13829
- [crypto/dh] side channel hardening for computing DH shared keys #13783
- x509_vfy.c: Fix a regression in find_issuer(); extend and re-organize
some tests #13762
- X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed to
due to invalid cert #13755
- Major improvemens of pkey app and bugfix on IS_HTTP(S) macros #13712
- X509 app: major cleanup of user guidance, documentation, and code
structure #13711
- Fix a crash with multi-threaded applications using the FIPS module #13660
- apps/{req,x509,ca}.c Make sure certs have SKID and AKID by default #13658
- Use centralized fetching errors #13467
- Remove pkey_downgrade from PKCS7 code #13435
- Test CLI key validation and SM2 key validation #13359
- EVP: fix keygen for EVP_PKEY_RSA_PSS #13099
- submitted 11 PRs:
- In particular:
- chacha20: Properly reinitialize the cipher context with NULL key #13850
- Deprecation of the remaining functions related to X9.31 RSA key
generation #13921
- Rename EVP_CIPHER_CTX_get_iv and EVP_CIPHER_CTX_get_iv_state for clarity
#13870
- Fixes in DH derivation related to DH support in CMS #13869
- Implement missing algorithm id generation for the RSA-PSS signatures
#13988
- took over the PR for deprecation of EC_KEY and related functions (#13139)
from Shane, finalized it
--
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.]
Re: OTC VOTE: Keeping API compatibility with missing public key
This vote is now closed. accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3) Tomas On Fri, 2020-12-04 at 13:45 +0100, Tomas Mraz wrote: > Vote background > --- > > The vote on relaxing the conceptual model in regards to required > public > component for EVP_PKEY has passed with the following text: > > 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). > > However since then the issue 13506 [1] was reported. > > During OTC meeting we concluded that we might need to relax also > other > public key algorithm implementations to allow private keys without > public component. > > Vote > > > topic: For 3.0 EVP_PKEY keys all algorithm implementations that were > usable >with 1.1.1 EVP_PKEY API or low level APIs without public > component must >stay usable. > >This overrules the > * all implementations apart from EC require the public > component to be present; > part of the vote closed on 2020-11-17. > > Proposed by Tomas Mraz > Public: yes > opened: 2020-12-04 > > Tomas Mraz > > -- 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.]
Remote unpack error when trying to push
It seems we are out of space or there is other similar problem on git.openssl.org. Pushing to openssl-...@git.openssl.org:openssl.git Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 8 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 474 bytes | 474.00 KiB/s, done. Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 error: remote unpack failed: unable to create temporary object directory To git.openssl.org:openssl.git ! [remote rejected] master -> master (unpacker error) error: failed to push some refs to 'openssl-...@git.openssl.org:openssl.git' -- 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.]
OTC VOTE: Keeping API compatibility with missing public key
Vote background --- The vote on relaxing the conceptual model in regards to required public component for EVP_PKEY has passed with the following text: 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). However since then the issue 13506 [1] was reported. During OTC meeting we concluded that we might need to relax also other public key algorithm implementations to allow private keys without public component. Vote topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable with 1.1.1 EVP_PKEY API or low level APIs without public component must stay usable. This overrules the * all implementations apart from EC require the public component to be present; part of the vote closed on 2020-11-17. Proposed by Tomas Mraz Public: yes opened: 2020-12-04 Tomas Mraz
Re: OTC Vote proposal: Relax the implementation in regards to required public component
There were no comments so far, so unless there is any comment today, I'll call a vote on the proposed vote text tomorrow. On Tue, 2020-12-01 at 12:20 +0100, Tomas Mraz wrote: > The vote on relaxing the conceptual model in regards to required > public > component for EVP_PKEY has passed with the following text: > > 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). > > However since then the issue 13506 [1] was reported. > > During OTC meeting we concluded that we might need to relax also > other > public key algorithm implementations to allow private keys without > public component. > > So here is my vote proposal in regards to this: > > -- proposed vote text -- > For 3.0 EVP_PKEY keys all algorithm implementations that were usable > with 1.1.1 EVP_PKEY API or low level APIs without public component > must > stay usable. > > > This effectively overrules the '* all implementations apart from EC > require the public component to be present' part of the previous > vote. > > I did not explicitly mention in the vote proposal that we do not want > to generate the public component on fly (or even on 'fromdata' call) > as > I do not think we were doing that in 1.1.1 so implementation of this > vote should not require that either. > > > [1] https://github.com/openssl/openssl/issues/13506 > -- 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.]
OTC Vote proposal: Relax the implementation in regards to required public component
The vote on relaxing the conceptual model in regards to required public component for EVP_PKEY has passed with the following text: 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). However since then the issue 13506 [1] was reported. During OTC meeting we concluded that we might need to relax also other public key algorithm implementations to allow private keys without public component. So here is my vote proposal in regards to this: -- proposed vote text -- For 3.0 EVP_PKEY keys all algorithm implementations that were usable with 1.1.1 EVP_PKEY API or low level APIs without public component must stay usable. This effectively overrules the '* all implementations apart from EC require the public component to be present' part of the previous vote. I did not explicitly mention in the vote proposal that we do not want to generate the public component on fly (or even on 'fromdata' call) as I do not think we were doing that in 1.1.1 so implementation of this vote should not require that either. [1] https://github.com/openssl/openssl/issues/13506 -- 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.]
Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`
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]: < > > >
