Re: [dev] TLS / HTTPS support

From: hiro <>
Date: Fri, 1 Sep 2017 13:00:25 +0200

your 99% is bullshit. 99% of all people don't care to encrypt the
silly suckless website specifically. the 1% that does can just type
the https manually, what's the fucking big deal?

On 9/1/17, Laslo Hunhold <> wrote:
> 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
> [0]:
> --
> Laslo Hunhold <>
Received on Fri Sep 01 2017 - 13:00:25 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 01 2017 - 13:12:50 CEST