4 ms·

Apt is probably a bad example here, as there's a fairly large amount of key verification involved in it. If you're installing from the main package repository y

Apt is probably a bad example here, as there's a fairly large amount of key verification involved in it. If you're installing from the main package repository you're pretty safe. PPAs you at least know what you're getting and that someone hasn't hijacked it. It's the dynamic language and other ones that run untrusted code to verify or install things that you have to be worried about.

ricardobeat 13y ago
npm uses https by default. The risk is the same, a package you get from apt-get can later install malicious code on it's own.
- 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.)
- FooBarWidget 13y ago
  Debian packages (and also RPMs) have pre and postinstall scripts that run with root privileges.
  - stormbrew 13y ago
    Yes, and they're also signed by both the author and the package maintainers and have to go through a public review to be included in the package repository. Even for an upgrade. The whole point of that rigmarole is to provide some extra level of guarantee that they haven't been taken over by aliens. Gems, as an alternative example, can be updated by the author (or anyone with their authentication key) at any time. They can be signed, but even if they are there's no real way to verify the authenticity of the signer. I'm not even saying this is a bad thing. There's validity to both approaches because they prioritize different things.
    - FooBarWidget 13y ago
      Yes but we're not comparing distribution-official APT repositories with unsigned downloads, we're comparing potentially third party APT repositories with HTTPS downloads. When users add a third party repo they often don't check who the author is, who the key belongs to or whether they even obtained a legit key. In the HTTPS case, users don't check the HTTPS certificate. The end security is about the same.
- nknighthb 13y ago
  No, the risk is very, very different. debs used in the official Debian repository are the result of a process that requires authorized developers who have been nontrivially vetted (including establishing their real-world identity) to cryptographically sign the packages with their own keys, before they are signed with the repository key. The packages also follow a strict release process that affords opportunity for malfeasance to be detected, especially in popular packages. You have a good assurance that the package is not malicious, and that if it is, someone will be accountable. npm, pypi, and rubygems do not follow such a process. Pretty much anyone can add a package to them which might do anything.

ricardobeat 13y ago

npm uses https by default. The risk is the same, a package you get from apt-get can later install malicious code on it's own.

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.)
FooBarWidget 13y ago
Debian packages (and also RPMs) have pre and postinstall scripts that run with root privileges.
- stormbrew 13y ago
  Yes, and they're also signed by both the author and the package maintainers and have to go through a public review to be included in the package repository. Even for an upgrade. The whole point of that rigmarole is to provide some extra level of guarantee that they haven't been taken over by aliens. Gems, as an alternative example, can be updated by the author (or anyone with their authentication key) at any time. They can be signed, but even if they are there's no real way to verify the authenticity of the signer. I'm not even saying this is a bad thing. There's validity to both approaches because they prioritize different things.
  - FooBarWidget 13y ago
    Yes but we're not comparing distribution-official APT repositories with unsigned downloads, we're comparing potentially third party APT repositories with HTTPS downloads. When users add a third party repo they often don't check who the author is, who the key belongs to or whether they even obtained a legit key. In the HTTPS case, users don't check the HTTPS certificate. The end security is about the same.
nknighthb 13y ago
No, the risk is very, very different. debs used in the official Debian repository are the result of a process that requires authorized developers who have been nontrivially vetted (including establishing their real-world identity) to cryptographically sign the packages with their own keys, before they are signed with the repository key. The packages also follow a strict release process that affords opportunity for malfeasance to be detected, especially in popular packages. You have a good assurance that the package is not malicious, and that if it is, someone will be accountable. npm, pypi, and rubygems do not follow such a process. Pretty much anyone can add a package to them which might do anything.