Moritz Muehlenhoff <j...@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 <b...@debian.org>
