[fooqux]

Well, the major difference being that apt is typically run as superuser, where I would presume you're not using sudo with bundle install. Unless there is an escalation exploit, worst case is that the code trashes your user's home folder.

Still, a valid point for the vast majority of other package managers, including apt. At some point, you have to trust somebody though.

[0x0]

But in almost all cases, the juicy data is in the user account. That's more important than leaking or deleting /bin/ls. :)

[swartkrans]

Yes if anyone ever got access to my user on my local dev machine, the gig is up. Although we keep production sensitive stuff gpg encrypted and require a password to decrypt, but there is so much information and data in my user home, you don't need super user access to cause damage.

[AceJohnny2]

Indeed, and I hadn't thought properly about it until XKCD, as often, shone a bright light on the nonsense that is root password paranoia: http://xkcd.com/1200/

Which leads me to better respect what Ubuntu was doing with the Yama ptrace scope limiting (which prevents you from debugging a running process even if you're the same user, unless you change a /proc/sys var), and why the Weyland developers are wringing their hands on how to properly handle graphical app communication privileges (because currently, X11 allows any process to view any other process's display and events, including keyboard input)

[chimeracoder]

> Unless there is an escalation exploit, worst case is that the code trashes your user's home folder.

Which is where your $PATH is often contained.

If an attacker can modify your $PATH (and has write-access to $HOME), you're pretty much done for.

[xorcist]

No, worst case is that the code copies your home folder to some server somewhere and leaves keylogger in your loginscript. Something like that.

[brl]

Escalation to root from an active admin user account is trivial. Use your imagination.