External check
CVE-2018-19039: RESERVED CVE-2018-8416: 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.
Bug#908678: Testing the filter-branch scripts
Hi, On Wed, Nov 14, 2018 at 07:45:59PM +0100, Moritz Muehlenhoff wrote: > On Wed, Nov 14, 2018 at 07:34:03AM +0100, Daniel Lange wrote: > > Am 13.11.18 um 23:09 schrieb Moritz Muehlenhoff: > > > The current data structure works very well for us and splitting the files > > > has many downsides. > > > > Could you detail what those many downsides are besides the scripts that > > need to be amended? > > Nearly all the tasks of actually editing the data require a look at the > complete > data, e.g. to check whether something was tracked before, whether there's an > ITP > for something, whether something was tracked as NFU in the past and lots more. Agreed from my point of view as well, history is and contains valuable data, we do not want to loose that. And even if researching in older items and made changes takes time. You will even see that with time passed people started to put more information in the respective done changes/commits, giving rationales, notes, and additional informations. And if that all is going to be too much hassle for the salsa infrastructure we would need/could move the repository to somewhere else, with the unfortunate downside on contributors from the whole comunity. But admitely the people regularly contributing is overviewable. On the agreement side I fully agree that initial clones of the repo are a problem. It as well would be intreesting to see what git upstream would think on that usecase and #913124 raised by Guido. Regards, Salvatore
Bug#908678: Testing the filter-branch scripts
On Wed, Nov 14, 2018 at 07:45:59PM +0100, Moritz Muehlenhoff wrote: > Nearly all the tasks of actually editing the data require a look at the > complete > data, e.g. to check whether something was tracked before, whether there's an > ITP > for something, whether something was tracked as NFU in the past and lots more. according to git log, the data goes back to 2004. Do you really need all those 15 years of history or could we maybe make a yearly split for (now) the first 10 years and have the last 5 years in "one"? And then when we move into 2019 we would move 2014 to the then 11 first years and so on... same in 2020 with 2015 then... IMHO we should do something, else dealing with security-tracker.git will be even more cumbersome in 5 or 10 years ahead. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#908678: Testing the filter-branch scripts
On Wed, Nov 14, 2018 at 07:34:03AM +0100, Daniel Lange wrote: > Am 13.11.18 um 23:09 schrieb Moritz Muehlenhoff: > > The current data structure works very well for us and splitting the files > > has many downsides. > > Could you detail what those many downsides are besides the scripts that > need to be amended? Nearly all the tasks of actually editing the data require a look at the complete data, e.g. to check whether something was tracked before, whether there's an ITP for something, whether something was tracked as NFU in the past and lots more. Cheers, Moritz
Bug#908678: Testing the filter-branch scripts
Hi, On Tue, Nov 13, 2018 at 11:09:41PM +0100, Moritz Muehlenhoff wrote: > On Tue, Nov 13, 2018 at 12:22:54PM -0500, Antoine Beaupré wrote: > > But before going through that trouble, I think we'd need to get approval > > from the security team first, as that's quite a lot of work. I figured > > we would make a feasability study first... > > The current data structure works very well for us and splitting the files > has many downsides. > > If we can't get the repository in run on salsa in a manner that doesn't > impact other repositories (e.g. by disabling the repository browser or > similar), then moving the security tracker repository out of Salsa is > the more likely solution. > > Did anyone follow Guido's suggestion to report this upstream to > get their assessment on possible optimisations? Just in case someone takes this upstream. I've filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913124 against git a couple of days ago. Cheers, -- Guido
