[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 Fri, 2021-09-03 at 13:11 +0200, Simon Richter wrote:
> > >    - 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
> > fallout.
> 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.

People who only want to trust specific CAs for APT can do that. APT has
a CaPath setting.

> > 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.

And nothing stops them from doing so.

> > >    - 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?

We already have that.

> This isn't a simple change of default, because this simple change
> pulls in a lot of dependencies.

ca-certificates should already be installed by default (it is Priority:
standard and recommended by apt).

> 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.

I don't see the problem? Currently we add another work step for users
that want to use https.

> > 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.

If a CA is untrustworthy, I don't think we would only want to detrust
it for apt's https method. So I see no problem.

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

So your concern is about Debian providing the deb.debian.org service at
all? That seems unrelated to the https or not question.


Reply to: