I find the apt package model to be very good (add trusted keys & repositories explicitly). What do you see as the shortcomings of apt compared to your ideal?
Yes, apt is indeed one of the best we have (the one-eyed amongst the blind).
Sadly it's still using a flawed[1] trust model where you trust repositories rather than publishers. And the UI-shim over GnuPG is 'basic' at best (to put it politely).
To add insult to injury deb/dpkg itself actually does contain a mechanism for package-level signing. But as far as I know no distro is using it.
To add even more insult to injury, all mobile platforms and both Windows and OSX have more reasonable package security models than Linux today.
[1] This is fine for guarding against compromised mirrors - and not much else.
The signing used by pacman (on arch) seems relatively nice, in that individual packages are signed by the maintainer rather than the repository.
Whether or not this buys you any extra security, I'm not sure. In reality I don't think many users check maintainer keys when asked if they want to trust them, but they could.
I'm not OP, but my opinion would be that APT does do some things better than npm etc but there's still some potential problems.
Probably one of the most obvious is that access to the repos is over unencrypted HTTP connections which opens the process up to tampering (depending on the attacker) for example injecting an older version of a package with a known security issue.
> 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.)
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.
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.
Sadly it's still using a flawed[1] trust model where you trust repositories rather than publishers. And the UI-shim over GnuPG is 'basic' at best (to put it politely).
To add insult to injury deb/dpkg itself actually does contain a mechanism for package-level signing. But as far as I know no distro is using it.
To add even more insult to injury, all mobile platforms and both Windows and OSX have more reasonable package security models than Linux today.
[1] This is fine for guarding against compromised mirrors - and not much else.