[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 Fri, Sep 10, 2021 at 08:02:42PM +0200, David Kalnischkies wrote:
On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote:
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. :)

"Darts" was just a play on "bullseye". It is not hard to imagine
a repository which has the same suite and component(s) but is not
Debian itself. As a pseudo-random [= its in an other topic here] real
example you can take Wine (https://dl.winehq.org/wine-builds/debian/).
So to what is "deb apt:// bullseye main" referring? Debian or Wine?

And to pre-empt the most common response: As an apt dev I can assure you
that we won't accept a solution involving "I am on Debian, so it means
Debian" as that is impossible to correctly guess programmatically (for
example on derivatives using a small overlay repo).

I'd considered adding a scope to the model, e.g., apt://debian.org but removed it for simplicity. If that was a desired feature then there'd either have to be some sort of well-known path or such a distribution would need to provide a policy plugin for that scope. Alternatively, they could just use the existing http/https/whatever syntax in sources.list for their overlay if they didn't want to bother. Same for third party repos.
> > 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.

And I have no idea if you know what you are talking about.

auto-apt-proxy already uses an interface apt provides to configure the
proxy at runtime. It isn't in the business of modifying sources.list nor
has it any interest in that. So you using it as an example for a plugin
who could use your proposed scheme to modify the sources at runtime
makes no sense.

The concern I was responding to was that switching to https breaks the case of using auto-apt-proxy to cache the transaction. Just turning the proxy on and off isn't sufficient if the default sources.list uses https instead of http--you'd currently have to both turn the proxy on *and* change sources.list from http to https. Hence my musings on whether it's possible/desirable to separate the configuration of what to use as a transport from the configuration of what repository is desired.

More generally, if we're talking about changing the default way that people interact with debian it just seems like a good time to ponder whether specifying sources the same way we did in 1998 makes sense given how many changes there have been to expectations about how we use internet resources. Maybe the answer is yes, and I'm not arguing that there has to be a change or that what I threw out as a possibility is the right answer, but it does seem worth considering.

Reply to: