Kudos for removing the nation from the title to neutralize the bait and keep it technical. I know this comment doesn't contribute much, just wanted to acknowledge the effort.
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.
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.
> The fact that developers have to explicitly write out which module to import in every file where they want to use an external package makes it less likely that any confusion can happen
Feels to me like they are joking.
When you have to type out the name in every single file you have a chance of making the mistake every single time you're typing it; while a centralised approach allows one to concentrate on the added import.
One of the vectors of attack using this library is to create a Merge Request that slightly changes the name of the import in one of the N files you are changing. Good luck spotting that as a reviewer.
There would also (by necessity) be a change in the centralized `go.mod` file (and `go.sum`) that corresponds to the addition of the new, almost-duplicate package being imported. Definitely spottable. Unless someone is using the deprecated GOPATH functionality, in which case things might be harder to spot. However, the author specifically pointed out how rare this attack seems to be in the Go ecosystem.
If the author identified malicious repos on user accounts that were created solely to make those malicious repos... it seems like something the author should have reported to GitHub. I wonder if GitHub would actually do anything, though.
[+] [-] pattt|5 years ago|reply
[+] [-] bokohut|5 years ago|reply
https://www.codeproject.com/Articles/30803/A-R-Live-Support-...
[+] [-] ReactiveJelly|5 years ago|reply
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.
[+] [-] heavenlyblue|5 years ago|reply
Feels to me like they are joking.
When you have to type out the name in every single file you have a chance of making the mistake every single time you're typing it; while a centralised approach allows one to concentrate on the added import.
One of the vectors of attack using this library is to create a Merge Request that slightly changes the name of the import in one of the N files you are changing. Good luck spotting that as a reviewer.
[+] [-] coder543|5 years ago|reply
If the author identified malicious repos on user accounts that were created solely to make those malicious repos... it seems like something the author should have reported to GitHub. I wonder if GitHub would actually do anything, though.
[+] [-] gowld|5 years ago|reply
Any non-trivial app would use a preprocessor to manage the import lines. This problem was solved 40 years ago.