Eclipse Foundation Project Handbook

The Open Source Rules of Engagement lie at the heart of the EDP:

The Open Source Rules of Engagement define a foundation for vendor neutral open source development. Vendor-neutrality is concerned with maintaining a level playing field that is open to all comers: no vendor is permitted to dominate a project, and nobody can be excluded from participating in a project based on their employment status.

Quality and intellectual property cleanliness are also important principles.

Quality means extensible frameworks and exemplary tools developed in an open, inclusive, and predictable process involving the entire community. From the consumption perspective, Eclipse quality means good for users (exemplary tools are cool/compelling to use, indicative of what is possible) and ready for use by adopters. From the creation perspective, Eclipse quality means working with a transparent and open process, open and welcoming to participation from technical leaders, regardless of affiliation.

Intellectual property (IP) is any artifact that is made available from a Eclipse server (this includes source code management systems, the website, and the downloads server). Artifacts include (but are not limited to) such things as source code, images, XML and configuration files, documentation, and more. Strict rules govern the way that we manage IP and your responsibilities as a committer.

Code produced by an Eclipse project is used by organisations to build products. These adopters of Eclipse technology need to have some assurance that the IP they’re basing their products on is clean: the organisation or individuals who claim copyright of the code are the legitimate copyright holders, and the copyright holders legitimately agree to make the code available under the license(s) that the project works under. As a committer, you must be careful that you do not copy code and inadvertently claim it as your own.

Eclipse open source projects start with a proposal that is made available to the community for review. At the end of the community review period, we engage in a creation review, and then provision the project resources.

A proposal must minimally include a description of the project, a declaration of scope, and a list of initial members (project leads and committers) before we make it accessible to the public for community review.

When you feel that the proposal is ready, send a note to the Eclipse Management Organization (EMO) requesting that the proposal be made available to the public for review. The EMO will review the proposal and may provide feedback before initiating the community review period.

At the beginning of the community review period, the EMO will announce the proposal on several channels (the Project Activity News page, Twitter, blog post, and an email note to the Eclipse Foundation members and committers). The EMO will also open a record in the Eclipse Foundation’s issue tracker — an instance of GitLab — to track the progress of the proposal; the proposal’s author, and project leads will be copied on that record.

A proposal will be open for community review for a minimum of two weeks.

Use the web form to create a new project proposal.

Instructions are provided on the form. All new proposals are created in draft mode, and are accessible only by the original author and anybody designated as a project lead or committer in the proposal. Only those individuals designated as a project lead may edit the proposal.

When making the decision to initiate the creation review that will turn the project proposal into an Eclipse open source project, the EMO will consider the following:

When the project name trademark has been secured and the proposal contents are finalised, the EMO will schedule a creation review.

Following a successful creation review, the EMO will initiate the provisioning process.

Provisioning starts with an email message being sent to each of the committers listed on the project proposal with instructions on how to engage in the committer paperwork process. The exact nature of that paperwork depends on several factors, including the employment status of the individual and the Eclipse Foundation membership status of their employer.

When the paperwork is received and processed for one committer, the Eclipse IT Team will begin the resources provisioning process. When that process is complete, the Eclipse IT Team will provide information regarding the nature and coordinates of the various resources and services available to the project.

Before pushing any code into an official Eclipse project repository, the project team must submit the project’s initial contribution of project code and wait for the Eclipse Intellectual Property (IP) Team to grant checkin of that contribution.

third party content that is required by the project code must also be reviewed by the Eclipse IP Team.

After the project code is pushed into the project repository, the project team can create and distribute milestone builds for the first release. However, all intellectual property must be approved by the Eclipse IP Team before the project team can issue any official releases.

Eclipse projects move through various phases. Projects in active phases (incubation or mature) engage in all the normal sorts of development activities: project committers write code, run builds, release software, court contribution, and seek to convert contributors into committers. All new projects start in the incubation phase. Projects tend to stay in the incubation phase for a few months (varies depending on the nature and composition of the project) and then move into the mature phase.

Key project life cycle events are gated by reviews; moving from the incubation phase to the mature phase must be, for example, preceded by a graduation review.

To highlight that a project is in the incubation phase, it must implement incubation branding. Primarily, this takes the form of displaying the incubation logo in prominent locations, including the project’s major web properties and including the word "incubation" or warning that products shipped as part of a release may include incubating components.

Incubating branding includes:

There are no incubation branding requirements for any user-facing elements.

The incubation mailing list exists to facilitate discussions related to the incubation phase, allowing project committers to ask questions about Eclipse Foundation processes, seek guidance from the Eclipse Architecture Council, Eclipse Management Organization, and connect with other community members involved in projects in the incubation phase.

New committers are encouraged to join the incubation mailing list; this list is a good place to ask questions about process, services available, and other aspects of working as a committer.

New project teams are usually eager to get started generating content. In addition to creating fantastic content, there are a few things to remember:

Essential to the Purposes of the Eclipse Foundation is the development of the three inter-related communities around each Project, and the Incubation Phase is the best time to start forming those communities:

Projects are expected to make substantial progress on establishing these communities during their Incubation Phase.

Incubation Phase projects will eventually graduate, signifying that the project code base has stabilised and that the project team is familiar with the Eclipse Development Process.

Graduation Reviews are generally combined with a release review.

The project checklist provides some general criteria to determine whether or not a project is ready to exit the incubation phase.

The project lead(s) are responsible for requesting a Graduation Review when the project leadership believes the project meets the exit criteria.

For Eclipse projects (and the open source world in general), committers are the ones who hold the keys. Committers are either appointed at the time of project creation, or elected by the existing project team.

Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the Eclipse Foundation Development Process, puts meritocracy on equal footing with transparency and openness: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit.

Committers:

Eclipse projects must have at least one project lead, and may have more than one. The project leads are the primary liaison between the project team and the Eclipse Management Organization(EMO). As the first link in the project leadership chain, project leads have responsibility to ensure that the project team is able to successfully implement the goals of the project in accordance with the Eclipse Foundation Development Process and Eclipse Foundation Intellectual Property Policy.

The EMO considers it a good practice to have more than one person in that role to ensure that there is continuity. There is no artificial maximum number of project leads for an Eclipse project: the main thing that the EMO is concerned with is that project leads are elected in a vendor neutral manner following public demonstrations of leadership (documented as comments on issues, contributions to mailing list discussions, etc.) that are cited in the nomination statement. The EMO specifically watches elections to ensure that vendor neutrality is observed.

Project leads are either appointed at the time of project creation or elected by their committer peers (an individual is generally expected to have served as a committer before being nominated for the project lead role). Project leads must also be committers, but the two roles are distinct.

Project leads are responsible for ensuring that project committers are following the rules. At the most basic level, the rules are the open source rules of engagement defined in the Eclipse Foundation Development Process (openness, transparency, and meritocracy), and we depend on them to make sure that team members understand their obligations under the IP Policy and are correctly implementing the Intellectual Property Due Diligence Process.

Project leads have the ability to retire committers: this is a power that must be used responsibly. A project lead needs to be able to support their decision to retire a committer. As a best practice, the project lead should give committers reasonable opportunity to retrain their status, and — should the decision be made to retire — committer retirements should be announced on the project’s primary communication channels including the dev-list.

When committers are disruptive or otherwise behaving in a manner that is detrimental to the project, the project lead should work with the PMC and the EMO to resolve the issue.

Project leads have some extra privileges on GitLab and GitHub.

The project lead is not the technical lead. So it’s not strictly their responsibility to develop things like coding standards, project policies, and such. They are responsible, however, for making sure that those sorts of things get created and for making sure that the project team is working to complete shared goals.

Any committer can initiate a review with the EMO, but the EMO will always copy the project lead(s) in related communication to ensure that they are aware that the committer is acting as their delegate.

Project leads can also request the EMO to initiate a restructuring review in case a project needs to change the meaning of the scope or make any other significant changes to one or more Projects.

A project management committee (PMC) is responsible for the operation of exactly one top-level project as defined by the Eclipse Foundation Development Process. Per the EDP, top-level projects sit at the top of the open source project hierarchy.

The PMC’s role is, fundamentally, to maintain the overall vision and operation of the top level project and all of the projects that fall within their purview. Very often (though it really depends on the nature of the top level project), the PMC will take a very active role in determining how their projects fit together, and how they communicate and interoperate. In pragmatic terms, the PMC ensures that projects are following the rules, set the standards over and above the basic requirements for releases and corresponding documentation, approves intellectual property contributions, and approves committer and project lead elections.

Top-level projects do not generally maintain open source content of their own, but rather provide oversight and guidance to those open source projects that fall under them in the project hierarchy. All projects that fall under a particular top-level project must fit within the mission and scope defined by the top-level project’s charter. In addition to mission and scope, the charter may further define other requirements or establish guidelines for practices by the project that fall under its purview.

The primary role of the PMC is to ensure that project teams are implementing the EDP and operating within the terms outlined by the top-level project’s charter. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner.

The PMC is responsible for defining and managing the structure of the top level project and the organisation of the open source (software and specification) projects contained within.

The PMC provides other oversight regarding the operation of open source projects. They review and approve progress reviews, and facilitate cross-project communication within the top level project.

The Eclipse Architecture Council serves the community by identifying and tackling any issues that hinder Eclipse’s continued technological success and innovation, widespread adoption, and future growth. This involves technical architecture as well as open source processes and social aspects. Comprising the finest technical leaders from all community stake holders, it is the council’s goal to keep the projects successful and healthy, the processes simple and smooth, and the communities vibrant and cohesive.

More concretely, the Eclipse Architecture Council serves four basic purposes:

Every PMC may appoint a representative to the Architecture Council to represent the interests of the PMC and corresponding Top-level Project. Every Strategic Member of the Eclipse Foundation may also appoint a representative. Other Architecture Council Members are nominated and voted on by the Architecture Council itself, and appointed by the council by the Eclipse Foundation’s Executive Director. Appointed members serve a two year renewable term.

The Architecture Council interacts primarily via their mailing list. List participation is limited only to Architecture Council members and subscription to the list is automatic. Additionally, the Architecture Council meets (remotely) every month for a one-hour closed discussion (with public minutes).

Committers and Project Leads should connect with the Architecture Council via their PMC.

The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture Council. The EMO is responsible for providing services to the projects, facilitating project reviews, resolving issues, and more. The EMO is the maintainer of the Eclipse Foundation Development Process. The best method of contact with the EMO is by email (emo@eclipse-foundation.org). If you have a question that cannot be answered by project lead, or PMC, ask the EMO.

While it is natural to have one or more committers become technical leaders in the project team, there is no formal technical lead role defined in the Eclipse Foundation Development Process (EDP). Likewise, while it is natural for certain members of a specification project team to become leaders in the specification process, there is no formal notion of specification lead (or "spec lead") defined in the Eclipse Foundation Specification Process (EFSP). Any de facto technical or specification lead does not have any special authority beyond that which is granted to them by the other project committers.

The committers in a project team have some say over who their leaders are and what powers they grant to those leaders. While the role is not specifically defined for this sort of thing, the project lead role could be granted decision making powers. It is completely reasonable for a project team to decide, for example, that somebody in the project lead role must approve of all commits and anybody with that role can mitigate potential rogue actions by rolling back commits. One of the key benefits of organising in this manner is that project lead is an elected position, so project committers have a build-in process for capturing the decision to grant those extra powers.

For many open source projects, the committers follow the natural leaders. But when a more formal relationship is desired, it must be arrived at by consensus of the project team (via public channels) and documented clearly so that everybody can understand how the project team works (making it very clear how a project team works is a critically important aspect of growing diversity in an open, transparent, and meritocratic open source project team). If the project team decides, for example, that all committers must contribute their updates as pull requests that may only be merged by a project lead, then that must be documented (it’s fairly common for project teams to require that pull requests from one committer be merged by a different committer). When the role is formally defined, it’s also important to document how a committer ascends to into that role (to be clear, in the spirit of vendor neutrality, this criteria cannot be based on employment status).

As discussed in the Eclipse Foundation Development Process and throughout this document, Eclipse open source projects operate in an open, transparent, and meritocratic manner.

In this regard, all project resources are publicly accessible. Put another way, Eclipse open source projects have no private resources. All content repositories, mailing lists, discussion forums, etc. are publicly accessible. Exceptions may be made with the approval of the PMC and EMO; and only when there is some legal reason or technical limitation that requires an exception.

Project resources make use of two sorts of IDs:

For example the "Eclipse Woolsey" project has a short name of "woolsey"; its qualified identifier is "technology.dash.woolsey", indicating that it is a subproject of the an Eclipse Dash Project which is itself a subproject of the Eclipse Technology Top Level Project.

Eclipse projects must maintain project content (source code, documentation, configuration, etc.) in the repositories assigned to the project by the Eclipse Foundation. These official repositories must be the exclusive source of all content delivered via the project’s distribution channels (e.g. the download server).

Git commit records are required to take a specific form. The credentials of the actual author must be used to populate the Author field. The author credentials must specify the author’s actual (legal) name and email address. The email address used must match the email address that the Eclipse Foundation has on file for the author (case-sensitive).

The commit message is divided into three sections:

The summary line is used in many places where Git commits are listed, ensure that this line is sensible by itself. The description area should be used to provide more detail about the commit. The footer area is used for extra fields and values.

If the bug id is included in the summary line (using the form "Bug 12345 - xxx" or "[12345] xxx") Gerrit Code Review will automatically add a link in the corresponding Bugzilla record back to the Gerrit record (this, of course, only applies to commits pushed to Gerrit).

The Change-Id is used by Gerrit Code Review to associate new versions of a change back to its original review. This field need only be specified if the repository is managed by Gerrit.

An Also-by (or Co-authored-by) entry can be added for each additional author of a commit (one committer per entry). This might apply, for example, if a commit has been authored via pair-programming, or the commit is the result of collapsing multiple commits authored by multiple developers. To be considered valid the entry must take the form Also-by: Name <email>.

Authors who are not committers on the project receiving the commit must have an Eclipse Foundation Account and must have a signed Eclipse Contributor Agreement (ECA) on file.

The Eclipse Foundation maintains an instance of GitLab for use by Eclipse open source projects. Project teams may opt to host some or all of their canonical source code repositories on our GitLab instance.

On GitLab, the root group for all Eclipse open source project repositories is eclipse. Under that root, two nesting options are available: an Eclipse open source project’s group can be nested directly under the root, or can be nested in a group corresponding to the Eclipse top-level project. In both nesting options, repositories may be arbitrarily nested in subgroups created under the projects' group to organise the repositories. The custom subgroups are cosmetic only, as the same permissions are applied to the nested groups and do not provide any extra functionality.

Project teams may opt to host some or all of their canonical source code repositories to an organisation on GitHub that is maintained by the Eclipse Foundation. Both GitHub Issues and Wiki may also be used.

Any committer can open a Help Desk issue to request that the Eclipse IT Team create a new repository for their project on, or move an existing repository to, GitHub. A project may have more than one repository on GitHub. When making the request, the committer should describe—​specifically and concisely—​what they want to make happen. Note that the Eclipse IT Team will verify the request with the project leads.

Repositories can be hosted in the default eclipse GitHub organisation, or a dedicated organisation can be created. Dedicated organisations use as their name, the conjunction of eclipse with the project short name (e.g., eclipse-woolsey).

The Eclipse IT Team installs some hooks onto all Eclipse project repositories on GitHub.

The Committers hook grants designated project committers write access to the GitHub-hosted project repositories. Project committers must add their GitHub id to their Eclipse Foundation account, and must use the email address they provide to the Eclipse Foundation as the email address in the author credentials of all commits.

The Eclipse Contributor Agreement (ECA) hook will inspect incoming GitHub pull requests to ensure that the contributor has a valid ECA on file. Project committers should only merge green pull requests:

Since the GitHub API does not provide a way for a Committers hook to absolutely deny a merge by itself, the hook warns committers when the contributors have not signed an ECA.

Click on the Details link for more information. Committers must not merge commits unless they are certain that the contributor does have a valid ECA on file.

It is however possible to set up a Branch Protection Rule for branches to prevent that pull requests which fail the ECA validation are getting merged into them:

Gerrit provides web based code review and repository management for the Git version control system. Many projects use Gerrit to reduce barriers and encourage contribution to the project. As Gerrit is deprecated, we encourage projects to use GitLab or GitHub for code hosting.

If a repository belonging to a project is unmaintained or deprecated and will not receive any further updates, it is good practice to clearly indicate that in the corresponding README.md and SECURITY.md files of the repository with a migration path if applicable.

Committers shall mark a deprecated repository as being archived either by using the Self-Service of GitHub Resources or by opening a Help Desk issue to request assistance from the Eclipse IT Team.

Eclipse projects must use an Eclipse Foundation-provided issue tracker. Project teams may opt to use either the Eclipse Foundation GitLab instance or — for projects that use GitHub — GitHub Issues instances associated with Eclipse Foundation-managed GitHub project repositories.

Eclipse projects have one or more mailing lists.

Mailing lists take the following form: <shortname>-<extension>@eclipse.org, where <shortname> is the project’s short name and <extension> signifies the nature of the list (e.g., woolsey-users@eclipse.org or woolsey-ci@eclipse.org).

With the exception of channels created to discuss security issues while they are in quarantine, there are no private channels for project work. This means that we do not provide private mailing lists for any project activity and that all mailing lists use for project activity are configured to have a public archive.

Mailing list subscriptions are managed via your Eclipse Foundation Account.

All projects are assigned a user forum as a point of contact between the user and adopter communities, and the project developers.

The EMO strongly encourages the use of alternative communication channels for connecting with the community: project teams know their community and how to best connect with them.

Project websites are an excellent way to connect an open source project with the community. Many projects opt to use the Project Management Infrastructure (PMI) project page as their website. PMI-based website URLs take the form of https://projects.eclipse.org/projects/<projectid> (e.g. https://projects.eclipse.org/projects/technology.foo).

Many project teams opt to create a custom main project website: if so-desired, a project may host a website on Eclipse Foundation-hosted servers. Project website URLs generally take the form https://eclipse.dev/<shortname>; (e.g. https://eclipse.dev/foo). Custom project website content is maintained in Git repositories hosted on Eclipse Foundation infrastructure. A background job moves content from the Git repository to the website; content pushed to the repository will appear on the live website within five minutes.

Project websites must implement the branding guidelines for project websites.

The Project Management Infrastructure (PMI) provides the main project website. Website URLs take the form of https://projects.eclipse.org/projects/<projectid> (e.g. https://projects.eclipse.org/projects/technology.foo).

Websites not hosted by the Eclipse Foundation are considered community portals and are subject to the Eclipse Foundation Trademark Usage Guidelines (the Eclipse Foundation asserts ownership of all project name trademarks). Furthermore, projects may be required to comply to specific security guidelines and requirements outlined by the Eclipse Foundation’s Security team.

If your project website or any other property maintained by or on behalf the project team uses Google Analytics or otherwise collects information, there may be privacy and data protection concerns that you’ll need to address. The Data Protection Impact Assessment Guidelines and Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy describe the Eclipse Foundation’s policy and your obligations.

Organisations who are investing in an open source project may want to provide links on the project website (or in other content related to a project: a README file, for example) to related professional services that they offer.

Including links to vendor-specific services related to an Eclipse open source project is completely consistent with the Eclipse Foundation Development Process.

Vendor-neutrality must be observed. Care needs to be taken to make sure that there is no confusion that the project itself is an Eclipse open source project, and not a Vendor X open source project. In that context, including references and links to vendors who provide services for an open source project is fine, so long as others can participate via the same set of rules.

The rules for inclusion of vendor-specific references need to be captured (even if only informally). A project team might, for example, decide that links to related vendor services are permitted only in cases where the vendor has an active committer on the project.

Vendor-specific links should be a statement of fact without qualification or anything that looks like an advertisement or endorsement (that is, "Vendor X provides services related to this project" is acceptable, but "Vendor X is the preferred services provider for this project" is not). It must be very obvious to users browsing the project content that the links to vendor-specific services lead to content that is separate from the open source project (for example, links to vendor-specific content on a project website must lead to web pages with a distinctive appearance to avoid misleading the user into thinking that the services provider page is part of the open source project’s website).

Links to vendor-specific services must be directly related to the project.

Use of Eclipse Foundation-provided and hosted build services, the so-called Common Build Infrastructure (CBI) is strongly recommended, but not strictly required.

Whether or not a project chooses to make use of provided build resources, it must be possible for members of the community to build project artifacts from source code with reasonable effort.

Where technically sensible, all downloadable artifacts should be signed by an Eclipse Foundation certificate.

The project is allocated space on the Eclipse download and archive servers.

Project artifacts (e.g. downloads) can be distributed via third party services (e.g. Maven Central), but — where technically sensible — the Eclipse Foundation-provided infrastructure must be considered the primary source of project downloads.

Project committers can upload project artifacts to the project’s directory on the download server. The short name is used to denote the area available to the project (e.g. https://downloads.eclipse.org/dash for the technology.dash project) via SFTP or SCP, or from a Eclipse Foundation hosted build infrastructure.

Project teams may use services that are not hosted by the Eclipse Foundation (e.g. GitHub or DockerHub).

The following rules apply:

Even when using services not hosted by the Eclipse Foundation, project teams are required to operate in an open, transparent, meritocratic, and vendor-neutral manner. Use of the service must not add an unreasonable access barrier for contributors, and no single individual or company can exert exclusive control of the service. Administrative level control of the service must be shared by as diverse a subset of the project committers as possible, and a documented policy must be established for managing that control.

All services require that users conform to some sort of terms of use that likely dictate copyright and licensing terms. Project leads must take care to ensure that those terms of use are not at odds with the project license or impact the copyright ownership of project contributions.

External resources can be used for:

This list is not exhaustive. Project leads should work with their Project Management Committee (PMC) and the EMO to determine the terms and conditions for an external resource are compatible with the project license(s), the Eclipse IP Policy, and Eclipse Foundation Development Process.

The chat service is a great way for projects to communicate and to connect with the community, provide real-time support, and to discuss project-related topics.

Eclipse project committers can request rooms/spaces for their project on the chat service. By default, the channel name is of the form #<shortname> where <shortname> is the project’s short name identifier (e.g. #dash for the technology.dash project) and located by default in the #eclipse-projects:matrix.eclipse.org space.

Custom rooms/spaces organisation can be requested, see the following examples:

All requests for new rooms/spaces have to be made by opening a Help Desk issue.

The chat service can be accessed via the web client at chat.eclipse.org or by using a Matrix client (e.g. Element, NeoChat, or any other Matrix client) via the matrix.eclipse.org server.

For more information, please see the documentation here:

The Eclipse Foundation Security Team provides help and advice to Eclipse projects on security issues and is the first point of contact for handling security vulnerabilities. Members of the Security Team are selected from the Eclipse Foundation staff.

You can contact the Eclipse Foundation Security Team by sending email to security@eclipse-foundation.org or by open an issue in the general vulnerability issue tracker.

All project contributors are responsible for ensuring best security practices and following of the Eclipse Foundation Vulnerability Reporting Policy. However, a specific group called the Project’s Security Team is responsible for handling undisclosed vulnerabilities. It is up to the project and project’s leadership chain to organise the Project’s Security Team. In the absence of other decisions, the Project’s Security Team includes all committers.

The project might decide to include a subset of the committers in the team, for example based on their security experience. Any project committer can propose a creation of a separate Project’s Security Team. This is discussed by the project leadership and might be submitted to a vote of all committers. The same procedure applies to bringing the responsibility back to the complete group of committers.

The project must provide a security contact to the Eclipse Foundation Security Team and should communicate that contact information to potential reporters (like security researchers).

The following resources are recommended for each project’s security team:

The Project’s Security Team members might grant access to specific issues to people outside of the team. Such rules should be defined by the Project’s Security Team and the PMC in advance.

Project Leads can define Project Security Team via PMI, in the Security section of the Edit tab (see screenshot below).

The default project setup is to use general Eclipse Foundation reporting (see below). The strong recommendation is to list reporting methods clearly inside a SECURITY.md file in the main repository (also in other repositories if it makes sense) to help security researchers to communicate with the project in a secure way. Similar information should be available in the project’s documentation.

If the project decides to activate reporting via confidential issues (GitLab) or private security advisories (GitHub), please make a request via the Help Desk. The Eclipse Foundation Security team can train the project in using those means. When new reporting methods are set up, update your SECURITY.md accordingly.

In order to be able to set up, monitor, and also help projects dealing with security settings, new project are set up with members of the Eclipse Foundation Security team. Also, in GitHub repositories, if self-management is enabled, the project will include .eclipsefdn repository. Please refer to the documentation for more information.

Vulnerabilities can be reported via a project-specific security tracker, or via general Eclipse Foundation means: an email to security@eclipse-foundation.org or an issue in the general vulnerability issue tracker.

The general security team email address can be used to report vulnerabilities in any Eclipse Foundation project. Members of the Eclipse Foundation Security Team will receive messages sent to this address. This address should be used only for reporting undisclosed vulnerabilities; regular issue reports and questions unrelated to vulnerabilities in Eclipse Foundation project software will be ignored. Note that this email address is not encrypted.

The community is encouraged to report vulnerabilities using the standard project-specific issue tracker. The appropriate link should be available in the project’s SECURITY.md file. In case of a doubt, use the general vulnerability issue tracker.

Disclosure is initially limited to the reporter, the project team and the Eclipse Foundation Security Team, but is expanded to include other individuals, and the general public. The timing and manner of disclosure is governed by the Eclipse Foundation Vulnerability Reporting Policy.

Publicly disclosed issues are listed on the Known Eclipse Security Vulnerabilities page.

The Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority and does assign CVE numbers to projects hosted by the Foundation.

A unique vulnerability number like a CVE allows developers, distributions and security researchers to talk about the same issue using a common name. It also helps the project documentation.

The project team can ask for a number when they learn about the vulnerability: by receiving a report or simply by discovering it. They can request the number before the fix is ready, as the request will be confidential until the project tells the Eclipse Foundation Security Team to publish it.

Project can request CVE numbers in different ways depending on the project setup.