I do think the results of the above (even with a small sample) suggest that there is a big expectations mismatch in how security issues are communicated in the JavaScript ecosystem
9 replies
@zachleat i think when it was my job (glitch) i would like to know asap so that i could action on it and make sure that user data was secure. now i have less immediate need and can follow along or just see the writeup afterwards
@keith mostly thinking about Monday’s incident, where active build infections were still happening but (imo) very little communication about it as folks were (to be fair) scrambling to minimize the impact
@zachleat oh yeah i think npm should have been communicating way more once it was clear
@keith yeah, I dunno what happened exactly internally but it does have me wondering if this hugely important thing has sufficient staffing
@zachleat @keith What do you think of https://jsr.io ?
@zachleat I see the theory, but in practice what does "communication" look like here? I'm not suggesting that this was perfectly handled or anything, but afaict the hacked versions were identified and pulled from npm in 3-4 hours. The only reason we saw it was it failed a build which we did in the window. How would npm have informed me in a 3-hour window? Without me getting 8 kajillion emails a day?
(maybe some people need that level of alerting, and they should have a way to get it, of course!)@sil the window from the timeline I measured was ~5 hours but to solve the root issue would require architecture changes to npm publish workflows — but until something changes upstream, yeah — more alerts! more emails! I want to know every time a build dependency in my projects is compromised as soon as possible so that I can make the best choices for my projects
From my perspective it seems like Monday’s style of incident is happening a few times a year
@zachleat fair, yeah; you are definitely one of the people who is OK with getting emails the whole time so you can stay 100% on top of this stuff, and I'm glad of that, and that does mitigate things for your downstreams, which is important in itself! I don't think a firehose will help everybody, but it'll help some people (who then help others) so it's a good thing to have. I don't envy those at npm who already have "identify problems fast; fix fast" on their list and also need "tell people" too
@sil yeah, that’s a good take. it also has me wondering if the project has sufficient staffing. sometimes those post-acquisition things can get kinda lean due to leadership problems