Sravan,
I flushed the cache on the job's workspace and reran it from scratch.
https://ci.eclipse.org/oomph/job/repository-analyzer/
This time it did not find unsigned jars from the platform's builds nor
in the SimRel aggregation. So most likely there was some build at some
time in which these were not signed, and those were cached the first
time they were visible. There's no way to track down such artifact
history when the IU IDs are identical; and these IUs have no qualifier
in the version...
Sorry for the false alarm. The platform never has made such mistakes in
the past, so the basic assumption was that this therefore was a
deliberate choice, especially given the ongoing discussions about not
signing things like Jetty in particular. Sorry for jumping to conclusions.
I feel better with your statement that such a change would not be made
unilaterally and without notice.
Regards,
Ed
On 02.05.2021 14:11, Sravan K Lakkimsetti wrote:
I don’t this mail is in good intentions. This is really offending and
upsetting.
This was not reported with the repository analysers either in platform
<https://download.eclipse.org/eclipse/downloads/drops4/I20210429-1800/buildlogs/reporeports/index.html>
or simrel
<https://download.eclipse.org/staging/2021-06/buildInfo/reporeports/>.
Here is the output of jarsigner when I ran on org.eclipse.jetty.util.ajax
C:\Users\SRAVANLAKKIMSETTI\Downloads>"c:\EclipseTest\JAVA\jdk-11.0.10+9\bin\jarsigner.exe"
-verify org.eclipse.jetty.util.ajax_10.0.2.jar
jar verified.
We do have a test in platform to verify unsigned content in the
repository. That test will fail if any bundle is reported as unsigned.
This is based on the repository analyser report generated during the
build. We have been using this for quite some time. I myself has
stopped simrel contribution multiple times the moment I notice a
problem with signing.
I don’t see a problem when the jarsigner returns as success.
-Sravan
*From:*Ed Merks <ed.me...@gmail.com>
*Sent:* 02 May 2021 13:41
*To:* Eclipse platform general developers list.
<platform-dev@eclipse.org>; Cross project issues
<cross-project-issues-...@eclipse.org>; Eclipse Planning Council
<eclipse.org-planning-coun...@eclipse.org>; eclipse-ide...@eclipse.org
*Subject:* [EXTERNAL] [platform-dev] Signed content
Hi, I am assume from observation that the platform team has decided to
change its signing policy to not physically sign some jars anymore:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html
<https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html>
Hi,
I am assume from observation that the platform team has decided to
change its signing policy to not physically sign some jars anymore:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html
<https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html>
This of course propagates to SimRel:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2021-06/index.html
<https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2021-06/index.html>
I don't recall a Planning Council policy decision to drop/change the
need for signed jars. I don't know the full impact this has on the
installer nor on consumers. The installer at least appears to
happily install such things and the IDE presents such things to the
user as if they are signed:
Slowly I get the feeling that SimRel is a no longer process where we
all work together as a team. Rather it feels as if the platform team
can and does unilaterally make decisions for everyone else.
Regards,
Ed
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
