This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # atom-editor (6)
- # babashka (31)
- # beginners (34)
- # calva (1)
- # cider (21)
- # clj-kondo (5)
- # cljsrn (2)
- # clojars (6)
- # clojure (35)
- # clojure-europe (3)
- # clojure-norway (2)
- # clojurescript (4)
- # conjure (10)
- # crux (4)
- # cursive (8)
- # data-science (78)
- # fulcro (23)
- # graphql (10)
- # helix (2)
- # luminus (1)
- # off-topic (50)
- # other-languages (1)
- # pathom (8)
- # re-frame (9)
- # reagent (9)
- # reitit (1)
- # rewrite-clj (6)
- # shadow-cljs (134)
- # tools-deps (53)
- # vscode (1)
say I am developing a financial related app. As in clojure, most libs are open sourced, and maintained by some contributors.
The problem is, what if one contributor’s key get hijacked and some malicious code gets added to the latest version?
It seems for critical applications, open source software with a limited audience is not a good choice. While sadly, most clojure libs have few users.
yes. orthogonal to oss, especially those found by apache. but for oss software use a fewer audiences, the risk is hideous.
With open source, you can actually vet your sources. With closed source, you only have trust.
with a quick search, it seems even checksum is not enforced by maven: https://stackoverflow.com/questions/34935297/create-a-checksum-for-all-maven-artifacts
You'll struggle to prove that java ecosystem isn't up to the task of security given the number of institutions using it.
@i wouldn't dependency on an already released version solve your problem? why the dependency on the latest version?
That's exactly what checksums are for. And the argument about Maven not using them is a pretty good one, IMO.
@dominicm If the service is not financial related, I don’t care about the security issues at all. However, if it is, every step should be cautioned against. If is kind of un-acceptable if we spent lots of efforts achieving strong consistency with linearizability, avoiding any fraud, any double spending issues, any durability loss, but at the end of day, the service is hijacked by some external dependency. (that would be crazily un-acceptable).
If you run any random code off the internet without reading it, then you must not care about security. I don't think you can blame open source for this.
FWIW I’ve read the source for most of the open source Clojure libs we’re using. It’s not onerous at all. Doing the same for the java ones, dear lord...
@orestis my worry is the situation that one dependency is later hijacked with a malicious copy.
Anyway, checksum with some potential pgp signing will suffice. but I guess lein currently does not have such support.
Many companies use an internal maven proxy (like nexus) for the multiple benefits of caching, build reproducibility, and control over the libs they include
Which does not fix those problem but does at least give you a company wide point of control
The hard questions there are all the same questions as in lein or mvn re signature checking. Just because it’s signed, how do you know to trust the signature?
If you want to check anything released under org.clojure, clojure itself and contrib libs are signed and you can verify using the key info here https://clojure.org/community/download_key
> how do you know to trust the signature? Of course you can never know with 100% certainty. Security is always about reducing the probability, not about eliminating it completely. Good to know about org.clojure, thanks!
I don't mean level of certainty, I mean with gpg keys, you literally don't know anything, you just know that it's been signed. you have to manually verify and mark as trusted any gpg keys you encounter and while we publish clojure's verifiable key information, you don't have anything like that for literally any other Clojure library I'm aware of.
gpg has tried to attack this via the "web of trust" but I think it is an inherently unworkable model
Right. I meant that if a library author decides to go that route as well, they will have to put that verifiable key information somewhere. And if that place is not near the code and/or the artifacts and requires different credentials, then the probability of someone spoofing the lib goes down drastically. My initial question was about doing stuff like
automatically. It would require users to put the key [web]location right there along with the dependency, but it's something. Perhaps, if nothing like that is planned, maybe there are plans for a plugin system? Of course such automatic validation can be done in an external tool, but just having that tool won't prevent you from forgetting to run it or from not noticing that something went wrong.
gpg --verify clojure-1.10.1.jar.asc ~/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar
you don't need a plugin system - you could write a program write now, using tools.deps to do this. as I mentioned above, almost nothing on clojars has signatures so it would just tell you that most of your jars are unsigned
having it integrated in clj is possible but just not a priority for me right now, given a) most unsigned, and b) signatures don't actually give you any greater trust right now
Can you elaborate on (b)? If that's the case, what's the point of having a GPG key for org.clojure?
well, we are doing the best thing we can do - sign it and tell you how to check the key
Right. So the trust is greater, if you trust the origin of the key and check the signature yourself.
this needs a better answer from a design perspective. personally, with source deps I don't even necessarily need or care about signatures. what I want is hashing to verify that the source jar I have is the source I think it is on github
yes, if you do all the manual stuff and have some external way to validate the key. the problem is - that dosen't scale
with the caveat of more centralized authority and the need to distribute root certificates
I trust my bank web site because there is a chain of trust with people verifying identity up to some root trusted authority
Oh, verifying the source jar sounds great. But I can't even start to think how it could be implemented given that there are multiple ways to create a jar from the same sources.
Source deps are amazing. Alas, the scope is rather limited - the dependency can't require any steps before you can produce a jar (so no Java, for example) and it must have a
deps.edn file (so no lein-based projects).
that has its own issues (like handling the failure of trust via revocation, etc) but seems like at least that's a system that is continuing to evolve and handle those as best as possible
I think hash verification is totally tractable and I don't think there is any reason it's not solvable in a generic way
Right. Thanks for the discussion! As usual, looking forward to anything that comes out. :)
@i You might want to consider git deps; depending on a content-addressed, immutable SHA means nothing can tamper with sources you took the time to verify locally
A security review for upgrading
ab8f16 would be a simple
git diff ensuring there's no extraneous code.
It helps that the vast majority of clj deps are essentially just sources, so there's a plausible transition path. For java libs not so much - IMO ideally people would organize and would make it feasible to compile your whole dep chain from scratch.
SHAs are not secure. If the actor was malicious they could -- in principle, at least -- construct a new SHA that matches.
I'll take a look! I did know that sha-1 had been "collided", but from memory I don't think it had an exploit for git, i.e. one thing is finding a random collision, another is creating meaningful code that will also collide. Will check out https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=sha1&sort=byPopularity&type=story