Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] March 2025 EAC Meeting Agenda: Security Topics Update and more!

Thank you to everyone who attended the call yesterday.

I captured some notes during the call and have captured them in the wiki.

Marta Rybczynska from the Eclipse Foundation's Security Team joined us and provided a short overview of some of the activities that the team is working on in service to Eclipse open source projects.

She briefly discussed the team's work with OWASP Dependency Track, which we're planning to use to warehouse SBOMs generated by (and for) projects. The idea is provide a home where we can keep track of them, so that -- in the event that a significant vulnerability along the lines of Log4Shell comes around -- we'll be able to quickly assess the scope of the problem and implement a mitigation strategy. We're also investigating how we might use this to add missing (or fix incorrect) licence data in SBOMs.

The Security Team is also engaged with some Eclipse projects to determine what we need to provide/support in various ecosystem pipelines, help them generate SBOMs, etc.

They've started engaging with a small number of Eclipse projects on "Mini security reviews". The idea is to spend a fixed amount of time reviewing the security posture of the project and provide feedback. These "mini" reviews are high-level. The intention is to identify key risk factors like projects with one active developer, no CI, etc. Their intention is to set up calls with projects to introduce the review, and then follow up with results. We're doing our best to align these with with progress reviews initiated by the EMO to try and keep the process as streamlined as possible (e.g., avoid bothering the project twice). This is all still experimental and will be refined as the team gains experience.

Finally, the Security Team is investigating an optional committer id verification feature for projects. The IT and security teams are working with various providers. Our thinking is that this is an optional feature that we can make available for those projects for which it makes sense. There are a lot of things to consider, including whether or not we feel that this sort of feature aligns with the open source rules of engagement, and how we fund this sort of activity. We did briefly discuss whether or not we felt that this aligns with the open source rules of engagement, and my take away was that the group all agreed that it does. If there's interest, we can make this a topic for more discussion at a later date.

We spent time discussing SBOMs. Mostly we have questions. This is a topic that we should expand on in a future discussion. Some questions that were asked:
  • Are SBOMs just going to be used to put a check mark on a list?
  • Do we include information about the build environment in the SBOM?
  • How do we leverage Eclipse IP data to improve the quality of licence information in SBOMs?
  • Do SBOMs make sense for a JAR file? (or do they really only make sense for a "product"?)
  • What does an SBOM for the Eclipse IDE look like? Does, and how does the SBOM change when you install a plug-in?
We did note that there is some work in progress by the Eclipse IDE WG to resolve the last point.

We talked about the notion of end of life of a development stream and what that means in open source. We discussed that the notion of an absolute end of life doesn't really make sense, since it's relatively easy for a project team to accept a pull request, or for the content to be forked and worked on elsewhere. The forking option may have trademark implications that we need to think about: if somebody forks an Eclipse project with the intention of providing support for that version, can they use the project name? Jesse and Wayne are going to discuss this and maybe make this a topic for conversation in the next call.

It was pointed out during the conversation that we need to be careful using the word "support". When we talk about supported versions and end-of-life, it gives a mistaken impression that the output of open source projects are "products" in a traditional sense. We have to keep in mind that the Eclipse Foundation is not a software vendor, our open source projects do not produce products in the traditional sense, and what we mean when we say "support" is very different from what an organisation that regards us as a software vendor thinks it means.

Anyway, I hope that those of you who were in attendance believe that this adequately captures the spirit of the discussion. Please feel free to fill in any gaps.

Thanks,

Wayne

On Mon, 10 Mar 2025 at 16:26, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Greetings Eclipse Architecture Council!

Due to the time shift in North America, the Committer Office Hours meeting now overlaps with our scheduled meeting time. I'll be doing some live demos with the Eclipse Dash License Tool; since this is a  topic that appears to be of interest to the community, I anticipate that I'll need all of the scheduled 45 minutes for that session.

To resolve the conflict, I'm going to push the start time of our meeting back by 15 minutes to 11:15 EDT. I hope that this works for you.

Here are the details:

Date: March 13 2025
Time: 11:15 EDT/1615 CET


I've posted the agenda for our meeting in the wiki. Feel free to add topics.

Here's what we have as of this moment:
  • Status update for security topics (Mikael)
  • Discuss EOL best practices and security implications (Jesse)
  • Resolve Prevent usage of github's noreply mail addresses? (Wayne)
I look forward to seeing everybody!

Wayne
--

Wayne Beaton (he/him)

Director, Open Source Projects | Eclipse Foundation



--

Wayne Beaton (he/him)

Director, Open Source Projects | Eclipse Foundation


Back to the top