I still can’t see a substantial change in security by requiring double signatures on JARs: these really just amount to a second “secret” that vendors must prove to Atlassian that they know (on top of account password + 2FA) in order to get Atlassian to apply its master signing signature. I don’t see how customers would be able to check this signature, so it’s really only between the vendor and Atlassian.
From a semantic perspective, requiring the vendor signature then becomes almost equivalent to (but far more complicated than) asking vendors to enter a second “signing password” into MPAC when creating the signature. Yes, this second password could be stolen, but then again, so could the signing secret. There are a few smaller differences between the two, but I don’t actually advocate for either because I don’t think they help substantially.
The goal should be to solve the problem with little or no effort for 99% of vendors, which is automatic single-signing by Atlassian of all JARs uploaded to Marketplace (and also doing whatever magic it takes to make @oliver.straesser ’s OBRs completely signed, top-to-bottom). For those distributing only through the Marketplace, there is no extra effort required. It would also be great if “private” releases uploaded to the Marketplace for a public app could also be signed by Atlassian without forcing it to be a public release, since this is very useful in support contexts.
For the 1% of remaining edge cases (customers with a stable of private plugins, app support team needs to make a private release outside of Marketplace, solutions partners who sell private plugins to their customers, etc), I think there is a use case for vendor signing, but this should be independent and not a condition of Atlassian’s signatures.
The signing tooling should be made available so that people can create their own certificates and sign their own JARs/OBRs. When installing an app, the host product verifies the app against the Atlassian master cert (baked into the host product), or also against a set of arbitrary certificates installed by the admin.
Please let these certs be something that can be added at runtime in a secure manner without recycling the cluster (for example, by scanning for .CRT files dropped somewhere into the product data directory).
This tool should ideally be a simple command-line (and offline) Java program that has one option to generate a cert+key, another to sign an artifact, and another one to validate an artifact and show the signature.