Consider signing Maven artifacts

[akurtakov]

With new capabilites in Tycho and PDE, Eclipse Platform considers using Jetty Maven artifacts directly instead of generating p2 repo for them.
Issue is that artifacts in p2 repo are signed while artifacts in maven central are not. Would you please consider signing them prior to publishing to maven central?
Signing is done via https://www.eclipse.org/cbi/maven-plugins/documentation/1.1.3/eclipse-jarsigner-plugin/sign-mojo.html currently and as you use maven build system it should be integratable.

[joakime]

Maven central requires that all artifacts (not just jar files) are capable of being verified via an associated gpg signature.
The gpg signatures used by Jetty developers are present in a file in our repo.

https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/KEYS.txt

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).

Question, if the artifacts are already signed (externally), and you can verify this programmatically, then why is signing the artifact internals a requirement for the entire world of users that consume Eclipse Jetty artifacts.

[akurtakov]

It's a requirement for Eclipse SimRel (https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Signing_.28tested.29) I wish we lift it in favor of solution like described at https://www.eclipse.org/lists/p2-dev/msg05910.html but it will take time to get an agreement and even more to implement.
I wish for easier path for me but looks like we are not there yet. Thanks for the fast reply!

[mickaelistria]

https://wiki.eclipse.org/IT_Infrastructure_Doc#What_about_GPG_signing.3F makes it clear: jar-signing (if happening) must happen before pgp signing. So one cannot jar-sign a published jar on Central after the fact; adding jar-signature requires a rebuild and a new release. It's not that complicated to setup though, but it's definitely extra work...

[joakime]

@mickaelistria the order of the build is not the issue here.

It's the existence of standard java JAR signatures in the META-INF/MANIFEST.MF is the problem for many of our users.

Eclipse SimRel, RCP, and OSGi requirements should not break our other users.

[mickaelistria]

It's the existence of standard java JAR signatures in the META-INF/MANIFEST.MF is the problem for many of our users.

OK. I'm curious, do you have reference to concrete issues about that?

[joakime]

There is large variety of bytecode manipulation tools/libs trigger these issues.

A common scenario are those that modify/instrument the Jetty internals and even the Servlet APIs to for auditing and metrics reasons.
When the JARs have signatures, those classes are not allowed to be modified at the classloader level.

There's many different bytecode manipulation techniques out there. It seems the ones that modify and replace the raw class bytes on the classloader are the ones that trigger this most often (eg: ones that use the various defineClass classloader methods).

We've also had past reports of users of the orbit versions of the servlet api in combination with java.lang.instrument.ClassFileTransformer.
The solution was to not use the orbit version and use the standard version of the servlet api instead. (simply moving away from the signed jar fixed things for them).

[mickaelistria]

OK, I was expecting jarsigning/bytecode manipulation to be more separated (ie jarsigning only happening when reading the .class file and that's all, allowing further bytecode manipulation to happen. But indeed, if this prevents bytecode manipulation, it's a major limitation!

[joakime]

To be clear, the bytecode manipulation I'm talking about is at runtime, not build time.

[mickaelistria]

To be clear, the bytecode manipulation I'm talking about is at runtime, not build time.

Yes, but still; I'm surprised and just didn't know well enough jarsigner. I wasn't expecting jarsigner would be doing so (too) much about classloading lifecycle, I thought it just hooked at resource loading.

[joakime]

I'm not sure when the classloader behavior changed, but my recollection was that it was late in the Java 7 cycle.
In the past, the default behavior of the java classloaders defineClass was essentially (paraphrasing here) create class from bytes (with no java.lang.Package or java.security.ProtectionDomain defined)
Now its behavior is ClassLoader.getAndVerifyPackage() and then create class from bytes with Package and associated ProtectionDomain (which in the case of signed classes means you cannot re-define those classes)