Bug#908678: Testing the filter-branch scripts

2018-11-13 Thread Antoine Beaupré
On 2018-11-12 12:22:58, Antoine Beaupré wrote: > I'll start a run on the whole history to see if I can find any problems, > as soon as a first clone finishes resolving those damn deltas. ;) The Python job finished successfully here after 10 hours. I did some tests on the new git repo

Bug#908678: Testing the filter-branch scripts

2018-11-12 Thread Antoine Beaupré
On 2018-11-10 18:56:01, Daniel Lange wrote: > Antoine, > > thank you very much for your filter-branch scripts. you're welcome! glad it can be of use. > I tested each: > > 1) the golang version: > It completes after 3h36min: > > # git filter-branch --tree-filter '/split-by-year' HEAD > Rewrite

Bug#908678: Some more thoughts and some tests on the security-tracker git repo

2018-11-09 Thread Antoine Beaupré
On 2018-11-09 16:05:06, Antoine Beaupré wrote: > 2. do a crazy filter-branch to send commits to the right > files. considering how long an initial clone takes, i can't even > begin to imagine how long *that* would take. but it would be the > most accurate simulatio

Bug#908678: Some more thoughts and some tests on the security-tracker git repo

2018-11-09 Thread Antoine Beaupré
On 2018-09-26 14:56:16, Daniel Lange wrote: [...] > In any case, a repo with just the split files but no maintained history clones > in ~12s in the above test setup. It also brings the (bare) repo down from > 3,3GB > to 189MB. So the issue is really the data/CVE/list file. So I've looked in

Re: Dealing with renamed source packages during CVE triaging

2018-06-20 Thread Antoine Beaupré
On 2018-06-15 10:27:45, Moritz Muehlenhoff wrote: > On Fri, Jun 15, 2018 at 04:34:14PM +1000, Brian May wrote: >> Moritz Muehlenhoff writes: >> >> > On Wed, Jun 13, 2018 at 05:19:40PM +1000, Brian May wrote: [...] >> That generates a report of all packages that we need to check. I assume >> we

Re: Dealing with renamed source packages during CVE triaging

2018-06-08 Thread Antoine Beaupré
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:

Re: Dealing with renamed source packages during CVE triaging

2018-06-08 Thread Antoine Beaupré
On 2018-06-08 03:29:38, Brian May wrote: > Antoine Beaupré writes: > >> Right now, it seems that all scripts that hammer at those files do so >> with their own ad-hoc parsing code. Is that the recommended way of >> chopping those files up? Or is there a be

Re: Dealing with renamed source packages during CVE triaging

2018-06-07 Thread Antoine Beaupré
Sorry for resurrecting this old thread, but I've been looking at how to deal with renamed packages in CVE triaging again. When we last talked about this, we observed how we were sometimes missing packages during triage, e.g. `tiff3` that was present in wheezy. That's not an issue anymore since

Re: pulling in other vulnerability databases

2018-01-26 Thread Antoine Beaupré
On 2018-01-26 00:31:19, Ben Hutchings wrote: > On Thu, 2018-01-25 at 10:17 -0500, Antoine Beaupré wrote: > [...] >> > OS vendors (RH/SUSE) >> > Upstream projects (Xen, Linux etc) >> >> I believe those already follow the CVE process and eventually converge &g

Re: pulling in other vulnerability databases

2018-01-25 Thread Antoine Beaupré
On 2018-01-25 16:27:58, Moritz Mühlenhoff wrote: > Antoine Beaupré wrote: >> So, regarding the first two (and similar), someone needs to teach those >> folks about proper security tracking here... ;) Should I contact them >> directly? > > Who in particular? Node a

Re: improving the report-vuln script

2017-03-31 Thread Antoine Beaupré
Those changes all look good to me. Note that I worked on a separate git repo and have more granular patches for my changes if that's useful. Thanks! -- I know where I am going, and I know the truth, and I do not have to be what you want me to be. I am free to be what I want.

Re: improving the report-vuln script

2017-03-31 Thread Antoine Beaupré
ed it > int via reportbug -i ... and do some cleanups before sending the mail. Interesting! I couldn't figure out how to use reportbug productively... surely it would be nice to have a better tip for this in the file itself... > On Thu, Mar 30, 2017 at 03:04:39PM -0400, Antoine Beaupré wrote: [

improving the report-vuln script

2017-03-30 Thread Antoine Beaupré
Hi, I had some spare time today and I figured I would look at the backlog of unreported vulnerabilities here: https://security-tracker.debian.org/tracker/status/unreported This is one of the housekeeping tasks we were told was useful for the security team here:

Bug#761945: fixing links for DLAs in the security tracker

2017-03-30 Thread Antoine Beaupré
On 2017-03-30 08:38:07, Salvatore Bonaccorso wrote: > Hi Antoine, > > On Wed, Mar 29, 2017 at 03:49:31PM -0400, Antoine Beaupré wrote: >> On 2017-03-29 17:02:44, Salvatore Bonaccorso wrote: >> > Hi Antoine, >> >> Hi! >> >> > If you want to

Bug#761945: fixing links for DLAs in the security tracker

2017-03-29 Thread Antoine Beaupré
On 2017-03-29 17:02:44, Salvatore Bonaccorso wrote: > Hi Antoine, Hi! > If you want to look at this part: There is a ./parse-dla.pl script in > the webwml CVS, which is used to import the DLAs (this is an > analogeous script to parse-advisory.pl which is used to import the > DSAs). I see... The

Bug#761945: fixing links for DLAs in the security tracker

2017-03-29 Thread Antoine Beaupré
On 2017-03-29 07:29:06, Salvatore Bonaccorso wrote: > Hi, > > On Wed, Mar 29, 2017 at 06:28:49AM +0200, Salvatore Bonaccorso wrote: >> Hi, >> >> On Tue, Mar 28, 2017 at 10:16:52PM +, Holger Levsen wrote: >> > On Tue, Mar 28, 2017 at 10:35:34PM +0200, Moritz Muehlenhoff wrote: >> > > Well, you

Bug#776738: security-tracker: ignoring end-of-life packages (was: squeeze/wheezy updates of Redmine (+ long term state of redmine packaging))

2016-01-01 Thread Antoine Beaupré
On 2016-01-01 11:30:36, Raphael Hertzog wrote: > Hi, > > On Thu, 31 Dec 2015, Antoine Beaupré wrote: >> > I have thus pushed the attached patch to the git repository of >> > debian-security-support. Ccing the security team to inform them >> > of this change. >