Community
Participate
Working Groups
I am requesting a CVE, the details will be provided later as a comment.
I've marked this issue as "committers only" (effectively private). As a matter of practice, we don't reserve CVEs in advance. There is some overhead, but the primary concern is that the CVE should not be used until it is actually promoted to the central authority. If there is some exceptional circumstance that warrants assigning in advance, please let me know. I'll assign the CVE when you're ready to promote. The process is described in the handbook. https://www.eclipse.org/projects/handbook/#vulnerability-cve
that's how I proceeded last times I needed one. So I just need to provide the details of the CVE to get one ? If that is so, I don't get how that can remain confidential until we publish a fix.
We assign a CVE when a project team are ready to disclose. If behaviour has been different in the past, then that was in error. Note that this issue is marked "committers only" which makes it accessible only to those individuals who have committer status with the Eclipse Foundation. This is not entirely confidential, but certainly accessible only to a limited (and trusted) audience.
here are a few cases we did in the past that went successful - https://bugs.eclipse.org/bugs/show_bug.cgi?id=539568 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=539170 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=539171 it is not clear how the current process is actually usable in practice when doing a release because we want to use the CVE ID in the commit. To do the release then we need to have this commit. And to get the CVE we need to have the release. How can we solve this circularity issue ? It seems that committers wide access is quite wide.
(In reply to Julien Viet from comment #4) > here are a few cases we did in the past that went successful (In reply to Wayne Beaton from comment #3) > If behaviour has been different in the past, then that was in error. Provide me with the details here and I'll assign a CVE, then you can wrap up your commit and push. I can delay pushing to the central authority for a day or so, but no longer. The problem that I'm trying to solve is this... when you use a CVE publicly before I push it to the central authority and some keener decides to use that CVE, then I wind up having a pleasant multiple round email conversation with the Mitre folks about using an invalid CVE.
I see. we can do also proceed this way, you assign a CVE, we use it in a commit that we keep private until we release. At release time we push the commit and you push the CVE ID the same day. Previously we kept this commit private until we released.
Use CVE-2019-17640
Thanks. We also have on RHT side a notion of embargo for CVE and it seems to me that the current process does not provide room for embargos.
> We also have on RHT side a notion of embargo for CVE and it seems to me that > the current process does not provide room for embargos. This is a discussion that we should probably move to another bug. The current process as it is defined has holes. That much is certain. If somebody is prepared to step up and provide resources to implement a more robust management of the process, then I'm all ears.
sure this is just a remark. I'm fine spending time on this as this happened already a couple of times.
here are the CVE details - versions: 3.4.x up to 3.9.4, 4.0.0.milestone1, 4.0.0.milestone2, 4.0.0.milestone3, 4.0.0.milestone4, 4.0.0.milestone5, 4.0.0.Beta1, 4.0.0.Beta2, 4.0.0.Beta3 - description: StaticHandler doesn't correctly processes back slashes on Windows Operating systems, allowing, escape the webroot folder to the current working directory. - CWE category: https://cwe.mitre.org/data/definitions/23.html
let us know when we can reference the CVE publicly.
I've send a pull request to the central authority. https://github.com/CVEProject/cvelist/pull/5048
The record has been merged. You can use the CVE publicly.
This has been fixed in Vert.x 3.9.4 and will be in 4.0.0 candidate release 1
