Hi,
On 10.09.21 01:46, Paul Wise wrote:
Another important argument is that it creates a dependency on
third-party commercial CDNs, and their *continued* sponsorship.
This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the scale needed
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
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
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
On Thu, Sep 9, 2021 at 6:03 PM Simon Richter wrote:
> Another important argument is that it creates a dependency on
> third-party commercial CDNs, and their *continued* sponsorship.
This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the
Hi,
On 04.09.21 22:12, Hideki Yamane wrote:
The TLS layer is not part of the security model, so we'd be teaching
users to look for the wrong thing, kind of like the "encrypted with SSL"
badges on web pages in the 90ies.
Is there any strong reason to use HTTP than HTTPS now?
The
* Michael Stone [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
On Thu, Sep 09, 2021 at 02:54:21PM +0200, Timo Röhling wrote:
* Michael Stone [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
* Michael Stone [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
On Thu, Sep 09, 2021 at 08:36:28AM +0200, Timo Röhling wrote:
* Michael Stone [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
* Michael Stone [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
2021, സെപ്റ്റംബർ 9 4:42:18 AM IST, Michael Stone ൽ എഴുതി
>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
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
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
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
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
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
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
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
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
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
On Fri, Sep 03, 2021 at 02:42:29AM +, Paul Wise wrote:
> httpredir.d.o was an alternative CDN-like thing that was based on HTTP
> redirects to the mirror network. It had lots of problems, but now that
> we have a mirror checker and zzz-dists, perhaps it could work better.
> The mirror://
On Thu, 2 Sep 2021 21:26:11 +0200
Simon Richter wrote:
> The TLS layer is not part of the security model, so we'd be teaching
> users to look for the wrong thing, kind of like the "encrypted with SSL"
> badges on web pages in the 90ies.
Is there any strong reason to use HTTP than HTTPS now?
Hi,
On 03.09.21 13:11, Simon Richter wrote:
[Revocation mechanism]
If we don't have one, shouldn't we worry more about that given the
widespread use of TLS?
We have a big hammer, shipping a new ca-certificates package. If we want
something that only affects apt, but not other packages, that
On Fri, 2021-09-03 at 13:11 +0200, Simon Richter wrote:
> > > - If I deselect all CAs in the configuration dialog of the
> > > ca-certificates package, what mechanism will allow apt to work?
>
> > If people intentionally detrust them, they have to deal with the
> > fallout.
>
> So this
Hi,
On 02.09.21 23:02, Ansgar wrote:
As it is now, I can install a Debian system where no X.509
certificate authorities are trusted.
That doesn't change with the proposal?
- If I deselect all CAs in the configuration dialog of the
ca-certificates package, what mechanism will allow apt
On Thu, Sep 2, 2021 at 9:06 PM Ansgar wrote:
> Accessing www.debian.org will also not work on such systems (and unlike
> deb.d.o that does not even offer non-https). It's not Debian's problem.
The Tor onion services offer alternatives to the https PKI:
https://onion.debian.org/
> Is replacing
On Thu, 2021-09-02 at 21:26 +0200, Simon Richter wrote:
> As it is now, I can install a Debian system where no X.509
> certificate authorities are trusted.
That doesn't change with the proposal?
> - If I deselect all CAs in the configuration dialog of the
> ca-certificates package, what
Hi,
On 02.09.21 03:22, Hideki Yamane wrote:
Providing "default secure setting" is good message to users.
The TLS layer is not part of the security model, so we'd be teaching
users to look for the wrong thing, kind of like the "encrypted with SSL"
badges on web pages in the 90ies.
We
On 2021-09-02 12:27:34 -0400 (-0400), Roberto C. Sánchez wrote:
[...]
> In this context, it might make sense to describe using HTTPS as
> the transport for APT operations is providing "default
> confidentiality".
Which, as similarly discussed, it really doesn't do either (because
of deterministic
On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
[...]
> Providing "default secure setting" is good message to users.
[...]
As previously covered, I'd suggest steering clear of referring to
this as adding "default security." That implies APT wasn't already
effectively secure over plain
On Thu, Sep 02, 2021 at 04:08:37PM +, Jeremy Stanley wrote:
> On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
> [...]
> > Providing "default secure setting" is good message to users.
> [...]
>
> As previously covered, I'd suggest steering clear of referring to
> this as adding
Hi,
On Wed, 01 Sep 2021 07:46:07 -0700
Russ Allbery wrote:
> >> I believe that the discussion has later identified that doing so would
> >> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> >> security benefits are not strong (beyond embracing good habits), I
> >> think the
Ansgar writes:
> On Wed, 2021-09-01 at 11:15 +0200, Helmut Grohne wrote:
>> I believe that the discussion has later identified that doing so would
>> break squid-deb-proxy-client and auto-apt-proxy. Given that the
>> security benefits are not strong (beyond embracing good habits), I
>> think the
On Wed, 2021-09-01 at 11:15 +0200, Helmut Grohne wrote:
> I believe that the discussion has later identified that doing so
> would
> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> security
> benefits are not strong (beyond embracing good habits), I think the
> reasonable thing
Control: tags -1 + moreinfo
On Sun, Aug 22, 2021 at 09:56:57PM +0900, Hideki Yamane wrote:
> As we discussed on -devel(*), it seems that we can enable https for
> {deb,security}.debian.org by default. With this bug report, I'll
> collect related things and fix it.
I believe that the
Package: general
Severity: wishlist
Dear developers,
As we discussed on -devel(*), it seems that we can enable https for
{deb,security}.debian.org by default. With this bug report, I'll
collect related things and fix it.
- Update mirror list (how?)
- Update security mirror setting in d-i
37 matches
Mail list logo
