Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote:
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)
I have no idea what darts is, so I don't have an answer. :)
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.
I'm not sure why you think I need that? The goal of my musings is to
separate the definition of what set of debian packages to use from the
decision of how to get those packages *when using apt*, so that there
are fewer things to consider in the common case, and to allow new
capabilities in uncommon cases. If someone's using some other tool, why
would anyone assume that the same configuration syntax would work? Just
use the same configuration file you use now, and ignore all of this. If
you want configurations to match across tools, then ignore all of this
again and keep the same sources.list syntax you're already using that
presumably does what you want.
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
approach.
The intent would be to make it easier to plug other tools into apt,
not to have the apt codebase do everything.
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
configured.
I have no idea what you're saying here.
Reply to: