Clojurians Log v2
tools-deps
@seancorfield I believe the Clojure tools use the HTTP client part of Jetty via com.cognitect/http-client.
@seancorfield The context is that we’re trying to ship a Docker image to a partner. They ran a Twistlock security scan on it and it reported that the container contains a version of Jetty that has a vulnerability.
Interesting. OK, so clojure -Stree -A:deps should do it.
It doesn’t actually tell you where in the container it found the offending copy of Jetty, but we looked around and there appears to be a copy in /usr/local/lib/clojure/libexec/clojure-tools-1.10.2.774.jar.
That will pull in the version of tools.deps.alpha used by the tools and show the dependency tree.
It’s not in our application’s dependencies, so clojure -Stree -A:deps shouldn’t show it, right?
-Stree includes the tools’ dependencies as well?
org.eclipse.jetty/jetty-client 9.4.24.v20191120
-A:deps brings in t.d.a so it shows up in -Stree
Ahhh.
That’s what I was missing.
Okay, great. That matches what I found with find … | xargs jar --list --file.
And, yes, that is a transitive dep of the cognitect http client. TIL!
Yeah, it was news to me as well.
Seems like a vulnerability is with the server part of Jetty. Wish me luck trying to convince their security team that the Clojure CLI tools are benign. 😅
FWIW, the latest com.cognitect/http-client is 0.1.105 (t.d.a. uses 0.1.104) and that later version uses org.eclipse.jetty/jetty-client 9.4.27.v20200227
That's still in the range affected (but, again, is the client not the server).
(this made me check what version of Jetty we're using at work -- we tend to update lib deps regularly -- and we're on 9.4.36 which is after that vuln was fixed!)
That vuln is about the way jetty unpacks war files in the temp directory, if you don't use war files, no problem
It effects jetty-runner
FYI, we now got rid of the CLJ_CONFIG hack in our mono-repo project by generating the deps.edns with babashka. It takes a map with default versions from another deps.end and merges those into the subproject deps.edn.
https://gist.github.com/borkdude/58f099b2694d206e6eec18daedc5077b
I seem to recall that t.d.a checks Maven Central before it checks Clojars but what does it do about other :mvn/repos provided via deps.edn files?
Answering my own question: looks like it has code to turn the :mvn/repos hash map into a sequence that is always "central", "clojars", followed by any other repos you specify?
It seems like that would allow malicious actors to upload to Clojars an artifact that shadowed something in your private repo and deliver it without you really noticing? (I was just reading the stuff about npm, PyPI etc where the researcher subverted private artifacts for a bunch of companies)
Thanks. I thought it had been discussed recently and I had read part of that thread before but not all of it.
So it still seems like someone who knew that Acme Inc was pulling some/thing 1.2.3 from their private repo could upload a fake some/thing 1.2.3 to Clojars and get into Acme's code that way...?
The access tokens are scoped to the groups each artifact falls beneath, which helps; however, if you org has no presence on clojars, there’s no DNS/ownership validation. So, it would be possible for a former employee of Acme to publish that dep + version to clojars
Yup, that was what I was thinking...
I really, really hope com / org / etc are restricted group names
Well, it's not about that per se: if Acme Inc were using arbitrary group/artifact IDs in their internal private repo, such as department names and project names, then it's not even tied to their reverse domain.
I mean, I know that's probably bad practice on their part, but I suspect that's common practice.
You’re probably right on that one
maven does allow for jar signing, and clojars even really pushes you to do it
https://github.com/clojure/tools.deps.alpha/blob/master/src/main/clojure/clojure/tools/deps/alpha/util/maven.clj#L126-L131 -- It would seem to be safer if the ordering here was central, then user-supplied repos, then clojars to avoid the supply chain issue?
Clojars long ago dropped any coercion to sign JAR files.
yeah, no one is checking signatures, and it annoys everyone
It used to have a two tier system where only signed JARs could be "promoted" to the top tier, but that's all gone.
Any reason not to have user-supplied first? (Unless signature warnings are provided by the toolchain, I’m not sure how many devs would notice)
I would say we'd want to discourage shadowing of central?
But shadowing Clojars with an in-house repo seems acceptable/safer maybe.
(I have no dog in this fight: we no longer have an in-house repo/proxy service so pushing something to Clojars cannot intercept a dependency from a custom repo any more for us)
Central had a minor incident is the only reason I question it: https://securityboulevard.com/2021/01/sonatype-stops-software-supply-chain-attack-aimed-at-the-java-developer-community/
moving the repos around doesn't really solve the issue though, if you put used defined repos before clojars, then some third party repo the user adds could be used to shadow some package in clojars
Yeah, I guess I’m strictly assuming that the only other real mvn/repos addition in this case is something like a private/internal artifactory that’d be sparsely populated
Yeah, that was my thinking too.
part of the reason the supply chain attack was so effective on other tooling is node and whatever python's package manager is both allow fetched packages to execute code as part of their build
In Central's "minor incident" that relied on devs searching Maven and mistaking the fake plugin artifact for the real one -- and stupidly adding a dependency on com.github.codingandcoding/something into their project at work. You can't protect against that sort of thing really.
(not that Central's massive range of group IDs isn't confusing at times with an artifact ID appearing under multiple group IDs due to not being unique enough or a project migrating from one org to another)
the problem of using names assigned to the content of files instead of names derived from the contents of files
Aye.