On Thu, 2021-09-02 at 21:26 +0200, Simon Richter 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 fallout. People can also detrust Debian's OpenPGP signing keys; it's not much different. 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. > - 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? > - Is there a revocation mechanism by which we can mark "root" CAs > as > untrustworthy? If we don't have one, shouldn't we worry more about that given the widespread use of TLS? Do we have a revocation mechanism by which we can mark OpenPGP signing keys as untrustworthy (say for apt)? > - What does the UI look like if OSCP verification fails? > - How do mirror operators get a signed certificate? Not all mirror operators have a TLS certificate. I don't think that was proposed to be changed (see subject of the mail). > I think we're adding a lot of complexity and external dependencies to > the system here, which adds a lot of burden to mirror operators that > aren't large CDNs. See above. > - do we have a contingency plan if deb.debian.org hosting on Fastly > is no longer feasible? Is replacing deb.d.o by a non-CDN feasible? If no, what does use of https change? As far as I know there is also at least https://cdn-aws.deb.debian.org/ if you don't like Fastly. Ansgar
