Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #101278 > unrolled thread
| Started by | Hideki Yamane <henrich@debian.org> |
|---|---|
| First post | 2021-08-22 15:10 +0200 |
| Last post | 2022-03-30 12:50 +0200 |
| Articles | 20 on this page of 57 — 21 participants |
Back to article view | Back to linux.debian.devel
Bug#992692: general: Use https for {deb,security}.debian.org by default Hideki Yamane <henrich@debian.org> - 2021-08-22 15:10 +0200
Processed: Re: Bug#992692: general: Use https for {deb,security}.debian.org by default "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-09-01 11:50 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Helmut Grohne <helmut@subdivi.de> - 2021-09-01 11:50 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-01 12:00 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Russ Allbery <rra@debian.org> - 2021-09-01 17:00 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Hideki Yamane <henrich@iijmio-mail.jp> - 2021-09-02 04:00 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Roberto C. Sánchez <roberto@debian.org> - 2021-09-02 18:30 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Jeremy Stanley <fungi@yuggoth.org> - 2021-09-02 19:00 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Jeremy Stanley <fungi@yuggoth.org> - 2021-09-02 19:00 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-02 21:40 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-02 23:10 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Paul Wise <pabs@debian.org> - 2021-09-03 04:50 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default David Kalnischkies <david@kalnischkies.de> - 2021-09-05 12:40 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-03 13:20 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-03 13:40 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Philipp Kern <pkern@debian.org> - 2021-09-03 13:40 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Hideki Yamane <henrich@iijmio-mail.jp> - 2021-09-04 22:20 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-09 20:10 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Paul Wise <pabs@debian.org> - 2021-09-10 02:00 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-10 17:10 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Helmut Grohne <helmut@subdivi.de> - 2021-09-08 13:20 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 13:40 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Helmut Grohne <helmut@subdivi.de> - 2021-09-08 14:00 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 14:10 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Helmut Grohne <helmut@subdivi.de> - 2021-09-08 15:50 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 16:00 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-09 01:30 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2021-09-09 01:40 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Eduard Bloch <edi@gmx.de> - 2021-09-10 11:30 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Timo Röhling <roehling@debian.org> - 2021-09-10 12:10 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-10 14:00 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Tim Woodall <debiandevel@woodall.me.uk> - 2021-09-08 14:20 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 14:30 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-09 01:30 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Timo Röhling <roehling@debian.org> - 2021-09-09 08:40 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-09 14:40 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Timo Röhling <roehling@debian.org> - 2021-09-09 15:00 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-09 15:10 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Timo Röhling <roehling@debian.org> - 2021-09-09 15:30 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-09 15:00 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default David Kalnischkies <david@kalnischkies.de> - 2021-09-10 16:40 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-10 17:10 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default David Kalnischkies <david@kalnischkies.de> - 2021-09-10 20:10 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-10 21:20 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Paul Wise <pabs@debian.org> - 2021-09-12 05:20 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Holger Levsen <holger@layer-acht.org> - 2021-09-13 00:00 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default David Kalnischkies <david@kalnischkies.de> - 2021-09-13 15:10 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Helmut Grohne <helmut@subdivi.de> - 2021-09-10 09:40 +0200
Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-10 10:20 +0200
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Michael Stone <mstone@debian.org> - 2021-09-10 14:10 +0200
Bug#994409: task-laptop: please recommend automatic apt proxying Phil Morrell <debian@emorrp1.name> - 2021-09-15 19:20 +0200
Re: task-laptop: please recommend automatic apt proxying Russ Allbery <rra@debian.org> - 2021-09-15 19:40 +0200
Re: task-laptop: please recommend automatic apt proxying Russ Allbery <rra@debian.org> - 2021-09-15 19:40 +0200
Bug#992692: next steps Hans-Christoph Steiner <hans@eds.org> - 2021-12-09 12:30 +0100
Bug#992692: more steps towards this goal Hans-Christoph Steiner <hans@eds.org> - 2022-03-30 10:00 +0200
Bug#992692: moar Hans-Christoph Steiner <hans@eds.org> - 2022-03-30 12:30 +0200
Bug#992692: link Geert Stappers <stappers@stappers.nl> - 2022-03-30 12:50 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2021-09-08 13:20 +0200 |
| Message-ID | <CV3Mu-1jd-9@gated-at.bofh.it> |
| In reply to | #101488 |
Hi,
On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> Some users want proxy but they can configure their settings.
> So just change "default setting for {deb,security}.debian.org"
> is not so harmful, IMO.
I fear you are putting this upside down. In reality, some sites (not
users) want their users to use their local cache (transparently or not).
> - Users can choose other mirror than https://deb.debian.org
As far as I can tell, most users don't want to make a choice here. They
want downloading packages to just work. Preferably fast. It is the
"fast" thing that you are breaking here.
> - Caching .debs from security.debian.org is not so huge, I guess
> (maybe except linux-image).
Not sure why security.d.o is singled out here. The switch is only
reasonable on the whole or not at all. And there the whole volume of
packages counts.
Enabling https by default quite simply breaks the simple recipe of
installing auto-apt-proxy. Would you agree with auto-apt-proxy's
postinst automatically editing your sources.list to drop the s out of
https? The answer repeatedly given in this thread to do so manually is
very unsatisfying.
So I actually argue for installing auto-apt-proxy by default and inside
d-i. That is in direct conflict with the proposed change here.
Unfortunately, I don't see consensus for this, but at the same time I
neither see consensus for enabling https by default. It's a matter that
keeps popping up and people disagreeing on over and over again. The one
thing that we have clearly understood at this point is that one size
does not fit everyone. Either way makes some people unhappy.
Helmut
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-09-08 13:40 +0200 |
| Message-ID | <CV45Q-1qv-17@gated-at.bofh.it> |
| In reply to | #101584 |
On Wed, 2021-09-08 at 13:09 +0200, Helmut Grohne wrote:
> On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> > Some users want proxy but they can configure their settings.
> > So just change "default setting for {deb,security}.debian.org"
> > is not so harmful, IMO.
>
> I fear you are putting this upside down. In reality, some sites (not
> users) want their users to use their local cache (transparently or
> not).
Then have the users install the site's CA authority that allows
inspecting and caching HTTPS traffic.
> Unfortunately, I don't see consensus for this, but at the same time I
> neither see consensus for enabling https by default. It's a matter
> that
> keeps popping up and people disagreeing on over and over again. The
> one
> thing that we have clearly understood at this point is that one size
> does not fit everyone. Either way makes some people unhappy.
Maybe we should just find out who is responsible for this decision and
reassign the bug to them. The installer team maintaining d-i and
debootstrap or the mirror team seem reasonable choices?
Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2021-09-08 14:00 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CV4pb-1yQ-7@gated-at.bofh.it> |
| In reply to | #101585 |
On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote: > Maybe we should just find out who is responsible for this decision and > reassign the bug to them. The installer team maintaining d-i and > debootstrap or the mirror team seem reasonable choices? We've already tried that approach on the /usr-merge and the resulting transition is miserable. Let's not repeat that mistake. It's the same pattern actually: * People propose a change that does have positive effects, though some find the positive effects unimportant. * Other people disagree and raise concerns. * Concerns are ignored. <- This is where we are with https-default. * Change is being implemented anyway. * Stuff breaks. <- This is where we are with /usr-merge. This is frustrating. I do see the advantages of using https. I do not see how to not make it happen without breaking relevant use cases. Same with the /usr-merge. I do see the advantages. I've stopped counting the things that broke. Most recent one is the uucp FTBFS. Change has a cost. I do not want to pay the cost for either of these changes. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-09-08 14:10 +0200 |
| Message-ID | <CV4yS-1S5-3@gated-at.bofh.it> |
| In reply to | #101586 |
On Wed, 2021-09-08 at 13:53 +0200, Helmut Grohne wrote: > On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote: > > Maybe we should just find out who is responsible for this decision > > and > > reassign the bug to them. The installer team maintaining d-i and > > debootstrap or the mirror team seem reasonable choices? > > We've already tried that approach on the /usr-merge and the resulting > transition is miserable. Let's not repeat that mistake. So what do you suggest then? Tech-ctte as with merged-/usr? Or a GR? Or something else? > It's the same pattern actually: > * People propose a change that does have positive effects, though > some > find the positive effects unimportant. > * Other people disagree and raise concerns. > * Concerns are ignored. <- This is where we are with https-default. It's also where we are with keep-http-as-default. > Change has a cost. I do not want to pay the cost for either of these > changes. Then we could never change anything. To keep up with merged-/usr: keeping non-merged-/usr also has a cost. Nobody wants to pay the cost for it. Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2021-09-08 15:50 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CV67D-2Ji-1@gated-at.bofh.it> |
| In reply to | #101587 |
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. > > * Concerns are ignored. <- This is where we are with https-default. > > It's also where we are with keep-http-as-default. I don't think https resolves any concerns. It's merely best-practice. In the absence of reason not to use https, https should be preferred. As it happens, we figured a reason not to use https. > > Change has a cost. I do not want to pay the cost for either of these > > changes. > > Then we could never change anything. Untrue. You get to choose which changes you want to pay the cost for. For instance, I want Debian to be cross buildable and bootstrappable. Holger, Mattia and a few others want Debian to be reproducible. You don't get to pay the cost for those changes. Change is possible in a way that limits cost for uninterested people. The contentious changes are the ones where the initiators fail to pay the cost. > To keep up with merged-/usr: keeping non-merged-/usr also has a cost. > Nobody wants to pay the cost for it. That is very true. With merged-/usr, I suppose most grief arises from the way the transition was (not) planned and only a minority takes issue with the goal. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-09-08 16:00 +0200 |
| Message-ID | <CV6hj-2MN-1@gated-at.bofh.it> |
| In reply to | #101591 |
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: you ask for auto-apt-proxy users to have connections that can be impersonated by a man in the middle by default. The above setting does that. Not verifying certificates for some users seems better than having all users not verify certificates (as no https is used at all). > In > the absence of reason not to use https, https should be preferred. As > it > happens, we figured a reason not to use https. I can find a reason not to use https for any protocol (some sites want to inspect/cache all traffic) :-) Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2021-09-09 01:30 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVfaV-8ll-5@gated-at.bofh.it> |
| In reply to | #101592 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Timothy M Butterworth <timothy.m.butterworth@gmail.com> |
|---|---|
| Date | 2021-09-09 01:40 +0200 |
| Message-ID | <CVfkB-8ob-5@gated-at.bofh.it> |
| In reply to | #101605 |
All, I am against automatically setting HTTPS. Their should be an option in the installer to set or unset HTTPS while configuring the mirror! I like a lot of folks am on a metered internet connection with a UTM proxy firewall. I have multiple computers that need patched and only having to download the package once is a great convenience to both data usage and download time as my internet is not fast 4G LTE usually only operating at 3G speed. Tim
[toc] | [prev] | [next] | [standalone]
| From | Eduard Bloch <edi@gmx.de> |
|---|---|
| Date | 2021-09-10 11:30 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVL18-366-9@gated-at.bofh.it> |
| In reply to | #101605 |
Hallo, * Michael Stone [Wed, Sep 08 2021, 07:25:26PM]: > 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 Precisely. Current handling of HTTPS on a caching proxy is either impossible or PITA for the user, as long as a such mixed behavior is not configurable. apt-cacher-ng works around that by telling users to disguise https URLs as HTTP with a special marker for protocol switch (ugly, I know). Also keep in mind that it off-loads the encryption work to the proxy, but that might be even intentional. > that also won't necessarily work on an existing proxy. Speaking at least for ACNG, my assumption was that it would support that but I was wrong. TODO created, https://salsa.debian.org/blade/apt-cacher-ng/-/issues/11 . > 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 would make it a list of trusted proxy hosts and a special value ALL. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994032 created. Best regards, Eduard.
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2021-09-10 12:10 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVLDQ-3ym-7@gated-at.bofh.it> |
| In reply to | #101605 |
[Multipart message — attachments visible in raw view] — view raw
* Michael Stone <mstone@debian.org> [2021-09-08 19:25]: >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. apt-cacher-ng has a second mode of operation where you can prefix 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)? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2021-09-10 14:00 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVNmh-4s5-1@gated-at.bofh.it> |
| In reply to | #101633 |
On Fri, Sep 10, 2021 at 12:00:57PM +0200, Timo Röhling wrote: >* Michael Stone <mstone@debian.org> [2021-09-08 19:25]: >>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. >apt-cacher-ng has a second mode of operation where you can prefix >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)? I'd much rather see something more like I proposed earlier (splitting the selection of what suites/components to install from the policy of how to obtain them) rather than further layering+confusing these two concepts within sources.list.
[toc] | [prev] | [next] | [standalone]
| From | Tim Woodall <debiandevel@woodall.me.uk> |
|---|---|
| Date | 2021-09-08 14:20 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CV4Ix-1VP-11@gated-at.bofh.it> |
| In reply to | #101586 |
On Wed, 8 Sep 2021, Helmut Grohne wrote: > I do see the advantages of using https. I do not see how to not make it > happen without breaking relevant use cases. Same with the /usr-merge. I > do see the advantages. I've stopped counting the things that broke. Most > recent one is the uucp FTBFS. Change has a cost. I do not want to pay > the cost for either of these changes. > This is a bit tongue in cheek, but how about these sites where the .debs are downloaded from publish their *private* key? They openly accept that anyone can MITM them. That way people who want to see "https" can see it. And people who want the benefits of http can, with a bit of work, simulate that. It also nicely addresses my concern which is that the next demand will be to drop http (because when you visit the site with a webbrowser users start getting a warning that the site is also available over http or something like that because the google/firefox dream seems to be that you cannot use http even where https doesn't add anything.)
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-09-08 14:30 +0200 |
| Message-ID | <CV4Sd-1Zq-7@gated-at.bofh.it> |
| In reply to | #101588 |
On Wed, 2021-09-08 at 13:13 +0100, Tim Woodall wrote: > This is a bit tongue in cheek, but how about these sites where the > .debs are downloaded from publish their *private* key? They openly > accept that anyone can MITM them. If you have access to the private key, you can request the CA to revoke the certificate: +--- | 4.9.1.1 Reasons for Revoking a Subscriber Certificate | | The CA SHALL revoke a Certificate within 24 hours if one or more of | the following occurs: | [...] | 3. The CA obtains evidence that the Subscriber’s Private Key | corresponding to the Public Key in the Certificate suffered a Key | Compromise +---[ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf ] So that would not be helpful. Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2021-09-09 01:30 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVfaV-8ll-7@gated-at.bofh.it> |
| In reply to | #101584 |
On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote: >Enabling https by default quite simply breaks the simple recipe of >installing auto-apt-proxy. Would you agree with auto-apt-proxy's >postinst automatically editing your sources.list to drop the s out of >https? The answer repeatedly given in this thread to do so manually is >very unsatisfying. Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management?
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2021-09-09 08:40 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVlT4-43u-9@gated-at.bofh.it> |
| In reply to | #101606 |
[Multipart message — attachments visible in raw view] — view raw
* Michael Stone <mstone@debian.org> [2021-09-08 19:12]: >Why not simply automate setting it at install time using preseed? I'm >honestly not sure who the target audience for auto-apt-proxy >is--apparently someone who has an infrastructure including a proxy, >possibly the ability to set dns records, etc., but can't change >defaults at install time or via some sort of runtime configuration >management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2021-09-09 14:40 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVrvs-7sr-7@gated-at.bofh.it> |
| In reply to | #101616 |
On Thu, Sep 09, 2021 at 08:36:28AM +0200, Timo Röhling wrote: >* Michael Stone <mstone@debian.org> [2021-09-08 19:12]: >>Why not simply automate setting it at install time using preseed? >>I'm honestly not sure who the target audience for auto-apt-proxy >>is--apparently someone who has an infrastructure including a proxy, >>possibly the ability to set dns records, etc., but can't change >>defaults at install time or via some sort of runtime configuration >>management? >The same reason you might want to deploy WPAD instead of preconfiguring >proxy settings in web browsers: flexibility. For example, we use >auto-apt-proxy for laptops which roam between different networks. >It's simple to configure, has virtually no maintenance overhead and >degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility.
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2021-09-09 15:00 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVrON-7CM-3@gated-at.bofh.it> |
| In reply to | #101619 |
[Multipart message — attachments visible in raw view] — view raw
* Michael Stone <mstone@debian.org> [2021-09-09 08:32]: >>>I'm honestly not sure who the target audience for auto-apt-proxy >>>is--apparently someone who has an infrastructure including a >>>proxy, possibly the ability to set dns records, etc., but can't >>>change defaults at install time or via some sort of runtime >>>configuration management? >>The same reason you might want to deploy WPAD instead of preconfiguring >>proxy settings in web browsers: flexibility. For example, we use >>auto-apt-proxy for laptops which roam between different networks. >>It's simple to configure, has virtually no maintenance overhead and >>degrades gracefully. >None of that speaks to whether an organization that deploys such a >thing has the ability to manage other configuration settings, even if >for some settings there's a desire for additional flexibility. I don't understand your point. You asked for a target audience for auto-apt-proxy. I gave you a legitimate (and real-world) example for such a deployment. Why should it matter whether or not an organization has other configuration facilities? As another example, nobody says: "the target audience for DHCP is an organization who has an infrastructure with full control over a network, including IP address management, but apparently can't configure IP addresses at install time or via some sort of runtime configuration management" and concludes that DHCP is useless. auto-apt-proxy (or DHCP for that matter) *is* the runtime configuration management, and a quite efficient one at that. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2021-09-09 15:10 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVrYt-7VA-5@gated-at.bofh.it> |
| In reply to | #101620 |
On Thu, Sep 09, 2021 at 02:54:21PM +0200, Timo Röhling wrote: >* Michael Stone <mstone@debian.org> [2021-09-09 08:32]: >>>>I'm honestly not sure who the target audience for auto-apt-proxy >>>>is--apparently someone who has an infrastructure including a >>>>proxy, possibly the ability to set dns records, etc., but can't >>>>change defaults at install time or via some sort of runtime >>>>configuration management? >>>The same reason you might want to deploy WPAD instead of preconfiguring >>>proxy settings in web browsers: flexibility. For example, we use >>>auto-apt-proxy for laptops which roam between different networks. >>>It's simple to configure, has virtually no maintenance overhead and >>>degrades gracefully. >>None of that speaks to whether an organization that deploys such a >>thing has the ability to manage other configuration settings, even >>if for some settings there's a desire for additional flexibility. >I don't understand your point. > >You asked for a target audience for auto-apt-proxy. I gave you a >legitimate (and real-world) example for such a deployment. Why >should it matter whether or not an organization has other >configuration facilities? Because the controversy concerning changing the default is over whether it's reasonable for someone using auto-apt-proxy to have to manage additional configuration settings. If the target audience is someone who has the ability to manage the infrastructure required by auto-apt-proxy but not the ability to manage anything else then I guess it's a valid criticism (but I have trouble envisioning that). If the auto-apt-proxy target audience can manage both the proxy infrastructure *and* sources.list (either at install time or run time) then the criticism is basically academic and not generally a real-world issue.
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2021-09-09 15:30 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVshQ-81S-9@gated-at.bofh.it> |
| In reply to | #101623 |
[Multipart message — attachments visible in raw view] — view raw
* Michael Stone <mstone@debian.org> [2021-09-09 09:05]: >Because the controversy concerning changing the default is over >whether it's reasonable for someone using auto-apt-proxy to have to >manage additional configuration settings. Ah, I understand your point now and I agree. It would be an inconvenience, yes, not but much more. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2021-09-09 15:00 +0200 |
| Subject | Re: Bug#992692: general: Use https for {deb,security}.debian.org by default |
| Message-ID | <CVrON-7CM-7@gated-at.bofh.it> |
| In reply to | #101606 |
On Thu, Sep 09, 2021 at 11:54:44AM +0530, Pirate Praveen wrote: >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. I don't really see why adding another debconf question would be better than just preseeding the existing one. 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 existing configurations it's a no-op but it allows more flexibility & new plugins/protocols in the future without having to micromanage sources.list. 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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.debian.devel
csiph-web