On Thu, Jan 21, 2021 at 9:32 AM Johan Compagner <[email protected]> wrote:
> (from there) > "If the eclipse-jarsigner-plugin modifies the META-INF/MANIFEST.MF with > signatures, then this is undesired for general usage of our artifacts > (there are enough projects that use Eclipse Jetty with bytecode > manipulation where actually signed jar files do cause problems at the > classloader)." > really? i have never heard of that.. isn't byte code manipulation done > after the class that you manipulate is loaded through the classloader and > checked? or are they saying if you generate fully new classes in memory > with that package then you get that "different signagures of the same > package" problem? > In many years i think we used byte code manipulation stuff (even currently > i think in our eclipse product) and everything is signed but i never > encountered any problem, so i really wonder if there is a unit test > As mentioned on that ticket, I was also surprised. I don't have knowledge to confirm nor invalidate that, so I trust them. Note that already related for the "strategy" part of dealing with signatures in the Eclipse Foundation and SimRel (it really brings the question whether jarsigner is still desired in general); this is technically not so related and not exclusive with the idea of having PGP signatures as well: jarsigner and PGP are compatible and can be both applied on the same artifact, as long as jarsigner runs first. If you do PGP external signatures, where do those external things come from > when for example eclipse wants to update/install plugins (and it checks > that kind of signature)? > As I imagine it (as Alexander mentioned, we're still brainstorming, imagining more than actually starting anything concrete), the artifact signatures would be stored a p2 metadata in artifacts.(xml|jar|xml.xz) files. The signature do contain the public key of the signers (`gpg --list-packets artifactSignature.asc`); resolving signer name from public key does require that the public key details gets available -in metadata, in local pgp registry or wherever else fits best- on the machine or can be retrieved remotely. > Do i need to have an internet connection? > Verifying that the signature matches artifact (`gpg --verify artifactSignature.asc artifact.jar`) and getting the signer public key (`gpg --verify artifactSignature.asc`) does not require an internet connection Knowing the declared identity of the signer from the public key requires to have access to key details, either they are available locally (`gpg --list-keys`) or usually need to be imported from some PGP registries (usually requiring connection). But we could totally imagine including the public key details in p2 metadata as well, that's 1 less thing to download. Deciding to trust or not a new/unknown/not-already-trusted key (in order to decide whether to continue installation or not) usually requires to contact some of the pgp registries that did perform some verification when pushing a key and guarantee that the key is actually owned by the declared owner. Not that this approach is not much about runtime integrity check (unlike jarsigner), it's more install time data to help deciding whether to install or not based on keys user decides to trust (+some integrity validation ensuring the content you downloaded is that actual content that was signed, which I agree with Ed are not much more than fancy checksums in this workflow). Assuming we put public key details in p2 metadata as well, then user would see when installing artifact "PGP-signed by [email protected]"), they could decide to abort installation or proceed with next step. If this key of [email protected] is trusted already, next step is installation and verification of the signature against the downloaded artifact. If this key of [email protected] is not trusted, user is prompted whether to trust it or not; the dialog could totally query most famous PGP registries to add a note "The public key is not verified in any popular registry" or "This public key is verified by this popular registry" to help user in making their decision of whether to reject or trust the key; and then to install or abort. Does it seem viable?
_______________________________________________ p2-dev mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/p2-dev
