> That's up to them but they're not pushing that sort of requirement out to everyone else.
You're right. They're not. Why are we arguing? Wayne On Sat, Jan 23, 2021 at 9:42 PM Jesse McConnell <jesse.mcconn...@gmail.com> wrote: > Security model for artifacts in Maven Central is sufficient for most of > the known world, and if the eclipse foundation was interested in signing > the keys of committers then the artifacts that committers from the eclipse > foundation published to Maven Central could have a web of trust associated > with the .asc and checksum files. Then if the bundlers of the eclipse > editor wanted to further sign their artifacts using jarsigner then that's > their prerogative, they can validate the web of trust on anything they're > using that's coming from a Maven Central and keep doing whatever the status > quo is for P2 repositories. That's up to them but they're not pushing that > sort of requirement out to everyone else. > > cheers, > Jesse > > On Sat, Jan 23, 2021, 16:36 Torkild U. Resheim <torki...@gmail.com> wrote: > >> 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 >> >> _______________________________________________ >> 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 mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation
_______________________________________________ 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
