Package: apt-listbugs Version: 0.1.42 Severity: wishlist
Hey. I'd guess that apt-listbugs, when retrieving the bugs from the BTS, uses the systemd wide default store of trusted certs (/etc/ssl/certs/)?! Now the consquence is that if someone has changed the certs there to not include the one used by Debian (or none at all), apt-listbugs will fail: Retrieving bug reports... 0% Fail Error retrieving bug reports from the server with the following error message: E: SSL_connect returned=1 errno=0 peeraddr=209.87.16.39:443 state=error: certificate verify failed (unable to get local issuer certificate) 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 I'd argue that the conceptual idea of any default store like /etc/ssl/certs/ or e.g. that used by Java is for generic use cases, like e.g. curl or wget, where the admin can decide which CAs to trust and which not. But a program like apt-listbugs must per se be used with whichever CA Debian uses for the HTTPs of the BTS, so I think it would be better if apt-listbugs could hard-code that CA file (or at least, which would of course be less secure, the whole mozilla bundle, i.e. /usr/share/ca-certificates/mozilla/, should the CA change a lot). It makes no sense for the trusted cert of apt-listbugs to be configurable, as that which Debian uses must be trusted or otherwise it will not work. This also means that it makes no sense of using the (configurable) default CA store. The opposite, it actually just makes it impossible to distrust the cert from the default store (for programs like curl, wget, etc.), because that in turn breaks apt-listbugs. I don't mean that the content of the CA file should be harcoded, but simply the path to that file as shipped by ca-certificates. That of course also means that ca-certificates should probably become a dependency of the package (which it is already indirectly via ruby/ruby3.1/rubygems-integration). Cheers, Chris.
