> 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

The attack scenarios are significantly different. The passive use of TLS
one is about not having to trust the operators of the network about the
following kinds of attacks:

- The operator themselves setting up a transparent HTTP/HTTPS proxy.
  This is very common in corporate networks. Sometimes the proxy
  malfunctions and only then its existence is noticed. Sometimes
  downloading packages fails immediately (because the HTTPS client
  does not acknowledge the root certificate issued by the corporate
  network). See https://xkcd.com/341/ for a humorous example of someone
  operating a wireless network this way.
- An active attacker performing MITM on specific hosts in a network by
  performing ARP spoofing to intercept and modify requests/responses.
  This can be prevented by the operators by filtering malicious ARP
  requests or even using static ARP tables.

HTTPS makes these a lot more noticable because now it's necessary to
have the client's trust and increases the overall effort required to
pull this off. At this level, more sophisticated attacks are required:

- Use of middleboxes/DPI at the data center/ISP level which intercept
  TLS and can weaken it.
- Use of deliberately weaker TLS settings, such as ETS instead of
  TLSv1.3.

> 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.

These are different attack scenarios that need to be handled separately.
One works at the network level, the other attacks the code distribution
itself, for example by abusing that people can type the name of a
dependency wrong or confuse it with an malicious one.

The idea of using several different measures to protect yourself against
a variety of attacks is known as defense in depth. It beats betting
everything on one card. Additionally to that, it degrades gracefully due
to (partial) redundancy. If one out of three protection mechanisms
fails, that's better than the only protection mechanism failing.

> 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.

That is yet another attack scenario. Signing protects someone else than
the author/maintainer slipping in malicious code. If the
author/maintainer is driven to weaponize their own code (for example by
accepting a bribe in return for monetizing their software).