Re: Dealing with renamed source packages during CVE triaging

2018-06-12 Thread Brian May
Antoine Beaupré writes: > I've finalized a prototype during my research on this problem, which I > have detailed on GitLab, as it's really code that should be merged. It > would also benefit from wider attention considering it affects more than > LTS now. Anyways, the MR is here: > >

External check

2018-06-12 Thread Security Tracker
CVE-2014-5220: TODO: 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:

DSA candidates

2018-06-12 Thread Security Tracker
blender -- bouncycastle -- discount -- evolution -- exiv2 -- giflib -- jasperreports -- kdepim -- libspring-java -- mupdf -- opencv -- openexr -- python-pysaml2 -- qemu -- ruby-rack-protection -- ruby-sanitize -- simplesamlphp -- slurm-llnl -- taglib -- vim-syntastic -- cups/stable --

Re: Dealing with renamed source packages during CVE triaging

2018-06-12 Thread Moritz Muehlenhoff
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