We are not, I was addressing Alexander's comment about signing becoming harder and relating that to participation in the release train. You can say that the editor isn't pushing out a requirement but signing is a requirement to opt-in and participate. I believe Alexander is saying that because external projects (or even internal projects) that don't participate in the release train are moving faster all the time the manual processes involved with signing to get things into a state for the editor to consume are becoming increasingly problematic. Seems like a place where establishing a web of trust around signing keys would work well to address but if talking about that is arguing then I am happy to go back to lurk mode.
cheers, Jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sat, Jan 23, 2021 at 10:15 PM Wayne Beaton < wayne.bea...@eclipse-foundation.org> wrote: > > 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 >
_______________________________________________ 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
