Just received this.
This is to let others know of such attacks
Ursprüngliche Nachricht
Von: "debian.org Service"
Gesendet: 12. Oktober 2022 18:41:11 MESZ
An: holg...@debian.org
Betreff: holg...@debian.org Authentication/Restriction
[ holg...@debian.org ] Accou
"LeJacq, Jean Pierre" writes:
> There are standard best practices for forwarding support in SPF.
>
> http://www.open-spf.org/Best_Practices/Forwarding/
Well, if it only was that simple.
There is NO working SRS software/example config for sendmail in Debian
or anywhere else AFAICS.
The only
On Fri, 4 Mar 2022 at 23:34, Ansgar wrote:
> On Fri, 2022-03-04 at 13:27 +0100, Stephan Lachnit wrote:
> > On Fri, Mar 4, 2022 at 12:47 PM Baptiste Beauplat
> > wrote:
> > > As a reminder debian.org addresses does support DKIM. After
> > > configuration on your
Baptiste Beauplat wrote:
>We recently discovered that Gmail started to bounce email from
>mentors.debian.net with the following message:
>
>550-5.7.26 This message does not have authentication information or
>fails to 550-5.7.26 pass authentication
> checks. To best protect our users from spam,
they are using a non-standard header that other
provider/tools might miss. Just a thought.
>
No irony, you are just missing the point.
gmail uses this X header for internal purposes, and there is no DKIM
signature because the message has a @debian.org 822.from address hence
gmail obviously lacks a valid
On Fri, 2022-03-04 at 13:27 +0100, Stephan Lachnit wrote:
>> Can you point to some quick guide on how to do this for gmail? The
>> support page seems kinda confusing to me.
> This usually requires you running your own mail server (for outgoing
> mail).
> I don't think mail providers like GMail
On Friday, March 4, 2022 12:37:38 PM EST Ansgar wrote:
> On Fri, 2022-03-04 at 10:21 -0500, LeJacq, Jean Pierre wrote:
> > There are standard best practices for forwarding support in SPF.
> >
> > http://www.open-spf.org/Best_Practices/Forwarding/
>
> Having each individual user have to configure
On Fri, 2022-03-04 at 10:21 -0500, LeJacq, Jean Pierre wrote:
> There are standard best practices for forwarding support in SPF.
>
> http://www.open-spf.org/Best_Practices/Forwarding/
Having each individual user have to configure forwarders (i.e., per-
user whitelists), including services like
on-standard header that other
> provider/tools might miss. Just a thought.
No irony, you are just missing the point.
gmail uses this X header for internal purposes, and there is no DKIM
signature because the message has a @debian.org 822.from address hence
gmail obviously lacks a valid key for
ult is currently broken (see #939808). The patch
> attached there is not helpful for local usage, so you might want
> something like what I've got in my config:
[...]
Useful to know - thanks!
--
Colin Watson (he/him) [cjwat...@debian.org]
On Friday, March 4, 2022 10:14:09 AM EST Ansgar wrote:
> On Fri, 2022-03-04 at 15:45 +0100, Baptiste Beauplat wrote:
> > However for SPF, if I'm not mistaken, this is not possible for
> > @debian.org addresses since Debian does not offers an MSA and
> > therefor not a singl
these in place to protect email.
> >
> > As an example, we may be spoofing mentors.debian.net with wv-debian-
> > mentors1.wavecloud.de (not 100% clear with the headers provided). SPF
> > could
> > handle this.
>
> Indeed we are looking into it for mentors.
>
On Fri, 2022-03-04 at 15:45 +0100, Baptiste Beauplat wrote:
> However for SPF, if I'm not mistaken, this is not possible for
> @debian.org addresses since Debian does not offers an MSA and
> therefor not a single (or enumerable list of) exit point.
Using SPF would be possible. Ge
Hi!
On Fri, 2022-03-04 at 14:36:01 +, Colin Watson wrote:
> I reproduced a similar problem, then set up DKIM for myself and
> everything then worked, so I think you're correct.
>
> The links in the original d-d-a email were mostly stale, but I found
>
> mentors1.wavecloud.de (not 100% clear with the headers provided). SPF could
> handle this.
Indeed we are looking into it for mentors.
However for SPF, if I'm not mistaken, this is not possible for
@debian.org addresses since Debian does not offers an MSA and therefor
not a single (or
your email address
> From: mentors.debian.net
> To: **@gmail.com
> Date: Fri, 04 Mar 2022 03:14:03 -
> Message-ID: <164636364329.4074035.11224505717463252...@mentors.debian.net>
I don't see anything about debian.org in those headers? Do you?
- mentors.debian.net is not debian.
On Friday, March 4, 2022 9:15:59 AM EST Baptiste Beauplat wrote:
> >
> >> mentors.debian.net with the following message:
> > Can you please share the complete headers of the bounced message? Aka
> > the thing in the message/rfc822 part of the DSN message. Right now we
> > don't know what they
On 3/4/22 15:27, Bastian Blank wrote:
> I don't see anything about debian.org in those headers? Do you?
Ah, I see the confusion. Gmail reject ALL unauthenticated email, this
isn't specific to @debian.org addresses but it does, at least, affect mine.
We detected the issue on mentors (the bou
nicolas.com/server/exim-multi-domain-dkim-custom-selector/
helpful in getting this going with my local Exim setup.
--
Colin Watson (he/him) [cjwat...@debian.org]
Hi Bastian,
On 3/4/22 14:40, Bastian Blank wrote:
> On Fri, Mar 04, 2022 at 12:38:02PM +0100, Baptiste Beauplat wrote:
>> We recently discovered that Gmail started to bounce email from
>> mentors.debian.net with the following message:
>
> Can you please share the complete headers of the bounced
On Fri, Mar 04, 2022 at 12:38:02PM +0100, Baptiste Beauplat wrote:
> We recently discovered that Gmail started to bounce email from
> mentors.debian.net with the following message:
Can you please share the complete headers of the bounced message? Aka
the thing in the message/rfc822 part of the
Hi Stephan,
On 3/4/22 13:27, Stephan Lachnit wrote:
> On Fri, Mar 4, 2022 at 12:47 PM Baptiste Beauplat wrote:
>>
>> My debian address is also affected, and probably others that did not
>> setup DKIM for their @debian.org address.
>>
>> As a reminder debian.org a
On Fri, 2022-03-04 at 13:27 +0100, Stephan Lachnit wrote:
> On Fri, Mar 4, 2022 at 12:47 PM Baptiste Beauplat
> wrote:
> > As a reminder debian.org addresses does support DKIM. After
> > configuration on your mail server, you can publish your DKIM public
> > key
&g
On Fri, Mar 4, 2022 at 12:47 PM Baptiste Beauplat wrote:
>
> My debian address is also affected, and probably others that did not
> setup DKIM for their @debian.org address.
>
> As a reminder debian.org addresses does support DKIM. After
> configuration on your mail server, yo
has
been blocked. Please visit 550-5.7.26
https://support.google.com/mail/answer/81126#authentication for more 5
50 5.7.26 information.
My debian address is also affected, and probably others that did not
setup DKIM for their @debian.org address.
As a reminder debian.org addresses does support DKIM
On Sun, Sep 12, 2021 at 03:10:27AM +, 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
On Sun, Sep 12, 2021 at 03:10:27AM +, 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
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
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 t
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
> > >
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
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 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
>
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, Sep 10, 2021 at 12:00:57PM +0200, Timo Röhling wrote:
* Michael Stone [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
* Michael Stone [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
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
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 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
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
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
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
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, 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, 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: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 no
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
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://
HTTP than HTTPS now?
Should we teach all our users (including non-tech) about "Secure APT"
mechanism?
And I said about only deb.debian.org and security.debian.org, and
just "default" - it means it does provide http access too.
--
Regards,
Hideki Yamane henrich @ debian.org/iijmio-mail.jp
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 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
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
eason to not use https by default
> > for all other users.
>
> Completely agreed.
Providing "default secure setting" is good message to users.
Some users want proxy but they can configure their settings.
So just change "default setting for {deb,security
s.
Yes. For example, the approach used by apt-cacher-ng works fine.
Explicitly opting in to a local cache seems desirable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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
Processing control commands:
> tags -1 + moreinfo
Bug #992692 [general] general: Use https for {deb,security}.debian.org by
default
Added tag(s) moreinfo.
--
992692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
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.
TL;DR: Any encrypted transport protocol (e.g. https) breaks caching.
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> This could be useful for both the "I've got a slow uplink and would like
> it to not be overwhelmed at the BSP I'm hosting for my Debian friends"
> type as well
On Sat, Aug 21, 2021 at 10:28:04AM +0200, Wouter Verhelst wrote:
> On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote:
> > On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> > > On 8/19/21 3:46 PM, Simon Richter wrote:
> > > > For the most part, users would configure https if
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
On Sat, Aug 21, 2021 at 11:05:23PM +, Stephan Verbücheln wrote:
> What about HTTP 304 Not Modified?
What about them? Care to give details?
Note that APT nowadays hardly makes requests which can legally be
replied to with 304 as it knows which index files changed (or not)
based on comparing
What about HTTP 304 Not Modified?
Regards
On 2021-08-21 12:04:32 +0100 (+0100), Phil Morrell wrote:
> On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
[...]
> > However, I've not been able to come up with a scheme which is simple
> > enough to be doable on a LAN while at the same time be usable by larger
> > network
On Sat, Aug 21, 2021 at 09:45:54AM +0200, Tomas Pospisek wrote:
> On 21.08.21 09:14, Philipp Kern wrote:
> > defense in depth if we wanted to, but maybe the world just agreed that
> > you need to get your clock roughly correct. ;-)
>
> I remember seeing apt-get refusing to update packages or the
On Sat, Aug 21, 2021 at 12:04:32PM +0100, Phil Morrell wrote:
> On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> > On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> > > Yes transparent proxies or overridden DNS lookups could be used to
> > > direct deb.debian.org
On 8/20/21 4:56 PM, Russ Allbery wrote:
> Jeremy Stanley writes:
>
>> I agree with all of the above, my point was that the current state of
>> HTTPS doesn't especially improve integrity for Debian package management
>> over the signed indices and checksums we already rely on, and trying to
>>
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> > Yes transparent proxies or overridden DNS lookups could be used to
> > direct deb.debian.org and security.debian.org to your alternative
> > location,
>
> I've
Wouter Verhelst writes:
> On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
>> Yes transparent proxies or overridden DNS lookups could be used to
>> direct deb.debian.org and security.debian.org to your alternative
>> location,
>
> I've been thinking for a while that we should bake
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
> On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote:
> > Yes transparent proxies or overridden DNS lookups could be used to
> > direct deb.debian.org and security.debian.org to your alternative
> > location,
>
> I've
On Sat, Aug 21, 2021 at 12:31:26PM +0200, Simon Richter wrote:
> Hi,
>
> On 21.08.21 10:40, Wouter Verhelst wrote:
>
> > I've been thinking for a while that we should bake a feature in apt
> > whereby a network administrator can indicate somehow that there is a
> > local apt mirror and that apt
Hi,
On 21.08.21 10:40, Wouter Verhelst wrote:
I've been thinking for a while that we should bake a feature in apt
whereby a network administrator can indicate somehow that there is a
local apt mirror and that apt should use that one in preference to
deb.debian.org.
I've been thinking the
etwork providers, *and* which can't also be abused by MitM attackers.
Perhaps it's just not something we would be able to do?
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
or anyone else who might be
> > listening.
>
> While this does complicate it, a snooping party can still know the
> site they're connecting to via SNI happening unencrypted,
SNI is not unencrypted if you do TLS1.3...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
On 21.08.21 09:14, Philipp Kern wrote:
On 20.08.21 21:11, Russ Allbery wrote:
The way I would put it is that the security benefit of using TLS for apt
updates is primarily that it makes certain classes of attempts to mess
with the update channel more noisy and more likely to produce immediate
Hi all,
Thanks for your comments!
It seems that no big blocker to make https default for deb.debian.org
and security.debian.org.
On Thu, 19 Aug 2021 22:38:20 +0900
Hideki Yamane wrote:
> Now deb.debian.org and security.debian.org provide https access
> but created sources.list file use
On 20.08.21 21:11, Russ Allbery wrote:
The way I would put it is that the security benefit of using TLS for apt
updates is primarily that it makes certain classes of attempts to mess
with the update channel more noisy and more likely to produce immediate
errors.
One thing of note is that it
On Sat, 21 Aug 2021, Vincent Lefevre wrote:
On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
The most naive attempt to mess with the update channel (intercepting the
http connection and replacing a package with a malicious one) will fail
immediately with both http or https. The primary
On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
> The most naive attempt to mess with the update channel (intercepting the
> http connection and replacing a package with a malicious one) will fail
> immediately with both http or https. The primary difference in that case
> with https is that
an mirrors seems like something we should not support.
Agreed. This seems like a feature, not a bug.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
On Fri, 2021-08-20 at 23:37 +0200, Simon Richter wrote:
> I was thinking of VPS hosting for the most part, where users will run
> apt or auto-apt inside their virtual server.
Hosting providers or ISPs messing with their customers' traffic with
Debian mirrors seems like something we should not
Hi,
On 8/20/21 9:04 PM, Russ Allbery wrote:
One of the things that confuses me about this user story is why are your
containers doing non-trivial amounts of apt traffic at runtime? Generally
the whole point of a container is that you only do this during container
build time. I'm not sure I
On Fri, 2021-08-20 at 12:11 -0700, Russ Allbery wrote:
> The way I would put it is that the security benefit of using TLS for apt
> updates is primarily that it makes certain classes of attempts to mess
> with the update channel more noisy and more likely to produce immediate
> errors.
APT is not
1 - 100 of 828 matches
Mail list logo
