Re: [eclipse.org-architecture-council] Update the EDP to include a Proje

[Jay Jay Billings <jayjaybillings@xxxxxxxxx>]

I want to throw in a perspective here. You're implying that "equal rights and responsibilities" extend to information access, and that's simply not the case. For example, when Eclipse ICE was actively under development by US government sponsors, we restricted access to a lot more than just security reports, and in some cases, we were required to do so by law. The idea that "All Project Committers have equal rights and responsibilities within the Project" has never crossed over organizational boundaries. That is, a committer at one company is not required to disclose how the project is used at that company or its strategic value to a committer at another company and vice versa. Likewise, even in the open, there are all sorts of emails between project leads and others that aren't shared because "equal rights and responsibilities" do not mean equal access to information.

Now, that being said, I think what the previous discussion between Mikael and Gunnar has revealed is the desirability, if not outright need, to enhance the EDP with an information classification and sharing framework. I'm fully supportive of developing that. I think it would certainly help with security, and in some cases, it may prove valuable in infrastructure, IP, marketing, and other areas. Thus, I'm looking forward to the answer to question #2 from Gunnar.

jm2c,

Jay

On Tue, Jun 11, 2024 at 2:31 PM Gunnar Wagenknecht via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:

Thanks Mikael!

I think this is the requirement I was looking for. I had the feeling that we were talking about a particular implementation/solution without full disclosure of the requirement.

Reading the cited sentence in isolation might indeed imply that "equal rights" is unbounded. But I think it's not, i.e. you have to consider it in context. The immediately following sentence already discusses the possibility of partitioning responsibilities.

I am in support of enhancing the EDP to explicitly allow projects "partition" (read: restrict) access to vulnerability reports. I think such restriction should be limited till their disclosure. I think to should also be very targeted, i.e. not give room for projects to declare something "classified". Since this may - in some cases - involve coordination across multiple organizations (vendors, other OSS communities, etc.) and are sometimes not within our control, I think we should refrain from automatic disclosure after XX days. But I hope we can find wording in a way that is not too specific and delegates to the policy for this.

Question for you (and Wayne):

1. Can we define (limit) this to very specific classified security information such as vulnerability reports only?

2. Can we abstain from implementing a team in the EDP but rather talk about "classified security information according to the Eclipse Security Policy" in the context of partitioning at the discretion of the project leadership?

3. Why do you believe extra wording is really necessary to include the Eclipse Foundation Security staff/experts into this process? Is there something that contradicts that in the EDP today?

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/

On Jun 11, 2024, at 19:08, Mikael Barbero <mikael.barbero@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Gunnar,

Thank you for challenging these changes; these discussions are indeed important.

Having a separate Project Security Team differs from having a separate Project IP Team, as the risks are fundamentally different. A leaked 0-day vulnerability is catastrophic and cannot be remedied after the fact, while a temporary, non-released dependency with an incompatible license is a reversible issue.

Some projects, and I would encourage most to do so, prefer that vulnerability reports be accessible only to individuals with proper security education, limiting access to a minimum number of qualified individuals. This is the only way to mitigate the aforementioned risk. This aligns with industry best practices. Implementing these practices benefits the projects, the organization members, and the Foundation as a whole.

Implementing this practice may require some committers to forgo access to some project resources (considering vulnerability reports as project resources). This is currently not feasible under the existing EDP, as:

All Project Committers have equal rights and responsibilities within the Project. (EDP Section 4.1)

This is the primary reason we believe a change to the EDP is necessary. We need an exception to the equal rights and responsibilities rule because the associated risks are critical, and the stakes are high.

If you have a different interpretation of the EDP and believe our concerns can be addressed at the project level or through the security policy, I would be glad to reconsider this request for changing the EDP.

Thanks again for your engagement.

Mikaël Barbero 

Head of Security | Eclipse Foundation

🐦 @mikbarbero

📅 Book an appointment

Eclipse Foundation: The Community for Open Innovation and Collaboration

On 10 Jun 2024 at 11:53:36, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:

On Jun 5, 2024, at 13:23, Mikael Barbero via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:

Indeed, this is possible and intentional. We expect that most projects will stick with the default where the Project Security Team equals the Committer team. This works well for projects with well-trained Committers where everyone can handle security.

Mikael, I believe this argumentation is flawed. We are creating an unbalanced treatment/apply of principles here. To emphasize why, just replace security with "IP". Why are we not having a separate Project IP team within the EDP? Because we want every developer to be aware and responsible of third-party licensing/legal risks. 

There is no requirement for committers to do all the work, the clearance and auditing. Yet, we want to be aware of the risk. I think the same principle shall apply to security, or to any other important matter of the EDP.

However, we see the need for an alternative approach, where the security team is a subset of Committers (plus maybe some external security experts), for large and mature projects, for several reasons:

IMO we should not have a:

* Project Security Team

* Project Legal Team

* Project Supply Chain Team

* Project Documentation Team

* Project Community Team

written into the EDP even though they may exist as separate roles and delegation of work at larger projects/organizations.

The EDP is about principles for open source development regardless of project size or maturity. Specifically adapting the process to specifics for a commercial entity is adding unnecessary bloat and bureaucracy IMO. It should be avoid.

• Not all developers have the required security background/training to handle vulnerability reports properly.
  

You can say the same thing about legal/IP handling. Yet we don't have a dedicated project team for this.

• The more people have access to a vulnerability report, the more likely it will leak before responsible disclosure is complete. For widely used projects with many Committers, giving everyone access to a high-profile vulnerability can be risky.

This is an AuthZ implementation thing. We want to keep this out of the EDP. If fine grained AuthZ is needed, the security policy can express such a requirement at the discretion of the management/escalation chain (project leads -> pmc -> emo -> ed). The nature of these things evolving changing should be very decoupled from the EDP revision process.

• When the security team equals the Committer team, a high-profile project may be reluctant to elect new Committers as any new person adds risk. Such a project might add restrictions to Committer elections, requiring security expertise, training in responsible disclosure processes, TLP, and other subtleties. This does not help the project grow its Committer base. We believe allowing projects to have a security team not necessarily composed of all Committers will help foster the onboarding of new contributors as Committers.
  

Please bring specific examples. I cannot understand that argument. Each project can define its own level of playing field with regards to committer requirements and such. We trust committers to do the right thing. Let each project define its own RACI matrix. That's the flexibility we already have  in the EDP. 

I think we really should just capture the case where non-committers can assume security roles within a project. Right now everything is focused on committers. But I am not even sure the current EDP would dis-allow such practice. 

-Gunnar

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

--

Jay Jay Billings, Ph.D.