Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Jun 2014 16:55:31 +0100
From: Richard Moore <>
Subject: Re: CVE Request for KIO/kmail

On 15 June 2014 16:17, <> wrote:

> Hash: SHA1
> [ actual security content, for people who don't want to read the
> meta-discussion:
>   Is this related to an
>   vulnerability?
> ]
That is unrelated.

> > From: Henri Salo <>
> > More details are needed for public CVE request.
> It might be worthwhile to clarify what problems we're solving, in the
> specific case of a request by a product's upstream vendor, by
> requiring that more vulnerability details be sent here at the time of
> the CVE request.
> MITRE is almost certainly willing to accept this as a valid reason, if
> there's general agreement:
>   - people here don't want to see announcements of vulnerabilities
>     that are both vague AND unfixed, and would just unsubscribe if there
>     were many of these
>     (vague vulnerability details for fixed issues typically haven't
>      had objections in the past, e.g., the
> post)
> (In 2013 and earlier, vulnerability details here had a de-duplication
> purpose for MITRE, but they often don't now. If we were to assign a
> CVE ID for this, we'd already know whether any kio CVE requests had
> been sent directly to us. The CVE-OpenSource-Request-HOWTO.html page
> and examples aren't directly applicable to us, and we're generally
> more concerned with knowing whether something is a unique issue that
> everyone will want to fix, than with knowing every possible detail.
> But we realize the list charter may imply a minimum level of details.)
> Going back to the security content, KDE Bug 330795 mentioned above says:
>   Product  kio
>   KDE's KIO completely ignores the first part, "must not automatically
>   redirect without prompting the user"
> and possibly this is (or was) a violation of RFC 7231 section 6.4,
> with security implications:
>   "Automatic redirection needs to done with care for methods not
>    known to be safe, as defined in Section 4.2.1, since the user
>    might not wish to redirect an unsafe request."
> Does anyone want a CVE ID for that?
> Finally, for the original "a vulnerability in KIO that causes a security
> issue in kmail" request: to get a CVE ID for this more quickly, please send
> to mentioning whether it is or isn't Bug 330795.
> We don't want to send a CVE ID here immediately because MITRE doesn't
> determine the list charter and it might be an off-topic request.
In the past when I've tried to use the cve-assign address it has basically
been a black hole. Since then I've either asked redhat or one of the other
OSS vendors for a CVE. I've used the now as a

I'd also note as part of the meta discussion that I'm not going to release
details of vulnerabilities to a public list  before the fix, and just
because someone asks for more details doesn't mean I will provide them. - I
have no way to know who the person asking is. If getting a CVE assigned
becomes a problem then the solution from my side will be to release the
advisory then let someone else sort out assigning CVEs afterwards.



Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ