Re: [cross-project-issues-dev] Simultaneous Release participation and th

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

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 <torkildr@xxxxxxxxx> 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.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

_______________________________________________
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