Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #101278 > unrolled thread

Bug#992692: general: Use https for {deb,security}.debian.org by default

Back to article view | Back to linux.debian.devel

Contents

  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 3 of 3 — ← Prev page 1 2 [3]

#101639 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

[Multipart message — attachments visible in raw view] — view raw

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.

(The Tor to https fallback can be done already if we talk onion services
 to others. You can't fall out of Tor – or redirect into it – through as
 that would allow bad actors to discover who you are/that you have an
 operational tor client installed. proxy configuration you can already
 change programmatically on the fly – a job auto-apt-proxy implements –,
 changing the mirror file with a hook from your network manager would
 be equally easy.)


> 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.


Best regards

David Kalnischkies

[toc] | [prev] | [next] | [standalone]

#101642 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

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 
separate the definition of what set of debian packages to use from the 
decision of how to get those packages *when using apt*, so that there 
are fewer things to consider in the common case, and to allow new 
capabilities in uncommon cases. If someone's using some other tool, why 
would anyone assume that the same configuration syntax would work? Just 
use the same configuration file you use now, and ignore all of this. If 
you want configurations to match across tools, then ignore all of this 
again and keep the same sources.list syntax you're already using that 
presumably does what you want.

>> 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.

The intent would be to make it easier to plug other tools into apt,
not to have the apt codebase do everything.

>> 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. 

[toc] | [prev] | [next] | [standalone]

#101644 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

[Multipart message — attachments visible in raw view] — view raw

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).


> > 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

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).

The configuration option which only works with apt tools already
exists in the form of the mirror method…


> > > 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.


Best regards

David Kalnischkies

[toc] | [prev] | [next] | [standalone]

#101645 — 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.

[toc] | [prev] | [next] | [standalone]

#101663

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

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101683 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 12, 2021 at 03:10:27AM +0000, Paul Wise wrote:
> ISTR the future of creating new Debian installations is to move from
> debootstrap to dpkg/apt. As an interim step, debootstrap could [...]

I've switched all my occurances of using debootstrap to mmdebstrap and
am a very happy user of it.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#101687 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 12, 2021 at 03:10:27AM +0000, Paul Wise wrote:
> 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

The spec deals with the installation of the essential set.
APT isn't essential – it is 'only' one of the first packages installed
after the bootstrap is done, usually at least.

Moving {,c}debootstrap to use apt means you increase the system
requirements from "can execute debootstrap" all the way up to "is
a fully bootstrapped Debian-based system". At which point you could
just use mmdebstrap instead of debootstrap and be done.

I am not involved with d-i to know if they would plan such a move, but
I have at least never heard of it and it seems outside the linked spec.
You might have confused this with the pipe-dream of obsoleting
mmdebstrap at some far away in the future point by folding it into apt
directly. The spec is one (of the many) pre-requirements for that.


Even if we do, that would move the goal post only slightly as you still
have the problem that the conf used to create the system might very well
not be the conf that can be used by the created system (as a trivial
example some old apt versions do not support https). That doesn't really
change regardless of using anna, debootstrap, apt or whatever else.


Best regards

David Kalnischkies

P.S.: Having apt be involved in its own bootstrap reminds me of that
time when I saved myself from drowning in a swamp by pulling on my hair…
https://en.wikipedia.org/wiki/Baron_Munchausen#Fictional_character

[toc] | [prev] | [next] | [standalone]

#101628 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote:
> 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?

I believe that the target audience is non-tech end-users. Most
orgnizations already optimized their way of downloading .debs via some
way (e.g. auto-apt-proxy) or another. As you point out, organizations
are easily able to deviate from defaults. They're not our primary target
with defaults.

Laptops of end-user systems are the target, but also developers. When
people gather at a place (conference, hackspace, private meetup, etc.)
downloading of .debs should just work quickly by default. Many such
sites could easily provide a local cache and a number even do. BSPs tend
to have a blackboard with information including the local mirror to use.
Seriously, how many people change their mirror when they go to a BSP? If
we installed auto-apt-proxy by default, much of the local caching would
just work.

The thing we seem to be disagreeing on is what is more important? https
by default or quick and efficient downloads? Some may think that our
CDN can handle the load just fine and the effects of caching are
peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8
days waiting for downloads) for me.

I see that we've given up on a global network of independently-managed
mirrors and that CDNs are way easier at this time. While initially CDNs
had bad reliability issues, those have completely vanished in my
experience. On the other hand, local caching still outperforms CDNs by a
factor of 10 or so. I'd love to make it the default.

Helmut

[toc] | [prev] | [next] | [standalone]

#101629

On Fri, 2021-09-10 at 09:33 +0200, Helmut Grohne wrote:
> If
> we installed auto-apt-proxy by default, much of the local caching
> would
> just work.

If you push for a local caching method to be used by default, apt
should always request (In)Release.gpg from a regular mirror (not auto-
discovered local cache), preferably via HTTPS; for subsequent data
(which apt can verify via (In)Release) a local mirror can be used,
falling back to the regular mirror when the data provided by the local
cache is not correct for any reason.

Especially at BSPs where people are likely to bootstrap new
environments (via debootstrap, for example for building packages) we
would allow downgrade attacks otherwise: (In)Release for stable
releases has no Valid-Until, so any initial (In)Release file can be
substituted by the cache operator for an older one which then refers to
known-vulnerable packages. (And I'm not sure debootstrap even checks
Valid-Until.)

Ansgar

[toc] | [prev] | [next] | [standalone]

#101635 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote:
>Laptops of end-user systems are the target, but also developers. When
>people gather at a place (conference, hackspace, private meetup, etc.)
>downloading of .debs should just work quickly by default. Many such
>sites could easily provide a local cache and a number even do. BSPs tend
>to have a blackboard with information including the local mirror to use.
>Seriously, how many people change their mirror when they go to a BSP? If
>we installed auto-apt-proxy by default, much of the local caching would
>just work.

I think you'd get a lot of pushback on installing auto-apt-proxy by 
default. If that's a proposal, make it seperately and not in this 
thread. 

>The thing we seem to be disagreeing on is what is more important? https
>by default or quick and efficient downloads? Some may think that our
>CDN can handle the load just fine and the effects of caching are
>peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8
>days waiting for downloads) for me.

>I see that we've given up on a global network of independently-managed
>mirrors and that CDNs are way easier at this time. While initially CDNs
>had bad reliability issues, those have completely vanished in my
>experience. On the other hand, local caching still outperforms CDNs by a
>factor of 10 or so. I'd love to make it the default.

I use a cache out of habit and to be a good netizen, but my internet 
connection is fast enough these days that it's basically a noop at best 
and a slight slowdown at worst. I had to move the cache from slow/cheap 
spinning disk to reasonably fast SSD to get to that point. If you're 
downloading the same stuff over and over (e.g., for testing or somesuch) 
it can be a big win, especially for VMs on a virtualized network 
connection, or if you're managing a large infrastructure, but 
for normal use with a couple of instances? It's just not worth the 
trouble. 

[toc] | [prev] | [next] | [standalone]

#101720 — Bug#994409: task-laptop: please recommend automatic apt proxying

[Multipart message — attachments visible in raw view] — view raw

Package: task-laptop
Version: 3.53
Severity: wishlist

I'm not sure on the difference between auto-apt-proxy and
squid-deb-proxy-client. Avahi is already pulled in by task-laptop.


On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote:
> > 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
> 
> Laptops of end-user systems are the target, but also developers. When
> people gather at a place (conference, hackspace, private meetup, etc.)
> downloading of .debs should just work quickly by default. Many such
> sites could easily provide a local cache and a number even do. BSPs tend
> to have a blackboard with information including the local mirror to use.
> Seriously, how many people change their mirror when they go to a BSP? If
> we installed auto-apt-proxy by default, much of the local caching would
> just work.



-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (100, 'buster-fasttrack'), (100, 'buster-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages task-laptop depends on:
ii  anacron  2.3-28
ii  tasksel  3.53

Versions of packages task-laptop recommends:
ii  avahi-autoipd   0.7-4+deb10u1
ii  bluetooth       5.50-1.2~deb10u2
ii  iw              5.0.1-1
ii  powertop        2.8-1+b2
ii  wireless-tools  30~pre9-13
ii  wpasupplicant   2:2.7+git20190128+0c1e29f-6+deb10u3

task-laptop suggests no packages.

-- no debconf information

[toc] | [prev] | [next] | [standalone]

#101721 — Re: task-laptop: please recommend automatic apt proxying

Phil Morrell <debian@emorrp1.name> writes:

> Package: task-laptop
> Version: 3.53
> Severity: wishlist

> I'm not sure on the difference between auto-apt-proxy and
> squid-deb-proxy-client. Avahi is already pulled in by task-laptop.

Please do not do this.  I do not want to have to reason about the security
impact of someone who controls local DNS taking over my apt sources.  I
understand that people believe that this is harmless because of apt
signature checking, but it still opens more attack paths and routes to
exercise other possible vulnerabilities.

The safe default for Debian in any standard installation mode, which I
believe includes tasks, is to talk explicitly to Debian infrastructure.
If people would like to improve local performance, they should automate
the configuration of the machines that they control, with the permission
and understanding of the people who are using those machines.

We should not enable people who control the local network but not the
Debian system to dynamically change security-relevant configuration of
that system, which I believe includes apt sources, without explicit
permission.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#101722 — Re: task-laptop: please recommend automatic apt proxying

Russ Allbery <rra@debian.org> writes:

> Please do not do this.  I do not want to have to reason about the
> security impact of someone who controls local DNS taking over my apt
> sources.

Incidentally, this is also exactly why I believe we should be using https
by default, so that a compromise of the local DNS to point to an untrusted
apt server fails at the TLS certificate validation stage rather than
continuing on to talk to an untrusted apt server for sufficiently long to
start downloading files and checking signatures and thus exposing more
attack surface.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#102723 — Bug#992692: next steps

I fully support the idea that HTTPS should become the default for apt repos. 
 From what I gather, the open question is how best to handle auto-apt-proxy 
configuration.  There seems to be a number of reasonable proposals:

* Make auto-apt-proxy set "Acquire::https::Verify-Peer false;"
* automate setting http at install time using preseed with auto-apt-proxy
   asking this as a debconf question.
* Users can always later edit the sources.list.  In the context of a BSP or
   DebConf, that is a very reasonable thing to ask.

auto-apt-proxy sounds like a nice feature, but it also adds security risks.  We 
also need to consider that.  Users should get best practice security without 
thinking about it at all.  That's HTTPS these days, despite its imperfections. 
Not defaulting to HTTPS means people have to be aware that HTTP is the default, 
then consider using HTTPS.  We should of course make it as easy as possible to 
use caching proxies, that also comes with a responsibility in making the sure 
aware that it adds small but present security risks.  So a debconf question in 
auto-apt-proxy seems like a good place for that.

For those who think that apt's GPG verification is enough, consider these CVEs:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1358
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1829
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3587
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1252
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0501
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462

For more on this whole topic, I wrote up a blog post based on my previous 
research and these ongoing discussions:
https://guardianproject.info/2021/12/08/debian-over-https/

[toc] | [prev] | [next] | [standalone]

#104023 — Bug#992692: more steps towards this goal

Another step towards this goal: the official Debian Vagrant images will default 
to HTTPS:
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/15

There are already many Debian mirrors that support HTTPS, not just CDNs.  Here's 
a script to find HTTPS mirrors
https://gist.github.com/HacKanCuBa/e3a998d68a82f81dbf11f2cce4f26d04

I think all mirrors should support HTTPS (this is a requirement for f-droid.org 
mirrors), so I filed a bug to track that:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008652

[toc] | [prev] | [next] | [standalone]

#104026 — Bug#992692: moar

There is also discussion about making the official Debian Docker images use HTTPS:

https://github.com/debuerreotype/docker-debian-artifacts/issues/15

[toc] | [prev] | [next] | [standalone]

#104027 — Bug#992692: link

iHTH https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008652

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.debian.devel

csiph-web