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 longer serving those who need to provide an HTTP-only link, for whatever reason. By any definition I can think of, that means you're doing less, which implies you're providing less service. > or that it is for political reasons, but even if it were, it being > political does not make the reason bad per se. It is if there are technical arguments against the change (there are) and there are no technical arguments in favour of the change (there aren't). > The use case broken by this change is preseeding installs over plain http > from a server somewhere on the internet. I find it doubtful whether this > would be something we need to be facilitating as a project. If it is a set of preseed files to allow installing machines on one particular corporate network? Not so much. On the other hand, if it is a set of preseed files that change the answers of some low-priority questions (which are not ordinarily shown to the user installing a machine) so that the default behaviour of d-i changes without changing the fundamental functionality? That could be something a Debian Developer might want to provide as a service to our users, and that would require some HTTP-only webspace, preferably under the debian.org domain. One example of such a scenario would be a preseed file that preseeds the answer of "passwd/make-user" to "false", and ensures that libnss-ldap or something similar is installed on the resulting system. This would greatly simplify installing machines without local users. Having said that, it is a fallacy to assume that just because only one example has been given, that one example is the only use case that we should consider. Here are a few others: - A company's ISP can't provide them with the bandwidth they need, so they install a transparent caching proxy to reduce bandwidth needs (this isn't specific to people.d.o, but that doesn't make it less valid). Transparently caching HTTPS is much more complex than transparently caching HTTP. - Someone broke OpenSSL (again) so that https downloads are broken, and the maintainer puts a (gpg-signed) patch up on their people.d.o space (or posts a message to a mailinglist; but lists.debian.org already is https-only apparently, so that doesn't help for people who aren't subscribed) - You are somewhere with extremely bad connectivity (say, in Wall Street during rush hour) where you need to look up/review some documentation before a meeting, and your SSL connections keep timing out. - You want to download a large file that is provided along with an md5sum and a GnuPG signature onto a resource-strapped device (say, a raspberry pi) which can't decrypt at link speed, and you don't like waiting. Need more? I can come up with more, but that would be missing the point. The point isn't that we should continue supporting HTTP because scenario X, Y, or Z. The point is that we should continue supporting HTTP because it doesn't buy us anything not to, while it may cost our users and our developers something they could do beforehand but can't do right now anymore. If you can come up with a scenario where an attack to the *project* would be prevented by providing an HTTPS-only people.debian.org, *then* I would agree that disabling HTTP is a good move. But I don't think that it's possible to come up with such a scenario, simply because you're providing static files which anyone can download. The only security benefit to be had is at the client side. In fact, due to the fact that TLS is a complex protocol which uses a number of rather complex algorithms, there's a lot that can go wrong with security in TLS which can't go wrong with plain HTTP, and which would *reduce* the security of the project. That this isn't just a hypothetical scenario is proven by the heartbleed bug of a few months ago. As with any security-related choice, choosing between HTTP and HTTPS involves a trade-off of features and convenience versus security. In most cases, security should win out, and for that reason I agree that making HTTPS the default (insofar as that is possible) could be a good thing to do. However, since the only security benefit to be had in enabling HTTPS for static files is at the client side, I think it's only fair to *allow* the client to make that tradeoff and decide that in this one particular case, disabling HTTPS is the right thing to do. By redirecting all HTTP requests to HTTPS, you're denying clients that choice, and thus are reducing the level of service that you provide them. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8448978.qll8l7k...@grep.be
