[cross-posted to epp-dev mailing-list] Hi, That means that the "Eclipse IDE for Rust developers" package should not appear on the https://www.eclipse.org/downloads/packages/ page. To be honest, it's not a big deal, I'll adjust links from Corrosion README so they point to the internal EPP download area. So if you wish to proceed with removal now, feel free.
The parts about signing are more a reminder of current rules, so no impact here. However as Alexander mentioned, I think it's worth exploring alternative approaches to signing if we want to innovate faster. The whole world, including the majority of active Eclipse Foundation projects, except Eclipse SimRel participant, manage to go round without jarsigner. If we want SimRel to remain in touch with this world, able to consume new APIs and so on more easily, in the continuation of all efforts done to improve 3rd-party approval from IP perspective, we need to find a more efficient way to deal with external artifacts that are unsigned. Orbit doesn't go fast enough anymore... On Fri, Jan 22, 2021 at 4:23 PM Wayne Beaton < wayne.bea...@eclipse-foundation.org> wrote: > As the recent SolarWinds hack has reminded us, security is everyone's > concern. We owe it to the millions of developers and adopters who use our > technologies to take all reasonable steps to ensure the validity of the > software that we distribute. > > Responsibility to decide which Eclipse IDE packages are distributed as > official "Eclipse IDE" releases (e.g., the packages listed on the Eclipse > IDE packages download page <https://www.eclipse.org/downloads/packages/> or > are installable via the installer) rests with the Eclipse Foundation. That > is, the Eclipse Foundation has (and has always had) responsibility to > ensure that the content being distributed as official "Eclipse IDE" > releases meets a well-defined standard. > > The standard is set by the participation rules of the simultaneous release > and following the practices established for the simultaneous release, are > in our opinion, the best means of mitigating risk. > > In order for a package to be listed as an official "Eclipse IDE" release, > displayed on "package" download pages and included in the installer, these > rules must be followed: > > *All features to the package must come through the simultaneous release. *That > is, all Eclipse open source projects contributing features to projects must > participate in the simultaneous release and follow the participation rules > defined and maintained by the Eclipse Planning Council. By way of > clarification, content produced by other Eclipse open source projects may > be included, but only when that content is sponsored into the simultaneous > release by a project that is itself participating in the process (Eclipse > Jetty is an example of this). > > *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. > > Please let me know if you have any questions or concerns. > > Wayne > -- > > 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 > -- Mickael Istria Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________ 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
