I think the confusion is understandable for a new user that doesn’t fully understand the relationship between clojure and java moving a discussion here from #sql https://clojurians.slack.com/archives/C1Q164V29/p1514306822000195 and it exposes a potential vector of attack if someone wanted to exploit people adopting clojure - that it’s this easy to make an artifact that gets mistaken for an official trusted resource. The solution to this could be education of new users, but there might be a more systemic fix available?

I guess this is relevant to boot as well - how do people know when an artifact is a good one, and how should that be validated?

(and tools.deps too since it also searches both Clojars and Maven by default)

Per @danielcompton (in #sql ), Clojars no longer allows artifacts to shadow Maven -- and although the existing groups/artifacts were grandfathered in, they were all checked at the time to be valid (against the Maven artifacts).

That doesn't mean that shadowing artifacts updated since that check aren't nefarious tho' I guess.

@noisesmith To your point about new users, I don't think we have good introductory material anywhere obvious about that aspect of the Clojure ecosystem...? I don't even recall the various books talking about it much...

yeah it would be nice if there was a simple “how to use clojure safely” guide for ops / opsec stuff - it’s hard because it’s easier to not say anything at all. Compared to saying something helpful knowing that you aren’t an expert and someone else is going to come in and say you got it so wrong that you would have been better off not giving advice at all…

security is hard

Even something that provides a basic outline of how to figure out how/where to find libraries (since Clojure itself and the Contrib libraries all live on Maven, along with all the Java, Scala, etc stuff, but nearly all other Clojure stuff lives on Clojars -- which opens up the immediate new user question of "why two systems?" 🙂 )

indeed. Then there’s the question of gpg signing of uploads (which may or may not be something we expect for clojars but last I checked the tooling prompted for it on upload…)

i think where i really went wrong was just trying to use guides to get started with postgres + clojure. A lot of them are pretty old so they use the clojars “postgres” repo. It wasnt until I happened across a Heroku guide that I noticed they were using a different repo / version for postgres that I thought to look more closely at the dependencies. I assumed I was doing something wrong in the code. Ultimately if the repo was instead someguy/postgres I would have realized more quickly that it’s not an “official” repo and probably would have done more digging earlier.

Leiningen still requires GPG signing (unless you disable it). Boot does not require GPG signing. Clojars doesn't care these days.

(and to be clear, Boot allows you to sign stuff if you want to -- it's just not "on" by default)

@seancorfield what about validating said signatures when using the lib as a client - is there some setting that determines whether the sigs are required / checked when using the dep?

and what risks (if any) are introduced by not using these signatures?

@jgh It's unfortunate that there are a lot of old, outdated tutorials out there (often created by people early in their Clojure learning who have since moved on and therefore never updated things).

I think it’s fine and expected, I never expect tutorials for anything to be perfectly up to date..but when the official-looking distribution repo seems to match (or is a few versions ahead) of the tutorial I thought I was going down the right track 😉

@noisesmith No idea about checking signatures.

What wasnt expected was that the repo wasnt official and it was out of date

@jgh I'm genuinely surprised that a tutorial even pointed to Clojars for a PostgreSQL driver 😞

well, like you said it could have been made by someone relatively inexperienced and at that point it’s the blind leading the blind 😄

clearly we need an expertise blockchain so that a tutorial would be signed in a way that proves how (in)experienced a dev is when writing a tutorial

lol

maybe ¯\(ツ)/¯

proof-of-code

i think clojars just needs a verified tag or something so that people can easily see that a repo is official

@jgh I'm not sure how that would work -- short of all group IDs requiring some sort of vetting by the folks who run Clojars (except for the org.clojars.{username} ones).

The group ID doesn't relate to the username on Clojars and artifacts don't necessarily track back to a GitHub repo (that's optional).

I dont think they need to do it for everyone, but if you want your repo to be official you contact clojars and they verify (via domain or github or whatever) and mark your repo official. Most people wont need it anyway, it’d mostly be things like sdks and drivers.

https://github.com/jkjuopperi -- this is the Clojars user who posted the PostgreSQL driver BTW. Looks like they were somewhat active with Clojure back in 2013/2014 but not since.

@jgh It wouldn't hurt to open an issue suggesting that at https://github.com/clojars/clojars-web

ah great, i’ll do that

And perhaps file a deletion request for that postgresql driver? https://github.com/clojars/clojars-web/issues?q=is%3Aissue+is%3Aopen+label%3Adelete-request

that could be very unpleasant for some existing users(?) - maybe if there were an official way to mark an artifact as depricated so any user would get a warning - does maven have a feature like that?

initial results say that maven lacks such a feature by design

If the exact same coordinates for that artifact exist in Maven Central, then the Clojars one could be deleted and tooling would just find that same version on Maven (I haven't checked the actual version -- I was making the suggestion more as a way of removing potential confusion).

oh that’s a good point

However, that doesn't appear to be the case http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22postgresql%22%20AND%20a%3A%22postgresql%22

https://github.com/clojars/clojars-web/issues/674 if you guys have anything to add

Here's the closest match on Maven http://search.maven.org/#artifactdetails%7Corg.postgresql%7Cpostgresql%7C9.3-1102-jdbc41%7Cjar -- note the different group ID (`org.`) and the slightly different artifact ID (`-jdbc41` instead of .jdbc41)

So, yeah, deleting it could break people's projects...

(but perhaps those projects should get broken and force a switch to the official driver artifact?)

might be worth looking at analytics for that repo to make the call

Maven repos do have a notion of “relocation” which is kind of like a 301 redirect. I’m not sure how they are actually implemented.