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

$> 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

clojure -T:project/new :template re-frame :name practicalli/reframe-example :output reframe-example :args '["+garden" "+10x" "+routes"]' 

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

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 !

Maven artifacts are immutable

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. http://jitpack.io, 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.

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 https://clojure.org/community/download_key for example). but the signature file is stored in the repo - if the maven server is compromised, the signature file is also vulnerable.

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.

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)

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

things like Sonatype Nexus

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? 😬

maven does not store private or public keys

it stores signature files alongside artifacts

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.

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?

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)

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