On Thu, Jan 21, 2021 at 10:33 AM Johan Compagner <[email protected]> wrote:
> >>> Signing is a certification of origin that follows the artifact around no >>> matter where it goes... >>> >> >> I've just tried getting Jetty to sign there artifacts and it seems that >> external PGP signature is preferred way in the way more security constraint >> world of web servers. Actually signatures in MANIFEST.MF are considered >> harmful for some usecases . Please see >> https://github.com/eclipse/jetty.project/issues/5898 for details. >> >> > > (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? > There is support for verifying at runtime (search osgi.signedcontent.support in https://help.eclipse.org/2020-12/index.jsp) and this is probably similar to the usecase that breaks for Jetty. If Jetty specifically removed injar signatures I trust them that they had a real issue. > > 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 > > 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)? Do i need to have an internet connection? > These are all questions that are up for discussion. Technically it should be possible for the pgp public key used to sign the plugin to be part of the p2 metadata so being part of the update site itself and using eclipse foundation pgp key as "Root CA" and distribute with eclipse always ( like it's expected "Root CA" is available on the machines or current certificate validation will fail) and this Root CA being used to sign the metadata itself. Such a model could allow extensibility like the following: - more open "Root CA" in which smaller entities can participate if they don't have the infrastructure/money/whatever to pay for certificates etc. - stricter "Root CA" where only your company certificate is trusted as one artifact could be signed with multiple certificates if the signature is external. Again, there is no work started so such questions are very appreciated as they allow us all to think more in detail and potential blockers. Keep'em coming! > > > _______________________________________________ > p2-dev mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/p2-dev > -- Alexander Kurtakov Red Hat Eclipse Team
_______________________________________________ p2-dev mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/p2-dev
