|
|
|
|
|
by djsumdog
2730 days ago
|
|
Really? So some team should have inspected the entire Linux or FreeBSD kernel they were running one? Someone should have gone line-by-line through nginx? What about all the shell commands used? They should have had people go line by line through bash, cat and all the other tools needed in the background to setup and environment, all their libraries, all their dependencies? That's not even getting to a project. Have you looked at a projects node_modules, or the maven/jar dependences pulled in? Even for small projects, it grows to a very non-trivial amount very quickly. Inspect ever single jar and dependency? Should people write their own web servers instead? Their own frameworks? Their own operating systems? At some point you have to trust someone enough to actually get your work done. If an OSS project breaks that trust (like we've seen with some node modules) you stop using them, but inspecting every last dependency is often impractical. |
|
Well, you see ... I happen to think that you can use a lot of tools to cover your ass, and .. the fact that this one slipped in is as much a comment on the crud that is promulgating the wild and woolly Node/JS ecosystem as it is anything else. In point of fact, this kind of bollocks is why I eschew Node/JS and use other things [1], instead.
I do believe there are tools and ecosystems which make this sort of thing less likely. I can't recall a Linux easter egg .. nor a Golang one ..
>Should people write their own web servers instead? Their own frameworks? Their own operating systems?
One should at least, audit. As much as possible. It doesn't take much for a competent dev to 'grep -ir "easter egg $CODEBLASE' or, whatever .. not that its an expectation.
But yeah, if you have to have government-level 5-nines on all services, then I would say - fair play. The responsibility for an audit of such things should definitely have been in the requirements. I've seen such expectations for lesser projects, personally, where .. indeed .. code audit and ownership were tightly .. and properly .. managed.
[1] - I don't know for sure, but I think its harder to slip in such an easter egg on a production golang system. I guess I'll tune into that if/when it happens/has happened..