[Bug 575904] Build artifacts made available at the Eclipse Foundation are verifiably the ones built by respective projects.
| Bugzilla Link | 575904 |
| Status | NEW |
| Importance | P3 normal |
| Reported | Sep 09, 2021 12:51 EDT |
| Modified | Oct 21, 2021 07:55 EDT |
| Depends on | 575688 |
| See also | 575688, 575731 |
Description
There have been discussions about relaxing the long-established SimRel requirement to sign all the jars/bundles of every project's release train contributions.
The IDE Working Group Steering Committee was asked for an opinion/position on the topic. I.e., are signed jars important to your organization? The general sense is that signing in and of itself is not so important but rather overall security is key, simply stated as "Build artifacts made available at the Eclipse Foundation are verifiably the ones built by respective projects."
The planning council is tasked with deciding on an appropriate strategy (rules) for ensuring that downloaded artifacts are "secure" and are actually verified to be exactly the ones produced by the projects.
Signing definitely serves that purpose and has the advantage of being verifiable even after the artifacts exist on the machine.
That being said, it has the huge disadvantage that it modifies the artifact such that if the consumed jar was already an OSGi bundle, it needs to be given a new version/ID to produce a result conforming to the current rules. It's also a disadvantage that signatures expire, requiring bundles to be signed yet again.
An alternative "external signature" approach has been proposed and prototyped/implemented.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572816
We could adopt this as an alternative approach to signing, perhaps restricting it to those situations where the contributed jars are not built on Eclipse infrastructure and hence are not readily signed as they are today by Tycho builds on Eclipse's CI infrastructure.
Is this alternative approach sufficient? What are the draw backs and advantages? (Where is it documented?)
Or taking one more step back, do we actually need anything beyond secure metadata (https) and SHAs to verify that the artifacts published to a repository are exactly the same ones (the same bytes) downloaded to the client from the internet? Even if we don't strictly need anything in addition to this, do we nevertheless want an additional (alternative) layer of security? After all, we all do signing already so other than the (significantly) longer build times, disabling internal signing now doesn't buy us anything (beyond faster builds).