Hi folks, I've got a head-scratcher with transitive dependencies. I found a workaround but it doesn't seem right. We have a new library which depends on a Java lib living in the BeDataDriven public repository: http://docs.renjin.org/en/latest/library/project-setup.html We wish to consume this library in a separate project. However, we get an error when starting a REPL via clojure CLI (or CIDER):

Error building classpath. Could not find artifact org.renjin:renjin-script-engine:jar:3.5-beta43 in central ()

clojure
appliedsciencestudio/rdata ;; {:local/root "/Users/daveliepmann/src/forks/rdata"}
        {:git/url ""
         :sha "6dff85aa7b83a9ce85eb8d70b0672a3adf0dc7f2"}

I don't think repos are conveyed across deps.edn projects. They're considered local like :aliases

Right, but the consumer lib doesn't know, or in my mind shouldn't care, that the lib it's requiring uses a repo that's not Maven or Clojars.

https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-46?filter=allissues&orderby=priority%20DESC&keyword=transitive @daveliepmann

Yup that looks like it, thanks. I missed it in my Jira search.

I can think of a couple cases where that's not true. Banks being one, repos are not transparent there. There's also the risk of someone adding a repo that them causes shadowing. I'm not sure how maven works for this.

I might be misunderstanding the problem here - but isn’t it a security risk for a transitive dep to specify a new :mvn/repo; if we’re not careful might it not cause tools deps to fetch other deps from there too? Granted 3rd party deps are always a security problem; but this suggested change in behaviour seems like it would obfuscate things further and potentially makes auditing harder? I think the usecase is interesting; but would it not be safer for libs containing :mvn/repos to cause tools.deps to fail with a message saying “add X to :mvn/repos”?

Also couldn’t it open up new attack vectors? e.g. an attacker could possibly set it to a private repo you own; and cause you to inadvertantly package secret deps in published binaries etc? Kind of like a CSRF attack. Admitedly this is a fanciful attack — and it would require you to depend on an attackers library either explicitly or transitively -- but attacks usually are elaborate.

That's right. But maven allows this, so it might already be the expected model.

Yes, this should work, just not handled right now

That attack vector sounds realistic

it needs some thought. imo, this is an under-considered part of the Maven model in general. repos are identified by name, and those names are just totally arbitrary and unique solely by rarity/convention.

but Maven does certainly let you add repos in transitive deps for this case. I'm not sure if their use is "scoped" to that dep and below though

they are somewhat shielded from this by using a top-down, breadth-first, first one found wins strategy as "parents" in the tree have already been resolved before the transitive repo is encountered

that's kind of also true with tools.deps (resolution happens top-down), but selection can be modified during the traversal and the "source" is not tracked right now in any way