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
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
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
