Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-ide-wg] [cross-project-issues-dev] [platform-dev] Signed content

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.merks@xxxxxxxxx>
Sent: 03 May 2021 11:57
To: Eclipse platform general developers list. <platform-dev@xxxxxxxxxxx>; Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>; Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>; eclipse-ide-wg@xxxxxxxxxxx
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/ 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/

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 or simrel.

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.merks@xxxxxxxxx>
Sent: 02 May 2021 13:41
To: Eclipse platform general developers list. <platform-dev@xxxxxxxxxxx>; Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>; Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>; eclipse-ide-wg@xxxxxxxxxxx
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


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

This of course propagates to SimRel:

  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@xxxxxxxxxxx
 
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
 


Back to the top