[DRE-maint] Bug#995448: apt-listbugs: fails to connect to the BTS - certificate expired

[Francesco Poli]

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!

[#792639]: <https://bugs.debian.org/792639>

[...]
> Versions of packages apt-listbugs depends on:
> ii  apt             2.3.9
> ii  ruby            1:2.7+2
> pn  ruby-debian     <none>
> pn  ruby-gettext    <none>
> ii  ruby-soap4r     2.0.5-5
> pn  ruby-unicode    <none>
> pn  ruby-xmlparser  <none>
[...]

By the way, is this information accurate?
Do you really miss some of the dependencies of apt-listbugs on your
system (which would be a broken system)? Or is it just that you purged
apt-listbugs, before filing the bug report?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-ruby-extras-maintainers/attachments/20211001/fc3ad098/attachment-0001.sig>