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

Bug#1109583: marked as done (please use SRV records to follow instead of using them as overwrites)

Your message dated Sun, 20 Jul 2025 15:54:17 +0200
with message-id <3149CF8D-3AB1-49DC-876F-0372CD8F4EE3@debian.org>
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 owner@bugs.debian.org
immediately.)


-- 
1109583: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109583
Debian Bug Tracking System
Contact owner@bugs.debian.org 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 <daniel@debian.org> 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 ---
Reply to: