-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable resigning of already signed jars #2134
Comments
This is might be doable but has to be checked deeper by someone as resigning is done before the decision to replace or not with baseline version is taken
Thus if the bundle is changed and not resigned - a not signed version will end up in the build output. |
if builds on master would not be signed at all, that would also be quite some relief for other projects imho. |
the eclipse-jarsigner could also be extended to have another resigningStrategy, something like |
One can exclude certain files from the comparator as it is for example done in M2E: IIRC for MANIFEST.MF only the main section is checked any ways so all signatures are ignored.
Thinking about it I wonder why artifacts signing was activated at all on the master. These artifacts are not published, only archived as Jenkins build artifacts. But I don't think they are used for anything else than checking build results. |
Signatures are (as far as I know) already excluded, anyways the log seem to suggest that the artifact is already signed, so skip the signing seems obvious, at least recently @merks needed to bump versions manually if signing changes anyways.... |
Reduce the number of actual signing by not signing artifacts on master branch builds in this repository (the built artifacts are not published) and not re-signing artifacts in the I-build that are baseline replaced and therefore already signed. Fixes eclipse-platform#2134
Reduce the number of actual signing by not signing artifacts on master branch builds in this repository (the built artifacts are not published) and not re-signing artifacts in the I-build that are baseline replaced and therefore already signed. Fixes eclipse-platform#2134
Reduce the number of actual signing by not signing artifacts on master branch builds in this repository (the built artifacts are not published anywhere). Fixes eclipse-platform#2134
Reduce the number of actual signing operations by not re-signing artifacts (in the I-build) are already signed (usually because they have been 'baseline-replaced'). Fixes eclipse-platform#2134
Reduce the number of actual signing operations by not re-signing artifacts (in the I-build) are already signed, usually because they have been 'baseline-replaced'. Fixes eclipse-platform#2134
With #2140 signing will be disabled entirely for the master/maintenance branch builds of this repository. Currently I find the String As a follow-up I created #2143 to reduce the signings even further by not re-signing the actual jars. |
You’re awesome 😎 |
tyvm, that should reduce the number of signing operations considerably and give us more room for implementing a more scalable signing service (they are usually charged by signing operations / year and our number is really high). |
Reduce the number of actual signing operations by not re-signing artifacts (in the I-build) are already signed, usually because they have been 'baseline-replaced'. In order to ensure that signatures of baseline-replaced artifacts can be considered, the p2-baseline-replacement is moved before the eclipse-jarsigner-plugin. Furthermore set 'defaultP2Metadata' to false to skip the default baseline replace. Fixes eclipse-platform#2134
Why doesn't EF recommend going PGP signing wherever possible (everything but native content more or less) in this case? |
We discussed this internally. Adding jar signing support to the Eclipse IDE was apparently a difficult process as I have been told and we do not want to open another can of worms atm that was the conclusion. Hopefully we have a more scalable solution soon. |
Reduce the number of actual signing operations by not re-signing artifacts (in the I-build) are already signed, usually because they have been 'baseline-replaced'. The baseline replacement is performed first the 'p2-metadata-default' goal executed by default and before the jar-signing. The subsequent explicit invocation of the p2-metadata (non-default) goal is again necessary to update the p2 metadata (like artifact size) after the jar has been altered by the signing operation. Fixes eclipse-platform#2134
Reduce the number of actual signing operations by not re-signing artifacts (in the I-build) are already signed, usually because they have been 'baseline-replaced'. The baseline replacement is performed first the 'p2-metadata-default' goal executed by default and before the jar-signing. The subsequent explicit invocation of the p2-metadata (non-default) goal is again necessary to update the p2 metadata (like artifact size) after the jar has been altered by the signing operation. Fixes eclipse-platform#2134
Reduce the number of actual signing operations by not re-signing artifacts (in the I-build) are already signed, usually because they have been 'baseline-replaced'. The baseline replacement is performed first the 'p2-metadata-default' goal executed by default and before the jar-signing. The subsequent explicit invocation of the p2-metadata (non-default) goal is again necessary to update the p2 metadata (like artifact size) after the jar has been altered by the signing operation. Fixes #2134
FYI I just submitted #2143, which should again (usually) significantly reduce the number of signing operations in I-builds. That should also reduce the overall runtime of I-builds. |
As you are aware, signing of jars using the Eclipse Foundation signing service is currently quite slow as the service is in degraded mode and only support 1 concurrent signing atm.
While trying to mitigate that for now till we have a more scalable solution, I have noticed in the build at https://ci.eclipse.org/platform/job/eclipse.platform.releng.aggregator/job/master/ that there are lots of jars (> 800) that are signed for each build. Many of these jars are already signed, and you will find entries like that in the log file:
I was wondering if it would not make sense to change the resigningStrategy of the eclipse-jarsigner plugin to something like
DO_NOT_RESIGN
instead of keeping at the default which isRESIGN
.More information about the configuration can be found at: https://eclipse-cbi.github.io/org.eclipse.cbi/eclipse-jarsigner-plugin/sign-mojo.html
Disable RESIGNING would reduce the number of signing operations considerably imho.
cc @merks
The text was updated successfully, but these errors were encountered: