Package: libprotocol-http2-perl Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu mantic ubuntu-patch
Dear Maintainer, The package uses the hardcoded tlsv1 value in its test-suite. When OpenSSL has been built with security level 2 (or is set to level 2 at runtime), the TLSv1 protocol is rejected. This makes the libprotocol-http2-perl build / autopkgtest fail. There is an upstream bug report: https://github.com/vlet/p5-Protocol-HTTP2/issues/15 And a PR was opened usptream: https://github.com/vlet/p5-Protocol-HTTP2/pull/16 Debian is currently unaffected (I assume the security level is set to 1 at build-time) but in the future OpenSSL 3.1 will reject TLSv1 at security level 1. In Ubuntu, the attached patch was applied to achieve the following: * Do not hardcode the test-suite TLS version to tlsv1 - which is disabled by OpenSSL seclevel 2 on Ubuntu (LP: #2023586). Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers lunar-updates APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), (100, 'lunar-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
diff -Nru libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch --- libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch 1970-01-01 01:00:00.000000000 +0100 +++ libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch 2023-07-28 11:43:40.000000000 +0200 @@ -0,0 +1,32 @@ +Description: Remove hardcoded tlsv1 protocol version + The test-suite of libprotocol-http2-perl uses a hardcoded value of tlsv1 - + which is disabled in Ubuntu by means of OpenSSL seclevel. Specifying another + version like tlsv1_2 would work but it seems sensible to leave that up to the + system decide. +Author: Olivier Gayot <olivier.ga...@canonical.com> +Bug-Ubuntu: https://launchpad.net/bugs/2023586 +Forwarded: https://github.com/vlet/p5-Protocol-HTTP2/pull/16 +Last-Update: 2023-07-28 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: b/t/lib/PH2ClientServerTest.pm +=================================================================== +--- a/t/lib/PH2ClientServerTest.pm 2023-07-28 11:35:33.957861624 +0200 ++++ b/t/lib/PH2ClientServerTest.pm 2023-07-28 11:43:04.843734902 +0200 +@@ -43,7 +43,6 @@ + if ( !$h{upgrade} && ( $h{npn} || $h{alpn} ) ) { + eval { + $tls = AnyEvent::TLS->new( +- method => 'tlsv1', + cert_file => $tls_crt, + key_file => $tls_key, + ); +@@ -122,7 +121,7 @@ + } + elsif ( $h{npn} || $h{alpn} ) { + eval { +- $tls = AnyEvent::TLS->new( method => 'tlsv1', ); ++ $tls = AnyEvent::TLS->new(); + + if ( delete $h{npn} ) { + diff -Nru libprotocol-http2-perl-1.10/debian/patches/series libprotocol-http2-perl-1.10/debian/patches/series --- libprotocol-http2-perl-1.10/debian/patches/series 1970-01-01 01:00:00.000000000 +0100 +++ libprotocol-http2-perl-1.10/debian/patches/series 2023-07-28 11:43:11.000000000 +0200 @@ -0,0 +1 @@ +no-tlsv1.patch
