Your message dated Sat, 12 Oct 2024 15:46:59 +0200
with message-id <20241012154659.8f5454c2b1dd2bf845747...@paranoici.org>
and subject line Re: Bug#1084960: apt-listbugs: hardcode CA certificate
has caused the Debian Bug report #1084960,
regarding apt-listbugs: hardcode CA certificate
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1084960: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084960
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
On Sat, 12 Oct 2024 00:20:08 +0200 Christoph Anton Mitterer wrote:
[...]
> Hey.
Hello Christoph,
thanks for your interest in apt-listbugs!
>
> 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/)?!
It uses Ruby libraries to connect to an https:// URL, which in their
turn, as far as I can tell, use system-wide trusted TLS certificates.
>
> 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
Well, I guess that this is what actually happens.
>
>
> 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.
Not only.
In my opinion, that centralized database of CA certificates (I have
never understood why Java needs its own...) is for any library or
application on the system.
It is useful, since, otherwise, each library or application would have
to ship its own database of CA certificates: a real waste of storage and
an administration nightmare (think of cases where one certificate has
to be distrusted, e.g. because it has been compromised, and one would
have to update each and every library- or application-specific
certificate database!).
>
> But a program like apt-listbugs must per se be used with whichever CA Debian
> uses for the HTTPs of the BTS,
Not necessarily.
In principle, apt-listbugs can be used with any other BTS (based on
debbugs and exposing the SOAP interface).
I am not aware of any such distribution, but a Debian-derivative distro
could have its own BTS based on debbugs and configure apt-listbugs so
that it queries that BTS through the corresponding SOAP interface.
See the AptListbugs::URL configuration option and the --url/-u command
line option, for more details.
> 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).
I disagree that apt-listbugs should hard-code any certificate (I am not
even sure it can be done in a reasonably clean way...).
I think it should do like any other application does: it should use the
system-wide certificates (through appropriate libraries).
>
> 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.
Well, this is not true, either.
Not only apt-listbugs can, at least in theory, used with BTSs other
than the Debian BTS (as explained above), but one can also configure
apt-listbugs to connect to a clear-text http:// URL , without using
TLS/SSL.
Once again, see the AptListbugs::URL configuration option and the
--url/-u command line option.
Try with:
# echo 'AptListbugs::URL "http://bugs.debian.org:80/cgi-bin/soap.cgi";;' >>
/etc/apt/apt.conf.d/10apt-listbugs
if you prefer clear-text HTTP communication (even though, maybe, a
Debian-server-side trick will switch you to HTTPS anyway, I am not
sure).
Of course, clear-text HTTP communications can be eavesdropped, so you'd
better stay with HTTPS, instead.
>
> 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.
Maybe I am misunderstanding what you mean, but this does not make sense
to me.
The main user of apt-listbugs is the system administrator (regular
users may also use it for informational purposes, with 'apt-listbugs
list' and 'apt-listbugs rss', but the central point is its automatic
check during package upgrade/installation).
Hence, if the sysadmin does not trust a given certificate, the same
sysadmin will not trust the same certificate, when using apt-listbugs.
If the sysadmin does not trust the certificate presented by
bugs.debian.org, then he/she does not consider the communication with
bugs.debian.org as secure.
Either the sysadmin does not want to communicate with bugs.debian.org
(i.e.: he/she does not want to use apt-listbugs, at least not with the
Debian BTS) or he/she does not want to use TLS/SSL with bugs.debian.org
(i.e.: he/she decides that the clear-text HTTP is OK).
[...]
> Cheers,
> Chris.
I hope I clarified why I am not going to hard-code any certificate in
apt-listbugs.
I am closing this bug report.
Bye.
--
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
pgpTQjB3r77g5.pgp
Description: PGP signature
--- End Message ---
