Your message dated Sun, 20 Jul 2025 15:54:17 +0200
with message-id <[email protected]>
and subject line Re: Bug#1109583: please use SRV records to follow instead of
using them as overwrites
has caused the Debian Bug report #1109583,
regarding please use SRV records to follow instead of using them as overwrites
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1109583: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109583
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: apt
Hi,
in order to transparently overwrite deb.debian.org in our own network,
we can overwrite the SRV records for http on the internal resolvers, i.e.:
_http._tcp.deb.debian.org. IN SRV 10 1 80 mirror.example.org.
however, in the case of HTTPS using _https.tcp.deb.debina.org this
doesn't work as we'll be having a certificate mismatch
(mirror.example.org cannot have a valid deb.debian.org certificate).
it would be nice, if apt would not just replace the IP of the
deb.debian.org request with the IP of mirror.example.org, but instead
treat it more like a 301: the request to deb.debian.org should be done
as a request to the hostname provided (aka mirror.example.org).
this would allow local network administrators to transparently redirect
traffic to the internal mirror in cases, where it's unrealistic to have
control/influence the clients otherwise (in our case, large university
network with all BYD devices).
I don't think this is a privacy/security issue if apt would implement
this, as you have to trust your local network administrator anyway (they
could use transparent proxies instead and still "inject" .deb files
without the user noticing it) and can't enforce client side where the
.debs are downloaded from.
As a user, you can be still sure that what you're getting is valid, as
all the security measures of apt-secure (gpg validation, indices
expiration, etc.) are untouched by that and will prevent any tampering.
or in other words: please support making local mirroring using
deb.debian.org possible with https.
Regards,
Daniel
--- End Message ---
--- Begin Message ---
On 20 July 2025 14:39:16 CEST, Daniel Baumann <[email protected]> wrote:
>Package: apt
>
>Hi,
>
>in order to transparently overwrite deb.debian.org in our own network, we can
>overwrite the SRV records for http on the internal resolvers, i.e.:
>
> _http._tcp.deb.debian.org. IN SRV 10 1 80 mirror.example.org.
>
>however, in the case of HTTPS using _https.tcp.deb.debina.org this doesn't
>work as we'll be having a certificate mismatch (mirror.example.org cannot have
>a valid deb.debian.org certificate).
>
>it would be nice, if apt would not just replace the IP of the deb.debian.org
>request with the IP of mirror.example.org, but instead treat it more like a
>301: the request to deb.debian.org should be done as a request to the hostname
>provided (aka mirror.example.org).
>
>
>this would allow local network administrators to transparently redirect
>traffic to the internal mirror in cases, where it's unrealistic to have
>control/influence the clients otherwise (in our case, large university network
>with all BYD devices).
>
>I don't think this is a privacy/security issue if apt would implement this, as
>you have to trust your local network administrator anyway (they could use
>transparent proxies instead and still "inject" .deb files without the user
>noticing it) and can't enforce client side where the .debs are downloaded from.
No that's not how SRV records work or can even work. You'd completely violate
the basic premise of TLS encryption and authenticity, allowing your local
network operator to intercept encrypted communications.
It's true that the repo is still gpg protected, however that's only one layer
of defense. If you want to rely on that, use http.
--
sent from my phone, excuse the brevity, if any
--- End Message ---
