In order to deal with vulnerabilities in a responsible way:
you cannot put a fix for a vulnerability into a public repository BEFORE you released a new version that includes the fix. Otherwise, you have produced a zero-day.
Ideally, you publish a new version of an artifact that includes the fix for the vulnerability BEFORE you add the corresponding commit to the public repo - which basically means to create release artifacts from private repos
Explicitly mentioning the CVE in the commit makes it even more easily exploitable, I would try to prevent that
Publish the CVE report after the new release is available
If things (vulnerability-related) happen in public by accident (random users report things in public issues, raise public visible PRs, etc.), you basically have to react immediately and delete all that information right away from GitHub (usually involves reaching out to folks at GH for support).
There might be even more difficult use cases coming up here, like specific consumers of your project would like to get the fixed version way ahead of the fix being visible publicly (to give them more time to incorporate the fixed version) - just to mention that this desire might come up one day and being a little prepared here can’t hurt… ;-)
I don’t think you can make such a policy (that basically deals with the cases mentioned above) mandatory for projects at Eclipse - as you probably can’t make those policies mandatory for any open-source project.
I think it would be good if the EF would support projects with this - IN CASE they want to work on vulnerabilities like this - which is - IMHO - a major undertaking for a project.
Just my 2 cents
Martin
Am 04.11.2026 um 15:01 schrieb Shelley Lambert via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx>:
That is why I asked 'can projects expedite a fix without publicly stating it relates to a CVE?' and I know a fix can be reverse engineered and expose that it patches a security issue, but also, a patch is fixing a vulnerability in the public code as it stands, that people can also find for themselves instead of reverse engineering a patch, so... waiting on coordinated response in the age of AI may be an arcane notion...
I think it would be really awesome if there were a GitLab issue
in which the detailed content from this email would be captured.
That would be a great place where associated comments, questions,
and answers could be recorded, all in one place, for future
reference.
Silly, ignorant me had to Google "coordinated vulnerability
disclosure"; okay, found some answers. That makes me wonder about
what it means to "handle a report in public"? Specifically, when
I created the following PR, I wonder if that is an example of
handling the associated CVE in public?
If the above is an example of handling a report in public, I do
immediately wonder what specifically is being proposed as the
alternative. I ask because my normal build process are driven
from PRs on the repository and I'm significantly averse to
tailoring additional/alternative build processes. And of course
at some point the PR needs to be merged into the public
repository...
All this is a long way of suggesting that I think it's super
important to understand what is being proposed concretely for
maintaining or ensuring privacy. Where is the handling boundary?
After all, we live in a glass house and that has always been a
virtue up until now...
On 11/4/2026 1:36 PM, Jesse McConnell
via eclipse.org-architecture-council wrote:
I am a fan of sane security policy, but also of allowing
projects the freedom to do things the way they want.
Having said that, at a high level, wouldn't the guiding
hand for this largely be the CRA and its requirements, along
with any other similar government policies? IMO, the best
thing the EF can do is help projects adhere to the
requirements that governments are setting for developers and
open-source projects, in both letter and spirit. The EF is on
the hook for reporting issues such as active exploits in
project releases, so requirements should flow down to projects
based on what the EF is either compelled to do or chooses to
do on their
behalf.
With so many valid arguments for, as well as, against the
proposal it could become hard to strictly force all
projects into one or the other approach.
What about offering projects to carry a sepcial kind of
badge on their project to indicate compliance with a
process?
Cheers
Eike
Am 04.11.2026 um 09:47 schrieb Mikael Barbero via
eclipse.org-architecture-council:
Dear TAC members,
I'd like your advice on a specific aspect of the
Eclipse Foundation Security Policy.
As currently written, the policy does not require
projects to practice coordinated vulnerability
disclosure (CVD). A project may choose to make every
incoming vulnerability report public from the outset,
regardless of whether the finding has been validated
or how severe it is. In practice, a reporter could
submit a valid, high-severity issue and see it
disclosed publicly before a fix is available, while
the project remains fully compliant with the policy.
Should the Security Policy require projects to
engage in CVD, at least for valid reports above a
certain severity threshold? Or should projects retain
the freedom to handle all reports in public?
To frame the discussion, here is how I see the
trade-offs.
Arguments in favor of retaining this freedom:
Transparency: some projects consider full
openness a core value and see private handling of
any issue as contrary to how they operate.
Simplicity and low overhead: a public-by-default
process requires no private channel, embargo
coordination or separate security team.
Faster community involvement: public reports can
attract fixes and reviews from a wider pool of
contributors.
Project autonomy: the policy has so far left
process choices to projects, consistent with the
Foundation's general approach to project
development process.
Arguments against retaining this freedom:
Risk to users: making a confirmed, severe
vulnerability public before a fix or mitigation is
available leaves adopters exposed.
Reporter expectations: many security researchers
expect a private reporting channel and an embargo
period. Immediate publication may discourage
reporters or conflict with their disclosure
practices and employer policies.
Downstream and regulatory expectations:
adopters, distributors and, increasingly,
regulators expect open source producers to follow
CVD practices. Allowing individual projects to opt
out may be difficult to explain or defend.
Inconsistency across the Foundation: reporters
and users cannot rely on a common baseline for how
Eclipse projects handle vulnerabilities, weakening
the value of a Foundation-wide policy.
Reputational risk: public disclosure of an
unpatched, severe vulnerability by an Eclipse
project reflects on the Foundation as a whole and
every other projects, not only on the project.
If the TAC favors a requirement, the next questions
would be what should trigger it (validity, severity or
exploitability) and what a minimum acceptable CVD
process would look like for small projects.
At this stage, I am asking for the TAC's view on
whether the policy should mandate CVD and, if so,
under what conditions, rather than for draft policy
language. I suggest we already use this thread to
discuss this matter and finalize TAC's opinion during
the next meeting.
_______________________________________________ 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
