[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

Brian May <bam@debian.org>

Reply to: