This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (27)
- # architecture (15)
- # aws (2)
- # babashka (5)
- # beginners (77)
- # calva (42)
- # cider (22)
- # clj-kondo (47)
- # cljfx (7)
- # clojure (66)
- # clojure-australia (1)
- # clojure-europe (32)
- # clojure-france (10)
- # clojure-israel (2)
- # clojure-italy (1)
- # clojure-nl (8)
- # clojure-uk (53)
- # clojurescript (29)
- # conjure (28)
- # core-async (2)
- # crux (9)
- # cursive (26)
- # data-science (1)
- # datascript (11)
- # datomic (33)
- # emacs (4)
- # fulcro (5)
- # girouette (3)
- # helix (1)
- # jobs (2)
- # leiningen (17)
- # luminus (2)
- # malli (15)
- # music (2)
- # off-topic (51)
- # pathom (3)
- # rdf (91)
- # remote-jobs (1)
- # reveal (7)
- # sci (6)
- # shadow-cljs (10)
- # spacemacs (3)
- # sql (23)
- # tools-deps (52)
- # uncomplicate (2)
- # vim (3)
@seancorfield I believe the Clojure tools use the HTTP client part of Jetty via
@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.
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
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?
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
(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
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.
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
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?
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
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.
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?
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 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
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
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)