[0] https://github.com/svanderburg/node2nix
[1] https://nixos.org/nix/about.html
[2] https://github.com/svanderburg/node2nix/blob/22d0c19575ecd19...
Edit: fix link formatting
91–100 of 197 posts
[0] https://github.com/svanderburg/node2nix
[1] https://nixos.org/nix/about.html
[2] https://github.com/svanderburg/node2nix/blob/22d0c19575ecd19...
Edit: fix link formatting
How can they claim no malicious actors were involved when packages such as duplexer3 were apparently replaced with undesirable code as reported in https://news.ycombinator.com/item?id=16087126 ?
I believe this was one of the cases of a community member stepping up to publish a package quickly so that malicious code wasn't published.
Presumably they make the claim that none of the code was malicious because they checked.
How can they claim no malicious actors were involved when packages such as duplexer3 were apparently replaced with undesirable code as reported in https://news.ycombinator.com/item?id=16087126 ?
This is not a claim or a fact, that's probably an uneducated guess, npm is broken on so many levels they can't say anything for sure. [1] npm is full of fundamental bugs in their software, workflows, architecture, and community. We learnt this in March 2016 when one developers got a copyright claim and had to remove their package. [2] Why is it even possible to remove a package? Why is it possible to create new packa…
"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.
What is your home address and phone number?
> We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons, but here is a high-level overview. Isn't that the opposite of good practice? You shouldn't rely on obscurity. It's better to have the security processes out in the open so that it can be audited and flaws pointed out.
Lots of people are piling onto npm here. This reads to me like a fairly simple unintended consequence of what seemed like a good approach. Automated spam filters help to avoid dodgy packages. Spam filtering operates on heuristics so it’s sensible to not publicise how they work. The automated spam filter kills dodgy uploads, as these mostly happen on previously unused names a decision is made to not have the spam pack…
It is really another embarrasment for NPM, considering that this is not the first time something similar happens (see: left-pad issue, 23 march 2016) So they learnt zero from it. Then, WHEN ARE THEY GOING TO SIGN THOSE PACKAGES? Zero, nothing. They didn't learn from mistakes, they don't listen. NPM is still open to all sorts of malicious use. Besides NPM problems, yesterday many packages won't work because package "p…
Earlier quoted context omitted.
This is not a claim or a fact, that's probably an uneducated guess, npm is broken on so many levels they can't say anything for sure. [1] npm is full of fundamental bugs in their software, workflows, architecture, and community. We learnt this in March 2016 when one developers got a copyright claim and had to remove their package. [2] Why is it even possible to remove a package? Why is it possible to create new packa…
At least get the company name right if you have to make guesses about what they know internally and what they don't. (lol, and edited it silently so my comment looks dumb now)
> they know internally and what they don't.
They know internally that they do a lot of things badly and this will result in more disasters for npm and JS communities, that's for sure. Check out how GitLab fixed their backup failure. They made new software for testing backups, they live-streamed their work on youtube, they made at least 2 write ups on this case. They were totally transparent about their mistakes and fixes, everyone applauded them for this. What did we get from npm?