Re: Dealing with renamed source packages during CVE triaging
On Wed, Jun 13, 2018 at 05:19:40PM +1000, Brian May wrote: > "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 directly > when it's the case, or otherwise." Of course, those can be resolved; it just needs someone to do the analysis work. Switching to some other tags (and incorrect ones!) doesn't change anything. Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
Antoine Beaupré writes: > https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/4 > > Comments are welcome there or here. Current comments on merge request, copied and pasted here, as I think relevant for the discussion here: Moritz Muehlenhoff @jmm commented 4 days ago Owner Strong nack, the data quality of embedded code copies isn't useful for this. When you've verified a certain package to be affected, add it manually (with references), but don't dump lots of unactionable data into the tracker. Brian May @bam commented 2 minutes ago Developer @jmm The problem I believe is how do we keep track of packages that might be affected but aren't listed in the security tracker? Do we maybe need to keep track of this information outside the security tracker? -- Brian May
Re: Dealing with renamed source packages during CVE triaging
Brian May writes: > In any case, possibly better to leave feedback on the pull request: s/pull request/issue/ Sorry for any confusion. -- Brian May
Re: Dealing with renamed source packages during CVE triaging
Moritz Muehlenhoff writes: > On Tue, Jun 12, 2018 at 05:40:34PM +1000, Brian May wrote: >> 1. Tagging with / instead of . > > Nothing of those can automated. The basic point of 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 > 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 directly when it's the case, or otherwise." Having said that, not sure I personally understand this concern. It would simplify things if we could just use . >> 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
External check
CVE-2016-10621: TODO: check CVE-2016-10624: TODO: check CVE-2017-16005: TODO: check CVE-2017-16021: TODO: check CVE-2017-16023: TODO: check CVE-2017-16026: TODO: check CVE-2017-16030: TODO: check CVE-2017-16118: TODO: check CVE-2017-16119: TODO: check CVE-2017-16129: TODO: check CVE-2018-1103: TODO: check -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run.
