> for example injecting an older version of a package with a known security issue

There's a limited window during which an attack like this will work. If you look at one of the Release files [1], you'll notice the pseudo-header:

    Valid-Until: Wed, 04 Feb 2015 16:41:23 UTC

After this date passes, aptitude update will fail, warning you that your sources are out of date, with a message like:

    E: Release file for http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 24min 32s). Updates for this repository will not be applied.

Of course, the Release file is signed, so you can't just forge that pseudo-header (or change any of the packages in the release).

You could also choose one of the mirrors that supports HTTPS, like mirrors.kernel.org or mirrors.ocf.berkeley.edu (both good for Bay Area folks).

(Granted, the window is probably larger than we'd like, though you could write a script to check that if you wanted. Something like [2] would work.)

[1] http://mirrors.ocf.berkeley.edu/debian-security/dists/wheezy... [2] https://github.com/ocf/puppet/blob/master/modules/ocf_mirror...

I'm fairly certain there's some protection against that sort of attack. A quick google brings me to [1] which seems to indicate that the Release file has a 7-day expiration period. Having apt connect over unencrypted HTTP allows for caching options that npm doesn't. It's also not dependant on the shitty SSL CA system.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499897

I guess its actually the package distribution that makes a difference, an apt package such as rimrafall won't ever reach an official debian repository. So in the context of adversary package code execution the weak spot is actually the npm registry policy and not npm packaging it self.