Clojurians Log v2
clojure-dev
Has signing Clojure CLI releases been considered/implemented? For example, providing a file to gpg --verify clojure-tools-X.{tar.gz,sha256}.asc the tarballs/sha's, or having clojure-build use signed commits/tags when committing tarball sha's? It might be a useful security layer for build tooling such as the setup-clojure Action or creating docker containers, the idea being we swap trusting a subset of github infra for trusting signatures.
Perhaps with further hardened/reproducible builds the sigs could be more trustworthy for subsequent releases. Or maybe jumping straight to attested builds makes more sense, but this seemed like lower-hanging fruit.
Started sketching it here https://github.com/frenchy64/brew-install/pull/1/files
This turned into 3 tasks that I think can be considered separately (probably sequentially): 1. check tar/zip checksum before extracting ("done" untested in PR) 2. sign the installers 3. improve bootstrapping security (e.g., use gpg key to validate the Clojure CLI installation we use to call tools.build)
seems like a good breakdown, feel free to make jiras for these in TDEPS project
can/should I pick these up and start working on them?
sure, although it's helpful to write down what you propose first and then I'm happy to review that before you spend the time to do it
I will do that
and the other thing is the windows installer is going away - it's been replaced by the https://github.com/casselc/clj-msi project so please don't spend any time touching the powershell stuff
ah great. I think we can simulate something similar by signing our .sha256 files, then having clj-msi verify the .sha256 signature, then checksum the release itself. I'll open an issue there.
the msi installer actually supports signing but it's not currently set up iirc
oh ok great
if you or anyone wants to figure that out, that would be great (might be some discussion needed to get secrets in the right place)
yeah I'll talk to @delaguardo about what we need for setup-clojure too. is that something we should track in jira? e.g., make a list of all the ways people install clojure in practice, and what the core team can do to help them improve security?
perhaps this list already exists. e.g., clj-msi, setup-clojure, brew...
feels like a jira Epic but I don't know if that's a thing in your process
nah, we don't use anything other than stories
clj-msi updates should be handled on that project's github issues
I proposed an approach for https://clojure.atlassian.net/browse/TDEPS-269 please take a look. The other two are a little entangled, because I want the build to be sufficiently compartmentalized before signing artifacts within it, but signed artifacts would help compartmentalize the build (into trusted/untrusted areas). I'll give it more thought.
@alexmiller I proposed a patch for https://clojure.atlassian.net/browse/TDEPS-269. I documented my testing procedure on the ticket.
Sure, could
What do you think about embedding the tarball's sha256 in linux-install.sh, and then signing linux-install.sh? Installer will verify tarball checksum after downloading similar to brew, but callers also have the option of verifying the signature of linux-install.sh themselves before they call it.
I just tried to reference java.lang.AutoCloseable and discovered that it's not in RT.java. The interface came out in JDK 1.7, and Clojure now requires Java 8, so should it be added?
Other java.lang items missing:
• BootstrapMethodError added 1.7
• ClassValue added 1.7
• FunctionalInterface added 1.8
• ReflectiveOperationException added 1.7
• SafeVarargs added 1.7
I also see that most of the inner classes are not included. I realize this may be a deliberate choice, though Thread$UncaughtExceptionError and Thread$State made it.
As Clojure starts to update the minimum JDK, then there are others to consider as well:
• IllegalCallerException added 9
• LayerInstantiationException added 9
• MatchException added 21
• ModuleLayer added 9
• ProcessHandle added 9
• Record added 16
• `StackWalker` added 9
• WrongThreadException added 19
We have a ticket for this under review right now
So much for offering to take on low-hanging fruit 🙂
Thank you
We have several tickets for updating all the Java stuff
@alexmiller Do you think there would be any support at all for auto-importing a couple of clojure.lang.* items? ArityException and ExceptionInfo are the only two I'd suggest, primarily because all the java.lang.*Exception classes are auto-imported.
I haven’t closed out that ask yet, I was planning to file a jira for ExceptionInfo and see what Rich thinks
I think ArityEx is vastly less common
I only noticed ArityException when I went looking at clojure/lang/*.java right now, and I don't think I've ever encountered it in the wild -- it was mostly for consistency that "Exception classes are auto-imported". I'd be fine with just ExceptionInfo being auto-imported. That said, at work we only have 18 instances of it in 12 files, and 7 of those files are tests. We tend to be lazy and catch Exception or (shudder) catch Throwable and then call ex-data but I think it if was auto-imported, we'd be more likely to catch ExceptionInfo instead 🙂
I'm plus_one for this one!
It feels like an obvious one, since there are clojure.core functions specifically for creating and working with it, and I don't want to call ex-data unless I've caught that specific type.
github has 940 instances of ArityException imported or used in public repos (which double counts when a file both imports and uses): https://github.com/search?q=lang%3Aclojure+ArityException&type=code