Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#929907: libgnutls30: Connections to older GnUTLS servers break
34 views
Skip to first unread message
Dominik George
Jun 2, 2019, 7:00:02 PM6/2/19
to
Package: libgnutls30
Version: 3.6.7-3
Severity: grave
Justification: renders package unusable
The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
client library) when connecting to a server with the previous 3.6.6-2
version. I am afraid it breaks more than that. GnuTLS-secured connections
are just closed with no visible reason.
Seen on more than 12 systems, then went to a system that had not got the
update yet. An ldapsearch works with 3.6.6-2, and fails after updating to
3.6.7-3 with the connection just being closed after reading some data from
the LDAP server setill on 3.6.6-2. Upgrading GnuTLS to 3.6.7-3 on the
server made the problem go away.
I am setting this critical as I cannot imagine it is expected that GnuTLS
clients require the server to be the exact same version.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libgnutls30 depends on:
ii libc6 2.28-10
ii libgmp10 2:6.1.2+dfsg-4
ii libhogweed4 3.4.1-1
ii libidn2-0 2.0.5-1
ii libnettle6 3.4.1-1
ii libp11-kit0 0.23.15-2
ii libtasn1-6 4.13-3
ii libunistring2 0.9.10-1
libgnutls30 recommends no packages.
Versions of packages libgnutls30 suggests:
pn gnutls-bin <none>
-- no debconf information
Version: 3.6.7-3
Severity: grave
Justification: renders package unusable
The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
client library) when connecting to a server with the previous 3.6.6-2
version. I am afraid it breaks more than that. GnuTLS-secured connections
are just closed with no visible reason.
Seen on more than 12 systems, then went to a system that had not got the
update yet. An ldapsearch works with 3.6.6-2, and fails after updating to
3.6.7-3 with the connection just being closed after reading some data from
the LDAP server setill on 3.6.6-2. Upgrading GnuTLS to 3.6.7-3 on the
server made the problem go away.
I am setting this critical as I cannot imagine it is expected that GnuTLS
clients require the server to be the exact same version.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libgnutls30 depends on:
ii libc6 2.28-10
ii libgmp10 2:6.1.2+dfsg-4
ii libhogweed4 3.4.1-1
ii libidn2-0 2.0.5-1
ii libnettle6 3.4.1-1
ii libp11-kit0 0.23.15-2
ii libtasn1-6 4.13-3
ii libunistring2 0.9.10-1
libgnutls30 recommends no packages.
Versions of packages libgnutls30 suggests:
pn gnutls-bin <none>
-- no debconf information
Andreas Metzler
Jun 3, 2019, 2:00:02 PM6/3/19
to
Control: severity -1 serious
On 2019-06-03 Dominik George <dominik...@teckids.org> wrote:
> Package: libgnutls30
> Version: 3.6.7-3
> Severity: grave
> Justification: renders package unusable
> The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
> client library) when connecting to a server with the previous 3.6.6-2
> version. I am afraid it breaks more than that. GnuTLS-secured connections
> are just closed with no visible reason.
> Seen on more than 12 systems, then went to a system that had not got the
> update yet. An ldapsearch works with 3.6.6-2, and fails after updating to
> 3.6.7-3 with the connection just being closed after reading some data from
> the LDAP server setill on 3.6.6-2. Upgrading GnuTLS to 3.6.7-3 on the
> server made the problem go away.
Hello,
Is this reproducile with gnutls-cli or is the respective server
publically accessible?
> I am setting this critical as I cannot imagine it is expected that GnuTLS
> clients require the server to be the exact same version.
Downgrading to serious for the time being, critical means something
different. [1]
cu Andreas
[1] https://www.debian.org/Bugs/Developer.en.html#severities
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
On 2019-06-03 Dominik George <dominik...@teckids.org> wrote:
> Package: libgnutls30
> Version: 3.6.7-3
> Severity: grave
> Justification: renders package unusable
> The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
> client library) when connecting to a server with the previous 3.6.6-2
> version. I am afraid it breaks more than that. GnuTLS-secured connections
> are just closed with no visible reason.
> Seen on more than 12 systems, then went to a system that had not got the
> update yet. An ldapsearch works with 3.6.6-2, and fails after updating to
> 3.6.7-3 with the connection just being closed after reading some data from
> the LDAP server setill on 3.6.6-2. Upgrading GnuTLS to 3.6.7-3 on the
> server made the problem go away.
Is this reproducile with gnutls-cli or is the respective server
publically accessible?
> I am setting this critical as I cannot imagine it is expected that GnuTLS
> clients require the server to be the exact same version.
different. [1]
cu Andreas
[1] https://www.debian.org/Bugs/Developer.en.html#severities
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Andreas Metzler
Jun 4, 2019, 2:40:03 PM6/4/19
to
On 2019-06-03 Dominik George <nature...@debian.org> wrote:
> Hi,
>> Is this reproducile with gnutls-cli or is the respective server
>> publically accessible?
> It is reproducible.
> 1. Create a buster chroot for the server, or something
> similar.
> 2. Install gnutls-bin 3.6.6-3 and ssl-cert.
> 3. Start something like:
> gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem
> 4. Create a buster chroot for the client.
> 5. Install gnutls-bin 3.6.7-2 and pwgen (I used that to generate
> random blobs of printable data).
> 6. Try:
> pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost
> From a size of 16383 bytes onwards, I get:
> |<1>| Received packet with illegal length: 16385
> |<1>| Discarded message[1] due to invalid decryption
> *** Fatal error: A TLS record packet with invalid length was received.
> *** Server has terminated the connection abnormally.
Hello,
with server at 3.6.6 (and .4 and .5) , client version 3.6.7 breaks, while
both earlier versions and 3.6.8 connect successfully.
server 3.6.8/3.6.7 does not break with client 3.6.7.
Will try a bisect to check why .8 works, but might not have time before
weekend.
cu Andreas
> Hi,
>> Is this reproducile with gnutls-cli or is the respective server
>> publically accessible?
> 1. Create a buster chroot for the server, or something
> similar.
> 2. Install gnutls-bin 3.6.6-3 and ssl-cert.
> 3. Start something like:
> gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem
> 4. Create a buster chroot for the client.
> 5. Install gnutls-bin 3.6.7-2 and pwgen (I used that to generate
> random blobs of printable data).
> 6. Try:
> pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost
> From a size of 16383 bytes onwards, I get:
> |<1>| Received packet with illegal length: 16385
> |<1>| Discarded message[1] due to invalid decryption
> *** Fatal error: A TLS record packet with invalid length was received.
> *** Server has terminated the connection abnormally.
Hello,
with server at 3.6.6 (and .4 and .5) , client version 3.6.7 breaks, while
both earlier versions and 3.6.8 connect successfully.
server 3.6.8/3.6.7 does not break with client 3.6.7.
Will try a bisect to check why .8 works, but might not have time before
weekend.
cu Andreas
Ross Boylan
Jun 15, 2019, 3:20:02 PM6/15/19
to
I've been following this bug because it came up as an issue for a
security upgrade to libgnutls-openssl27 in buster. I'm still seeing
3.6.7-3 as the upgrade target.
Will an openssl27 variant be coming? Or perhaps this problem never
applied to -openssl27 and apt-listbugs just got over-eager? I came
here for ..ssl27; the original report is for ..ssl28; the package the
bug is filed against is apparently ..ssl30. The versioning is a bit
mysterious to me :)
Ross
security upgrade to libgnutls-openssl27 in buster. I'm still seeing
3.6.7-3 as the upgrade target.
Will an openssl27 variant be coming? Or perhaps this problem never
applied to -openssl27 and apt-listbugs just got over-eager? I came
here for ..ssl27; the original report is for ..ssl28; the package the
bug is filed against is apparently ..ssl30. The versioning is a bit
mysterious to me :)
Ross
Andreas Metzler
Jun 16, 2019, 12:50:03 AM6/16/19
to
On 2019-06-15 Ross Boylan <rossb...@stanfordalumni.org> wrote:
> I've been following this bug because it came up as an issue for a
> security upgrade to libgnutls-openssl27 in buster. I'm still seeing
> 3.6.7-3 as the upgrade target.
Hello Ross,
> I've been following this bug because it came up as an issue for a
> security upgrade to libgnutls-openssl27 in buster. I'm still seeing
> 3.6.7-3 as the upgrade target.
I do not know whether this bug applies to packages using GnuTLS via the
openssl wrapper library. There aren't a lot of rdepends, and the wrapper
is thin and does not expose the complete functionality.
> Will an openssl27 variant be coming? Or perhaps this problem never
> applied to -openssl27 and apt-listbugs just got over-eager?
the underlying libgnutls is fixed. There is no separate step involved,
it is just a wrapper.
> I came
> here for ..ssl27; the original report is for ..ssl28;
> the package the
> bug is filed against is apparently ..ssl30. The versioning is a bit
> mysterious to me :)
soname. ;-)
Anyway, obviously I do not want to ship buster with this bug, it is
fixed in sid and there is an unblock request for buster.
Ross Boylan
Jun 16, 2019, 4:00:03 PM6/16/19
to
See below.
On Sat, Jun 15, 2019 at 9:42 PM Andreas Metzler <amet...@bebt.de> wrote:
>
> On 2019-06-15 Ross Boylan <rossb...@stanfordalumni.org> wrote:
> > I've been following this bug because it came up as an issue for a
> > security upgrade to libgnutls-openssl27 in buster. I'm still seeing
> > 3.6.7-3 as the upgrade target.
>
> Hello Ross,
>
> I do not know whether this bug applies to packages using GnuTLS via the
> openssl wrapper library. There aren't a lot of rdepends, and the wrapper
> is thin and does not expose the complete functionality.
>
> > Will an openssl27 variant be coming? Or perhaps this problem never
> > applied to -openssl27 and apt-listbugs just got over-eager?
>
> If the bug applies to libgnutls-openssl27 it will be fixed exactly when
> the underlying libgnutls is fixed. There is no separate step involved,
> it is just a wrapper.
>
> > I came
> > here for ..ssl27; the original report is for ..ssl28;
>
> Where?
I was going to upgrade libgnutls-openssl27 and apt-listbugs listed
this bug as a critical one.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libgnutls-openssl27;dist=unstable
identifies the source package as gnutls28 (sorry--no ssl in there),
and apt-listbugs must have been reporting all bugs in the source
package.
The original bug report identifies libgnutls30 as the (presumably
binary) package in which the bug is found.
>
> > the package the
> > bug is filed against is apparently ..ssl30. The versioning is a bit
> > mysterious to me :)
>
> It is pretty mch straightforward, when the ABI breaks we bump the
> soname. ;-)
I meant it was mysterious why all these different ABI versions are
ending up together in the bug system. I think I've figured that out:
they all are from the same source package.
The libgnutls-openssl27 I would install now depends on libgnutls30
version 3.6.7-3.
Currently installed libgnutls30 is 3.6.6-2.
So it sounds as if I should wait til gnutls30 3.6.7-4 appears before
doing the upgrade. Or maybe the security problem is serious enough to
warrant an upgrade now? TLS is likely to matter to me only as a
client.
Ross
On Sat, Jun 15, 2019 at 9:42 PM Andreas Metzler <amet...@bebt.de> wrote:
>
> On 2019-06-15 Ross Boylan <rossb...@stanfordalumni.org> wrote:
> > I've been following this bug because it came up as an issue for a
> > security upgrade to libgnutls-openssl27 in buster. I'm still seeing
> > 3.6.7-3 as the upgrade target.
>
> Hello Ross,
>
> I do not know whether this bug applies to packages using GnuTLS via the
> openssl wrapper library. There aren't a lot of rdepends, and the wrapper
> is thin and does not expose the complete functionality.
>
> > Will an openssl27 variant be coming? Or perhaps this problem never
> > applied to -openssl27 and apt-listbugs just got over-eager?
>
> If the bug applies to libgnutls-openssl27 it will be fixed exactly when
> the underlying libgnutls is fixed. There is no separate step involved,
> it is just a wrapper.
>
> > I came
> > here for ..ssl27; the original report is for ..ssl28;
>
> Where?
this bug as a critical one.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libgnutls-openssl27;dist=unstable
identifies the source package as gnutls28 (sorry--no ssl in there),
and apt-listbugs must have been reporting all bugs in the source
package.
The original bug report identifies libgnutls30 as the (presumably
binary) package in which the bug is found.
>
> > the package the
> > bug is filed against is apparently ..ssl30. The versioning is a bit
> > mysterious to me :)
>
> It is pretty mch straightforward, when the ABI breaks we bump the
> soname. ;-)
ending up together in the bug system. I think I've figured that out:
they all are from the same source package.
The libgnutls-openssl27 I would install now depends on libgnutls30
version 3.6.7-3.
Currently installed libgnutls30 is 3.6.6-2.
So it sounds as if I should wait til gnutls30 3.6.7-4 appears before
doing the upgrade. Or maybe the security problem is serious enough to
warrant an upgrade now? TLS is likely to matter to me only as a
client.
Ross
Andreas Metzler
Jun 17, 2019, 2:00:07 PM6/17/19
to
On 2019-06-16 Ross Boylan <rossb...@stanfordalumni.org> wrote:
[...]
this choice a noop, 3.6.7-4 is in testing now.
cu Andreas
[...]
> So it sounds as if I should wait til gnutls30 3.6.7-4 appears before
> doing the upgrade. Or maybe the security problem is serious enough to
> warrant an upgrade now? TLS is likely to matter to me only as a
> client.
Hello Ross,
> doing the upgrade. Or maybe the security problem is serious enough to
> warrant an upgrade now? TLS is likely to matter to me only as a
> client.
this choice a noop, 3.6.7-4 is in testing now.
cu Andreas
0 new messages