Looks good? But doesn't this just change the compromise window from first installation to first run?
Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
Upcoming breaking changes for npm v12
11–20 of 221 posts
Re: Upcoming breaking changes for npm v12
#12didn't know npm was owned by github.. well, that explains things...
NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (March 16, 2020; 571 comments; 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin...
Some of it aged... interesting.
Top comment:
> Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has adopted more GitHub stuff, especially from a product POV. GitHub still runs as a separate company (different logins and health care and hiring systems) with its own policies and point of view.
> ...
Re: Upcoming breaking changes for npm v12
#13Looks good? But doesn't this just change the compromise window from first installation to first run?
I’m sure we’d all welcome your alternative and or superior proposals.
Without that, this just comes across like unconstructive commentary.
This moves the needle a little your proposals or the lack thereof don’t move it at all. So I’ll take this over nothing.
Re: Upcoming breaking changes for npm v12
#14They should have added a 1-day age limit by default, so security scanners have some time.
I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching.
A better safety net would be to require active 2FA proof for every package update.
Re: Upcoming breaking changes for npm v12
#15Looks good? But doesn't this just change the compromise window from first installation to first run?
I’m sure we’d all welcome your alternative and or superior proposals. Without that, this just comes across like unconstructive commentary. This moves the needle a little your proposals or the lack thereof don’t move it at all. So I’ll take this over nothing.
An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash ".
Re: Upcoming breaking changes for npm v12
#16Looks good? But doesn't this just change the compromise window from first installation to first run?
"First run" doesn't exist for JavaScript libs used only in web apps. So for that entire class of packages this change makes them safe.
Re: Upcoming breaking changes for npm v12
#17They should have added a 1-day age limit by default, so security scanners have some time.
I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching. A better safety net would be to require active 2FA proof for every package update.
If you need a quick patch, you pass another parameter to turn off the 1 day. 1 day delay will prevent more problems than it makes.
Re: Upcoming breaking changes for npm v12
#18Re: Upcoming breaking changes for npm v12
#19Looks good? But doesn't this just change the compromise window from first installation to first run?
Yes, but that's actually a huge win. I can't know what a package needs to do at install time - the dev knows that. But I know what my tests and program need to do at runtime because it's my job to understand those things.
The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe.
It'd be great to have more tools for untrusting libraries (iframes are awesome for this on the frontend) but this is still a massive win.
Re: Upcoming breaking changes for npm v12
#20Earlier quoted context omitted.
Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell
Breaking changes have had that tag for ages
Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?