Re: Dealing with renamed source packages during CVE triaging
Moritz Muehlenhoff <jmm@inutil.org> writes:
> On Tue, Jun 12, 2018 at 05:40:34PM +1000, Brian May wrote:
>> 1. Tagging with <removed>/<unfixed> instead of <undetermined>.
>
> Nothing of those can automated. The basic point of <undetermined> is that
> we lack data to make a proper assessment.
>
> The correct way to handle these is to triage
> https://security-tracker.debian.org/tracker/status/undetermined by contacting
> e.g. upstream developers or the reporters of the vulnerability and then amend
> CVE/list with the necessary information, i.e. either converting them to
> <unfixed> if it has been confirmed to be an issue or to
> <not-affected>.
>From an email sent to a Freexian list:
"as I said in the mailing list discussion, I don't like the usage of the
undetermined tag... we use it to hide stuff we can't investigate under
the carpet, I would much prefer that we put it as <removed> directly
when it's the case, or <unfixed> otherwise."
Having said that, not sure I personally understand this concern. It
would simplify things if we could just use <undertermined>.
>> 3. Resolve general issue regarding CVE/list, and if it should be split up.
>
> That has been proposed and nacked several times before. There's simply
> no practical reason for it. It would add multiple complications (starting
> with the MITRE sync, syncing with external parties, changes to the tracker)
> for no measurable gain. Quite the contrary; it's extremely useful to have
> 20 years of vulnerability data easily available in a single emacs buffer.
The concerns (from reading the PR) were that:
* git can't cope efficiently with such large files.
* emacs can't cope efficiently with such large files.
In any case, possibly better to leave feedback on the pull request:
https://salsa.debian.org/security-tracker-team/security-tracker/issues/2
--
Brian May <bam@debian.org>
Reply to: