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

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

> This applies to pretty much every pkg manager ever created.

For what it's worth, the package manager for Dart does not have this problem. We specifically didn't add support for any kind of post-install hook because executing arbitrary code from transitive dependencies feels a little fishy to me, and I'm not at all a security person.

Unfortunately, there's lot of good uses for post-install hooks too. It's a hard problem.

> This applies to pretty much every pkg manager ever created.

This seems a bit more dangerous... to do this with apt, you need to MITM, since the Debian repos are ultimately checked by ftpmasters to make sure (amongst other things) that packages like rimrafall don't get in. Apt also has mitigations against MITM, as described elsewhere in this thread.

Who's checking what packages make it into npm? How did rimrafall get accepted as a package?

What do you find wrong with the yast/zypper's RPM repo signing methods? I've never seen it add a repo without prompting to accept the signing keys before adding it.

> This applies to pretty much every pkg manager ever created.

(noob question) Does it apply to PyPi/pip also?

Yes, the packages that pip installs contain a setup.py (created by the package author) and pip will run that as you when you're doing your pip install. The setup.py could do arbitrary bad things to you, like leaking your ssh keys, deleting your files, or whatever.

RPM.