Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Adam D. Barratt]

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

[Sebastian Andrzej Siewior]

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

[Adam D. Barratt]

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

[Sebastian Andrzej Siewior]

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

[Adam D. Barratt]

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

[Kurt Roeckx]

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

[Sebastian Andrzej Siewior]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Adam D. Barratt]

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

[Kurt Roeckx]

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

[Adam D. Barratt]

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

[Sebastian Andrzej Siewior]

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

[Julien Cristau]

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:

[Wesley Redondo]

I would like to stop receiving these emails

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Wesley Redondo]

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

[Adam D. Barratt]

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

[Andreas Metzler]

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

[Sebastian Andrzej Siewior]

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 "${NO_

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Kurt Roeckx]

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

[Sebastian Andrzej Siewior]

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

[Kurt Roeckx]

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

[Paul Gevers]

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

[Adam D Barratt]

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

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 Au

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, &pkey_sig_nid) == 0)
++pkey_sig_nid = EVP_PKEY_base_id(pkey);
+ if (OBJ_find_sigid_algs(OBJ_obj2nid(subject->cert_info.signature.algorithm),
+-NULL, &pkey_nid) == 0)
++NULL, &subj_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
++lB9z

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 itself

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

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

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 buster-pu: package openssl/1.1.1h-1
Bug #959469 [release.debian.org] buster-pu: package openssl/1.1.1g-1
Changed Bug title to 'buster-pu: package openssl/1.1.1h-1' from 'buster-pu: 
package openssl/1.1.1g-1'.

-- 
959469: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959469
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Re: 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