| Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages |
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.mcconnell@xxxxxxxxx>: > > > 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@xxxxxxxxxxx > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Attachment:
signature.asc
Description: Message signed with OpenPGP