On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
So what do you suggest then? Tech-ctte as with merged-/usr? Or a
GR? Or
something else?
I propose that the proponents pay the cost. In this case, it is a bit
unclear what that means precisely (which likely is the reason they
haven't done it already). At the very least though, apt install
auto-apt-proxy should continue to work on a default installation in a
sensible way.
I can file a bug for auto-apt-proxy to include an apt.conf snippet
saying
Acquire::https::Verify-Peer false;
That clearly makes it work again
Why can't auto-apt-proxy ask this as a debconf question? I also like auto-apt-proxy but I agree with this, someone needing auto-apt-proxy should be able to change the default as well.
On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote:
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
So what do you suggest then? Tech-ctte as with merged-/usr? Or a
GR? Or
something else?
I propose that the proponents pay the cost. In this case, it is a bit unclear what that means precisely (which likely is the reason they haven't done it already). At the very least though, apt install auto-apt-proxy should continue to work on a default installation in a sensible way.
I can file a bug for auto-apt-proxy to include an apt.conf snippet
saying
Acquire::https::Verify-Peer false;
That clearly makes it work again
I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think
that also won't necessarily work on an existing proxy.
If we're imagining apt options, something like Acquire::https::Force-Proxy-HTTP true;
would probably be more useful for this specific case (not that I think it's
a great idea--too much potential for surprise).
I think the issue isn't certificate validation, it's that https proxy >requests are made via CONNECT rather than GET. You could theoretically >rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't beapt-cacher-ng has a second mode of operation where you can prefix
a drop-in replacement. I suppose you could instead add an apt option
to pass the https request to the proxy via GET instead of using
CONNECT, but I think that also won't necessarily work on an existing
proxy.
* Michael Stone <mstone@debian.org> [2021-09-08 19:25]:
I think the issue isn't certificate validation, it's that httpsapt-cacher-ng has a second mode of operation where you can prefix
proxy requests are made via CONNECT rather than GET. You could >>theoretically rewrite the proxy mechanism to MITM the CONNECT, but
that wouldn't be a drop-in replacement. I suppose you could instead
add an apt option to pass the https request to the proxy via GET
instead of using CONNECT, but I think that also won't necessarily
work on an existing proxy.
the source URL with the proxy URL, i.e.
deb http://proxyhost:3142/deb.debian.org/debian unstable main
Maybe we could introduce this as an "official" APT proxy mode, where >http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy
can decide whether or not to fetch via HTTPS as an implementation
detail)?
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
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
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.
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 >approach.
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.
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
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.
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).
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.
Because this thread started with the idea to switch the default of d-i
and co to another URI. If you target only apt then you still need
a solution for d-i and a way to convert whatever d-i had into what apt
gets in the end (of the installation).
ISTR the future of creating new Debian installations is to move from debootstrap to dpkg/apt. As an interim step, debootstrap could [...]
On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote:
Because this thread started with the idea to switch the default of d-i
and co to another URI. If you target only apt then you still need
a solution for d-i and a way to convert whatever d-i had into what apt
gets in the end (of the installation).
ISTR the future of creating new Debian installations is to move from debootstrap to dpkg/apt. As an interim step, debootstrap could move
from doing its own downloads to passing the appropriate APT_CONFIG/DPKG_ROOT/etc to `apt download`.
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 376 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 40:05:19 |
| Calls: | 8,039 |
| Calls today: | 3 |
| Files: | 13,037 |
| Messages: | 5,830,574 |