The host actually responds with a 301 that redirects you to:

https://raw.githubusercontent.com/Microsoft/Virtualization-D...

If you're worried just enter the above instead, fully HTTPS-ed. Invoke-WebRequest (aliased to wget in this example) follows 301 links unless told not to, so you're actually downloading the script over HTTPS all the time, but someone could still MITM the link shortening service.

As you note, the redirect breaks all benefits of HTTPS. That can just be trivially stripped.

Powershell, in any case, allows for scripts to be signed. Since the script in question is semi-auto-generated in any case, they should just include that as a step in the build. But serving unsigned scripts over HTTP is just beyond the pale.

Arnt these things signed? Powershell has signing capability to verfiy the author is ms.

What if an exploit is found in the signed copy? Someone else can host the old version which is still signed and supply it to the user. Are they going to revoke the certificate used to sign it entirely?! Not using HTTPS is a sloppy security practice on their side.

Linux packages are signed and commonly served over HTTP by various mirrors. How is this any different?

Ideally, you'd want them to use HTTPS to deliver the packages as well. However, I cut free software distribution some slack, because of massive distributed mirroring and delivery by a number of third parties. For Microsoft, it would be easy: why _not_ use HTTPS and get another line of defense?

(update: revelation's comment is insightful; just saw it. I forgot about versioning.)

They are versioned, of course. You will have to explicitly agree to a downgrade.

Don't understand the downvotes, it really should have been https