Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-02-01 Thread Wayne Beaton 
At the risk of being vague and handwavy...

The requirement is that the contents of the packages *come through the
simultaneous release*. That is, Eclipse JustJ needs to participate in the
simultaneous release as participation is defined by the Planning Council.
It's not clear to me whether or not "bits must be in this specific p2
repository" is an absolute requirement.

I believe that we can reasonably interpret the participation rules
 as
permitting a project that is otherwise following the rules for
participation to be absent from the specific simultaneous release
repository under circumstances that make adding it particularly onerous or
otherwise undesirable (that is, I believe that the fundamental principles
that underlie the participation rules can be met). But I defer to the
wisdom of the Eclipse Planning Council.

Wayne


On Mon, Feb 1, 2021 at 11:59 AM Jonah Graham  wrote:

> Hi Wayne,
>
> Where does JustJ fit in here? JustJ is part of the simrel, but not part of
> the aggregated content on simrel? Is it still OK for EPP to consume JustJ
> in that way?
>
> Thanks
> Jonah
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Fri, 22 Jan 2021 at 10:23, 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  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
>>
> ___
> 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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-02-01 Thread Jonah Graham 
Hi Wayne,

Where does JustJ fit in here? JustJ is part of the simrel, but not part of
the aggregated content on simrel? Is it still OK for EPP to consume JustJ
in that way?

Thanks
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 22 Jan 2021 at 10:23, 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  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
>
___
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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-29 Thread Ed Merks 

There is no context in this post...

Note that the train contents themselves should be signed, not just those 
things actually used in the packages.    Here's what happens when that's 
not the case:


https://www.eclipse.org/forums/index.php/mv/msg/1106767/1837377/#msg_1837377

Such a problem is harder to diagnose when sometimes an artifact is 
signed and something it's not signed but has the same IU/ID; you never 
know from which artifact repo the artifact is resolved from and once 
cached, an older local signed version will be used instead of a newer 
unsigned remote version, so I might not even notice while testing or 
running newer tests...


Also, I thought that in fact the Maven artifact was modified in order to 
make it into a bundle.  Or is it a new artifact that wraps the 
unmodified Maven jar (jar in jar)?  Or did I misunderstand the process 
completely?



On 29.01.2021 15:37, Mickael Istria wrote:
This also prevents from shipping the PDE/Maven integration by default 
in packages because it contains BND artifact (unmodified from Maven) 
that is not signed with the Eclipse certificate.


___
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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-29 Thread Mickael Istria 
This also prevents from shipping the PDE/Maven integration by default in
packages because it contains BND artifact (unmodified from Maven) that is
not signed with the Eclipse certificate.
___
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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-23 Thread Wayne Beaton 
> 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 
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  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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-23 Thread Jesse McConnell 
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  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  >:
> >
> >
> > 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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-23 Thread Torkild U. Resheim 
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 :
> 
> 
> 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



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-22 Thread Jesse McConnell 
> *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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-22 Thread Mickael Istria 
[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  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 
developer, for Red Hat Developers 
___
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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-22 Thread Aleksandar Kurtakov 
On Fri, Jan 22, 2021 at 5: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  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.
>

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.


>
> 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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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] Simultaneous Release participation and the Eclipse IDE packages

2021-01-22 Thread Wayne Beaton 
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  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