Re: [dev] TLS / HTTPS support

From: Laslo Hunhold <>
Date: Fri, 1 Sep 2017 10:33:50 +0200

On Fri, 1 Sep 2017 10:15:24 +0200
ilf <> wrote:

Dear ilf,

> No, I am serious. Users, who think HTTPS sucks, shouldn't use HTTP
> euther, because that sucks, too. The choice shouldn't be HTTPS or
> HTTP, but HTTPS or Gopher. But please let HTTP die.
> In the current setup, users who type the domain into
> their URL get HTTP cleartext. I think these users should get HTTPS.
> And what about old external links to the site, they are currently
> 100% HTTP, too. Without a redirect, HTTP will continue ti be used by
> many users although many would rathet use HTTPs - or don't care.

I honestly agree with you. There's no reason not to use HTTPS except
for legacy reasons, however, there are still quite a lot of programs
who choose not to implement TLS, which is mostly due to the fact that
working with OpenSSL is a pain in the ass.
The solution comes, as often, from OpenBSD with libtls[0].

In software development, one should always follow the 99/1 rule. Aim
for the 99% of use cases, discard the 1% of unusual use cases. These 1%
can bloat your software up into unseen heights and weights.

This matter I think is also the point we are arguing about here. Surely
there are many programs that do not implement TLS for good reasons, but
is it reason enough to discard the 99% from having HTTPS in all cases
and not only when they do it by hand and trust HSTS to do it? It's not
our fault the spec is deeply flawed and we have to discuss this here.

Having given this a lot of thought over the last few days, I think
going with the redirect is the proper approach.

> OTOH, I have yet to read a valid example which software "breaks" with
> a HTTP to HTTPS redirect. I assume, it's very little software and
> probably easily fixable - or should just die.

No, this is not correct. As I said above, OpenSSL is a pain to work
with. What matters is how likely you are going to use this software
with I mean, the 99% will either want to browse the pages
or download from, if we ignore the entire git-stack for
a moment that has already been addressed.
I know that curl has TLS support, so tarball-downloading is covered.
Browsing is done with big browsers, which all support TLS extensively,
and for us terminal folks by lynx, links, w3m and so forth, which all
support TLS as well.
So given the usual use cases, I think in our context, it doesn't really
make sense to keep the HTTP-fallback.

With best regards

Laslo Hunhold


Laslo Hunhold <>
Received on Fri Sep 01 2017 - 10:33:50 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 01 2017 - 10:37:58 CEST