4 ms·

| npm uses https by default SSL just protects against man-in-the-middle attacks. | a package you get from apt-get can later | install malicious code on it

by pyre 13y ago

| npm uses https by default SSL just protects against man-in-the-middle attacks. | a package you get from apt-get can later | install malicious code on it's own. The package that you install using apt-get is signed, using public key cryptography. Those keys would have to be compromised for someone to upload a malicious package. As for installed software installing malicious code, that's something that a user can do manually too. Installed software could be compromised as well.

ricardobeat 13y ago
Or the publisher's machine has been compromised. Or maybe he accepted a malicious patch. I don't see any difference here.
- nknighthb 13y ago
  Or maybe he's been infected by a mind-control slug. Why don't we just dispense with all security since it's always possible someone might do something stupid?
- bradleyland 13y ago
  I think you're missing the point. Security is achieved through layers of protection that an attacker must defeat in order to take a malicious action. The technologies being discussed here solve different problems: SSL - Validates that you are actually connecting to the server represented by the URL and that no one is listening/inserting information in between. Author signed packages - Validates that the package contains only what the author has released. Yes, it's possible for both to be compromised with enough work, but that's the point: "with enough work". We can't prevent attacks 100%, but we can layer up security so that an attacker's chances of finding a usable exploit approach zero when looking at the full chain.
jackcviers3 13y ago
npm modules require an owner with a valid username and password for npm. This user is then identified via npm. Problem management goes through Issac, the human in charge of npm.
- pyre 13y ago
  Are you claiming that a username/password is more secure than public key cryptography? (Also, it's not like SSL hasn't been compromised before. Absolute faith in SSL isn't advisable when there is an alternative.)

by pyre 13y ago

ricardobeat 13y ago

Or the publisher's machine has been compromised. Or maybe he accepted a malicious patch. I don't see any difference here.

nknighthb 13y ago
Or maybe he's been infected by a mind-control slug. Why don't we just dispense with all security since it's always possible someone might do something stupid?
bradleyland 13y ago
I think you're missing the point. Security is achieved through layers of protection that an attacker must defeat in order to take a malicious action. The technologies being discussed here solve different problems: SSL - Validates that you are actually connecting to the server represented by the URL and that no one is listening/inserting information in between. Author signed packages - Validates that the package contains only what the author has released. Yes, it's possible for both to be compromised with enough work, but that's the point: "with enough work". We can't prevent attacks 100%, but we can layer up security so that an attacker's chances of finding a usable exploit approach zero when looking at the full chain.

jackcviers3 13y ago

npm modules require an owner with a valid username and password for npm. This user is then identified via npm. Problem management goes through Issac, the human in charge of npm.

pyre 13y ago
Are you claiming that a username/password is more secure than public key cryptography? (Also, it's not like SSL hasn't been compromised before. Absolute faith in SSL isn't advisable when there is an alternative.)