Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-03-22 19:52:00 [+0100], To Kurt Roeckx wrote:
> > I will prepare 1.1.1k for unstable, do buster-security based on
> > 1.1.1d-0+deb10u5 and then come back with an updated pu :)

New round. I prepared a pu for Buster based on OpenSSL 1.1.1k. The
unstable release migrated to testing. I am not aware of any regressions
so far.
Please find attached a diff against the last proposed pu, based on
1.1.1j.
I will also reply to this mail with a diff against the current version
in buster-pu.

Sebastian
diff --git a/CHANGES b/CHANGES
index 1ab64b35c9a48..7d0129e687652 100644
--- a/CHANGES
+++ b/CHANGES
@@ -7,6 +7,50 @@
  https://github.com/openssl/openssl/commits/ and pick the appropriate
  release branch.
 
+ Changes between 1.1.1j and 1.1.1k [25 Mar 2021]
+
+  *) Fixed a problem with verifying a certificate chain when using the
+ X509_V_FLAG_X509_STRICT flag. This flag enables additional security checks
+ of the certificates present in a certificate chain. It is not set by
+ default.
+
+ Starting from OpenSSL version 1.1.1h a check to disallow certificates in
+ the chain that have explicitly encoded elliptic curve parameters was added
+ as an additional strict check.
+
+ An error in the implementation of this check meant that the result of a
+ previous check to confirm that certificates in the chain are valid CA
+ certificates was overwritten. This effectively bypasses the check
+ that non-CA certificates must not be able to issue other certificates.
+
+ If a "purpose" has been configured then there is a subsequent opportunity
+ for checks that the certificate is a valid CA.  All of the named "purpose"
+ values implemented in libcrypto perform this check.  Therefore, where
+ a purpose is set the certificate chain will still be rejected even when the
+ strict flag has been used. A purpose is set by default in libssl client and
+ server certificate verification routines, but it can be overridden or
+ removed by an application.
+
+ In order to be affected, an application must explicitly set the
+ X509_V_FLAG_X509_STRICT verification flag and either not set a purpose
+ for the certificate verification or, in the case of TLS client or server
+ applications, override the default purpose.
+ (CVE-2021-3450)
+ [Tomáš Mráz]
+
+  *) Fixed an issue where an OpenSSL TLS server may crash if sent a maliciously
+ crafted renegotiation ClientHello message from a client. If a TLSv1.2
+ renegotiation ClientHello omits the signature_algorithms extension (where
+ it was present in the initial ClientHello), but includes a
+ signature_algorithms_cert extension then a NULL pointer dereference will
+ result, leading to a crash and a denial of service attack.
+
+ A server is only vulnerable if it has TLSv1.2 and renegotiation enabled
+ (which is the default configuration). OpenSSL TLS clients are not impacted
+ by this issue.
+ (CVE-2021-3449)
+ [Peter Kästle and Samuel Sapalski]
+
  Changes between 1.1.1i and 1.1.1j [16 Feb 2021]
 
   *) Fixed the X509_issuer_and_serial_hash() function. It attempts to
diff --git a/Configurations/unix-Makefile.tmpl b/Configurations/unix-Makefile.tmpl
index 3a24d551359bd..41648c952667f 100644
--- a/Configurations/unix-Makefile.tmpl
+++ b/Configurations/unix-Makefile.tmpl
@@ -917,8 +917,8 @@ ERROR_REBUILD=
   done )
 
 ordinals:
-	( b=`pwd`; cd $(SRCDIR); $(PERL) -I$$b util/mkdef.pl crypto update )
-	( b=`pwd`; cd $(SRCDIR); $(PERL) -I$$b util/mkdef.pl ssl update )
+	$(PERL) $(SRCDIR)/util/mkdef.pl crypto update
+	$(PERL) $(SRCDIR)/util/mkdef.pl ssl update
 
 test_ordinals:
 	( cd test; \
diff --git a/NEWS b/NEWS
index 3cce525066457..05991a0c214a9 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,14 @@
   This file gives a brief overview of the major changes between each OpenSSL
   release. For more details please read the CHANGES file.
 
+  Major changes between OpenSSL 1.1.1j and OpenSSL 1.1.1k [25 Mar 2021]
+
+  o Fixed a problem with verifying a certificate chain when using the
+X509_V_FLAG_X509_STRICT flag (CVE-2021-3450)
+  o Fixed an issue where an OpenSSL TLS server may crash if sent a
+maliciously crafted renegotiation ClientHello message from a client
+(CVE-2021-3449)
+
   Major changes between OpenSSL 1.1.1i and OpenSSL 1.1.1j [16 Feb 2021]
 
   o Fixed a NULL pointer deref in the X509_issuer_and_serial_hash()
diff --git a/README b/README
index da5629f92c819..b92a8bd3a4b59 100644
--- a/README
+++ b/README
@@ -1,7 +1,7 @@
 
- OpenSSL 1.1.1j 16 Feb 2021
+ OpenSSL 1.1.1k 25 Mar 2021
 
- Copyright (c) 1998-2020 The OpenSSL Project
+ Copyright (c) 1998-2021 The OpenSSL Project
  Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
  All rights reserved.
 
diff --git a/apps/s_cb.c b/apps/s_cb.c
index 6406ddfb9e1b2..dee1b2e5b4f65 100644
--- a/apps/s_cb.c
+++ b/apps/s_cb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 1995-2020 The OpenSSL Project 

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

Resending because I managed to accidently clear TO:

On 2021-03-22 19:48:31 [+0100], Cc 959...@bugs.debian.org wrote:
> On 2021-02-24 23:23:07 [+0100], To Kurt Roeckx wrote:
> > On 2021-02-10 21:52:46 [+0100], To Kurt Roeckx wrote:
> > > OpenSSL upstream announced [0] 1.1.1j for next Tuesday with a security
> > > fix classified as MODERATE [1].
> 
> So this happened. OpenSSL upstream announced [0] 1.1.1k for next
> Thursday (25th).
> 
> I will prepare 1.1.1k for unstable, do buster-security based on
> 1.1.1d-0+deb10u5 and then come back with an updated pu :)
> 
> [0] https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html
>  
Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-02-24 23:23:07 [+0100], To Kurt Roeckx wrote:
> On 2021-02-10 21:52:46 [+0100], To Kurt Roeckx wrote:
> > OpenSSL upstream announced [0] 1.1.1j for next Tuesday with a security
> > fix classified as MODERATE [1].

So this happened. OpenSSL upstream announced [0] 1.1.1k for next
Thursday (25th).

I will prepare 1.1.1k for unstable, do buster-security based on
1.1.1d-0+deb10u5 and then come back with an updated pu :)

[0] https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html
 
Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-02-01 23:50:03 [+0100], To Kurt Roeckx wrote:
> in case someone wants to test.
> I think the ship for this pu is sailing without me but I'm ready for the
> next cruise :)

OpenSSL upstream announced [0] 1.1.1j for next Tuesday with a security
fix classified as MODERATE [1].

[0] https://mta.openssl.org/pipermail/openssl-announce/2021-February/000191.html
[1] https://www.openssl.org/policies/secpolicy.html#moderate

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-29 20:35:52 [+0100], To Kurt Roeckx wrote:
> On 2021-01-28 00:28:03 [+0100], Kurt Roeckx wrote:
> > On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote:
> > > There are a whole bunch of other issues and pull requests related to
> > > this. I hope this is the end of the regressions in the X509 code.
> > 
> > So there is something else now:
> > https://github.com/openssl/openssl/issues/13931
> > https://github.com/openssl/openssl/pull/13982
> 
> So what is the plan here? Upload to unstable and prepare a pu once it
> migrate to testing or right away?

fed to unstable, migrated to testing. The small diff towards the
previous is attached. I uploaded the whole thing (source package +
amd64 binary) to
https://breakpoint.cc/openssl-pu.tar

in case someone wants to test.
I think the ship for this pu is sailing without me but I'm ready for the
next cruise :)
The complete diff vs the last package is comming soon.

> > Kurt

Sebastian
diff --git a/debian/changelog b/debian/changelog
index 56a950734f01d..89ce61e9d6be7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,8 +5,9 @@ openssl (1.1.1i-0+deb10u1) buster; urgency=medium
   (Closes: #947949).
   * Update symbol list.
   * Apply two patches from upstream to address x509 related regressions.
+  * Cherry-pick a patch from upstream to address #13931.
 
- -- Sebastian Andrzej Siewior   Sun, 24 Jan 2021 11:22:16 +0100
+ -- Sebastian Andrzej Siewior   Mon, 01 Feb 2021 23:23:03 +0100
 
 openssl (1.1.1d-0+deb10u4) buster-security; urgency=medium
 
diff --git a/debian/patches/check_sig_alg_match-weaken-sig-nid-comparison-to-base-alg.patch b/debian/patches/check_sig_alg_match-weaken-sig-nid-comparison-to-base-alg.patch
new file mode 100644
index 0..2b2dfd420cb28
--- /dev/null
+++ b/debian/patches/check_sig_alg_match-weaken-sig-nid-comparison-to-base-alg.patch
@@ -0,0 +1,244 @@
+From: "Dr. David von Oheimb" 
+Date: Tue, 26 Jan 2021 11:53:15 +0100
+Subject: check_sig_alg_match(): weaken sig nid comparison to base alg
+
+This (re-)allows RSA-PSS signers
+
+Fixes #13931
+
+Reviewed-by: Tomas Mraz 
+(Merged from https://github.com/openssl/openssl/pull/13982)
+---
+ crypto/x509v3/v3_purp.c   |  9 ++---
+ test/certs/ca-pss-cert.pem| 21 +
+ test/certs/ca-pss-key.pem | 28 
+ test/certs/ee-pss-cert.pem| 21 +
+ test/certs/mkcert.sh  | 22 +-
+ test/certs/setup.sh   | 13 +
+ test/recipes/25-test_verify.t |  5 -
+ 7 files changed, 106 insertions(+), 13 deletions(-)
+ create mode 100644 test/certs/ca-pss-cert.pem
+ create mode 100644 test/certs/ca-pss-key.pem
+ create mode 100644 test/certs/ee-pss-cert.pem
+
+diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c
+index 93b5ca4d4283..3f5ce5c91c5d 100644
+--- a/crypto/x509v3/v3_purp.c
 b/crypto/x509v3/v3_purp.c
+@@ -348,14 +348,17 @@ static int setup_crldp(X509 *x)
+ /* Check that issuer public key algorithm matches subject signature algorithm */
+ static int check_sig_alg_match(const EVP_PKEY *pkey, const X509 *subject)
+ {
+-int pkey_nid;
++int pkey_sig_nid, subj_sig_nid;
+ 
+ if (pkey == NULL)
+ return X509_V_ERR_NO_ISSUER_PUBLIC_KEY;
++if (OBJ_find_sigid_algs(EVP_PKEY_base_id(pkey),
++NULL, _sig_nid) == 0)
++pkey_sig_nid = EVP_PKEY_base_id(pkey);
+ if (OBJ_find_sigid_algs(OBJ_obj2nid(subject->cert_info.signature.algorithm),
+-NULL, _nid) == 0)
++NULL, _sig_nid) == 0)
+ return X509_V_ERR_UNSUPPORTED_SIGNATURE_ALGORITHM;
+-if (EVP_PKEY_type(pkey_nid) != EVP_PKEY_base_id(pkey))
++if (pkey_sig_nid != EVP_PKEY_type(subj_sig_nid))
+ return X509_V_ERR_SIGNATURE_ALGORITHM_MISMATCH;
+ return X509_V_OK;
+ }
+diff --git a/test/certs/ca-pss-cert.pem b/test/certs/ca-pss-cert.pem
+new file mode 100644
+index ..566b63a800f7
+--- /dev/null
 b/test/certs/ca-pss-cert.pem
+@@ -0,0 +1,21 @@
++-BEGIN CERTIFICATE-
++MIIDXjCCAhagAwIBAgIBAjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAaEa
++MBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgGiAwIBIDASMRAwDgYDVQQDDAdSb290
++IENBMCAXDTIxMDEyNjEwMDUwOFoYDzIxMjEwMTI3MTAwNTA4WjARMQ8wDQYDVQQD
++DAZDQS1QU1MwggEgMAsGCSqGSIb3DQEBCgOCAQ8AMIIBCgKCAQEAtclsFtJOQgAC
++ZxTPn2T2ksmibRNVAnEfVCgfJxsPN3aEERgqqhWbC4LmGHRIIjQ9DpobarydJivw
++epDaiu11rgwXgenIobIVvVr2+L3ngalYdkwmmPVImNN8Ef575ybE/kVgTu9X37DJ
++t+8psfVGeFg4RKykOi7SfPCSKHKSeZUXPj9AYwZDw4HX2rhstRopXAmUzz2/uAaR
++fmU7tYOG5qhfMUpP+Ce0ZBlLE9JjasY+d20/mDFuvFEc5qjfzNqv/7okyBjaWB4h
++gwnjXASrqKlqHKVU1UyrJc76yAniimy+IoXKAELetIJGSN15GYaWJcAIs0Eybjyk
++gyAu7Zlf/wIDAQABo2AwXjAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAd
++BgNVHQ4EFgQUGfmhA/VcxWkh7VUBHxUdHHQLgrAwHwYDVR0jBBgwFoAUjvUlrx6b
++a4Q9fICayVOcTXL3o1IwPQYJKoZIhvcNAQEKMDCgDTALBglghkgBZQMEAgGhGjAY
++BgkqhkiG9w0BAQgwCwYJYIZIAWUDBAIBogMCASADggEBAF6rSSBj+dkv0UGuE1El

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-28 00:28:03 [+0100], Kurt Roeckx wrote:
> On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote:
> > There are a whole bunch of other issues and pull requests related to
> > this. I hope this is the end of the regressions in the X509 code.
> 
> So there is something else now:
> https://github.com/openssl/openssl/issues/13931
> https://github.com/openssl/openssl/pull/13982

So what is the plan here? Upload to unstable and prepare a pu once it
migrate to testing or right away?

> Kurt

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Kurt Roeckx]

On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote:
> There are a whole bunch of other issues and pull requests related to
> this. I hope this is the end of the regressions in the X509 code.

So there is something else now:
https://github.com/openssl/openssl/issues/13931
https://github.com/openssl/openssl/pull/13982


Kurt

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-25 19:57:18 [+0100], Cyril Brulebois wrote:
> Not really *much* easier, to be honest. I can definitely build a package
> locally given a source debdiff, or slightly better, given a source
> package I can run dget against (since we're talking about new upstream
> releases, by the looks of it), and do whatever testing with the
> generated packages built into d-i and/or fetched from the network as
> required (similarly to what's done for the various kernel udebs).
> 
> IOW that can be tested before even having to make a decision regarding a
> possible acceptance into p-u.

in case it helps, I uploaded
  https://breakpoint.cc/openssl-pu.tar

| $ sha512sum openssl-pu.tar 
| 
1a3df2e37aa9312a378046691794bf7d7d72570ed9ade7ffbf50f87c8c8a7dd5e671a7f704fc4f1ebdbada1dda3007a5db24b426deefd33fff39b81e7be38aa3
  openssl-pu.tar

containing the source package and amd64 packages.

> Cheers,

Sebastian


signature.asc
Description: PGP signature

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Cyril Brulebois]

Adam D. Barratt  (2021-01-25):
> KiBi - I'm assuming that it would be much easier for you to check d-i
> against the new OpenSSL version if it were already in p-u?

Not really *much* easier, to be honest. I can definitely build a package
locally given a source debdiff, or slightly better, given a source
package I can run dget against (since we're talking about new upstream
releases, by the looks of it), and do whatever testing with the
generated packages built into d-i and/or fetched from the network as
required (similarly to what's done for the various kernel udebs).

IOW that can be tested before even having to make a decision regarding a
possible acceptance into p-u.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Adam D. Barratt]

On Sun, 2021-01-24 at 12:25 +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-22 16:38:28 [+], Adam D. Barratt wrote:
> > Both would be good, please.
> 
> Here is the complete diff against the last openssl release in Buster.

Thanks.

I realise that this has been dragging on for quite some time now, and
apologies again for my part in that. My (possibly overly paranoid)
concern right now is that if we aim for including 1.1.1i in 10.8,
there's less than a week of the upload window remaining for any testing
to happen and issues to be flagged up.

While I can't see any reason that packages in general should end up
with dependencies on 1.1.1i specifically, the debian-installer rebuild
for the point release will end up pulling in whichever version of
OpenSSL is in p-u at the time. That implies that we can't simply not
include the update if it's in p-u and blocking issues show up.

KiBi - I'm assuming that it would be much easier for you to check d-i
against the new OpenSSL version if it were already in p-u?

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-22 16:38:28 [+], Adam D. Barratt wrote:
> Assuming that a patched m2crypto will also build fine against openssl
> 1.1.1d, then there's no reason that the two shouldn't proceed in
> parallel (i.e. feel free to file the m2crypto request already).

Yes, it does. Bug filled. Thank you.

> Regards,
> 
> Adam

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-22 16:38:28 [+], Adam D. Barratt wrote:
> Both would be good, please.

here is the with the two additional patches.

Sebastian
diff --git a/debian/changelog b/debian/changelog
index 088c914a3dd4a..56a950734f01d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,8 +4,9 @@ openssl (1.1.1i-0+deb10u1) buster; urgency=medium
 - CVE-2019-1551 (Overflow in the x64_64 Montgomery squaring procedure),
   (Closes: #947949).
   * Update symbol list.
+  * Apply two patches from upstream to address x509 related regressions.
 
- -- Sebastian Andrzej Siewior   Wed, 06 Jan 2021 21:04:15 +0100
+ -- Sebastian Andrzej Siewior   Sun, 24 Jan 2021 11:22:16 +0100
 
 openssl (1.1.1d-0+deb10u4) buster-security; urgency=medium
 
diff --git a/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch b/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch
new file mode 100644
index 0..4e6a391da269d
--- /dev/null
+++ b/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch
@@ -0,0 +1,232 @@
+From: "Dr. David von Oheimb" 
+Date: Wed, 30 Dec 2020 09:57:49 +0100
+Subject: X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed
+ to due to invalid cert
+
+This is the backport of #13755 to v1.1.1.
+Fixes #13698
+
+Reviewed-by: Tomas Mraz 
+(Merged from https://github.com/openssl/openssl/pull/13756)
+---
+ crypto/x509/x509_cmp.c| 18 ++
+ crypto/x509/x_all.c   |  2 +-
+ crypto/x509v3/v3_purp.c   |  3 ++-
+ doc/man3/X509_get_extension_flags.pod |  9 +++--
+ include/openssl/x509v3.h  |  5 +++--
+ test/certs/invalid-cert.pem   | 19 +++
+ test/recipes/80-test_x509aux.t| 13 -
+ test/x509aux.c| 17 +++--
+ 8 files changed, 61 insertions(+), 25 deletions(-)
+ create mode 100644 test/certs/invalid-cert.pem
+
+diff --git a/crypto/x509/x509_cmp.c b/crypto/x509/x509_cmp.c
+index ad620af0aff4..c9d89336406f 100644
+--- a/crypto/x509/x509_cmp.c
 b/crypto/x509/x509_cmp.c
+@@ -133,19 +133,21 @@ unsigned long X509_subject_name_hash_old(X509 *x)
+  */
+ int X509_cmp(const X509 *a, const X509 *b)
+ {
+-int rv;
++int rv = 0;
+ 
+ if (a == b) /* for efficiency */
+ return 0;
+-/* ensure hash is valid */
+-if (X509_check_purpose((X509 *)a, -1, 0) != 1)
+-return -2;
+-if (X509_check_purpose((X509 *)b, -1, 0) != 1)
+-return -2;
+ 
+-rv = memcmp(a->sha1_hash, b->sha1_hash, SHA_DIGEST_LENGTH);
+-if (rv)
++/* try to make sure hash is valid */
++(void)X509_check_purpose((X509 *)a, -1, 0);
++(void)X509_check_purpose((X509 *)b, -1, 0);
++
++if ((a->ex_flags & EXFLAG_NO_FINGERPRINT) == 0
++&& (b->ex_flags & EXFLAG_NO_FINGERPRINT) == 0)
++rv = memcmp(a->sha1_hash, b->sha1_hash, SHA_DIGEST_LENGTH);
++if (rv != 0)
+ return rv;
++
+ /* Check for match against stored encoding too */
+ if (!a->cert_info.enc.modified && !b->cert_info.enc.modified) {
+ if (a->cert_info.enc.len < b->cert_info.enc.len)
+diff --git a/crypto/x509/x_all.c b/crypto/x509/x_all.c
+index aa5ccba44899..bec850af5797 100644
+--- a/crypto/x509/x_all.c
 b/crypto/x509/x_all.c
+@@ -363,7 +363,7 @@ int X509_digest(const X509 *data, const EVP_MD *type, unsigned char *md,
+ unsigned int *len)
+ {
+ if (type == EVP_sha1() && (data->ex_flags & EXFLAG_SET) != 0
+-&& (data->ex_flags & EXFLAG_INVALID) == 0) {
++&& (data->ex_flags & EXFLAG_NO_FINGERPRINT) == 0) {
+ /* Asking for SHA1 and we already computed it. */
+ if (len != NULL)
+ *len = sizeof(data->sha1_hash);
+diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c
+index 2b06dba05398..93b5ca4d4283 100644
+--- a/crypto/x509v3/v3_purp.c
 b/crypto/x509v3/v3_purp.c
+@@ -391,7 +391,8 @@ static void x509v3_cache_extensions(X509 *x)
+ }
+ 
+ if (!X509_digest(x, EVP_sha1(), x->sha1_hash, NULL))
+-x->ex_flags |= EXFLAG_INVALID;
++x->ex_flags |= (EXFLAG_NO_FINGERPRINT | EXFLAG_INVALID);
++
+ /* V1 should mean no extensions ... */
+ if (!X509_get_version(x))
+ x->ex_flags |= EXFLAG_V1;
+diff --git a/doc/man3/X509_get_extension_flags.pod b/doc/man3/X509_get_extension_flags.pod
+index 43c9c952c6b7..cca72c71fcab 100644
+--- a/doc/man3/X509_get_extension_flags.pod
 b/doc/man3/X509_get_extension_flags.pod
+@@ -78,12 +78,17 @@ The certificate contains an unhandled critical extension.
+ 
+ =item B
+ 
+-Some certificate extension values are invalid or inconsistent. The
+-certificate should be rejected.
++Some certificate extension values are invalid or inconsistent.
++The certificate should be rejected.
+ This bit may also be raised after an out-of-memory error while
+ processing the X509 object, so it may not be related to the processed
+ ASN1 object 

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Adam D. Barratt]

On Thu, 2021-01-21 at 21:06 +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-16 19:14:53 [+0100], Kurt Roeckx wrote:
> > So I went over the open issues and pull requests, and currently
> > don't see a reason not to upload it to unstable with those 2
> > patches. I don't know about any other regressions in 1.1.1.
> 
> The openssl package migrated to testing.
> I would prepare the pu package for Buster. Should I post here the
> complete diff or an incremental containing only the new patches?

Both would be good, please.

FWIW we're also fighting the clock (yet) again, as we're now a week
away from the freeze for the 10.8 point release. ("Yay"!)

> Once the openssl pu is acked I would open a pu for m2crypto. Or
> should it be done now? (just asking).

Assuming that a patched m2crypto will also build fine against openssl
1.1.1d, then there's no reason that the two shouldn't proceed in
parallel (i.e. feel free to file the m2crypto request already).

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-16 19:14:53 [+0100], Kurt Roeckx wrote:
> So I went over the open issues and pull requests, and currently
> don't see a reason not to upload it to unstable with those 2
> patches. I don't know about any other regressions in 1.1.1.

The openssl package migrated to testing.
I would prepare the pu package for Buster. Should I post here the
complete diff or an incremental containing only the new patches?
Once the openssl pu is acked I would open a pu for m2crypto. Or should
it be done now? (just asking).

> Kurt

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Kurt Roeckx]

On Thu, Jan 14, 2021 at 09:13:49PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote:
> > > Do you have pointers to upstream issues?
> > 
> > There are a whole bunch of other issues and pull requests related to
> > this. I hope this is the end of the regressions in the X509 code.
> 
> Okay. Please ping once this gets sorted out and I will prepease
> unstalbe/stable uploads. The m2crypto issue got resolved in unstable
> \o/.

So I went over the open issues and pull requests, and currently
don't see a reason not to upload it to unstable with those 2
patches. I don't know about any other regressions in 1.1.1.


Kurt

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote:
> > Do you have pointers to upstream issues?
> 
> There are a whole bunch of other issues and pull requests related to
> this. I hope this is the end of the regressions in the X509 code.

Okay. Please ping once this gets sorted out and I will prepease
unstalbe/stable uploads. The m2crypto issue got resolved in unstable
\o/.

> Kurt

Sebastianc

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Kurt Roeckx]

On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote:
> Hi,
> 
> On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote:
> > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior
> > wrote:
> [...]
> > > The i release in unstable managed to migrate to testing. It was
> > > blocked due to ci by m2crypto and swi-prolog. The swi-prolog issue
> > > got fixed in unstable (the testuite was updated) and is not an
> > > issue in stable (the package builds, the testsuite gets ignored).
> > > The m2crypto issue is a different story and is still open in BTS
> > > (#977655). I *think* someone added an override or the ci-system was
> > > kind to Kurt/me and looked the other way :)
> > > The m2crypto package in stable and bpo will FTBFS with the updated
> > > openssl package.
> > > 
> > > I'm not aware of other issues.
> > 
> > I think there are at least 2 upstream issues since the 1.1.1i
> > release we want to fix first. As far as I know, they haven't been
> > fixed upstream yet.
> 
> Just to confirm, these are issues that you'd want to have fixed before
> adding 1.1.1i to stable, presumably requiring further uploads to
> unstable first?

Yes.

> Do you have pointers to upstream issues?

They both got merged today:
commit 76ed0c0ad119569f6e6f6c96b27b76d3b110413b (origin/OpenSSL_1_1_1-stable)
Author: Dr. David von Oheimb 
Date:   Mon Dec 28 11:25:59 2020 +0100

x509_vfy.c: Fix a regression in find_isser()

...in case the candidate issuer cert is identical to the target cert.

Fixes #13739

Reviewed-by: Tomas Mraz 
(Merged from https://github.com/openssl/openssl/pull/13749)

commit fb1e2411042f0367c2560e4ec5e4b1189ca9cd45
Author: Dr. David von Oheimb 
Date:   Wed Dec 30 09:57:49 2020 +0100

X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed to due 
to invalid cert

This is the backport of #13755 to v1.1.1.
Fixes #13698

Reviewed-by: Tomas Mraz 
(Merged from https://github.com/openssl/openssl/pull/13756)


There are a whole bunch of other issues and pull requests related to
this. I hope this is the end of the regressions in the X509 code.


Kurt

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Adam D. Barratt]

Hi,

On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote:
> On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior
> wrote:
[...]
> > The i release in unstable managed to migrate to testing. It was
> > blocked due to ci by m2crypto and swi-prolog. The swi-prolog issue
> > got fixed in unstable (the testuite was updated) and is not an
> > issue in stable (the package builds, the testsuite gets ignored).
> > The m2crypto issue is a different story and is still open in BTS
> > (#977655). I *think* someone added an override or the ci-system was
> > kind to Kurt/me and looked the other way :)
> > The m2crypto package in stable and bpo will FTBFS with the updated
> > openssl package.
> > 
> > I'm not aware of other issues.
> 
> I think there are at least 2 upstream issues since the 1.1.1i
> release we want to fix first. As far as I know, they haven't been
> fixed upstream yet.

Just to confirm, these are issues that you'd want to have fixed before
adding 1.1.1i to stable, presumably requiring further uploads to
unstable first?

Do you have pointers to upstream issues?

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Kurt Roeckx]

On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote:
> 
> > At some point, could we please have a combined / single diff between
> > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
> > assume)?
> 
> Please find attached the diff between 1.1.1d-0+deb10u4 and the proposed
> 1.1.1i-0+deb10u1.
> 
> The i release in unstable managed to migrate to testing. It was blocked
> due to ci by m2crypto and swi-prolog. The swi-prolog issue got fixed in
> unstable (the testuite was updated) and is not an issue in stable (the
> package builds, the testsuite gets ignored).
> The m2crypto issue is a different story and is still open in BTS
> (#977655). I *think* someone added an override or the ci-system was kind
> to Kurt/me and looked the other way :)
> The m2crypto package in stable and bpo will FTBFS with the updated
> openssl package.
> 
> I'm not aware of other issues.

I think there are at least 2 upstream issues since the 1.1.1i
release we want to fix first. As far as I know, they haven't been
fixed upstream yet.


Kurt

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote:
> That would be preferable at this point, yes, sorry. We should try and
> make sure it's sorted soon afterwards though, to avoid things getting
> stuck again.

I will set up an alarm on my side :)

> At some point, could we please have a combined / single diff between
> the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
> assume)?

Sure. I will prepare one tomorrow.

> Regards,
> 
> Adam

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Adam D. Barratt]

On Fri, 2020-11-20 at 21:04 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-20 17:24:30 [+], Adam D. Barratt wrote:
> > Predictably we're again quite close to a point release. :-( (One
> > week from freeze, specifically.)
> 
> oh.

In fairness, given an approximately two month cycle, we're never /that/
far away from a point release. But some points are obviously closer
than others.

> > Looking at the upstream issues regarding certificate validation
> > changes between 1.1.1e and f/g, #11456 appears to have been
> > addressed already, but #11625 is still open and looks stalled. Have
> > you seen any more reports of that issue?
> 
> Not that I am aware of.

OK, thanks.

> I don't want to rush anything. I have no problem to delay this until
> after the point release if you prefer to do so.

That would be preferable at this point, yes, sorry. We should try and
make sure it's sorted soon afterwards though, to avoid things getting
stuck again.

At some point, could we please have a combined / single diff between
the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
assume)?

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2020-11-20 17:24:30 [+], Adam D. Barratt wrote:
> Predictably we're again quite close to a point release. :-( (One week
> from freeze, specifically.)

oh.

> Looking at the upstream issues regarding certificate validation changes
> between 1.1.1e and f/g, #11456 appears to have been addressed already,
> but #11625 is still open and looks stalled. Have you seen any more
> reports of that issue?

Not that I am aware of.

I don't want to rush anything. I have no problem to delay this until
after the point release if you prefer to do so.

> Regards,
> 
> Adam

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Adam D. Barratt]

On Sun, 2020-11-15 at 11:29 +0100, Sebastian Andrzej Siewior wrote:
> control: retitle -1 buster-pu: package openssl/1.1.1h-1
> 
> On 2020-05-02 22:34:40 [+0100], Adam D. Barratt wrote:
> > > > Do we have any feeling for how widespread such certificates
> > > > might be?
> > > > The fact that there have been two different upstream reports
> > > > isn't particularly comforting.
> > > 
> > > This is correct. I don't know if there is tooling that is
> > > generating broken certificates or just some individuals. I
> > > updated my two OpenVPN instances and I saw clients connecting
> > > again.
> > 
> > Thanks for the information.
> 
> look at that. I deployed it locally and forgot all about it. Now I
> was going to open a pu for 1.1.1h and noticed that I didn't finish
> this one.
> 
> I hereby propose an update to 1.1.1h.

Predictably we're again quite close to a point release. :-( (One week
from freeze, specifically.)

Looking at the upstream issues regarding certificate validation changes
between 1.1.1e and f/g, #11456 appears to have been addressed already,
but #11625 is still open and looks stalled. Have you seen any more
reports of that issue?

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2020-11-15 20:59:18 [+0100], Paul Gevers wrote:
> Hi Sebastian,
Hi Paul,

> I don't fully understand what you say here. We *do* run autopkgtests in
> stable to check for issues. 

Yes, but the package does not use it in stable.

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Paul Gevers]

Hi Sebastian,

On 15-11-2020 11:29, Sebastian Andrzej Siewior wrote:
> The same error is also present in the stable version of swi-prolog.
> However, this is not the only failure in the test suite (it also
> complains about too small keys) and there is no debci for stable which
> would cause a regression so I don't think that it is worth to address
> this in stable.

I don't fully understand what you say here. We *do* run autopkgtests in
stable to check for issues. The results (if negative) show up here:
https://release.debian.org/proposed-updates/stable.html You can
currently see one REJECTED_PERMANENTLY there. So yes, if this breaks the
test (and only the test) that's valuable information.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

control: retitle -1 buster-pu: package openssl/1.1.1h-1

On 2020-05-02 22:34:40 [+0100], Adam D. Barratt wrote:
> > > Do we have any feeling for how widespread such certificates might
> > > be?
> > > The fact that there have been two different upstream reports isn't
> > > particularly comforting.
> > 
> > This is correct. I don't know if there is tooling that is generating
> > broken certificates or just some individuals. I updated my two
> > OpenVPN instances and I saw clients connecting again.
> 
> Thanks for the information.

look at that. I deployed it locally and forgot all about it. Now I was
going to open a pu for 1.1.1h and noticed that I didn't finish this one.

I hereby propose an update to 1.1.1h.
There were no dramatic CVEs closed according to the news file, only

| o Disallow explicit curve parameters in verifications chains when
|   X509_V_FLAG_X509_STRICT is used
| o Enable 'MinProtocol' and 'MaxProtocol' to configure both TLS and DTLS
|   contexts
| o Oracle Developer Studio will start reporting deprecation warnings

is listed under "major changes" since the g release.

We have h in unstable and testing. It took almost a month to migrate. It
was first blocked by swi-prolog (#972862) which was cause by an
"interesting" test suite. Test suite errors do not lead to build
failures, only debci is/was affected. The fix included only an update
to the testsuite.
The same error is also present in the stable version of swi-prolog.
However, this is not the only failure in the test suite (it also
complains about too small keys) and there is no debci for stable which
would cause a regression so I don't think that it is worth to address
this in stable. The package builds fine from source.

I'm attaching a debdiff against the proposed g release.

> Regards,
> 
> Adam

Sebastian


1.1.1h.diff.xz
Description: application/xz

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Adam D. Barratt]

On Sat, 2020-05-02 at 22:29 +0200, Sebastian Andrzej Siewior wrote:
> On 2020-05-02 20:32:01 [+0100], Adam D. Barratt wrote:
> > On Sat, 2020-05-02 at 18:36 +0200, Sebastian Andrzej Siewior wrote:
> > > I'm fairly late, I know.
> > 
> > Just a little. :-( Particularly as OpenSSL builds udebs.
> > 
> > CCing KiBi and -boot so they're aware of the discussion, but this
> > does
> > come quite late.
> 
> Yes, I know. I'm won't cry if this skips this pu, I just couldn't get
> earlier to it.

OK. To be honest, at this stage I would be happier looking at this for
10.5 than 10.4.

> > Do we have any feeling for how widespread such certificates might
> > be?
> > The fact that there have been two different upstream reports isn't
> > particularly comforting.
> 
> This is correct. I don't know if there is tooling that is generating
> broken certificates or just some individuals. I updated my two
> OpenVPN instances and I saw clients connecting again.

Thanks for the information.

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2020-05-02 20:32:01 [+0100], Adam D. Barratt wrote:
> On Sat, 2020-05-02 at 18:36 +0200, Sebastian Andrzej Siewior wrote:
> > I'm fairly late, I know.
> 
> Just a little. :-( Particularly as OpenSSL builds udebs.
> 
> CCing KiBi and -boot so they're aware of the discussion, but this does
> come quite late.

Yes, I know. I'm won't cry if this skips this pu, I just couldn't get
earlier to it.

> Do we have any feeling for how widespread such certificates might be?
> The fact that there have been two different upstream reports isn't
> particularly comforting.

This is correct. I don't know if there is tooling that is generating
broken certificates or just some individuals. I updated my two OpenVPN
instances and I saw clients connecting again.

> Regards,
> 
> Adam

Sebastian

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Adam D. Barratt]

On Sat, 2020-05-02 at 18:36 +0200, Sebastian Andrzej Siewior wrote:
> I'm fairly late, I know.

Just a little. :-( Particularly as OpenSSL builds udebs.

CCing KiBi and -boot so they're aware of the discussion, but this does
come quite late.

> The last update was addressed via DSA providing only a patch for the
> CVE with severity high. This pu updates Buster's OpenSSL version from
> `d' to current `g' fixing CVE-2019-1551 which was earlier skipped due
> to its low severity. 
> The "EOF" bug-fix-regression introduced in `e' is reverted again in
> `g'.
> OpenSSL now checks certificates more strictly. There should be no
> problems with "officially" issued certificats but some certificates
> contain an invalid (combination of) attributes which are now. The `g'
> version is since 25th April in testing and received no bug reports
> but OpenSSL upstream received [0], [1] for custom issued OpenVPN
> certificates.
> Please find attached a compressed debdiff since last security update.
> 
> [0] https://github.com/openssl/openssl/issues/11456
> [1] https://github.com/openssl/openssl/issues/11625

Do we have any feeling for how widespread such certificates might be?
The fact that there have been two different upstream reports isn't
particularly comforting.

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2020-05-02 18:36:42 [+0200], To sub...@bugs.debian.org wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: buster
> Severity: normal
> 
> I'm fairly late, I know.
> The last update was addressed via DSA providing only a patch for the CVE
> with severity high. This pu updates Buster's OpenSSL version from `d' to
> current `g' fixing CVE-2019-1551 which was earlier skipped due to its
> low severity. 

Haven't seen it in the list archive as of now, so it in case it did not
pass due to its size, here is a note about it.

Sebastian