On Thu, Jun 01, 2023 at 07:07:04AM -0400, Michael Lazin wrote:
> I realize it is work but it would be good if apt had an option for https.
It does.
> You can still update with FTP mirrors. Wouldn't it be a good idea to allow
> using https and keep http as a fall back for those who need an http mi
I realize it is work but it would be good if apt had an option for https.
You can still update with FTP mirrors. Wouldn't it be a good idea to allow
using https and keep http as a fall back for those who need an http mirror?
Thank you,
Michael Lazin
.. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.
O
On Thu, Jun 1, 2023, 02:08 Simon Richter wrote:
>
> The reason for the change is that it reduces user confusion. Users are
> learning that unencrypted HTTP has neither integrity nor
> confidentiality, and that they should actively check that web sites use
> HTTPS, so we have gotten several inquir
Hi,
- when you use switches, the local network segment has no other nodes
- if there were other nodes, they would likely miss some packets in
the conversation, which means they cannot generate checksums
- there is no software that can perform this inspection
Yep, there are limitation
Hi Simon - thanks for the response. Please find my reply inline below:
On Wed, 31 May 2023 at 11:07, Simon Richter wrote:
>
> On 5/31/23 05:42, James Addison wrote:
>
> >* It allows other devices on the local network segment to inspect the
> > content that other nodes are sending and re
Hi,
On 5/31/23 05:42, James Addison wrote:
* It allows other devices on the local network segment to inspect the
content that other nodes are sending and receiving.
That is very theoretical:
- when you use switches, the local network segment has no other nodes
- if there were other
In follow-up to: https://lists.debian.org/debian-devel/2016/10/msg00592.html
As an update here: the default recommendation in the Debian release notes now
recommends[1] HTTPS instead of HTTPS by default.
Despite the validity of many of the theoretical concerns about APT over HTTP,
I reckon that t
On Fri, 11 Nov 2016, Christoph Biedl wrote:
> a proof of concept for all this (I can resist, though). The apt programs
> could obfuscate their request behaviour, the TLS layer could add random
> padding of data and time, but I doubt this would help much.
AFAIK, the TLS layer *does* bit-stuffing an
Henrique de Moraes Holschuh wrote...
> There are some relevant issues, here.
>
> 1. It does protect against passive snooping *from non-skilled
> attackers*.
Well, yes, no. The tools become better so thinking a few years into
the future sophisticated programs for that purpose might be available t
On Thu, Nov 10, 2016 at 12:39:40PM -0200, Henrique de Moraes Holschuh wrote:
> I'd prefer if we enhanced apt transports to run a lot more protected
> (preferably under seccomp strict) before any such push for enabling
> https transports in apt. It would reduce the security impact a great
> deal.
On Mon, Oct 24, 2016, at 00:28, Russ Allbery wrote:
> The value of HTTPS lies in its protection against passive snooping.
There are some relevant issues, here.
1. It does protect against passive snooping *from non-skilled
attackers*. And this is not being made anywhere clear enough.
2. It is u
On Sun, Nov 06, 2016 at 12:03:03AM +0100, Philipp Kern wrote:
> On 2016-11-05 22:23, Adrian Bunk wrote:
> > The solution you are trying to sell is apt-transport-https as default.
> [...]
> > Your solution would be a lot of work with relatively little improvement.
>
> Well, the client-side exists a
On 2016-11-05 22:23, Adrian Bunk wrote:
The solution you are trying to sell is apt-transport-https as default.
[...]
Your solution would be a lot of work with relatively little
improvement.
Well, the client-side exists and works. Then it boils down if the mirror
sponsors would be willing to
On Tue, Oct 25, 2016 at 11:06:23AM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> So, I'm not quite sure how to put this, since I don't know how much work
> you've done professionally in computer security, and I don't want to
> belittle that. It's entirely possible that we have equivalen
On Thu, Oct 27, 2016 at 10:05:56PM +0200, Tollef Fog Heen wrote:
> ]] David Kalnischkies
> > I would kinda like to avoid encoding the entire answer and sending that
> > in for display because it would be a lot of noise (and bugreporters will
> > truncate it if it is too long trying to be helpful),
]] Adam Borowski
> Despite many fast mirrors nearby, deb.debian.org almost always connects me
> to a server in the US (I got NL just once). Tried from three ISPs.
Is this on IPv6 or legacy IP? The former is known to be less-than-ideal
routing-wise in a bunch of cases and I'll talk to Fastly to
Hi!
On Mon, 2016-10-24 at 11:51:00 -0400, Paul Tagliamonte wrote:
> On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> > It is also evident that there are some challenges for deploying TLS on
> > a mirror network and/or CDN. I don't think anyone is suggesting
> > tearing down our exis
On Thu, Oct 27, 2016 at 08:35:18AM +0200, Vincent Bernat wrote:
> ❦ 17 octobre 2016 20:49 +0200, Vincent Bernat :
> >> TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
> >> use e.g. in base images (including for Jessie)?
>
> When I said that, I was using cdn-fastly-v6.deb.
On 10/27/2016 12:40 PM, Russell Stuart wrote:
> It's *far* better than httpredir. But given adding httpredir as a
> backup has become a net negative for me, that's not saying much.
> deb.debian.org so far has been net positive.
As a counter-point - in order to give credit where it's due - I had
]] David Kalnischkies
> I would kinda like to avoid encoding the entire answer and sending that
> in for display because it would be a lot of noise (and bugreporters will
> truncate it if it is too long trying to be helpful), so if people who
> actually know what they would need to deal with issu
On Thu, 2016-10-27 at 08:35 +0200, Vincent Bernat wrote:
> Moreover, the download speed can be very slow, either from work or
> from home (100M fiber connection). Sometimes 100kbytes/s. That's a
> pain.
>
> I am a bit worried for deb.debian.org to become a default as it
> doesn't work well for me.
❦ 17 octobre 2016 20:49 +0200, Vincent Bernat :
>> TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
>> use e.g. in base images (including for Jessie)?
>
> I get a 404 from time to time. Doing a second apt full-upgrade fixes the
> issue. This works far better than httpredir
On Wed, Oct 26, 2016 at 08:38:33AM +0200, Philipp Kern wrote:
> On 10/24/2016 09:19 AM, Tollef Fog Heen wrote:
> > ]] Philipp Kern
> >> It's also a little awkward that apt does not tell you which of the SRV
> >> records it picked. (The "and why" is clear: round robin.) I had a short
> >> read earl
On 10/24/2016 09:19 AM, Tollef Fog Heen wrote:
> ]] Philipp Kern
>> On 10/18/2016 06:47 PM, Marco d'Itri wrote:
>>> On Oct 17, Ian Campbell wrote:
Have we gotten to the point where we consider deb.d.o suitable for
production use? The web page still says Experimental (so I would assume
>
Adrian Bunk writes:
> If I were looking at the apt traffic, the most interesting for me would
> be the traffic to security.debian.org that a computer running Debian
> stable usually produces.
> Just collecting the data when and how much HTTPS traffic is happening
> should be sufficient to deter
On Tue, 25 Oct 2016, Ian Jackson wrote:
> Adrian Bunk writes ("Re: client-side signature checking of Debian archives
> (Re: When should we https our mirrors?)"):
> > snake oil
> > snake oil
>
> The phrase "snake oil" is very insulting. I have asked y
Adrian Bunk writes ("Re: client-side signature checking of Debian archives (Re:
When should we https our mirrors?)"):
> snake oil
> snake oil
The phrase "snake oil" is very insulting. I have asked you several
times to to stop.
Publicly CCing listmaster this ti
On Mon, Oct 24, 2016 at 04:33:57PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> > I would assume this can be pretty automated, and that by NSA standards
> > this is not a hard problem.
>
> Since the entire exchange is encrypted, it's not completely trivial to map
> size of data transfe
Paul Wise writes:
> Debian has Tor onion service frontends to various Debian services,
> including several Debian machines with archive mirrors, this is
> implemented in an automated way using Puppet and onionbalance. So we do
> not rely on Tor exit nodes, just relays and the onion service system
On Tue, Oct 25, 2016 at 7:33 AM, Russ Allbery wrote:
> Tor is easier for us as a project, since we don't really have to do
> anything (assuming we just rely on existing exit nodes).
Debian has Tor onion service frontends to various Debian services,
including several Debian machines with archive m
Adrian Bunk writes:
> The government operating or having access to the mirror you are using is
> a lot more realistic and easier than the MITM with a fake certificate
> you were talking about.
Both of those were also in the category of things that I think are
unlikely attacks unless the governme
On Mon, Oct 24, 2016 at 09:22:39AM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>
> >>...
> >> The value of HTTPS lies in its protection against passive snooping. Given
> >> the sad state of the public CA infrastructure, you c
On Mon, Oct 24, 2016 at 07:26:37PM +0200, Tollef Fog Heen wrote:
> ]] Paul Tagliamonte
> > On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> > > It is also evident that there are some challenges for deploying TLS on
> > > a mirror network and/or CDN. I don't think anyone is suggestin
Hi Kristian,
To one of your side questions,
On 24.10.2016 02:33, Kristian Erik Hermansen wrote:
>> 1) Checking chain (e.g. gpgv and its callers) have bugs. True, same as
>> checking layer for secure transports also have bugs.
>
> Agreed. Please let me know of a good test case to validate that y
]] Paul Tagliamonte
> On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> > It is also evident that there are some challenges for deploying TLS on
> > a mirror network and/or CDN. I don't think anyone is suggesting
> > tearing down our existing mirror network.
>
> https://deb.debian.
On Mon, Oct 24, 2016 at 06:52:41PM +0200, Ansgar Burchardt wrote:
> deb.debian.org has a debian-security area, so security updates should
> also be available via https:// now.
yes, they are, thanks!
--
cheers,
Holger
signature.asc
Description: Digital signature
Adrian Bunk writes ("Re: When should we https our mirrors?"):
> My point is that for the problem Kristian is describing,
> using https is just snake oil.
Since you haven't stopped being rude just because I asked, I have
emailed listmaster.
Russ's recent posting is a
On Mon, 2016-10-24 at 16:30 +, Holger Levsen wrote:
> On Mon, Oct 24, 2016 at 11:51:00AM -0400, Paul Tagliamonte wrote:
> > https://deb.debian.org/ is now set up (thanks, folks!)
>
> whoohooo, & it works on stable too! apt install apt-transport-https
> was
> all it took. (and changing the entr
On Mon, Oct 24, 2016 at 11:51:00AM -0400, Paul Tagliamonte wrote:
> https://deb.debian.org/ is now set up (thanks, folks!)
whoohooo, & it works on stable too! apt install apt-transport-https was
all it took. (and changing the entries in sources.list to that…)
Just security.d.o (or rather, it's su
Adrian Bunk writes:
> On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>>...
>> The value of HTTPS lies in its protection against passive snooping. Given
>> the sad state of the public CA infrastructure, you cannot really protect
>> against active MITM with HTTPS without certificate
On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: When should we https our mirrors?"):
>...
> Adrian:
> > Noone is arguing that switching to https would be a bad thing,
> > but whether or not it will happen depends solely on whe
On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> It is also evident that there are some challenges for deploying TLS on
> a mirror network and/or CDN. I don't think anyone is suggesting
> tearing down our existing mirror network.
https://deb.debian.org/ is now set up (thanks, folks!
Adrian Bunk writes ("Re: When should we https our mirrors?"):
> On Mon, Oct 24, 2016 at 04:00:49AM -0700, Kristian Erik Hermansen wrote:
> > so I also probably
> > shouldn't consider your TLS knowledge very highly...
>
> Your incorrect claims won't bec
On Mon, Oct 24, 2016 at 04:00:49AM -0700, Kristian Erik Hermansen wrote:
> On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk wrote:
> but also I should point out that your email is being routed
> insecurely via welho.com and lacks TLS in transit, so I also probably
> shouldn't consider your TLS knowled
On Mon, Oct 24, 2016 at 2:33 AM, Adrian Bunk wrote:
> You are implicitely assuming that mirrors can be trusted,
> and even that is not true.
No, not actually. Just presuming that NSA doesn't operate ALL mirrors.
Of course they can operate single servers or a number of servers, but
that increases
On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk wrote:
> It is a common misconception that https could help against these kinds
> of attacks.
>
> https is an improvement over http and it would be good if Debian could
> switch to https by default in stretch, but for the problem you are
> talking about
On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>...
> The value of HTTPS lies in its protection against passive snooping. Given
> the sad state of the public CA infrastructure, you cannot really protect
> against active MITM with HTTPS without certificate pinning.
You are implicite
On Sun, Oct 23, 2016 at 06:04:50AM -0700, Kristian Erik Hermansen wrote:
>...
> The main issue is that a well positioned attacker, such as the NSA or
> Chinese router admins, have the ability to collect and analyze in
> real-time what systems have installed what patches installed by
> monitoring th
]] Philipp Kern
> On 10/18/2016 06:47 PM, Marco d'Itri wrote:
> > On Oct 17, Ian Campbell wrote:
> >> Have we gotten to the point where we consider deb.d.o suitable for
> >> production use? The web page still says Experimental (so I would assume
> > I do not think that it is appropriate for gene
Hi Russ, Kristian,
On 24.10.2016 07:19, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:28 PM, Russ Allbery wrote:
>> The idea is to *add* HTTPS protection on top of the protections we already
>> have. You're correct that it doesn't give you authentication of the
>> packages without a
On Sun, Oct 23, 2016 at 7:28 PM, Russ Allbery wrote:
> The idea is to *add* HTTPS protection on top of the protections we already
> have. You're correct that it doesn't give you authentication of the
> packages without a bunch of work, and we should assume that the general
> public CA system is c
"Eugene V. Lyubimkin" writes:
> I'm not sure that benefits outweight the costs. HTTPS requires that I
> trust the third-parties -- mirror provider and CA. Gpgv doesn't require
> third parties.
It's critical here that we do not drop GPG. We continue using GPG for the
integrity and authenticatio
On Sun, Oct 23, 2016 at 10:03 AM, Eugene V. Lyubimkin wrote:
> Thank you for the long list of examples what could go wrong. I'm happy I
> don't have urgent fixes to apply.
Well, I would say the privacy issues are rather concerning. Security
is generally broken down into at least the following th
On 10/18/2016 06:47 PM, Marco d'Itri wrote:
> On Oct 17, Ian Campbell wrote:
>> Have we gotten to the point where we consider deb.d.o suitable for
>> production use? The web page still says Experimental (so I would assume
> I do not think that it is appropriate for general use, since at least
> o
Hi,
[ please don't CC me directly ]
On 23.10.2016 17:20, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin
> wrote:
>> I'm a developer of a tool which downloads and validates Debian archives
>> in a similar way APT does.
>>
>> As you use the word "theoretical
Hi :)
On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin wrote:
> I'm a developer of a tool which downloads and validates Debian archives
> in a similar way APT does.
>
> As you use the word "theoretically", that suggests that practically
> one can bypass the validation. Could you please list a
Hello Kristian,
On 23.10.2016 15:04, Kristian Erik Hermansen wrote:
> [...]
> Although APT theoretically protects tampering of packages in transit
> over HTTP based on the signing key, there are numerous ways to exploit
> the plaintext HTTP protocol in transit and the way APT handles some
> aspect
Greetings list :)
> So, the real question:
>
> So, when are we going to push this? If not now, what criteria need to be
> met? Why can't we https-ify the default CDN mirror today?
>
> (Sadly this means my trick to MITM the debian mirrors with my LAN mirror
> breaks, but this strikes me as a featur
On Thu, 2016-10-20 at 13:25 +0200, Tollef Fog Heen wrote:
> ]] Ian Campbell
>
> >
> > Have we gotten to the point where we consider deb.d.o suitable for
> > production use? The web page still says Experimental (so I would assume
> > "not production yet")
>
> As of this morning, the bit about ex
]] Ian Campbell
> Have we gotten to the point where we consider deb.d.o suitable for
> production use? The web page still says Experimental (so I would assume
> "not production yet")
As of this morning, the bit about experimental was removed from the web
page.
--
Tollef Fog Heen
UNIX is user f
On Tue, Oct 18, 2016 at 01:58:10PM -0400, Robert Edmonds wrote:
> Since the Debian project controls the mirror client (in particular the
No. Debian "controls" 'a' client, not 'the' client. APT isn't used in
bootstrapping for example. Also proxy-setups are (potentially) not going
to work anymore le
On Mon, Oct 17, 2016 at 08:48:57PM +0200, Cyril Brulebois wrote:
> should revisit this setup when I find more time. There's also Pipeline-
> Depth option's being advertised as not supported for https, too.
Yes. apt-transport-https is on a pretty low priority maintainership wise
which if combined w
On Tue, 2016-10-18 at 18:47 +0200, Marco d'Itri wrote:
> On Oct 17, Ian Campbell wrote:
>
> > Have we gotten to the point where we consider deb.d.o suitable for
> > production use? The web page still says Experimental (so I would assume
> I do not think that it is appropriate for general use, sin
On Oct 17, Ian Campbell wrote:
> Have we gotten to the point where we consider deb.d.o suitable for
> production use? The web page still says Experimental (so I would assume
I do not think that it is appropriate for general use, since at least
one of the CDNs backing it lacks nodes in many (most
Tollef Fog Heen wrote:
> ]] Paul Tagliamonte
>
> > So, when are we going to push this? If not now, what criteria need to
> > be met? Why can't we https-ify the default CDN mirror today?
>
> The usual crypto answer: because key handling is hard.
>
> Doing this for the per-country mirrors means t
On 10/17/2016 08:48 PM, Cyril Brulebois wrote:
> Philipp Kern (2016-10-17):
>> On 10/17/2016 05:39 PM, Cyril Brulebois wrote:
>>> AFAICT from a recent https deployment, apt will perform a TLS handshake
>>> for each and every file it downloads from the mirror; including indices,
>>> translations, p
Philipp Kern (2016-10-17):
> On 10/17/2016 05:39 PM, Cyril Brulebois wrote:
> > AFAICT from a recent https deployment, apt will perform a TLS handshake
> > for each and every file it downloads from the mirror; including indices,
> > translations, pdiffs, and finally debian packages.
>
> Last I ch
❦ 17 octobre 2016 16:21 +0100, Ian Campbell :
> TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
> use e.g. in base images (including for Jessie)?
I get a 404 from time to time. Doing a second apt full-upgrade fixes the
issue. This works far better than httpredir.d.o.
Ho
On 10/17/2016 05:39 PM, Cyril Brulebois wrote:
> AFAICT from a recent https deployment, apt will perform a TLS handshake
> for each and every file it downloads from the mirror; including indices,
> translations, pdiffs, and finally debian packages.
Last I checked it pipelined within a single TLS c
On Mon, 2016-10-17 at 15:24 +, Peter Palfrader wrote:
> On Mon, 17 Oct 2016, Ian Campbell wrote:
>
> > TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
> > use e.g. in base images (including for Jessie)?
>
> Yes.
Thanks!
On Sun, Oct 16, 2016 at 09:11:42AM +0800, Paul Wise wrote:
> Exactly what actions do you mean by this?
>
> Debian does not control what mirror operators do, they are free to add
> https or not. Some do but most don't.
We do control the CDN. We can also start to move systems with a new apt
to a HTT
❦ 17 octobre 2016 17:39 +0200, Cyril Brulebois :
> AFAICT from a recent https deployment, apt will perform a TLS handshake
> for each and every file it downloads from the mirror; including indices,
> translations, pdiffs, and finally debian packages.
>
> Either I've blatantly failed at noting wh
On Mon, Oct 17, 2016 at 15:24:42 +, Peter Palfrader wrote:
> On Mon, 17 Oct 2016, Ian Campbell wrote:
>
> > Have we gotten to the point where we consider deb.d.o suitable for
> > production use? The web page still says Experimental (so I would assume
> > "not production yet") and I'm not real
(Please Cc me if you want me to notice any response.)
Paul Tagliamonte (2016-10-15):
> I find most of these arguments pretty boring, and I don't think the
> "costs" outweigh the benefits.
>
>
> I see no reason why the argument that the mirror server may be
> compromised means we have to open ou
On Mon, 17 Oct 2016, Ian Campbell wrote:
> TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
> use e.g. in base images (including for Jessie)?
Yes.
> On Sun, 2016-10-16 at 09:11 +0800, Paul Wise wrote:
> > httpredir.d.o is not well maintained
>
> There still seems to be g
TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
use e.g. in base images (including for Jessie)?
On Sun, 2016-10-16 at 09:11 +0800, Paul Wise wrote:
> httpredir.d.o is not well maintained
There still seems to be general grumbling (including a persistent drip
of CI failures
On Sat, Oct 15, 2016 at 02:03:36PM -0400, Paul Tagliamonte wrote:
>...
> So, the real question:
>
> So, when are we going to push this? If not now, what criteria need to be
> met? Why can't we https-ify the default CDN mirror today?
>...
This is actually only the server-side part of the problem,
]] Aron Xu
> To make it clear, content delivery systems used by pypi and npm don't
> work for many people in China because:
>
> 1) Major global CDN providers don't have decent services in the
> country (except akamai and cloudflare but need special contract);
>
> 2) BGP based network topology d
]] Dimitri John Ledkov
> I'm not a sysadmin. My naive approach would be to have cname specified
> on the certs that are subject to redirect. E.g. ftp.d.o should have
> cname's for all country codes, such that any country mirror can fall
> back to ftp.d.o.
This would restrict us to always point a
On 15 October 2016 at 20:25, Tollef Fog Heen wrote:
> ]] Paul Tagliamonte
>
>> So, when are we going to push this? If not now, what criteria need to
>> be met? Why can't we https-ify the default CDN mirror today?
>
> The usual crypto answer: because key handling is hard.
>
> Doing this for the per
On Sunday, October 16, 2016, Aron Xu wrote:
>
>
> On Sunday, October 16, 2016, Paul Wise > wrote:
>
>> On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote:
>>
>> > Doing this for the per-country mirrors means that repointing mirrors
>> > becomes a lot harder than it currently is, and this is
On Sunday, October 16, 2016, Paul Wise wrote:
> On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote:
>
> > Doing this for the per-country mirrors means that repointing mirrors
> > becomes a lot harder than it currently is, and this is something we do
> > on a daily basis. We'd need a solution
On Sunday, October 16, 2016, Tollef Fog Heen wrote:
> ]] Paul Tagliamonte
>
> > So, when are we going to push this? If not now, what criteria need to
> > be met? Why can't we https-ify the default CDN mirror today?
>
> The usual crypto answer: because key handling is hard.
>
> Doing this for the
On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote:
> Doing this for the per-country mirrors means that repointing mirrors
> becomes a lot harder than it currently is, and this is something we do
> on a daily basis. We'd need a solution for deploying the TLS cert for,
> say, ftp.de.d.o to ftp
On Sun, Oct 16, 2016 at 2:03 AM, Paul Tagliamonte wrote:
> So, when are we going to push this? If not now, what criteria need to be
> met? Why can't we https-ify the default CDN mirror today?
Exactly what actions do you mean by this?
Debian does not control what mirror operators do, they are fre
Marco d'Itri wrote:
> On Oct 15, Dimitri John Ledkov wrote:
> > I believe the TLS overhead costs are negligible, especially if one
> This is not about the TLS overhead: the real issue is not being able to
> use sendfile(2).
If you really want to use sendfile (or splice or vmsplice) for your TLS
c
On Sat, Oct 15, 2016 at 09:24:15PM +0200, Jakub Wilk wrote:
> Some of ftp*.*.d.o and cdimage.d.o mirrors serve random free (and sometimes
> non-free) software that is not Debian[*]. This may mislead inexperienced
> people into thinking that this software is endorsed or even produced by
> Debian. Sh
On Oct 15, Dimitri John Ledkov wrote:
> I believe the TLS overhead costs are negligible, especially if one
This is not about the TLS overhead: the real issue is not being able to
use sendfile(2).
> uses ECC keys. The further privacy it buys one, is IMHO, well worth
> the effort. I would be in f
]] Paul Tagliamonte
> So, when are we going to push this? If not now, what criteria need to
> be met? Why can't we https-ify the default CDN mirror today?
The usual crypto answer: because key handling is hard.
Doing this for the per-country mirrors means that repointing mirrors
becomes a lot ha
There's nothing stopping mirror operators from enabling HTTPS. Some of them
actually have done it already:
https://crt.sh/?q=ftp%25.%25.debian.org
(and there's more in non-*.debian.org domains)
We should have an official list of HTTPS mirrors, and encourage more operators
to enable it.
On a s
On 15 October 2016 at 19:03, Paul Tagliamonte wrote:
>
> So, the real question:
>
> So, when are we going to push this? If not now, what criteria need to be
> met? Why can't we https-ify the default CDN mirror today?
>
It is my understanding that in 2016 there is a huge difference between
the fol
Howdy -devel,
It's that time of the year again - that's right, another paultag rant
with some grand ideas about the state of the world.
It seems like every month or so, someone pops into a channel and asks
why we aren't using https on our mirrors. This well-meaning question is
usually met with h
92 matches
Mail list logo