JAR signing, v2

[danielcompton]

From this thread: https://twitter.com/tcrawley/status/768640307588104192

There are meaningful security benefits that could be had from signing JARs if we can overcome the horrendous UX problems that they involve. Leaving this as a placeholder for more discussion.

[lvh]

Can we enumerate the UX problems? I'm hardly a GPG UX apologist, but some of the major issues as I understand them include "people don't understand WoT", "nobody actually uses WoT but instead only use keys that came with their machine or keys they signed themselves", and "literally every e-mail plugin is awful". It seems like the main UX issues are around WoT?

I'd agree that keybase is a real solution to this, if keybase focused more on being GPG anchoring (which is how I, as an early adopter, interpreted it), instead of the stuff around it like kbfs, per-device keys, et cetera, which would be their current focus.

[danielcompton]

The main UX problems that I've encountered:

• It is difficult/nigh on impossible for most Windows developers to get GPG setup properly, or at least I've never found a straightforward guide for this. From memory running gpg-agent was particularly troublesome.
• I don't have a good mental model for GPG key management. Compared to SSH, where I can read plain text files in ~/.ssh, with one file per key, GPG has a few opaque binary files which store my key state.
• I don't remember now exactly what the problem was, but I've wrestled with GPG to set it up on new computers.

To me, the web of trust conceptually is pretty simple, although I'm not clear what the mechanics are of managing this (as I've never had a need to).

At least for me, it has all boiled down to not having a clear model of what GPG is doing, which means that when stuff doesn't go quite right, I don't know how to debug this.

For future reference, starting from scratch with Keybase, and using https://gist.github.com/danieleggert/b029d44d4a54b328c0bac65d46ba4c65 worked quite well (though I installed gnupg2 and pinentry-mac from Homebrew).

[lvh]

Whew! This is a blast from the past :) I'd be happy to talk to the PyPI folks to see what they'd do today but honestly I think I'd just go straight for minisign or ssh-based signatures now, especially since SSH keys are exposed via GitHub (and so we can independently at least attach a GitHub identity to a signing key).

[lvh]

tagging @tcrawley in this since they presumably have opinions :)

[tobias]

I was just doing some cleanup, and converting discussion-y issues to discussions. I currently have no opinion :)

[nealmcb]

These days the cool kids are using Sigstore, which can sign just one package or an entire supply chain, and lets you optionally avoid key management entirely by leveraging email identities via OIDC. See Talk - Dustin Ingram: Securing the Open Source Software Supply Chain

From a Jar perspective, see also Maven Central and Sigstore.

[lvh]

Yup: I was in the audience for that talk and am generally a big fan of Chainguard and Sigstore. I'm excited for it it, but it does seem a bit early though: all in beta, and assuming everyone can rely on OIDC identity (either via something like workload identity or via OAuth). I'm a fan, but it is going to need someone motivated with a lot of spare cycles to implement, and I expect we'll have a few curmudgeons (who granted may not be happy with anything other than their DSA GPG key from 2004).

[slipset]

From a slack comment I wrote:

Hey, I’ve been grappling with the issue of verifying signed artifacts for a while. It would be really nice if Clojars in one way or another could show that a given signed artifact was in fact signed by some verified key.
First thought that came to mind was that one could publish the public signing key in the repo that contains the code under a known file name and that Clojars then would have enough information to actually verify.
What’s wrong with an approach like that?

The last question is not an assertive one, but rather an invitation to pull this solution apart and tell me why it will never work in practice.

FWIW. I do some work with clj-commons, and have set up automagic builds for a bunch of those projects which deploy signed artifacts to Clojars. Getting that to work properly was so painful, I'm not even sure I could endure doing it again. Basically I followed https://joemiller.me/2019/07/signing-releases-with-a-gpg-project-key/ here to create a signing key (not really understanding what I did) and then hacking around with CircleCI yaml to arrive at https://github.com/clj-commons/ordered/blob/Release-1.15.11/.circleci/config.yml#L157 which allows for us to pass enough information to leiningen for it to be able to sign the releases.

Making the signing key available to Circle without having to type a pass phrase was extremely difficult. So difficult I even don't remember why. And I believe that the first time I tried to publish a key, gpg just hung, so I gave up :/

Of course, in that process, I forgot to publish my public signing key to somewhere, so there is no way to verify that the signed artifacts are actually signed by me.