Sravan,
Don't worry! You were simply being honest about how you felt and given
there was indeed no intent behind the unsigned artifacts it's perfectly
understandable that you should find my comments upsetting and therefore
offensive. Am I am sorry for that.
Yes, signing jars produced by others, especially externally, is not
completely ideal either. I know the platform is working on alternatives
to that and of course that's something we'll need to consider and
discuss in the near future as an alternative.
Regards,
Ed
On 03.05.2021 10:20, Sravan K Lakkimsetti wrote:
Hi Ed,
I am sorry If I offended you with my earlier mail. Let me clarify my
stance on signing.
Any bundle that is built by Eclipse project has to be signed. To me
this is non-negotiable.
The discussion is on the orbit bundles that gets built by fetching
from maven central. By signing these we are actually creating new
bundle which can diverge(technically) from the source(maven central).
In this case the vendor will not responsible(as we modified the
bundle) from problems we encounter in the bundle. This is something I
want to find a solution for. We had discussions but there is no
concrete solution in this matter.
I hope I clarified my position in this matter.
Thanks
Sravan
*From:*Ed Merks <ed.me...@gmail.com>
*Sent:* 03 May 2021 11:57
*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] Re: [cross-project-issues-dev] [platform-dev]
Signed content
Sravan, I flushed the cache on the job's workspace and reran it from
scratch. https://ci.eclipse.org/oomph/job/repository-analyzer/
<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
Sravan,
I flushed the cache on the job's workspace and reran it from scratch.
https://ci.eclipse.org/oomph/job/repository-analyzer/
<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> <mailto:ed.me...@gmail.com>
*Sent:* 02 May 2021 13:41
*To:* Eclipse platform general developers list.
<platform-dev@eclipse.org> <mailto:platform-dev@eclipse.org>;
Cross project issues <cross-project-issues-...@eclipse.org>
<mailto:cross-project-issues-...@eclipse.org>; Eclipse Planning
Council <eclipse.org-planning-coun...@eclipse.org>
<mailto:eclipse.org-planning-coun...@eclipse.org>;
eclipse-ide...@eclipse.org <mailto: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 <mailto:platform-dev@eclipse.org>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/platform-dev
<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
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
