Re: Dealing with renamed source packages during CVE triaging
Moritz Muehlenhoff <firstname.lastname@example.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
>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 <email@example.com>