Why Namespacing Matters in Public Open Source Repositories
Yesterday we saw the disclosure of a report showing how a security researcher was able to successfully infiltrate 35+ name brand companies, primarily via npm. Ironically, the mechanism used to perpetrate the attack, what’s being called namespace confusion or dependency confusion, is one that I’m quite familiar with and has been at the heart of the contention of how we’ve managed the Maven Central repository for 16+ years vs the users who push back on the standards and just want it to be “easy like npm”.
Since I’ve written extensively about this problem both recently and in the past, I’m going to try something different and assemble a blog post like we build our software today. I’m going to build the case by stitching together parts of the narrative from the past so we can see how it continues to hold up.
Providing Namespaces is really important
During JavaOne 2017, I had a hallway chat that informed me about some of the plans around the new module names that immediately set off alarm bells for me. I recognized that it had the potential to either fork the community ala Python 2 vs 3 or to toss away the well understood Java classpath naming conventions from which Maven derived its own coordinate convention. I ended up getting involved in the JSR 376 Java Modules spec process to help avoid the mistakes I was observing in those other ecosystems. At that time, I wrote both to the mailing lists, and on a Dzone post detailing some of the history and concerns:
Traditionally, the Java ecosystem has been very mature in terms of naming and namespacing. The reverse fqdn (fully qualified domain name) introduced into the Java package was a great choice to ensure classes don’t conflict. Popular build tools (Read more...)
*** This is a Security Bloggers Network syndicated blog from Sonatype Blog authored by Brian Fox. Read the original post at: https://blog.sonatype.com/why-namespacing-matters-in-public-open-source-repositories
