Feature Request: Better distinction of signature verification vs. trust

[ches]

This is a feature request, I'll try to work on it myself when I can find time but I wanted to log the idea. The project is due for some love 😊

The current output of checkPgpSignatures conflates trust and signature verification. The usage documentation kind of acknowledges the shortcoming:

In the above output, the signature for derby is from an untrusted key (id: 0x98e21827). You can import this key into your public key ring, and then the plugin will trust artifacts from that key. The public, by default, accepts any keys included in your public key ring file.

(I presume the last sentence is a typo, s/The public/The plugin).

Mere presence of a key on my keyring, with no signature by me, is not how trust works in PGP. I think we all know that, but sbt-pgp could do better to make this clear.

In reality most of us can't reasonably expect to trust, in the formal PGP sense, the providers of every library dependency in our software projects, open source communities are so far-reaching and there aren't that many dedicated regular PGP users out there to realistically connect a web.

So in practice, trust is secondary to signature verification for the usage of PGP signing in artifact distribution: we want to feel confident that binaries haven't been altered or corrupted.

I propose that checkPgpSignatures should output two distinct columns:

• Indication of signature verification – true/false value
• Trust level – values of unknown/none/marginal/full as the gpg tool displays (I haven't consulted the OpenPGP spec in detail yet but I'm hoping that basically maps to the content of the opaque byte array from Bouncy Castle's getTrustData(), but that might be "owner trust"…).

IMO, the task should pass if all signatures are valid, regardless of trust. This is the most practically and realistically useful behavior and is consistent with the task's name. Then we could improve on the ambiguity of the summary output:

Some artifacts have bad signatures or are signed by untrusted sources!

Finally, it would be nice if the plugin offered to import all the keys missing on the keyring, to make it easier to actually use checkPgpSignatures on a regular basis, even as an sbt-release ReleaseStep for instance. This could be worked on as a separate feature.

[jsuereth]

So, checkPgpSignatures was original created to start promoting the PGP model. Indeed, it was kind of a "quick hack" to see if we could get anywhere near what GPG offers (but implemented in a way that was windows friendly, i.e. pure JVM).

I'm more than happy to see it expanded, and I understand your concerns on trust vs. verified. I'd be more than happy to see improvements here. I agree it should not fail for untrusted, perhaps we need tasks that do though? (checkTrustPgpSignatures).

The reality is that after I implemented the method and checked some real-life project there were SO MANY missing PGP signatures, that I realized it'd be impractical to ever force checkPgpSignatures outside of perhaps a company setting. I could be wrong, and we may need to push users to sign more and to promote the idea of signatures, trust, etc.

More than happy to see your two-column approach. Send the PRs :)

[ches]

Thanks for the feedback Josh. It's a pretty functional quick hack already 😃

It's unfortunate that a lot of packages aren't signed, at least Maven Central requires it but I wouldn't be surprised if that's at least part of the reason that some people prefer to use other repos, lower friction…

That does bring up a point: I was thinking checkPgpSignatures would pass as long as there are no invalid signatures, I hadn't considered whether to require that every dependency is actually signed… I wonder how people feel about that or if there should ideally be settings or something.

Anyway I'll try to get something cooking when I can find the hack time 😄

[jsuereth]

regarding things not being signed, I think it's just a matter of time until everything we use in maven-central is something that has been published under the "required PGP signature" regime we have now. So it's a temporary problem, but one that convinced me not to pursue checkPgpSignatures "yet". Maybe the time is right? Would be worth checking it out :)

[graingert]

This would allow sbt-pgp to auto download untrusted keys and check to see if they are trusted later.

[graingert]

maybe a sbt signPgpKeys [local] [trustLevel]