Hi Jesse,

To paraphrase Wayne, in short: the Eclipse Foundation has a responsibility in 
making sure that the community can trust every bundle they consume from the 
simultaneous release.

What we currently do is to sign these bundles with a certificate from the 
Eclipse Foundation. This is a quality mark: Implicitly stating that we have a 
complete history of every commit to every repository producing these bundles; A 
pretty good QA process for these commits, and a very good idea of who these 
committers and contributors are; A rigorous process to ensure safe 
licensing/patent use and provenance of third party bundles. It's pretty much as 
good it as it can get in open source.

I think I understand from your message, is that you believe this signing is 
worthless and that no consumer should require a signed artefact. If I'm right, 
how do you propose we otherwise could do this better? What is impractical  with 
having to deal with signed bundles?

Best regards,
Torkild


> 22. jan. 2021 kl. 20:33 skrev Jesse McConnell <jesse.mcconn...@gmail.com>:
> 
> 
> All bundles must be signed using the EF's certificate. Obvious exceptions 
> will be made in cases where signing is impossible.
> 
> We will be applying this standard to the next release and for every release 
> thereafter.
> 
> The means by which the simultaneous release participation rules are changed 
> is to engage with the Eclipse Planning Council via your Eclipse Planning 
> Council representative.
> 
> So if I understand correctly everything from above can be changed via the 
> Planning Council. I'm especially interested in the signing as it's becoming 
> harder and harder to keep up with external ecosystem due to way faster pace 
> and being able to use different means of signing as discussed at 
> https://www.eclipse.org/lists/p2-dev/msg05910.html becomes critical. But 
> let's keep this discussion for the next Planning Council meeting.
> 
> Personally, I think the entire concept of this sort of signing should be 
> reviewed.  If the editor wants to release signed artifacts then the onus 
> should be on the editor to trust and sign everything it pushes out with the 
> EF cert, it shouldn't export requirements to projects it consumes to 
> themselves have things signed by the EF cert. That whole service that the EF 
> provides for jar files to show up in some directory and signed artifacts 
> popping out in another is hokey and combined with the concept of p2 
> repositories is a big reason Jetty left the release train.
> 
> cheers,
> Jesse
> 
> _______________________________________________
> 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

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
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

Reply via email to