Hacker News Reader

Comment by bokohut | Hacker News Reader

Code intake technique aside, in this case "typosquatting", the root of the problem is developers that are tasked with writing code choose instead just use others existing work without EVER reviewing nor understanding every line of that 'copied' code. While this code reuse technique has existed in many forms since the very first software languages were created the internet has just exacerbated the code sharing problem. As the world is coming to learn day after day that easy is not secure and if you copy code one better "trust but verify" however most people are just lazy. Here is a post I made 11 years ago and rest assured this "people are lazy" security compromise technique has been around a lot longer and will continue to prevail well into the future.

https://www.codeproject.com/Articles/30803/A-R-Live-Support-...

View on HN

What's the first step in solving this?

Maybe list out my dependencies and spend one day a week auditing the most-risky, least-popular ones? Random audits where I make sure that my vendored dependencies or files like Cargo.lock haven't changed when I wasn't looking?

Do something like Firefox did with Graphite, and compile as many dependencies as possible into a webasm sandbox so they can't do I/O?

Years ago I thought "Haskell's I/O discipline is cool, but man it looks inconvenient..." Now I wonder if that will become the mandate for new languages. I imagine it's hard to enforce in native code. At least Rust has a strong foundation for both running, and running as, wasm, so maybe in the future it'll be easy to say "Run this function / these functions in a sandbox, nevermind the cost, and write all the glue code for me."

Ironicially, a webasm runtime, especially if it has a JIT, is far too large a project for me to audit on company time... but at least it's also very popular.

It's worth noting that Haskell has escape hatches for doing IO from outside the IO monad, so that wouldn't exactly solve this problem.

If one does not take the time needed to review ALL copied code which is to be included in a project then is that particular individual held responsible for the entirety of an impacting negative result should that code be the source of said impact? The individual was tasked with 'complete this portion of the project' and instead of writing the code and bettering their understanding of said project, of which they will very likely be a source of knowledge to support, the individual saved themselves the mental effort and included copied code. I have also seen the exact same “corner cutting” in the M$ world where developers submit an expense report in which they purchased a component library without ANY consideration of the licensing or the production costs around that components production architectural deployment. As to my latter point you will find the Payment Card Industry (PCI) planning or soon requiring third party assertions on black box code components used in a system but as a multi decade payments entrepreneur/architect/developer this is pure foolishness because if you do not own all the code AND understand it there is no way to know what it may do in the future.

Would you consume candy from a stranger? Would you pick up a piece of candy off the ground which appears unaltered and consume it? When one applies logic to other life safety situations hopefully some can see the analogous similarities to just picking up code off the ground and putting it into one's mouth.

This sh!t storm is just getting started as more and more “no code” businesses are introduced and industries adopt the “easy way” in fear of missing out on “exponential” income. Most are taught at a very young age that fire is hot but until one gets burned the concept of hot is not personally comprehended. The majority of people are lazy and will always take the easy route but as the world comes to learn from more and more catastrophic global breaches, easy is very often not secure.

Now consider critical to life medical device companies that copy code without review.

Trust but verify.

Reply on news.ycombinator.com