Package: libio-socket-ssl-perl Version: 2.002-1 Severity: normal Tags: upstream
Initially ran into this with uscan, refusing to fetch source from google code. Dug in a bit, and discovered that Perl is using the Public Suffix List (https://publicsuffix.org/) to restrict wildcard certificates. e.g. HEAD https://re2.googlecode.com/files/re2-20140304.tgz 500 Can't connect to re2.googlecode.com:443 (certificate verify failed) Yet gnutls-cli and openssl s_client both have no issue with this certificate. I don't believe that this is a correct use of the PSL. The PSL lists domains that users can register/receive subdomains of, but this doesn't mean that the users control the DNS/hosting of these subdomains. There are quite a few domains in the PSL that I know have wildcard certificates issued for them: cloudfront.net s3.amazonaws.com github.io appspot.com herokuapp.com and probably many others. I even have a domain in there, that we intend to provide wildcard SSL for, in the future. Blocking wildcard certificates for TLDs makes sense. For other public suffix domains, doesn't. SR -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libio-socket-ssl-perl depends on: ii libnet-ssleay-perl 1.65-1+b1 ii netbase 5.2 ii perl 5.20.1-2 Versions of packages libio-socket-ssl-perl recommends: ii libio-socket-inet6-perl 2.72-1 ii libio-socket-ip-perl 0.32-1 ii libsocket6-perl 0.25-1+b1 ii liburi-perl 1.64-1 ii perl 5.20.1-2 ii perl-base [libsocket-perl] 5.20.1-2 Versions of packages libio-socket-ssl-perl suggests: ii ca-certificates 20141019 -- no debconf information
signature.asc
Description: Digital signature
