Control: affects -1 apt-listbugs On Fri, Oct 01, 2021 at 05:42:32PM +0200, Francesco Poli wrote: > Control: severity -1 important > Control: tags -1 + unreproducible > Control: reassign -1 ruby-soap4r 2.0.5-5 > > On Fri, 1 Oct 2021 09:23:10 -0300 Antonio Terceiro wrote: > > > Package: apt-listbugs > > Version: 0.1.35 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > Hello Antonio! > Thanks for your bug report. > > > > > The old Let's Encrypt root certificate expired recently. Let's Encrypt > > has moved on from that certificate a long time ago, and in principle > > only old devices who don't get their CA store updated should be > > affected. > > > > https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry/ > > > > However, apt-listbugs fails due to a expired certificate, while curl and > > my web browser can access the BTS just fine: > > > > ----------------8<----------------8<----------------8<----------------- > > ~$ apt-listbugs list apt-listbugs > > Retrieving bug reports... 0% Fail > > Error retrieving bug reports from the server with the following error > > message: > > E: SSL_connect returned=1 errno=0 state=error: certificate verify failed > > (certificate has expired) > > It could be because your network is down, or because of broken proxy > > servers, or the BTS server itself is down. Check network configuration and > > try again > > Retry downloading bug information? [Y/n] n > > Continue the installation anyway? [y/N] n > > E: Exiting with error > [...] > > ----------------8<----------------8<----------------8<----------------- > > > > I can also reproduce this on a clean unstable system. > > I cannot reproduce this issue on my testing systems: > > $ apt-listbugs list apt-listbugs > Retrieving bug reports... Done > Parsing Found/Fixed information... Done > grave bugs of apt-listbugs (→ ) <Outstanding> > b1 - #995448 - apt-listbugs: fails to connect to the BTS - certificate > expired > Summary: > apt-listbugs(1 bug) > > I have just tried on my unstable chroot, as well. > It works there, too... > > > Some points worth noticing: > > * apt-listbugs does _not_ handle the HTTP connection directly, it uses > the ruby-soap4r library (which, in its turn, uses some underlying > library to handle the HTTP connection): I am reassigning this bug > report down the chain > > * apt-listbugs does _not_ explicitly force the use of SSL (I am waiting > for openssl 3.0.0 to be in unstable for that: see [#792639] for the > long story): it just passes an http:// URL to the SOAP library; > there must be something else (on your system, or on the network path > between your system and the Debian BTS) that switches the connection > to HTTPS, otherwise I really do not know what's going on!
I tracked this down to an issue between apt-listbugs (or ruby-soap4r, or something else below that) and apt-cacher-ng. If I disable apt-cacher-ng, apt-listbugs works fine. However trying to make other clients go for bugs.debian.org through apt-cacher-ng work fine (e.g. curl), so maybe this is not even caused by apt-cacher-ng itself.
signature.asc
Description: PGP signature