No. artifacts.jar and content.jar do not need to be signed. (Nothing checks if have been tampered with).
Its a little less important that they are, since they are primarily data that's read from server (and, ideally not even 'mirrored') ... they are not something that's downloaded and executed ... though I'm sure someone could in theory find some way to abuse it (but, by then they'd have access to the server, and I'm sure could do more interesting things :) (Last I asked about it ... 3 or 5 years ago, the response I got was basically "guess we could, but currently do not"). From: Jeff Johnston <jjohn...@redhat.com> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 09/13/2013 01:44 PM Subject: [cross-project-issues-dev] Change in signing plug-in results in repository changes Sent by: cross-project-issues-dev-boun...@eclipse.org In Linux Tools, we have switched over to use the eclipse-jarsigner-plugin instead of eclipse-signing-maven-plugin. We have noted that in past builds, we ended up getting a top-level META-INF directory with signing info for artifacts.jar when we used the old eclipse-signing-maven-plugin. Is this an issue? Does anything use this info to verify that artifacts.jar is not tampered with? -- Jeff J. _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
