Fork me on GitHub

hi guys, good morning, I'm trying to startup a Clojurescript / re-frame project with clj-new,, the way suggested there:

clojure -Tclj-new create :template re-frame :name yourname/spa :output front-end :args '[+garden "+10x" +routes]'
and get the following error reported:
Error building classpath. Bad coordinate for library , expected map: nil
what should I do, or might be doing wrong? thanks !


Missing double quotes around the :args values, the values should be individual strings in a vector So wrap +garden and +route in double quotes


thie way?

$> clojure -Tclj-new create :template re-frame :name yourname/spa :output front-end :args '["+garden" "+10x" "+routes"]'
Error building classpath. Bad coordinate for library , expected map: nil
if so, I still get the same error just in case, I tried the following ways as well, always getting the same error:
$> clojure -Tclj-new create :template re-frame :name yourname/spa :output front-end :args "[+garden "+10x" +routes]"
Error building classpath. Bad coordinate for library , expected map: nil
$> clojure -Tclj-new create :template re-frame :name yourname/spa :output front-end :args "["+garden" "+10x" "+routes"]"
Error building classpath. Bad coordinate for library , expected map: nil
thanks !


clojure -T:project/new :template re-frame :name practicalli/reframe-example :output reframe-example :args '["+garden" "+10x" "+routes"]' 
This works with the alias I have in For your example, it seems the quotes around the vector were changed to double quotes, when they should be single.


My only guess is that something went wrong with installing the clj-new project as a tool. Check the .clojure config directory for tools/clj-new configuration, or just try install the clj-new as a tool again

clojure -Ttools install com.github.seancorfield/clj-new '{:git/tag "v1.2.381"}' :as clj-new
You can also use clj-new as an alias, in which case -T:alias-name is used instead of -Tclj-new create


hi John, thank you very much for your replies ! You were absolutely right. I had clj-new installed via deps.edn, I reviewed ~/.clojure/deps.edn and it seemed ok. Nevertheless, I commented all the :new element there, and then reinstalled clj-new "as a tool". And then the error I reported above got fixed: project with re-frame template was created right with the command shown in the README. Again: thank you very much !

👍 1

Perhaps unrelated to this channel, but given yet another JS packaging brouhaha (search for node-ipc), I was wondering how much safer the Clojure/JVM ecosystem is, if at all? My understanding is that Maven packages are immutable but it's not clear if my deps.edn file will always generate the same jars etc, seeing that there's no hash of the downloaded JAR anywhere. Can someone with more info shed some light? Thanks!

Alex Miller (Clojure team)12:03:46

Maven artifacts are immutable

Alex Miller (Clojure team)12:03:23

I'm not sure what scenario you're imagining, can you be more specific?


Let's say I host a library on a maven-like server (e.g., maven-restlet, to take example of my current deps.edn). I upload my library foo/nicelib which consists of nicelib-1.2.3.jar and nicelib-1.2.3.pom. I assume if a specify {foo/nicelib {:mvn/version "1.2.3"}} this is what I'm getting. Now say that a hacker breaks in my maven-like server, and replaces nicelib-1.2.3.jar with a hacked version - is there anyway for the toolchain to detect that and complain about a mismatch in the digest?


To some extent, git coordinates in deps.edn don't have this issue because tools-deps will clone the repository and can verify that the sha1 requested is the one on the disk. But with versioned artifacts, I'm not sure how you could pin a jar file to its sha digest.

Alex Miller (Clojure team)13:03:25

if the maven server is compromised, then I think you're sunk regardless. maven does support authenticated artifacts (gpg signed) and things on Maven central are required to be signed, but by default there is no way to automatically verify that the key used for the signed artifact was "correct". you really would have to manually check every lib. (The info to do this for the clojure and clojure contrib jars is at for example). but the signature file is stored in the repo - if the maven server is compromised, the signature file is also vulnerable.

Alex Miller (Clojure team)13:03:28

maven now requires https and have made other changes to minimize MITM attacks (which were previously pretty easy)


Right, thanks. What about the scenario of a malicious library author? Can they upload whatever they want under their account (e.g. delete the previous artifact and upload a new one)?


I mean, are the artifacts immutable only in practice, or also in principle? 🙂 Thanks for taking the time to explain this, BTW.

Alex Miller (Clojure team)13:03:54

generally, you can't delete/replace artifacts in most maven repos (but it's an open system and someone could make a repo that allowed this)

Alex Miller (Clojure team)13:03:51

many people use a enterprise-wide server to serve as a proxy for public maven repos, which has the benefits of caching and giving you a point to detect such changes and/or lock things down

Alex Miller (Clojure team)13:03:11

things like Sonatype Nexus

Alex Miller (Clojure team)13:03:14

clj/tools.deps work fine with those setups - that support is built into Maven. they do not yet work with Git proxies (but I hope to add that)


Right, it seems that AWS CodeArtifact is such a proxy I could use. Thanks for the guidance!


What about shadowing Maven artifacts? AFAIUI tools deps by default checks clojars and maven central in some defined order. Assuming it checks clojars first and falls back to central only when an artifact couldn't be found there (is this correct?), then a malicious user could shadow any artifact from central by putting a homonymous one with the same version on clojars without any dependees noticing, right?


re this: > if the maven server is compromised, the signature file is also vulnerable. Only if the private key of the author is compromised, as well, though, which wouldn't be the case only by breaking into the Maven repo. Or does central store private keys on their servers, too? 😬

Alex Miller (Clojure team)13:03:22

maven does not store private or public keys

Alex Miller (Clojure team)13:03:21

it stores signature files alongside artifacts

👍 1
Alex Miller (Clojure team)13:03:41

someone with control of the maven contents could provide correctly signed artifacts using a different key. the catch here is that there is no way for a Maven consumer to know what key is the "correct" one to look for other than trusting this key as a manual step per key, which no one does.

Alex Miller (Clojure team)13:03:58

Re "What about shadowing Maven artifacts?" - this is a potential problem but note that for deps.edn specifically the only maven repos used are ones that you define at the top-level (not transitive repos), which differs from Maven's behavior. so you are explicitly in control of the set of maven repos being used. I'm not sure what controls clojars has in place over this wrt Maven Central - I know there have been discussions about it in the past. you could ask about that at #clojars


Sounds reasonable, thanks for the info! Is there some way to make tools deps check signatures when provided with a set of trusted public keys?

Alex Miller (Clojure team)15:03:33

not currently. there is support for that in Maven but it's a huge pain from a user pov (and I've never met anyone that actually did it)

Alex Miller (Clojure team)15:03:04

if you want to put a request on ask for it, happy to gauge interest via that

👍 2