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