In light of the recent announcement of a method to inject libraries into internal builds by shadowing internal names (aka ‘Dependency Confusion’), we have decided to take steps to make Clojars more secure. Clojars will soon require that all new libraries have a verified group name, and that group name needs to be reverse-domain-based. This will help protect against Clojars being used in [shadowing and typo-squatting attacks]
– Verified Group Names (Clojars Wiki)
I wanted to make sure everyone here had seen this important announcement about a key part of our Clojure ecosystem. First off, for existing libraries in existing groups on clojars.org, there is no change needed at all. If you have already published a library to Clojars, you will be able to continue releasing new versions of that library, using the same group. Nothing needs to change.
The TL;DR of all this is that after April, 18th (2021) you will not be able to publish any new libraries into existing groups that have not been verified and you will not be able to create new groups that cannot be verified – that are not reverse domain names.
Clojars has always allowed users to publish libraries into
net.clojars.<username> as I recently found out). The former is assumed to be for non-canonical forks of other libraries and for “sandbox” versions of libraries (test releases, etc) and the latter is assumed to be for full public releases of libraries for users who don’t have (or don’t want) a more elaborate reverse domain name group.
As part of the upcoming changes, Clojars will auto verify
io.github.<username> groups based on authenticating via GitHub when you login on Clojars, and will soon add verification of
io.gitlab.<username> groups based on authenticating via GitLab. I would expect many of us who have been publishing libraries under a generic username will switch to one of these, depending on where we host our projects.
In addition, anyone who is responsible for a domain name can apply to get a group name verified that is the reverse of that domain (the process is documented in the wiki page linked above but typically you open an issue at Clojars, on the administration repo, and they’ll have you add TXT record to your DNS or something similar).
- If you use the
depstarto update the
<groupId>field in your
pom.xmland it doesn’t look like a reverse domain name, you’ll get a warning (but it will go ahead and do it anyway).
- When you create a new project with
clj-new, it will do its best to set the
<groupId>field in the generated
pom.xmlfile to an appropriate group name.
clj-new has always tried to encourage you to create projects with a qualified name, such as
myname/myproj – where
myname is, say, your GitHub username or your Clojars username – and now it will create a
<groupId>, by default, that is
net.clojars.myname. For casual usage, that will suffice: users can publish libraries easily under their Clojars username. If you create a project with a qualified name like
com.github.myusername/myproj, it will treat it as if you used
myusername/myproj but create a
com.github.myusername (and assume you are using GitHub for hosting, as it has done in the past). It will recognize
io.github.myusername as being equivalent (but use a
io.github.myusername). Similarly for folks on GitLab, with a qualified name of
clj-new also tries to do the right thing with qualified names like
com.acme/myproj (but you’ll likely need to adjust the
:scm-user property via the
Today I released
clj-new 1.1.264 under both the
com.github.seancorfield group and the
seancorfield group. I released
depstar 2.0.193 under both the
com.github.seancorfield group and the
seancorfield group yesterday. I intend to double-publish all of my libraries for a while under both the existing group – which will not be verified – and under this new group which will be auto-verified, and will switch all my libraries to
com.github.seancorfield in due course.
No one else needs to follow my lead, of course, but I hope that the Clojure community will take this attempt to improve security seriously and will give some conscious thought to their choice of group IDs in future.