Likening Kickstarter to an investment has always concerned me. Investment implies a return if the idea is successful and (as you can see from Oculus Rift) early kickstarter backers didn't get any of the very large payout that Oculus got when the were bought by Facebook.
We're starting to see that idea come about with platforms like https://www.seedrs.com/ where if it goes swimingly the backers do well out of it, which kind of offsets the risk.
I think the problem with standard crowd-funding is the people doing the project obviously have an interest in downplaying the risks, and the platform does too, so with no regulation that's exactly what'll happen, and then we get a lot of very late, underdelivering projects which will sour people on the whole concept.
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.
that's interesting. Any pointers to package stores that do a better job on security? I'm researching the area a bit at the moment and I've not seen a lot of good practice out there, so would be interesting to have some good examples to hold up.
Fedora and RHEL have had mandatory signing since before either existed (back when it was RHL).
Debian has had what we'd call 'EV' level security these days for about 15 years - people bringing their passports in and reading out their GPG public keys at LUGs.
We haven't developed far enough for a package store at this point, but this is one of the use cases we're hoping to explore as part of our capability-based shell scripting language: shill-lang.org.
This is a problem with most/all lib installers. They tend to have hooks to allow post-install actions and those hooks tend to be able to run OS commands, with the privileges of the installing user.
Of course what's extra worrying is it's not just the libs you directly install, but all their dependencies which get to carry out these actions. So for example when you install rails, it will install quite a large number of subsidiary gems.
Then when you add in the fact that the credentials that control dev access to push to places like rubygems and npm are just static username/password combos (which sometimes get stored in plain text in a dot file in the developers home dir) and that there's no common use of digital signing for issued libs (in some cases the installers don't even support it).
Well, even if it wasn't a post/pre install, even a node library can fork that exact command, upload your home directory, etc.
That's actually the reason it isn't just dangerous if run as root. Many people have huge amounts of sensitive information and data with read and write access.
A library could of course also fetch even more data. One could create an npm based botnet.
