[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#992692: general: Use https for {deb,security}.debian.org by default


On 02.09.21 23:02, Ansgar wrote:

As it is now, I can install a Debian system where no X.509
certificate authorities are trusted.

That doesn't change with the proposal?

   - If I deselect all CAs in the configuration dialog of the
ca-certificates package, what mechanism will allow apt to work?

If people intentionally detrust them, they have to deal with the

So this introduces a policy that users need to mark X.509 CAs as trusted?

People can also detrust Debian's OpenPGP signing keys; it's
not much different.

The Debian signing keys have separate trust setup, and are trusted for nothing but APT updates.

If we wanted the same for X.509, we'd need /etc/apt/ca-certificates or something such, and apt to configure the list of accepted CAs explicitly in the TLS layer rather than using the default settings.

Accessing www.debian.org will also not work on such systems (and unlike
deb.d.o that does not even offer non-https). It's not Debian's problem.

There are a lot of systems out there that have no need to access www.debian.org, but do need to access deb.debian.org.

   - Do we want to pin the certificate provider for Debian mirrors, in
the knowledge that we want to be bound to this provider for several
years, do we want any "root" CA to be able to provide a trust anchor?

Probably not?

So what do we want then? A list of root CAs that users have to mark as trusted, possibly with an "are you sure?" dialog in ca-certificates?

This isn't a simple change of default, because this simple change pulls in a lot of dependencies. That users can override the default means adding another work step for users, either a manual step that needs to be performed after a manual installation, or an automated step that needs to be integrated into users' deployment processes.

   - Is there a revocation mechanism by which we can mark "root" CAs

If we don't have one, shouldn't we worry more about that given the
widespread use of TLS?

We have a big hammer, shipping a new ca-certificates package. If we want something that only affects apt, but not other packages, that mechanism doesn't exist yet.

Do we have a revocation mechanism by which we can mark OpenPGP signing
keys as untrustworthy (say for apt)?

Yes, by shipping an update.

   - do we have a contingency plan if deb.debian.org hosting on Fastly
is no longer feasible?

As far as I know there is also at least https://cdn-aws.deb.debian.org/
if you don't like Fastly.

It's not about what I like, but on what external services we want to depend.


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: