Control: tag -1 + unreproducible

On Sun, 28 Jan 2024 09:07:00 +0100, Christian Marillat wrote:

uscan from devscipts package fail to verify certificates afetr upgrading
to liblwp-protocol-https-perl 6.12-1

Thanks for your bug report.

,----
| uscan warn: In watchfile debian/watch, reading webpage
| https://qa.debian.org/watch/sf.php/pcre/ failed: 500 SSL upgrade failed: hostname verification failed
| uscan warn: In watchfile debian/watch, reading webpage
| https://qa.debian.org/watch/sf.php/mjpeg/ failed: 500 SSL upgrade failed: hostname verification failed
| uscan warn: In watchfile debian/watch, reading webpage
| https://gitlab.com/AOMediaCodec/SVT-AV1/-/tags failed: 500 SSL upgrade failed: SSL connect attempt failed error:0A000410:SSL routines::sslv3 alert handshake failure
| uscan warn: In watchfile debian/watch, reading webpage
| https://qa.debian.org/watch/sf.php/synfig/ failed: 500 SSL upgrade failed: hostname verification failed
`----

I was a bit skeptical that these issues come from
liblwp-protocol-https-perl, as the changes between 6.11 and 6.12 are
small[0], and the errors sound like different issues:
- "hostname verification failed" might be the change in HTTP::Tiny …
or no, as that validates SSL certs; the error "hostname verification
failed" comes from libio-socket-ssl-perl
- "routines::sslv3 alert handshake failure" sounds like an openssl
configuration thing


Interestingly I can't reproduce the issue which makes diving into the
problem a bit hard:


% cat qa-sf-watch
version=4
https://qa.debian.org/watch/sf.php/pcre/ .*@ANY_VERSION@@ARCHIVE_EXT@


% cat gitlab-watch
version=4
https://gitlab.com/AOMediaCodec/SVT-AV1/-/tags .*@ANY_VERSION@@ARCHIVE_EXT@


% for w in qa-sf-watch gitlab-watch; do uscan --report --watchfile $w --package abc --upstream-version 123; done
%


Does it work for you if you downgrade liblwp-protocol-https-perl to 6.11-1
from testing? If yes, which of the two hunks from [0] is causing the
problem?
Do the errors from qa.debian.org go away if you run uscan as "PERL_LWP_SSL_VERIFY_HOSTNAME=1 uscan …"?


Does anyone else reading along have any ideas?


Cheers,
gregor


[0]
diff --git a/lib/LWP/Protocol/https.pm b/lib/LWP/Protocol/https.pm
index 16fce19..01a800b 100644
--- a/lib/LWP/Protocol/https.pm
+++ b/lib/LWP/Protocol/https.pm
@@ -56,7 +56,7 @@ EOT
}
}
$self->{ssl_opts} = \%ssl_opts;
- return (%ssl_opts, $self->SUPER::_extra_sock_opts);
+ return (%ssl_opts, MultiHomed => 1, $self->SUPER::_extra_sock_opts);
}

# This is a subclass of LWP::Protocol::http.
@@ -96,9 +96,12 @@ sub _get_sock_info
if ( $Net::HTTPS::SSL_SOCKET_CLASS->can('start_SSL')) {
*_upgrade_sock = sub {
my ($self,$sock,$url) = @_;
+ # SNI should be passed there only if it is not an IP address.
+ # Details: https://github.com/libwww-perl/libwww-perl/issues/449#issuecomment-1896175509
+ my $host = $url->host_port() =~ m/:|^[\d.]+$/s ? undef : $url->host();
$sock = LWP::Protocol::https::Socket->start_SSL( $sock,
SSL_verifycn_name => $url->host,
- SSL_hostname => $url->host,
+ SSL_hostname => $host,
$self->_extra_sock_opts,
);
$@ = LWP::Protocol::https::Socket->

On Sun, 28 Jan 2024 18:44:02 +0100, Christian Marillat wrote:

Does it work for you if you downgrade liblwp-protocol-https-perl to 6.11-1 from testing? If yes, which of the two hunks from [0] is causing the problem?

This issue doesn't exist with 6.11-1. I've seen this bug when 6.12 has
been installed.

What doesn't help is that I've uploaded libio-socket-ssl-perl 2.085-1
as well … (Although with minimal changes as well.)

The attached patch isn't clean :

Sorry, that was a diff of the upstream git tags.

From the debdiff:

#v+
diff -Nru liblwp-protocol-https-perl-6.11/lib/LWP/Protocol/https.pm liblwp-protocol-https-perl-6.12/lib/LWP/Protocol/https.pm
--- liblwp-protocol-https-perl-6.11/lib/LWP/Protocol/https.pm 2023-07-09 17:10:32.000000000 +0200
+++ liblwp-protocol-https-perl-6.12/lib/LWP/Protocol/https.pm 2024-01-22 18:51:33.000000000 +0100
@@ -56,7 +56,7 @@
}
}
$self->{ssl_opts} = \%ssl_opts;
- return (%ssl_opts, $self->SUPER::_extra_sock_opts);
+ return (%ssl_opts, MultiHomed => 1, $self->SUPER::_extra_sock_opts);
}

# This is a subclass of LWP::Protocol::http.
@@ -96,9 +96,12 @@
if ( $Net::HTTPS::SSL_SOCKET_CLASS->can('start_SSL')) {
*_upgrade_sock = sub {
my ($self,$sock,$url) = @_;
+ # SNI should be passed there only if it is not an IP address.
+ # Details: https://github.com/libwww-perl/libwww-perl/issues/449#issuecomment-1896175509
+ my $host = $url->host_port() =~ m/:|^[\d.]+$/s ? undef : $url->host();
$sock = LWP::Protocol::https::Socket->start_SSL( $sock,
SSL_verifycn_name => $url->host,
- SSL_hostname => $url->host,
+ SSL_hostname => $host,
$self->_extra_soc

On 28 janv. 2024 19:03, gregor herrmann <gregoa@debian.org> wrote:

On Sun, 28 Jan 2024 18:44:02 +0100, Christian Marillat wrote:

Does it work for you if you downgrade liblwp-protocol-https-perl to 6.11-1 >> > from testing? If yes, which of the two hunks from [0] is causing the
problem?

This issue doesn't exist with 6.11-1. I've seen this bug when 6.12 has
been installed.

What doesn't help is that I've uploaded libio-socket-ssl-perl 2.085-1
as well … (Although with minimal changes as well.)

Could you try to reprocduce this bug with the svt-av1 package ?

The attached patch isn't clean :

Sorry, that was a diff of the upstream git tags.

This diff fix this issue.

Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29 janv. 2024 20:58, gregor herrmann <gregoa@debian.org> wrote:

On Mon, 29 Jan 2024 08:53:45 +0100, Christian Marillat wrote:

[...]

This diff fix this issue.

Thanks for checking.
Alright, so we know that
1) something is different between your and my environment, and
2) one of the two small changes between 6.11 and 6.12 causes errors
for you

Could you try which of the two hunks is the culprit? My very random
guess is that it's the first one [0]; for some reason my laptop
prefers IPv4 although I also have IPv6 …

My DMZ doesn't have IPv6.

The second hunk fix this issue for me.

,----
| @@ -96,9 +96,12 @@
| if ( $Net::HTTPS::SSL_SOCKET_CLASS->can('start_SSL')) {
| *_upgrade_sock = sub {
| my ($self,$sock,$url) = @_;
| + # SNI should be passed there only if it is not an IP address.
| + # Details: https://github.com/libwww-perl/libwww-perl/issues/449#issuecomment-1896175509
| + my $host = $url->host_port() =~ m/:|^[\d.]+$/s ? undef : $url->host();
| $sock = LWP::Protocol::https::Socket->start_SSL( $sock,
| SSL_verifycn_name => $url->host,
| - SSL_hostname => $url->host,
| + SSL_hostname => $host,
| $self->_extra_sock_opts,
| );
| $@ = LWP::Protocol::https::Socket->errstr if ! $sock;
`----

Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 30 Jan 2024 18:18:59 +0100, Christian Marillat wrote:

@@ -96,9 +96,12 @@
if ( $Net::HTTPS::SSL_SOCKET_CLASS->can('start_SSL')) {
*_upgrade_sock = sub {
my ($self,$sock,$url) = @_;
+ # SNI should be passed there only if it is not an IP address.
+ # Details: https://github.com/libwww-perl/libwww-perl/issues/449#issuecomment-1896175509

I had the idea to read this github issue.

Thanks for your further investigations!

In my case I've a proxy and IPv6 isn't configured so this explain this
Debian bug and reverting upstream changes in 6.12 is maybe a bad idea.

Ok; so where does this leave us? Do I understand you correctly that
we should not revert the above change, and that the issue is with
your local setup? So should we just close the bug or is there
anything left?


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmW9KH9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qga6oQ//atTtIuaAK2dvQBp/7LyWdh7jblkwPHEXA/5KP9p5eKog3P5/9DQnshpy D541TjBxltxSvceXs3MIu0ZJrK3r0yvh7KrKgDWHPUG6MaXMjdA8GU1wkCY08PQM eaM+ub8TZfjOHXggjnfobCVBkQX9+v4hFJSjs8jSaNQW+wWHYrNugi/JuTSeU/t3 sICRzdjwHa9jmsU3ScJYzZYItIDk9SZzUete9aaNtKB/8qXEP6H2Y2RaSyydEYkm sNi3DjlgLipktOX2W/1fOwEHeX/QJ/KNNSYFUku8GchyRNIzCtW6IPnk51gB4j/W 83XQCwxlSwq4gLq6MCBs8uFPCoYDSwjlc+GH/W8OyvBUGbZvMYw87Ok9/dPiBoST 5/tOjy4jbfEBVE0kG+7U934gfdpvEpUXLcWUaedPO/I2FW5otmFJifgVe65yE5oH 89avvXPhF3BGNIWyYOhKqvO7a78A6CgTfUY47bZEsUeKJvo5H5C260cT/QpqMunk zozmqiQTrdyfkHmpeTY7g3irhqQb2x+yPJZEpGAEao7ziNCJhsWka8DH1/pfNiMn lEBTz3UHWv9KOIsyWjkilihLkJUhtFOLlnXnRwfVFakwjt7pm8PFSo86eMFWHjMA 69f+CxrZas9Fa0pfqAuOi6g0Odmf3SxBXwjm2TLQzayioSxepKc=
=/j6r
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)