Thanks for the extensive comments.

> The arguments could be better:
>
> - Baseline Requirements are a thing and required for CAs to fulfill
>    before they can be included into trust stores. Certificate
>    Transparency is used to monitor issuing of new certificates and detect
>    compromises.
> - It doesn't merely provide confidentiality, but also ensures integrity
>    of whatever I download (provided I'm not on corporate network and
>    install their root CA). This is a low-effort way of ensuring third
>    parties on the network can mess with something like packages downloaded
>    via snow/akku. A workaround would be to use cryptographic signing, but
>    that's a far bigger can of worms to get right.
> - Let's Encrypt turned out to work just fine since that blog post. They
>    support wildcards, though they require a DNS challenge. Mind you,
>    wildcards are not recommended to be used (the argument is that a
>    compromise of a server would allow serving arbitrary subdomains).
>
> That leaves the argument that browser makers lock out features for
> websites not using HTTPS, thereby raising the overall barrier to entry.
> This is the only one I sympathize with. There should be no need to set
> up HTTPS locally to do web development.

This is getting into the territory that requires some background, but
we're being pushed in a direction where we shall take complexity, change
and centralization for granted. A big CA like Let's Encrypt is a
goldmine for any major actor looking to cause harm. The algorithms (a
moving target) likewise.

This is not low effort, and it's not clear how it ensures the integrity
of data in a practical scenario.

>> I think we should continue to offer plain unencrypted HTTP access.
>
> call-cc.org operates on this principle (the main reason being that
> `chicken-install` has minimal dependencies and therefore cannot depend
> on a TLS library),

Makes a lot of sense. IMHO we should do the same for scheme.org.

> I'd still keep using TLS for delivery of source code meant to be
> installed on other people's machines (like tarballs on snow/akku). I've
> considered researching how hard it would be to pull off a MITM scenario
> on package managers/repositories in the Emacs/Scheme/CL ecosystems, I
> guess not terribly. Whether it makes sense to actively invest time into
> it, no idea. What are your thoughts on this?

I'm surprised if anyone believes TLS significantly protects the
integrity of code. AFAICT it wouldn't have stopped any of these, for
example: https://en.wikipedia.org/wiki/Supply_chain_attack

MITMing a download site is unlikely to be worth anyone's time unless
it's a state-level actor. Software development and sysadmin practices
being the much same Wild West they've always been, wouldn't it be easier
to social-engineer your way into a server or git repo or break into a
programmer's PC? Of course, states can also do all of this with a big
budget.

A disgruntled coder (e.g. recent Ukraine protests on NPM, old
OpenBSD/NetBSD feud) doesn't even need to break into anything. Just slip
naughty code into one of the innumerable dependencies that current
systems have.

The solution is for authors to sign releases with their own keys. Then
it doesn't matter how the files are distributed. Safely shipping keys
around is not trivial, but that problem has to be solved no matter what
kind of transport is used.