|
|
|
|
|
by marcus_holmes
2731 days ago
|
|
Another reminder that dependencies are bad. Introducing someone else's code into your production environment without auditing it is a security breach. This "undocumented code change" could easily have grabbed any login details/session cookies/personal data from the page and sent them somewhere, instead of drawing snowflakes. I doubt anyone would have noticed for a while... clearly there were a large number of people who weren't auditing the latest version of the code to see what changed, and only noticed the change because of the visual effects. Sorry, but if you deploy a random chunk of third-party code into your production environment without knowing exactly what it does, you deserve to be sacked. |
|
Have you reviewed all of Linux, glibc, nginx/Apache, bash, all several thousand node dependencies, and so on? Do you do such a review each time you have to update a package?
Don't get me wrong, I think there's a serious problem with the micro-dependency insanity, but every single person on the planet depends on others. "We stand on the shoulders of giants" is more of a truism today than it has ever been. It's not a sacking offense to trust people (because you wouldn't be able to do your job if you spent all of it reviewing other people's work).
Most people have a reasonable expectation that maintainers of a project are reasonable people -- which is why the micro-package insanity is particularly problematic. I trust most kernel maintainers and so I don't check each Linux release to see whether a backdoor was added (I only check if I've noticed a problem). The blame should be on the maintainers here -- it isn't acceptable to add Easter eggs like this to a library used by many people (especially if it's being used for Serious Business™).
Would you blame every glibc user (which is all Linux users) if they decided to make all math functions return 25 on Christmas? Of course you wouldn't -- you'd blame the maintainers for having lost their minds.