No, Clojars is not pushed to Maven Central.

I guess, it was something considered in the past and rejected?

I don't know if it was ever considered since Clojars supports group names that aren't compatible with maven's rules. You can no longer create incompatible group names, but must projects on clojars predate that change, so couldn't be synced.

That looks like a solvable problem. Is there a committee whom I can reach and make a request a to create a auto maven sync process.

A project owner can come up with a compatible group name and add it in their lein configuration. And the workflow can take care of pushing the jars to maven.

The abandoned projects would still be leftout. But we will have something future proof.

I just saw https://github.com/clojars/clojars-web/wiki/Contact and realized you are that committee. LOL

Indeed :) I'd be willing to look at what this would take, but I do think it would require a large community-wide effort to make happen, and it's not clear what the benefit would be other than "it's easier to use Clojure in places where dependency resolution is locked down". I don't think it is fair to consider stable projects on Clojars that haven't had releases as "abandoned" though.

The case I would like to make is that it will make enterprise adaption easier.

We have less people to convince

We have to seek approvals from artifactory people, devOps people, security folks, blackduck license scan people , open source governance body etc

Making Jars available in Maven make it a much smaller problem.

I have not seen many developers who have the persuasion skills needed to answer questions raised in opposition.

I think you may be overestimating the number of jars on Clojars that meet Central requirements (https://central.sonatype.org/publish/requirements/) . I suspect it is < 0.1%. Any jar that we did want to push would need to: • be gpg-signed (most jars likely meet this requirement) • have accompanying javadocs & sources jars (few to none meet this requirement) • have a verified reverse-domain group name (very few meet this requirement) Getting folks to release new versions of jars to meet the above requirements would be a huge effort.

Oh I didn't know about these rules

Thank you

Given that only Leiningen "required" signing (and that could be disabled) and the default for Boot and the various CLI tools has been unsigned -- for years -- I'd be inclined to believe a "lot" of Clojars artifacts are not signed these days. I haven't signed any of my JARs for maybe 6-7 years now (since I stopped using Leiningen). Using GPG is a giant pain, especially on Windows.

Even before I switched away from Leiningen, GPG had broken on my Mac and I was never able to get it working again, so I'd had to disable signing in project.clj files to be able to continue pushing JARs to Clojars.

That's a good point Sean. I'll admit that I can't remember the last time I actually released a project on Clojars (other than test ones), so I don't know what most folks do these days.

deps-deploy is probably the most common CLI/`deps.edn` tool for deployment and its default is unsigned, but it has added support for signing because some folks requested that. So some folks are still signing their JARs 🙂

even if jars are signed, nothing about that is checked by either Maven Central or the vast majority of consumers of said jars

I have been (slowly) working towards signing most commits in the clojure repos, and signing commits and release tags for automated releases using the same gpg key that we use for maven jar signing (info about that key is published here for verification: https://clojure.org/releases/download_key)

also fyi, the javadoc and source requirements can be waived on request for non-Java artifacts in Maven central

Thanks Alex

1. Yes, and I don't think it's possible to prevent detect that in the general case. This is probably not a different situation than many other languages though. 2. It's probably quite difficult to replace an existing jar. I think the real scenario here is whether you could release a new version of an existing jar and have users include that artifact without knowing it had malicious code. If the actual owner did this, probably very possible - many consumers automatically bump version deps. That's really on you as a consumer and the amount of diligence you have around deps (in general, I think we should have much higher awareness than we do now). A malicious user would require authentication access to be able to deploy a new jar version (what this is depends on the repository as its a decentralized system), so you're back to "how secure are your passwords"/2FA kind of questions. http is by default not allowed, and there have been other changes in Maven recently to reduce the possibility of MITM.

Noted. Thank you.

Given that Veracode only really understands Java/JavaScript, I don't know how it could scan Clojure source code. It can check artifact dependencies but it's pretty much only going to know about CVEs in Java libraries, not Clojure ones (we run clj-watson against our dependencies at work to highlight such CVEs and help us fix them).

Vulnerability investigation in OSS clojure code, pentesting of http://clojars.org web site needed. I do not know if it is already being done, if not what sort of money is needed for it

"Thinking of log4j2"

Since Clojure libraries are nearly always deployed as source JARs, not bytecode, and are often small and focused, I suspect some people just read the source 🙂

But you're right: some enterprise-level companies are going to be much more concerned about that kind of thing and could mandate that sort of investigation -- and therefore make Clojure unusable for themselves.

There hasn't been any pentesting of http://clojars.org. I have no idea how much it would cost to do so. My current focus is improving security when I have time to work on it.