On Thu, Jul 31, 2014 at 01:26:09PM +0200, Jakub Wilk wrote:
* Jakub Wilk jw...@debian.org, 2014-07-30, 22:26:
WARNING: The following packages cannot be authenticated!
apt-transport-https
Install these packages without verification? [y/N]
E: Some packages could not be authenticated
[...]
But
* Jakub Wilk jw...@debian.org, 2014-07-30, 22:26:
WARNING: The following packages cannot be authenticated!
apt-transport-https
Install these packages without verification? [y/N]
E: Some packages could not be authenticated
[...]
But if the authentication troubles are really related to the
* Agustin Martin agmar...@debian.org, 2014-07-28, 13:06:
This can actually lead to a weird behavior for users. In a system
having something under people.debian.org in apt sources.list and
apt-transport-https not installed, in today's testing upgrade,
$ sudo apt-get update
[...]
E: The method
* Jakub Wilk jw...@debian.org, 2014-07-30, 22:26:
* Agustin Martin agmar...@debian.org, 2014-07-28, 13:06:
This can actually lead to a weird behavior for users. In a system
having something under people.debian.org in apt sources.list and
apt-transport-https not installed, in today's testing
On Tue, Jul 15, 2014 at 02:00:12PM +, Thorsten Glaser wrote:
Dixi quod…
Martin Zobel-Helas dixit:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
[…]
Take it as a heads-up to
Hi!
On Mon, 2014-07-21 at 19:44:18 +0200, Jakub Wilk wrote:
* Peter Palfrader wea...@debian.org, 2014-07-20, 12:07:
we have been moving towards https for most services over the last 12
months.
Is that intentional that the http-https redirect for bugs.d.o is only
temporary (302)? Should we
On Mon, 21 Jul 2014, Jakub Wilk wrote:
* Peter Palfrader wea...@debian.org, 2014-07-20, 12:07:
we have been moving towards https for most services over the last
12 months.
Is that intentional that the http-https redirect for bugs.d.o is
only temporary (302)? Should we update devscripts and
On 07/21/2014 12:19 AM, Peter Palfrader wrote:
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
These are all good arguments for enabling HTTPS and making it the
default (which I've said repeatedly is a move that I support, or at the
very least don't oppose), but not for *disabling* the
Op zondag 20 juli 2014 21:22:48 schreef Peter Palfrader:
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
If HSTS is enabled and you access people.debian.org even once (and you
don't clear out their entire cache for as long as the HSTS timeout
lives), then HSTS will ensure that the HTTP URL gets
On Sun, July 20, 2014 21:34, Steve Langasek wrote:
Because it's not an improvement to the service; it's a change that makes
the *service* to Debian developers worse, for political reasons.
I don't agree that it gets worse or that it is for political reasons, but
even if it were, it being
On Mon, Jul 21, 2014 at 5:22 PM, Wouter Verhelst wrote:
Yes it does.
No...
I just tried chromium and iceweasel on this laptop (running sid, a few
days out of date). Both will turn http://www.debian.org; into
https://www.debian.org; due to HSTS. This works whether I enter the
http://;
Op maandag 21 juli 2014 17:39:44 schreef Paul Wise:
On Mon, Jul 21, 2014 at 5:22 PM, Wouter Verhelst wrote:
Yes it does.
No...
I just tried chromium and iceweasel on this laptop (running sid, a few
days out of date). Both will turn http://www.debian.org; into
https://www.debian.org;
On Mon, 21 Jul 2014, Wouter Verhelst wrote:
Op zondag 20 juli 2014 21:22:48 schreef Peter Palfrader:
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
If HSTS is enabled and you access people.debian.org even once (and you
don't clear out their entire cache for as long as the HSTS timeout
Op maandag 21 juli 2014 11:34:53 schreef Thijs Kinkhorst:
On Sun, July 20, 2014 21:34, Steve Langasek wrote:
Because it's not an improvement to the service; it's a change that makes
the *service* to Debian developers worse, for political reasons.
I don't agree that it gets worse
You're no
Op maandag 21 juli 2014 11:34:49 schreef Peter Palfrader:
On Mon, 21 Jul 2014, Wouter Verhelst wrote:
Are you talking about something else? If so, can you clarify in more
than two words?
Sure, I can clarify:
As I understand the RFC, servers MUST NOT send HSTS headers on insecure
Hi Iain,
On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote:
The main one is that there are places in the world you just can't use HTTPS
for legal reasons [...]
I'm curious, can you name one?
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
On Mon, Jul 21, 2014 at 01:12:37PM +0200, Holger Levsen wrote:
Hi Iain,
On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote:
The main one is that there are places in the world you just can't use HTTPS
for legal reasons [...]
I'm curious, can you name one?
The United Kingdom when using
Hi,
On Montag, 21. Juli 2014, Iain R. Learmonth wrote:
The United Kingdom when using IPv4 over AX.25 on Amateur Radio. Encryption
is illegal because it goes against the self-policing nature of the amateur
bands.
and so are probably prison inmates, workers of armed forces and other who
might
On 7/21/14, Holger Levsen hol...@layer-acht.org wrote:
Hi Iain,
On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote:
The main one is that there are places in the world you just can't use
HTTPS
for legal reasons [...]
I'm curious, can you name one?
I'm also curious - is there a Debian
On 7/21/14, Iain R. Learmonth i...@fsfe.org wrote:
On Mon, Jul 21, 2014 at 01:12:37PM +0200, Holger Levsen wrote:
Hi Iain,
On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote:
The main one is that there are places in the world you just can't use
HTTPS
for legal reasons [...]
I'm
On Mon, Jul 21, 2014, at 13:12, Holger Levsen wrote:
Hi Iain,
On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote:
The main one is that there are places in the world you just can't use HTTPS
for legal reasons [...]
I'm curious, can you name one?
Hi Jacob,
On Mon, Jul 21, 2014 at 01:14:14PM +, Jacob Appelbaum wrote:
I believe you are mistaken. My understanding is that you're not
supposed to use crypto on the radio layer and IP packets are already
several layers away from that concern. It would be great to hear from
a HAM radio
On Mon, Jul 21, 2014 at 9:32 PM, Ondřej Surý wrote:
The current problem with HTTPS is that it bundles encryption with
authenticity.
This needs to be unbundled[1]. My opinion is that even a transparent
opportunistic encryption (f.e. like DANE implementation in postfix)
would improve the
On 7/21/14, Iain R. Learmonth i...@fsfe.org wrote:
Hi Jacob,
On Mon, Jul 21, 2014 at 01:14:14PM +, Jacob Appelbaum wrote:
I believe you are mistaken. My understanding is that you're not
supposed to use crypto on the radio layer and IP packets are already
several layers away from that
On Mon, Jul 21, 2014 at 02:38:14PM +, Jacob Appelbaum wrote:
On 7/21/14, Iain R. Learmonth i...@fsfe.org wrote:
By that reasoning, we may not authenticate except by sending plaintext
passwords over such a network. That seems to either be an old policy,
a mistake or a network that is simply
Hi,
On Sun, Jul 20, 2014, at 08:47, Tollef Fog Heen wrote:
Not many HTTP clients support DANE, unfortunately, and MITM-ing
DNSSEC-secured domains is a bit more effort than just MITM-ing a
plaintext HTTP connection.
my team has just produced js-types version of DNSSEC/TLSA Validator
so it
* Jacob Appelbaum ja...@appelbaum.net, 2014-07-21, 13:09:
I'm also curious - is there a Debian developer who will not use HTTPS
but does use SSH to access servers?
Very unlikely, with or without the “but …” part. (But I'm afraid I don't
understand what point you're trying to make.)
Is
* Peter Palfrader wea...@debian.org, 2014-07-20, 12:07:
we have been moving towards https for most services over the last 12
months.
Is that intentional that the http-https redirect for bugs.d.o is only
temporary (302)? Should we update devscripts and python-debianbts to use
HTTPS for
Op zaterdag 19 juli 2014 22:54:47 schreef u:
]] Wouter Verhelst
Op zondag 13 juli 2014 22:13:10 schreef Martin Zobel-Helas:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
]] Wouter Verhelst
Op zaterdag 19 juli 2014 22:54:47 schreef u:
]] Wouter Verhelst
Op zondag 13 juli 2014 22:13:10 schreef Martin Zobel-Helas:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will
On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
Additionally, since debian.org uses DNSSEC, if you can somehow MITM
people.debian.org then due to DANE you can MITM it for HTTP as well as
HTTPS, so forcing HTTPS really doesn't gain you much.
But that implies that the attacker has access
Hi,
Ondřej Surý:
Pervasive monitoring.
In and of itself, if you only access publicly-availble files, that's not a
threat.
Really we should introduce encryption
*everywhere*.
This change does not introduce encryption.
It disables the option not to use encryption.
I can accept that e.g. if
Op zondag 20 juli 2014 09:23:55 schreef u:
On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
Additionally, since debian.org uses DNSSEC, if you can somehow MITM
people.debian.org then due to DANE you can MITM it for HTTP as well as
HTTPS, so forcing HTTPS really doesn't gain you much.
Op zondag 20 juli 2014 08:47:07 schreef Tollef Fog Heen:
]] Wouter Verhelst
Op zaterdag 19 juli 2014 22:54:47 schreef u:
]] Wouter Verhelst
Op zondag 13 juli 2014 22:13:10 schreef Martin Zobel-Helas:
Furthermore, we will change the people.debian.org web-service such
that
On Sun, Jul 20, 2014 at 09:23:55AM +0200, Ondřej Surý wrote:
On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
There are lots of attack vectors. It's not a response to a single
attack being exploited in the wild.
So name one?
Pervasive monitoring. Really we should introduce
* Tollef Fog Heen tfh...@err.no, 2014-07-20, 08:47:
Would you be happy with
http://people.debian.org/THIS-IS-INSECURE/YES-I-WANT-TO-PROCEED/~user/file
as the URLs?
No need to be condescending. :-(
Also, I wouldn't say “insecure”, which might be vague in this context.
My proposal:
On 20 July 2014 10:07, Wouter Verhelst w...@uter.be wrote:
With the state of the CA cartel these days, I have little
trust in the strength of HTTPS as a verification mechanism, and so I
wouldn't trust a file to be correct even if it came through an HTTPS
connection that validates. Instead, I
On Sun, 20 Jul 2014 10:45:10 +0200, Wouter Verhelst w...@uter.be wrote:
Op zondag 20 juli 2014 09:23:55 schreef u:
On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
Additionally, since debian.org uses DNSSEC, if you can somehow MITM
people.debian.org then due to DANE you can MITM it for
On Sun, 20 Jul 2014, Steve Langasek wrote:
On Sun, Jul 20, 2014 at 09:23:55AM +0200, Ondřej Surý wrote:
On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
There are lots of attack vectors. It's not a response to a single
attack being exploited in the wild.
So name one?
On Sun, 20 Jul 2014, Ondřej Surý wrote:
Pervasive monitoring. Really we should introduce encryption
*everywhere*.
And indeed we have been moving towards https for most services over the
last 12 months.
www is still not done, due to unfortunate push-bash by the service
owners, but most others
At Sun, 20 Jul 2014 11:07:16 +0200,
Wouter Verhelst wrote:
Even ignoring that, assuming people trust that code off
people.debian.org is safe, if they run a validating DNS resolver they
don't run more of a risk than if they use only HTTPS.
I don't really follow that. A validating DNS resolver
Op zondag 20 juli 2014 11:06:00 schreef Tim Retout:
On 20 July 2014 10:07, Wouter Verhelst w...@uter.be wrote:
With the state of the CA cartel these days, I have little
trust in the strength of HTTPS as a verification mechanism, and so I
wouldn't trust a file to be correct even if it came
Op zondag 20 juli 2014 12:53:59 schreef Jeroen Dekkers:
At Sun, 20 Jul 2014 11:07:16 +0200,
Wouter Verhelst wrote:
Even ignoring that, assuming people trust that code off
people.debian.org is safe, if they run a validating DNS resolver they
don't run more of a risk than if they use only
On Sun, July 20, 2014 08:15, Wouter Verhelst wrote:
Op zaterdag 19 juli 2014 22:54:47 schreef u:
Please note that there remain cases where accessing HTTPS is difficult
or impossible. One of these (but by no means the only one) is the
current release of debian-installer: the wget
Op zondag 20 juli 2014 11:38:13 schreef Marc Haber:
On Sun, 20 Jul 2014 10:45:10 +0200, Wouter Verhelst w...@uter.be wrote:
Op zondag 20 juli 2014 09:23:55 schreef u:
On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
Additionally, since debian.org uses DNSSEC, if you can somehow MITM
On Sun, 20 Jul 2014 13:21:03 +0200, Wouter Verhelst w...@uter.be wrote:
Op zondag 20 juli 2014 11:38:13 schreef Marc Haber:
I might me missing something, and I admit not having read the entire
thread, but how would they have access to private key material?
Beyond GPG keys there are also DNSSEC
]] Wouter Verhelst
AFAIK, people.debian.org does not allow running server-side HTTP scripts
(and even if it does, I think that's a bad idea and we should disable it
ASAP). As such, people.debian.org is not an interface for reading mail
in your browser over HTTP, or doing IRC, or whatnot. So
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
These are all good arguments for enabling HTTPS and making it the
default (which I've said repeatedly is a move that I support, or at the
very least don't oppose), but not for *disabling* the possibility of
plain HTTP.
Pray tell: How do you make it
On Sun, Jul 20, 2014 at 10:38:23AM +0200, Matthias Urlichs wrote:
Pervasive monitoring.
In and of itself, if you only access publicly-availble files, that's not a
threat.
1 Security service has unknown exploit.
2 Pervasive monitoring sees you install a package from somewhere over HTTP.
3
On Sun, Jul 20, 2014 at 12:03:59PM +0200, Jakub Wilk wrote:
My proposal:
http://nohttps.people.debian.org/~user/file
This is similar to my proposal[1], using a seperate VHOST that would allow HTTP
access. It's clear in the URL what is going on, and most people will be
using HTTPS but there are
On Sun, Jul 20, 2014 at 01:52:20PM +0200, Peter Palfrader wrote:
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
These are all good arguments for enabling HTTPS and making it the
default (which I've said repeatedly is a move that I support, or at the
very least don't oppose), but not for
On Sun, 20 Jul 2014, Iain R. Learmonth wrote:
Pray tell: How do you make it default.
See: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
It sends a header to tell you you should be using HTTPS.
Alas, that's not what HSTS is about or for. It cannot be used for this.
--
W dniu 20/07/2014 11:01, Peter Palfrader napisał(a):
I do think that if DSA are going to enforce such a policy, they should
be
able to explain why.
What Ondřej said
a.k.a. “because”. Do try better.
– j.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
Op zondag 20 juli 2014 13:52:20 schreef Peter Palfrader:
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
These are all good arguments for enabling HTTPS and making it the
default (which I've said repeatedly is a move that I support, or at the
very least don't oppose), but not for *disabling*
Op zondag 20 juli 2014 13:28:43 schreef Marc Haber:
On Sun, 20 Jul 2014 13:21:03 +0200, Wouter Verhelst w...@uter.be wrote:
Op zondag 20 juli 2014 11:38:13 schreef Marc Haber:
I might me missing something, and I admit not having read the entire
thread, but how would they have access to
On Sun, Jul 20, 2014, at 12:06, Tim Retout wrote:
On 20 July 2014 10:07, Wouter Verhelst w...@uter.be wrote:
With the state of the CA cartel these days, I have little
trust in the strength of HTTPS as a verification mechanism, and so I
wouldn't trust a file to be correct even if it came
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
These are all good arguments for enabling HTTPS and making it the
default (which I've said repeatedly is a move that I support, or at the
very least don't oppose), but not for *disabling* the possibility of
plain HTTP.
Pray tell: How do
On Sun, Jul 20, 2014 at 06:19:14PM +0200, Peter Palfrader wrote:
None of these brings people who type in people.debian.org into their
browser to https.
Right.
AFAICT the only technical change that will do that (sanely) is an
HTTP-level redirection from http://(.*) to https://$1 . Having that
On 2014-07-20 08:15, Wouter Verhelst wrote:
True, but debian-installer simply does not support any signed/encrypted
preseeding.
[…]
Granted, these are probably bugs, and IIRC Colin was working on
providing HTTPS support for jessie. Still, I while I support enabling
HTTPS for people.d.o, I
On Sun, Jul 20, 2014 at 08:23:58PM +0200, Philipp Kern wrote:
On 2014-07-20 08:15, Wouter Verhelst wrote:
True, but debian-installer simply does not support any signed/encrypted
preseeding.
[…]
Granted, these are probably bugs, and IIRC Colin was working on
providing HTTPS support for
Op zondag 20 juli 2014 18:19:14 schreef Peter Palfrader:
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
These are all good arguments for enabling HTTPS and making it the
default (which I've said repeatedly is a move that I support, or at
the
very least don't oppose), but not for
On Sun, 20 Jul 2014, Stefano Zacchiroli wrote:
AFAICT the only technical change that will do that (sanely) is an
HTTP-level redirection from http://(.*) to https://$1 .
That is my understanding as well.
- it's not entirely clear how much extra work implementing this would
require. In
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/20/2014 03:08 PM, Wouter Verhelst wrote:
Op zondag 20 juli 2014 18:19:14 schreef Peter Palfrader:
None of these brings people who type in people.debian.org into
their browser to https.
If they type it in because they want to avoid
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
If HSTS is enabled and you access people.debian.org even once (and you
don't clear out their entire cache for as long as the HSTS timeout
lives), then HSTS will ensure that the HTTP URL gets turned into an
HTTPS URL automatically.
Alas, no.
--
On Sun, Jul 20, 2014 at 01:19:58PM +0200, Thijs Kinkhorst wrote:
On Sun, July 20, 2014 08:15, Wouter Verhelst wrote:
Op zaterdag 19 juli 2014 22:54:47 schreef u:
Please note that there remain cases where accessing HTTPS is difficult
or impossible. One of these (but by no means the only
On Sun, Jul 20, 2014 at 09:00:05PM +0200, Peter Palfrader wrote:
IMO, a dedicated vhost name sounds much more appealing than magic apache
configs. I wonder whether it should use the same UserDirs.
Oh, right. With different UserDirs (bonus point: the default one,
public_html/, being the one
On Mon, Jul 21, 2014 at 12:05:56AM +0200, Stefano Zacchiroli wrote:
On Sun, Jul 20, 2014 at 09:00:05PM +0200, Peter Palfrader wrote:
IMO, a dedicated vhost name sounds much more appealing than magic apache
configs. I wonder whether it should use the same UserDirs.
Oh, right. With
Hi,
On Sun, Jul 20, 2014 at 07:30:35PM +0100, Colin Watson wrote:
I'll hopefully get to finishing this at DebConf; I think I merged most
of the safe and independent pieces already, and mostly just need to deal
with wget-udeb. I'm not expecting to backport this to wheezy though.
yeah, it
Op zondag 13 juli 2014 22:13:10 schreef Martin Zobel-Helas:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
Why?
Please note that there remain cases where accessing HTTPS is difficult
]] Wouter Verhelst
Op zondag 13 juli 2014 22:13:10 schreef Martin Zobel-Helas:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
Why?
Because the world is a nastier place than it
2014-07-17 2:20 GMT+02:00 brian m. carlson sand...@crustytoothpaste.net:
On Wed, Jul 16, 2014 at 11:43:17PM +0100, Steven Chamberlain wrote:
Some sites (I mean, deployments) like to use a caching proxy, especially
if many machines use the same resource, and/or bandwidth is scarce. Or
even
2014-07-15 21:39 GMT+02:00 Philipp Kern pk...@debian.org:
On 2014-07-15 16:00, Thorsten Glaser wrote:
Martin Zobel-Helas dixit:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
[…]
On Wed, 2014-07-16 at 19:50 +0200, Bálint Réczey wrote:
2014-07-15 21:39 GMT+02:00 Philipp Kern pk...@debian.org:
On 2014-07-15 16:00, Thorsten Glaser wrote:
Martin Zobel-Helas dixit:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will
Some sites (I mean, deployments) like to use a caching proxy, especially
if many machines use the same resource, and/or bandwidth is scarce. Or
even just one machine accessing the same resource often. Maybe this
won't apply to anything particular on people.d.o, but certainly a lot of
websites
On Wed, Jul 16, 2014 at 11:43:17PM +0100, Steven Chamberlain wrote:
Some sites (I mean, deployments) like to use a caching proxy, especially
if many machines use the same resource, and/or bandwidth is scarce. Or
even just one machine accessing the same resource often. Maybe this
won't apply
Dixi quod…
Martin Zobel-Helas dixit:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
[…]
Take it as a heads-up to maybe move stuff elsewhere, if it needs http
(e.g. APT repos work well via
On 2014-07-15 16:00, Thorsten Glaser wrote:
Martin Zobel-Helas dixit:
Furthermore, we will change the people.debian.org web-service such
that
only HTTPS connections will be supported (unencrypted requests will
be
redirected).
[…]
Take it as a heads-up to maybe move stuff elsewhere, if it
Hi,
On Sonntag, 13. Juli 2014, Thorsten Glaser wrote:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
This means that requests from wget (since it switched from OpenSSL to
GnuTLS) and
On Mon, Jul 14, 2014 at 11:16:01AM +0200, Holger Levsen wrote:
am I getting this right, that there are architectures which are too slow to
use https??? if so: wow...
This seems likely, especially for embedded platforms where power is a
massive constraint.
(And, if that's the case, I dont't
On Mon, Jul 14, 2014 at 10:36:10AM +0100, Iain R. Learmonth wrote:
If Debian stops supporting embedded platforms, it stops being a universal
operating system.
FSVO universal.
I think this is not a good argument unless/until we have some more-or-less
common and official agreement about what does
h01ger wrote:
On Sonntag, 13. Juli 2014, Thorsten Glaser wrote:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
This means that requests from wget (since it switched from OpenSSL to
Martin Zobel-Helas dixit:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
This means that requests from wget (since it switched from OpenSSL to
GnuTLS) and other utilities from slow
* Martin Zobel-Helas zo...@debian.org, 2014-07-13, 22:13:
The plan is to execute a final sync of home directories on 2014-JUL-26
starting at 0800Z.
http://xkcd.com/1179/
we will change the people.debian.org web-service such that only HTTPS
connections will be supported (unencrypted requests
Hi Martin,
On Sun, Jul 13, 2014 at 10:13:10PM +0200, Martin Zobel-Helas wrote:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
Could you elaborate on why people.d.o will enforce https?
On Sun, 2014-07-13 at 15:19:22 -0700, Steve Langasek wrote:
On Sun, Jul 13, 2014 at 10:13:10PM +0200, Martin Zobel-Helas wrote:
Furthermore, we will change the people.debian.org web-service such that
only HTTPS connections will be supported (unencrypted requests will be
redirected).
[…]
On Mon, Jul 14, 2014 at 7:09 AM, Guillem Jover wrote:
HSTS protects mostly from MITM (except for first connection), but I'm
not sure if DSA is planning to add it.
HSTS is a standard part of HTTPS setup on machines run by DSA, so it
is very likely they will.
--
bye,
pabs
86 matches
Mail list logo
