Clojars now rejects deployments where the group name and artifact name
match a project that is already available from Maven Central.
# Why?
Artifact resolution tools (used by Leiningen, Boot, Maven, etc)
iterate through a list of repositories, asking each for an artifact
until it is found. So if an artifact exists under the same GAV (Group
name, Artifact name, Version) in multiple repositories, the actual
artifact downloaded depends on the order in which the repositories are
asked. By default, Leiningen and Boot list Maven Central before
Clojars, but if someone sets custom repositories in a project and
places Clojars before Maven Central, any duplicated GAVs will be
provided by Clojars. Since Clojars has no group ownership verification
policy, it was possible for someone to deploy an artifact that shadows
the GAV of one on Maven Central, which could be used as a vector for
overriding the artifacts downloaded by a project, with the opportunity
to do malicious things.
We don't have any evidence that anyone has used Clojars to shadow
Maven Central GAVs maliciously, but wanted to close this hole
proactively.
# What if I want to mirror my library on both repositories?
If you are publishing a library to Maven Central, there's no real
value in deploying a copy to Clojars as well; if Maven Central is
unavailable, users won't be able to fully resolve dependencies for a
Clojure project, as Clojure itself is served by Maven Central, not
Clojars.
# What about existing deployments that shadow?
For any projects that are already deployed to Maven Central and
Clojars, the existing artifacts on Clojars will remain (with a few
exceptions, noted below). But any attempts to deploy new versions of
those projects to Clojars will be rejected.
We analyzed all of the existing GAVs from Clojars that shadow GAVs on
Maven Central and compared the checksums for the jars from both
repositories. Of those that differed[1], most were clearly deployed to
Clojars (and, presumably, Maven Central) by the author of the project,
so those have been left in place. However, we decided to delete the
rest of the jars that had differing checksums (those jars are still
available from Maven Central, so if you depend on them, your code will
still work). The GAVs for the jars we deleted are:
[ch.cmbntr/jsdt-compat "1.0.0"]
[com.datastax.cassandra/cassandra-driver-core "1.0.0-beta1"]
[com.googlecode.efficient-java-matrix-library/ejml "0.19"]
[com.rabbitmq/amqp-client "1.8.1"]
[com.sna-projects.krati/krati "0.3.8"]
[concurrent/concurrent "1.3.4"]
[io.dropwizard.modules/dropwizard-elasticsearch "0.9.2-1"]
[org.apache.lucene/lucene-snowball "2.9.3"]
[org.apache.maven/maven-ant-tasks "2.1.0"]
[org.erlang.otp/jinterface "1.5.3"]
[org.erlang.otp/jinterface "1.5.6"]
[org.erlang.otp/jinterface "1.6.1"]
[org.flywaydb/flyway-core "3.1"]
[org.jgroups/jgroups "2.12.0.CR3"]
[org.pegdown/pegdown "1.0.2"]
[org.scribe/scribe "1.3.2"]
[org.uncommons/reportng "1.1.3"]
[pircbot/pircbot "1.5.0"]
[postgresql/postgresql "9.1-901.jdbc4"]
Thanks for listening, and let us know if you have any questions.
- The Clojars Staff
1: Based on some spot checks, the checksum differences most likely
result from the the artifacts being built with a different version
of Java and/or under a different username - those values are stored
in a manifest file within the jar. We didn't find examples of the
class files differing.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
