3 ms·

There are two obvious errors here. 1) We didn’t discover the hack for over 60 days. Recommending 7/14/X does not address this. What X is sufficient to ensure t

There are two obvious errors here. 1) We didn’t discover the hack for over 60 days. Recommending 7/14/X does not address this. What X is sufficient to ensure the community inspects new code? X=60 didn’t cut it. 2) Private signing keys are only private from us, the general public, not necessarily from maintainers, and may be sold and transferred with ease. If I were buying a codebase, I’d require the signing private keys for continuity reasons alone. (CAB EV rules permit this!)

kevinsimper 8y ago
Hi floatingatoll, thanks for the comment, I really appreciate it! It is valid reasons! 1) Yes, absolutely, it is quite interesting that there went so much time by, but that you can install npm packages without noticing that are less than > 1 hour old exposes you to risks that even people noticing can't prevent you from being exposed to. 2) That it could be sold, is a big problem that you can't solve, but if we discovered that it had been sold in this case, we cold then discard all packages that the author had also published, so a author would essentially put all his reputation at risk by just selling/giving away one package.
- floatingatoll 8y ago
  If I chose to sell my key, I’d simply generate a new one and start using it. If you then chose not to trust my old key retroactively, you would be unable to do your job without rewriting my code. Reputation has no material relevance today sufficient to compel a solution, sadly.
  - kevinsimper 8y ago
    Yes, I would be unable to do my job, and I would have to consider the project security higher than features then. If I knew a project had been compromised, the next step should always be to move away from it or fix the issue. The solution would maybe not be to delete all the code, but just not accept any updates since it is not sure the key belongs to the rightful owner.

kevinsimper 8y ago

Hi floatingatoll, thanks for the comment, I really appreciate it! It is valid reasons! 1) Yes, absolutely, it is quite interesting that there went so much time by, but that you can install npm packages without noticing that are less than > 1 hour old exposes you to risks that even people noticing can't prevent you from being exposed to. 2) That it could be sold, is a big problem that you can't solve, but if we discovered that it had been sold in this case, we cold then discard all packages that the author had also published, so a author would essentially put all his reputation at risk by just selling/giving away one package.

floatingatoll 8y ago
If I chose to sell my key, I’d simply generate a new one and start using it. If you then chose not to trust my old key retroactively, you would be unable to do your job without rewriting my code. Reputation has no material relevance today sufficient to compel a solution, sadly.
- kevinsimper 8y ago
  Yes, I would be unable to do my job, and I would have to consider the project security higher than features then. If I knew a project had been compromised, the next step should always be to move away from it or fix the issue. The solution would maybe not be to delete all the code, but just not accept any updates since it is not sure the key belongs to the rightful owner.