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

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

On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote:
> The only thing I could see that would be a net gain would be to generalizes
> sources.list more. Instead of having a user select a specific protocol and
> path, allow the user to just select high-level objects. Make this a new
> pseudo-protocol for backward compatibility, and introduce something like
>   deb apt:// suite component[s]
> so the default could be something like
>   deb apt:// bullseye main
>   deb apt:// bullseye/updates main
> then the actual protocols, servers, and paths could be managed by various
> plugins and overridden by configuration directives in apt.conf.d. For

In this scheme the Debian bullseye main repo has the same 'URI' as the
Darts bullseye main repo. So, you would need to at least include an
additional unique identifier of the likes of Debian and Darts, but
who is to assign those URNs?
(Currently we are piggybacking on the domain name system for this)

Also, but just as an aside, whatever clever system you think of apt
could be using, you still need a rather simple system for the likes of
tools which come before apt like the installers/bootstrappers as they
are not (all) using apt, especially not in the very early stages, and
a mapping between them.

> If someone wants to use tor by default but fall back to https if it's
> unreachable, they can do that. If someone wants to use a local proxy via
> http but https if they're not on their local network, they can do that. New
> installations could default to https, existing installations can keep doing

You can do most of the fallback part with the mirror method backed by
a local file. It is of no concern to apt how that file comes to be, so
you could create it out of a massive amount of options or simply by
hand. I do think if the creation is tool-based it shouldn't be apt
as I envision far too many unique snowflakes for a one-size-fits-all

(The Tor to https fallback can be done already if we talk onion services
 to others. You can't fall out of Tor – or redirect into it – through as
 that would allow bad actors to discover who you are/that you have an
 operational tor client installed. proxy configuration you can already
 change programmatically on the fly – a job auto-apt-proxy implements –,
 changing the mirror file with a hook from your network manager would
 be equally easy.)

> their thing, and a plugin like auto-apt-proxy can override defaults to do
> something more complicated, using more policy-friendly .d configurations
> rather than figuring out a way to rewrite some other package's configuration
> file.

JFTR: auto-apt-proxy has nothing to do with sources. It is true that
apt-cacher-ng (and perhaps others) have a mode of operation in which you
prefix the URI of your (in that case caching) proxy to the URI of the
actual repo, but that isn't how a proxy usually operates and/or is

Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature

Reply to: