Re: [cross-project-issues-dev] [platform-dev] Signed content

2021-05-02 Thread Andrey Loskutov 
Ed,

 

most likely you saw the I-Build (one or two) with unsigned jetty jars, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=572586#c10.

 

Sometimes things simply break, but we monitor signing issues and try to fix them as soon as we can.

 

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [platform-dev] Signed content

2021-05-02 Thread Ed Merks 

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 
*Sent:* 02 May 2021 13:41
*To:* Eclipse platform general developers list. 
; Cross project issues 
; Eclipse Planning Council 
; 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 
 



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

Re: [cross-project-issues-dev] [platform-dev] Signed content

2021-05-02 Thread Sravan K Lakkimsetti 
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  
Sent: 02 May 2021 13:41
To: Eclipse platform general developers list. ; Cross 
project issues ; Eclipse Planning Council 
; 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
 ZjQcmQRYFpfptBannerStart 




This Message Is From an External Sender 


This message came from outside your organization. 

ZjQcmQRYFpfptBannerEnd



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

 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Signed content

2021-05-02 Thread Ed Willink 

Hi

The QVTd build has just failed [1] with:

java.lang.SecurityException: class "org.eclipse.core.runtime.RegistryFactory"'s 
signer information does not match signer information of other classes in the same package

This has happened a few times before [2], [4].

The problem was always that a split package had only been partially 
rebuilt and so was inconsistently signed.


The specific bad build was fixed, but the stretch bug [3] of 
guaranteeing a rebuild of the split package ensemble remains outstanding.


This looks like the same problem again, but may be the new don't sign 
policy has rippled, so I'll defer raising another Bugzilla pending 
discussion here.


Regards

Ed Willink

[1] https://ci.eclipse.org/qvtd/job/qvtd-master/377/display/redirect
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=267150
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466991
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=531640
On 02/05/2021 09:10, Ed Merks wrote:


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



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Signed content

2021-05-02 Thread Ed Merks 

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


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev