Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Thu, 2022-03-24 at 22:00 +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-24 12:39:55 [+], Adam D. Barratt wrote: > > I've added that text to the announcement for the buster point > > release. > Thanks. > > > If anyone has any changes, please yell ASAP. > > The gnutls and perl changes are not yet built. I guess this is > intended > ;) Yes. :-) The general deadline for uploads closed on Sunday evening and so far as we could tell the issues only affect the testsuites (I realise that in the case of the Perl package that causes a FTBFS) rather than functionality, so I decided to wait to accept them until after the point release. Regards, Adam
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On 2022-03-24 12:39:55 [+], Adam D. Barratt wrote: > I've added that text to the announcement for the buster point release. Thanks. > If anyone has any changes, please yell ASAP. The gnutls and perl changes are not yet built. I guess this is intended ;) > Regards, > > Adam Sebastian
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Wed, 2022-03-23 at 22:38 +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-23 17:40:59 [+], Adam D. Barratt wrote: > > Right, let's have another go at this then: > > > > " > > OpenSSL signature algorithm check tightening > > = > > > > The OpenSSL update provided in this point release includes a > > change to ensure that the requested signature algorithm is > > supported by the active security level. > > > > Although this will not affect most use-cases, it could lead to > > error messages being generated if a non-supported algorithm is > > requested - for example, use of RSA+SHA1 signatures with the > > default > > security level of 2. > > > > In such cases, the security level will need to be explicitly > > lowered, either for individual requests or more globally. This > > may require changes to the configuration of aplications. For > > OpenSSL itself, per-request lowering can be achieved using a > > command-line option such as > > > > -cipher "ALL:@SECLEVEL=1" > > > > with the relevant system-level configuration being found in > > /etc/ssl/openssl.cnf > > " > > > > Is that any better? Further suggestions welcome, but I'm trying not > > to > > make it longer than the rest of the text combined. :-) > > This good Adam, thank you. I have nothing to add. > Thanks. I've added that text to the announcement for the buster point release. If anyone has any changes, please yell ASAP. Regards, Adam
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On 2022-03-23 17:40:59 [+], Adam D. Barratt wrote: > Right, let's have another go at this then: > > " > OpenSSL signature algorithm check tightening > = > > The OpenSSL update provided in this point release includes a > change to ensure that the requested signature algorithm is > supported by the active security level. > > Although this will not affect most use-cases, it could lead to > error messages being generated if a non-supported algorithm is > requested - for example, use of RSA+SHA1 signatures with the default > security level of 2. > > In such cases, the security level will need to be explicitly > lowered, either for individual requests or more globally. This > may require changes to the configuration of aplications. For > OpenSSL itself, per-request lowering can be achieved using a > command-line option such as > > -cipher "ALL:@SECLEVEL=1" > > with the relevant system-level configuration being found in > /etc/ssl/openssl.cnf > " > > Is that any better? Further suggestions welcome, but I'm trying not to > make it longer than the rest of the text combined. :-) This good Adam, thank you. I have nothing to add. > Regards, > > Adam Sebastian
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, 2022-03-22 at 22:13 +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-22 21:47:52 [+0100], Kurt Roeckx wrote: > > On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > > > OpenSSL signature algorithm check tightening > > > = > > > > > > The OpenSSL update included in this point release includes a > > > change to > > > ensure that the requested signature algorithm is supported by the > > > active security level. > > > > > > Although this will not affect most use-cases, it could lead to > > > error > > > messages being generated if a non-supported algorithm is > > > requested - > > > for example, use of SHA1 with the default security level of 2. In > > > such > > > cases, the security level will need to be explicitly lowered when > > > invoking OpenSSL, using an option such as > > > > > > -cipher "ALL:@SECLEVEL=1" > > > " > > > > So reading it again, I think the "when invoking OpenSSL" is > > confusing. > > Not only the openssl binary is affected, but also all clients and > > server applications making use of the library are. Some > > applications > > might have a way to set the cipher in their own configuration file, > > others might need to change the defaults in /etc/ssl/openssl.cfg > > s/openssl.cfg/openssl.cnf Right, let's have another go at this then: " OpenSSL signature algorithm check tightening = The OpenSSL update provided in this point release includes a change to ensure that the requested signature algorithm is supported by the active security level. Although this will not affect most use-cases, it could lead to error messages being generated if a non-supported algorithm is requested - for example, use of RSA+SHA1 signatures with the default security level of 2. In such cases, the security level will need to be explicitly lowered, either for individual requests or more globally. This may require changes to the configuration of aplications. For OpenSSL itself, per-request lowering can be achieved using a command-line option such as -cipher "ALL:@SECLEVEL=1" with the relevant system-level configuration being found in /etc/ssl/openssl.cnf " Is that any better? Further suggestions welcome, but I'm trying not to make it longer than the rest of the text combined. :-) Regards, Adam
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 10:13:25PM +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-22 21:47:52 [+0100], Kurt Roeckx wrote: > > On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > > > OpenSSL signature algorithm check tightening > > > = > > > > > > The OpenSSL update included in this point release includes a change to > > > ensure that the requested signature algorithm is supported by the > > > active security level. > > > > > > Although this will not affect most use-cases, it could lead to error > > > messages being generated if a non-supported algorithm is requested - > > > for example, use of SHA1 with the default security level of 2. In such > > > cases, the security level will need to be explicitly lowered when > > > invoking OpenSSL, using an option such as > > > > > > -cipher "ALL:@SECLEVEL=1" > > > " > > > > So reading it again, I think the "when invoking OpenSSL" is confusing. > > Not only the openssl binary is affected, but also all clients and > > server applications making use of the library are. Some applications > > might have a way to set the cipher in their own configuration file, > > others might need to change the defaults in /etc/ssl/openssl.cfg > > s/openssl.cfg/openssl.cnf > > Kurt correct me if I'm wrong: > This only affects clients which were using TLS1.2 while connecting to > the server and did not send a sig-alg string which let the server > fallback to the default (sha1) which was not checked vs security level. > Would the client have sent sha1 as the sig-cipher then it would fail in > the version d, too. The client can send a list of supported sigalgs. Before the change there were 3 options: - the client didn't send anything, the server selected SHA1 - the client only send SHA1, the server selected SHA1 - the client send both SHA1 and SHA256, the server selected SHA256 With this change, it changes to: - the client didn't send anything, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client only send SHA1, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client send both SHA1 and SHA256, the server selects SHA256. The default client will send both SHA1 and SHA256 for a very long time, but you can change the settings. If the server selects SHA1, before the change the client will accept it, after the change it requires security level <= 1. When talking about SHA1 here, it's really about something RSA+SHA1, as in an RSA signature over a SHA1 hash. > Would the client need a lower protocol (TLSv1.0) then it would fail, too. > In these two cases the server administrator must have lowered the > security level to 1 (for the announced low sig-alg) and/or allow TLSv1 > in order for the client to connect. (The same for the other way around). SHA1 can be used for various things in the protocol. Other uses of SHA1 where already properly rejected, it just allowed SHA1 as signature algorithm. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On 2022-03-22 21:47:52 [+0100], Kurt Roeckx wrote: > On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > > OpenSSL signature algorithm check tightening > > = > > > > The OpenSSL update included in this point release includes a change to > > ensure that the requested signature algorithm is supported by the > > active security level. > > > > Although this will not affect most use-cases, it could lead to error > > messages being generated if a non-supported algorithm is requested - > > for example, use of SHA1 with the default security level of 2. In such > > cases, the security level will need to be explicitly lowered when > > invoking OpenSSL, using an option such as > > > > -cipher "ALL:@SECLEVEL=1" > > " > > So reading it again, I think the "when invoking OpenSSL" is confusing. > Not only the openssl binary is affected, but also all clients and > server applications making use of the library are. Some applications > might have a way to set the cipher in their own configuration file, > others might need to change the defaults in /etc/ssl/openssl.cfg s/openssl.cfg/openssl.cnf Kurt correct me if I'm wrong: This only affects clients which were using TLS1.2 while connecting to the server and did not send a sig-alg string which let the server fallback to the default (sha1) which was not checked vs security level. Would the client have sent sha1 as the sig-cipher then it would fail in the version d, too. Would the client need a lower protocol (TLSv1.0) then it would fail, too. In these two cases the server administrator must have lowered the security level to 1 (for the announced low sig-alg) and/or allow TLSv1 in order for the client to connect. (The same for the other way around). I don't know which clients/server don't send sig-alg version. The test in gnutls explicitly used TLSv1.0. The server check from ssllabs does not expose server's sig-alg that was used during the handshake. Someone complained about it: https://github.com/ssllabs/ssllabs-scan/issues/465 > > Kurt Sebastian
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > OpenSSL signature algorithm check tightening > = > > The OpenSSL update included in this point release includes a change to > ensure that the requested signature algorithm is supported by the > active security level. > > Although this will not affect most use-cases, it could lead to error > messages being generated if a non-supported algorithm is requested - > for example, use of SHA1 with the default security level of 2. In such > cases, the security level will need to be explicitly lowered when > invoking OpenSSL, using an option such as > > -cipher "ALL:@SECLEVEL=1" > " So reading it again, I think the "when invoking OpenSSL" is confusing. Not only the openssl binary is affected, but also all clients and server applications making use of the library are. Some applications might have a way to set the cipher in their own configuration file, others might need to change the defaults in /etc/ssl/openssl.cfg Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > Is the note below accurate? Yes. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, 2022-03-22 at 21:01 +0100, Kurt Roeckx wrote:
> On Tue, Mar 22, 2022 at 07:37:00PM +, Adam D. Barratt wrote:
> > On Mon, 2022-03-21 at 00:12 +0100, Sebastian Andrzej Siewior wrote:
> > > The change in openssl is commit
> > >cc7c6eb8135b ("Check that the default signature type is
> > > allowed")
> > >
> > > Before the commit in question it connects as:
> > > - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)
> > >
> > > after that, the server throws:
> > > 140490373015360:error:14201044:SSL
> > > routines:tls_choose_sigalg:internal error:../ssl/t1_lib.c:2880:
> > >
> > > and it appears that the security level in openssl forbids SHA1
> > > here.
> > > The argument on the s_server side
> > >-sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256
> > >
> > > doesn't help here but
> > >-cipher "ALL:@SECLEVEL=1"
> > >
> > > does.
> > >
> >
> > If we wanted to add a note to the release announcement in case
> > users
> > face similar issue with other software, is
> > "tls_choose:sigalg:internal
> > error" a reliable signal of this situation occurring? Should the
> > recommended solution be to lower the security level, or might
> > specifying -sigalgs work on its own in some scenarios?
>
> So to clarify things. The problem is that SHA1 was allowed as
> signature
> algorithm while the security level should not have allowed it. If the
> peer does not support SHA256, the security level needs to be lowered
> so that SHA1 is allowed again.
Thanks.
Is the note below accurate? I'm not entirely happy with the title, but
it's the best I could come up with currently.
"
OpenSSL signature algorithm check tightening
=
The OpenSSL update included in this point release includes a change to
ensure that the requested signature algorithm is supported by the
active security level.
Although this will not affect most use-cases, it could lead to error
messages being generated if a non-supported algorithm is requested -
for example, use of SHA1 with the default security level of 2. In such
cases, the security level will need to be explicitly lowered when
invoking OpenSSL, using an option such as
-cipher "ALL:@SECLEVEL=1"
"
Regards,
Adam
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 07:37:00PM +, Adam D. Barratt wrote:
> On Mon, 2022-03-21 at 00:12 +0100, Sebastian Andrzej Siewior wrote:
> > The change in openssl is commit
> >cc7c6eb8135b ("Check that the default signature type is allowed")
> >
> > Before the commit in question it connects as:
> > - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)
> >
> > after that, the server throws:
> > 140490373015360:error:14201044:SSL
> > routines:tls_choose_sigalg:internal error:../ssl/t1_lib.c:2880:
> >
> > and it appears that the security level in openssl forbids SHA1 here.
> > The argument on the s_server side
> > -sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256
> >
> > doesn't help here but
> > -cipher "ALL:@SECLEVEL=1"
> >
> > does.
> >
>
> If we wanted to add a note to the release announcement in case users
> face similar issue with other software, is "tls_choose:sigalg:internal
> error" a reliable signal of this situation occurring? Should the
> recommended solution be to lower the security level, or might
> specifying -sigalgs work on its own in some scenarios?
So to clarify things. The problem is that SHA1 was allowed as signature
algorithm while the security level should not have allowed it. If the
peer does not support SHA256, the security level needs to be lowered
so that SHA1 is allowed again.
Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Mon, 2022-03-21 at 00:12 +0100, Sebastian Andrzej Siewior wrote:
> The change in openssl is commit
>cc7c6eb8135b ("Check that the default signature type is allowed")
>
> Before the commit in question it connects as:
> - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)
>
> after that, the server throws:
> 140490373015360:error:14201044:SSL
> routines:tls_choose_sigalg:internal error:../ssl/t1_lib.c:2880:
>
> and it appears that the security level in openssl forbids SHA1 here.
> The argument on the s_server side
>-sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256
>
> doesn't help here but
>-cipher "ALL:@SECLEVEL=1"
>
> does.
>
If we wanted to add a note to the release announcement in case users
face similar issue with other software, is "tls_choose:sigalg:internal
error" a reliable signal of this situation occurring? Should the
recommended solution be to lower the security level, or might
specifying -sigalgs work on its own in some scenarios?
Regards,
Adam
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On 2022-03-21 22:11:17 [+0100], Julien Cristau wrote: > Hi, Hi, > Specifically, we were hoping to better understand the risk of openssl > changes breaking existing setups. It's possible the issues with gnutls > and libnet-ssleay-perl tests were narrowly scoped enough that that risk > is low, but we're just not sure right now. Other input would be > welcome. No matter how it turns out, I'm fine with it. It would be nice in in case of postponing it, to keep in pu for the following point release so that it receives more test coverage. [Unless of course if this means that the pu is canceled.] > Thanks, > Julien Sebastian
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
Hi, Specifically, we were hoping to better understand the risk of openssl changes breaking existing setups. It's possible the issues with gnutls and libnet-ssleay-perl tests were narrowly scoped enough that that risk is low, but we're just not sure right now. Other input would be welcome. Thanks, Julien On Mon, Mar 21, 2022 at 08:23:20PM +, Adam D. Barratt wrote: > On Sun, 2022-03-20 at 22:00 +0100, Paul Gevers wrote: > > Dear Sebastian, Kurt, > > > > On 19-03-2022 12:33, Adam D Barratt wrote: > > > Upload details > > > == > > > > > > Package: openssl > > > Version: 1.1.1n-0+deb10u1 > > > > > > Explanation: new upstream release > > > > We're seeing a regression in buster in the autopkgtest of gnutls28 > > with > > the new version of openssl on all tested architectures. Can you > > please > > have a look and advise? (bullseye doesn't seem to have the test > > anymore, > > hence it doesn't fail). > > Thanks to both Kurt and Sebastian for quickly identifying the issue > here, and to Adrian Bunk for the libnet-ssleay-perl fix. > > There's been some continued discussion today as to whether we feel > comfortable releasing the update with the 10.12 point release when we > have only been finding such issues during the week leading up to the > point release. > > I fully appreciate that the large delays in getting to this point were > mostly on our part, and that postponing the release until 10.13 would > likely be frustrating, but the worry is that we don't have a good view > of the changes that might be user-affecting in order to be comfortable > with potential behaviour changes landing in oldstable - for example, > the libnet-ssleay-perl issue appears to be related to 1024-bit keys no > longer being accepted by default; while in general this is obviously a > desirable behaviour, it is nonetheless a change in the behaviour > compared to the current package in buster. > > The situation is also slightly complicated by the fact the debian- > installer uses OpenSSL internally, so we are also under internal time > pressure to reach a conclusion, in order to be able to proceed with the > installer build for the point release, rather than being able to leave > the decision until the end of the week. > > Thank you for bearing with us. > > Regards, > > Adam >
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
How do I stop these emails On Mon, Mar 21, 2022, 3:27 PM Adam D. Barratt wrote: > On Sun, 2022-03-20 at 22:00 +0100, Paul Gevers wrote: > > Dear Sebastian, Kurt, > > > > On 19-03-2022 12:33, Adam D Barratt wrote: > > > Upload details > > > == > > > > > > Package: openssl > > > Version: 1.1.1n-0+deb10u1 > > > > > > Explanation: new upstream release > > > > We're seeing a regression in buster in the autopkgtest of gnutls28 > > with > > the new version of openssl on all tested architectures. Can you > > please > > have a look and advise? (bullseye doesn't seem to have the test > > anymore, > > hence it doesn't fail). > > Thanks to both Kurt and Sebastian for quickly identifying the issue > here, and to Adrian Bunk for the libnet-ssleay-perl fix. > > There's been some continued discussion today as to whether we feel > comfortable releasing the update with the 10.12 point release when we > have only been finding such issues during the week leading up to the > point release. > > I fully appreciate that the large delays in getting to this point were > mostly on our part, and that postponing the release until 10.13 would > likely be frustrating, but the worry is that we don't have a good view > of the changes that might be user-affecting in order to be comfortable > with potential behaviour changes landing in oldstable - for example, > the libnet-ssleay-perl issue appears to be related to 1024-bit keys no > longer being accepted by default; while in general this is obviously a > desirable behaviour, it is nonetheless a change in the behaviour > compared to the current package in buster. > > The situation is also slightly complicated by the fact the debian- > installer uses OpenSSL internally, so we are also under internal time > pressure to reach a conclusion, in order to be able to proceed with the > installer build for the point release, rather than being able to leave > the decision until the end of the week. > > Thank you for bearing with us. > > Regards, > > Adam > >
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Sun, 2022-03-20 at 22:00 +0100, Paul Gevers wrote: > Dear Sebastian, Kurt, > > On 19-03-2022 12:33, Adam D Barratt wrote: > > Upload details > > == > > > > Package: openssl > > Version: 1.1.1n-0+deb10u1 > > > > Explanation: new upstream release > > We're seeing a regression in buster in the autopkgtest of gnutls28 > with > the new version of openssl on all tested architectures. Can you > please > have a look and advise? (bullseye doesn't seem to have the test > anymore, > hence it doesn't fail). Thanks to both Kurt and Sebastian for quickly identifying the issue here, and to Adrian Bunk for the libnet-ssleay-perl fix. There's been some continued discussion today as to whether we feel comfortable releasing the update with the 10.12 point release when we have only been finding such issues during the week leading up to the point release. I fully appreciate that the large delays in getting to this point were mostly on our part, and that postponing the release until 10.13 would likely be frustrating, but the worry is that we don't have a good view of the changes that might be user-affecting in order to be comfortable with potential behaviour changes landing in oldstable - for example, the libnet-ssleay-perl issue appears to be related to 1024-bit keys no longer being accepted by default; while in general this is obviously a desirable behaviour, it is nonetheless a change in the behaviour compared to the current package in buster. The situation is also slightly complicated by the fact the debian- installer uses OpenSSL internally, so we are also under internal time pressure to reach a conclusion, in order to be able to proceed with the installer build for the point release, rather than being able to leave the decision until the end of the week. Thank you for bearing with us. Regards, Adam
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
X-Debbugs-Cc: gnutl...@packages.debian.org, Kurt Roeckx , Paul Gevers , Sebastian Andrzej Siewior On 2022-03-21 Sebastian Andrzej Siewior wrote: > On 2022-03-21 00:12:11 [+0100], To Kurt Roeckx wrote: > > doesn't help here but > > -cipher "ALL:@SECLEVEL=1" > > does. > Only debci is affected. The package builds because this testsuite is not > part of the build process. > I prepared a NMU against Buster for gnutls. I can open later today a > buster-pu and do the upload unless someone objects or gnutls folks have > something in their queue. > Please let me know. Hello Sebastian, thanks for taking care, feel free to NMU. cu Andreas PS: Style nitpick: As can be see from "ls debian/patches/" I think it is a very good idea to use patch filenames with obvious sorting. signature.asc Description: PGP signature
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On 2022-03-21 00:12:11 [+0100], To Kurt Roeckx wrote:
> doesn't help here but
>-cipher "ALL:@SECLEVEL=1"
>
> does.
Only debci is affected. The package builds because this testsuite is not
part of the build process.
I prepared a NMU against Buster for gnutls. I can open later today a
buster-pu and do the upload unless someone objects or gnutls folks have
something in their queue.
Please let me know.
> > Kurt
Sebastian
diff -Nru gnutls28-3.6.7/debian/changelog gnutls28-3.6.7/debian/changelog
--- gnutls28-3.6.7/debian/changelog 2021-05-14 13:33:38.0 +0200
+++ gnutls28-3.6.7/debian/changelog 2022-03-21 14:52:01.0 +0100
@@ -1,3 +1,11 @@
+gnutls28 (3.6.7-4+deb10u7.1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport testcompat-openssl-improve-testing-against-secured-O.patch to
+pass testsuite with openssl 1.1.1e.
+
+ -- Sebastian Andrzej Siewior Mon, 21 Mar 2022 14:52:01 +0100
+
gnutls28 (3.6.7-4+deb10u7) buster; urgency=medium
* 46_handshake-reject-no_renegotiation-alert-if-handshake.patch pulled from
diff -Nru gnutls28-3.6.7/debian/patches/series gnutls28-3.6.7/debian/patches/series
--- gnutls28-3.6.7/debian/patches/series 2021-05-11 18:13:03.0 +0200
+++ gnutls28-3.6.7/debian/patches/series 2022-03-21 08:35:24.0 +0100
@@ -23,3 +23,4 @@
47_rel3.6.16_04-pre_shared_key-avoid-use-after-free-around-realloc.patch
47_rel3.6.16_05-_gnutls_buffer_resize-account-for-unused-area-if-AGG.patch
47_rel3.6.16_06-str-suppress-Wunused-function-if-AGGRESSIVE_REALLOC-.patch
+testcompat-openssl-improve-testing-against-secured-O.patch
diff -Nru gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch
--- gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch 1970-01-01 01:00:00.0 +0100
+++ gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch 2022-03-21 08:37:07.0 +0100
@@ -0,0 +1,274 @@
+From: Dimitri John Ledkov
+Date: Mon, 21 Mar 2022 07:44:25 +0100
+Subject: [PATCH] testcompat-openssl: improve testing against secured OpenSSL
+
+[bigeasy: This is backport of commit fbd3e261513d641dce6bd1b2c368ce25e79dc094 ]
+
+In Debian, and soon Ubuntu, OpenSSL is compiled with SECLEVEL=2 and
+requiring minimum TLSv1.2. However, smaller hashes/keys/versions are
+allowed if one enables SECLEVEL=1. Do so when testing pre v1.2 algos,
+and thus enabling testing more compatability combinations.
+
+Signed-off-by: Dimitri John Ledkov
+Signed-off-by: Sebastian Andrzej Siewior
+---
+ tests/suite/testcompat-main-openssl | 67 +
+ 1 file changed, 30 insertions(+), 37 deletions(-)
+
+diff --git a/tests/suite/testcompat-main-openssl b/tests/suite/testcompat-main-openssl
+index d2708bfa8c710..2ea762faebaca 100755
+--- a/tests/suite/testcompat-main-openssl
b/tests/suite/testcompat-main-openssl
+@@ -74,7 +74,6 @@ NO_TLS1_2=$?
+
+ test $NO_TLS1_2 != 0 && echo "Disabling interop tests for TLS 1.2"
+
+-
+ ${SERV} version|grep -e '[1-9]\.[1-9]\.[0-9]' >/dev/null 2>&1
+ if test $? = 0;then
+ NO_DH_PARAMS=0
+@@ -82,18 +81,8 @@ else
+ NO_DH_PARAMS=1
+ fi
+
+-# Do not use DSS or curves <=256 bits in 1.1.1+ because these
+-# are not accepted by openssl on debian.
+-${SERV} version|grep -e '[1-9]\.[1-9]\.[1-9]' >/dev/null 2>&1
+-if test $? = 0;then
+- NO_DSS=1
+- FIPS_CURVES=1
+-else
+- ${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1
+- NO_DSS=$?
+-fi
+-
+-test $FIPS_CURVES = 1 && echo "Running with FIPS140-2 enabled curves enabled"
++${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1
++NO_DSS=$?
+
+ if test $NO_DSS != 0;then
+ echo "Disabling interop tests for DSS ciphersuites"
+@@ -121,6 +110,10 @@ NO_NULL=$?
+
+ test $NO_NULL != 0 && echo "Disabling interop tests for NULL ciphersuites"
+
++${SERV} ecparam -list_curves 2>&1|grep -e prime192v1 >/dev/null 2>&1
++NO_PRIME192v1=$?
++
++test $NO_PRIME192v1 != 0 && echo "Disabling interop tests for prime192v1 ecparam"
+
+ if test "${NO_DH_PARAMS}" = 0;then
+ OPENSSL_DH_PARAMS_OPT=""
+@@ -218,7 +211,7 @@ run_client_suite() {
+
+ #-cipher RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA
+ eval "${GETPORT}"
+- launch_bare_server $$ s_server -cipher "ALL" -quiet -www -accept "${PORT}" -keyform pem -certform pem -tls1 ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" ${DSA_PARAMS} -Verify 1 -CAfile "${CA_CERT}" >/dev/null
++ launch_bare_server $$ s_server -cipher "ALL:@SECLEVEL=1" -quiet -www -accept "${PORT}" -keyform pem -certform pem -tls1 ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" ${DSA_PARAMS} -Verify 1 -CAfile "${CA_CERT}" >/dev/null
+ PID=$!
+ wait_server ${PID}
+
+@@ -267,9 +260,9 @@ run_client_suite() {
+ kill ${PID}
+ wait
+
+- if test "${FIPS_CURVES}" != 1; then
++ if test "${FIPS_CURVES}" != 1 && test
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Mon, Mar 21, 2022 at 12:12:11AM +0100, Sebastian Andrzej Siewior wrote:
>
> The change in openssl is commit
>cc7c6eb8135b ("Check that the default signature type is allowed")
So that's:
commit cc7c6eb8135be665d0acc176a5963e1eaf52e4e2
Author: Kurt Roeckx
Date: Thu Jan 2 22:53:32 2020 +0100
Check that the default signature type is allowed
TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the
others. TLS 1.2 sends a list of supported ciphers, but allows not sending
it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory.
When we didn't receive a list from the client, we always used the
defaults without checking that they are allowed by the configuration.
Reviewed-by: Paul Dale
GH: #10784
(cherry picked from commit b0031e5dc2c8c99a6c04bc7625aa00d3d20a59a5)
Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On 2022-03-20 23:15:57 [+0100], Kurt Roeckx wrote:
> > https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz
> >
> > Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> > %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> > *** Fatal error: A TLS fatal alert has been received.
> > Failure: Failed
> > *** Fatal error: A TLS fatal alert has been received.
> > %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> > Failure: Failed
> > *** Fatal error: A TLS fatal alert has been received.
> > Failure: Failed
> > FAIL [11]../../tests/suite/testcompat-main-openssl
> >
> > Which, according to me, is this check:
> > https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307
>
> That test still seems to exist, but is just moved to a different file:
> https://github.com/gnutls/gnutls/blob/master/tests/suite/testcompat-openssl-cli-common.sh#L255
>
> My understanding is that gnutls now passes the correct list of signature
> algorithms to use to OpenSSL's s_client to be able to do that test, and
> that this is probably fixed by:
> https://github.com/gnutls/gnutls/commit/23958322865a8a77c2f924f569484e5fd150a24b
> (and
> https://github.com/gnutls/gnutls/commit/8259a1dc8503ad760c0887eb95278f9957a00667)
>
> I'm trying to remember what was changed and why, but I can't
> find/remember it.
The change in openssl is commit
cc7c6eb8135b ("Check that the default signature type is allowed")
The server is
openssl s_server -quiet -www -accept 57687 -keyform pem -certform pem
-tls1 \
-key tests/certs/ecc384.pem -cert tests/certs/cert-ecc384.pem -Verify
1 \
-named_curve secp384r1 -CAfile tests/certs/ca-cert-ecc.pem
The client is
/usr/bin/gnutls-cli -p 57687 127.0.0.1 \
--priority
NONE:+CIPHER-ALL:+SIGN-ALL:+COMP-NULL:+MAC-ALL:+VERS-TLS1.0:+ECDHE-ECDSA:+CURVE-ALL
\
--insecure --x509certfile tests/certs/cert-ecc384.pem --x509keyfile
tests/certs/ecc384.pem
Before the commit in question it connects as:
- Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)
after that, the server throws:
140490373015360:error:14201044:SSL routines:tls_choose_sigalg:internal
error:../ssl/t1_lib.c:2880:
and it appears that the security level in openssl forbids SHA1 here.
The argument on the s_server side
-sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256
doesn't help here but
-cipher "ALL:@SECLEVEL=1"
does.
> Kurt
Sebastian
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Sun, Mar 20, 2022 at 10:00:15PM +0100, Paul Gevers wrote: > Dear Sebastian, Kurt, > > On 19-03-2022 12:33, Adam D Barratt wrote: > > Upload details > > == > > > > Package: openssl > > Version: 1.1.1n-0+deb10u1 > > > > Explanation: new upstream release > > We're seeing a regression in buster in the autopkgtest of gnutls28 with the > new version of openssl on all tested architectures. Can you please have a > look and advise? (bullseye doesn't seem to have the test anymore, hence it > doesn't fail). > > https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz > > Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > *** Fatal error: A TLS fatal alert has been received. > Failure: Failed > *** Fatal error: A TLS fatal alert has been received. > %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > Failure: Failed > *** Fatal error: A TLS fatal alert has been received. > Failure: Failed > FAIL [11]../../tests/suite/testcompat-main-openssl > > Which, according to me, is this check: > https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307 That test still seems to exist, but is just moved to a different file: https://github.com/gnutls/gnutls/blob/master/tests/suite/testcompat-openssl-cli-common.sh#L255 My understanding is that gnutls now passes the correct list of signature algorithms to use to OpenSSL's s_client to be able to do that test, and that this is probably fixed by: https://github.com/gnutls/gnutls/commit/23958322865a8a77c2f924f569484e5fd150a24b (and https://github.com/gnutls/gnutls/commit/8259a1dc8503ad760c0887eb95278f9957a00667) I'm trying to remember what was changed and why, but I can't find/remember it. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
Dear Sebastian, Kurt, On 19-03-2022 12:33, Adam D Barratt wrote: Upload details == Package: openssl Version: 1.1.1n-0+deb10u1 Explanation: new upstream release We're seeing a regression in buster in the autopkgtest of gnutls28 with the new version of openssl on all tested architectures. Can you please have a look and advise? (bullseye doesn't seem to have the test anymore, hence it doesn't fail). https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... *** Fatal error: A TLS fatal alert has been received. Failure: Failed *** Fatal error: A TLS fatal alert has been received. %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... Failure: Failed *** Fatal error: A TLS fatal alert has been received. Failure: Failed FAIL [11]../../tests/suite/testcompat-main-openssl Which, according to me, is this check: https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307 Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
package release.debian.org tags 959469 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: openssl Version: 1.1.1n-0+deb10u1 Explanation: new upstream release
