One cannot simply obtain a cert from a trusted CA. Hence how they become signing authorities. Granted it's not impossible to do, but it is very difficult. Certainly a far better assurance than not running HTTPS at all.
> If your threat model includes this kind of adversary, please don't use my script. You should also consider how funny would be to host a VPN and route your traffic like this in a network which you don't trust.
We're not talking local network here - literally nobody can trust the internet. Hence why CA's exist in the first place. This isn't some weird edge case threat model, this is something that's well known and already handled. And it's something that is already supported by Github but you are intentionally breaking.
> What would an adversary accomplish pointing a DIFFERENT short URL to a malicious script?
Do you really need that answered for you?
1. Clone repo
2. Publish their own shortened malicious URL in cloned repo
3. ???
4. Profit
> I'm not careless.
Given this script is aimed at less-technical people, I'd say it's rather presumptuous to assume they'd even realise just how careless it is to run a script downloaded from an unverified source.
> But minimal distro images don't come with trusted CA certificates, so it's useless. Yes, I could install them. No, I don't want to.
That's an edge case. You can add a comment to disable the certs in that edge case - or better yet, instructions on how to install the CA certs.
Every excuse you make is really just a plea for your own laziness. "it's the users responsibility" - no it's not, you're providing instructions for them thus it's your responsibility to get those instructions right. "they might not have CA installed", so add a footnote about installing that. I mean seriously dude, Github have already handed you the tools you need securing the install - there's literally no good excuse for disabling them.