Hi,
Le Tue, Apr 08, 2025 at 07:24:07PM +0200, Sylvain Beucler a écrit :
> On 07/04/2025 13:06, Adrian Bunk wrote:
> > On Sun, Apr 06, 2025 at 07:33:22PM +0200, Bastien Roucaries wrote:
> > > Le dimanche 6 avril 2025, 09:25:58 heure d’été d’Europe centrale Roberto
> > > C.
> > > Sánchez a écrit :
> > > ...
> > > > As one example, some time ago I encountered the issue of the size of
> > > > data/CVE/list, specifically in the context of a git blame operation
> > > > taking a few hours to complete. I became convinced that data/CVE/list
> > > > needs to be split. As I've done some research on the topic, the answer
> > > > to that is far from clear. I'm less convinced now that "split
> > > > data/CVE/list" is the de facto right solution, and I'm definitely
> > > > convinced that a big change here will not be accepted without many good
> > > > reasons and proof that doesn't also include some massive drawbacks.
> > >
> > > split per year will help here.
> > > ...
> >
> > Which is not easy, see
> > https://salsa.debian.org/security-tracker-team/security-tracker-service/-/issues/1
>
> Back then I put together a git-filter-branch rewrite&subdir of
> security-tracker/data/CVE/, to isolate triaged CVEs per-file and allow
> near-instant history/blame for any specific CVE, e.g.:
> $ gitk 2025/31115
>
> https://lists.debian.org/debian-lts/2020/10/msg00017.html
> https://lists.debian.org/debian-lts/2020/10/pngYP1m7tAWfw.png
>
> It took a day to run IIRC, it probably would take much longer now as
> data/CVE/list more than doubled and gets slower to process.
> Nobody gave a damn and I eventually removed it ¯\_(ツ)_/¯
>
> I still update my local repo to help understand specific CVEs triage, thanks
> to the incremental feature of git-filter-branch.
> I just checked the newer git-filter-repo (which is based on
> git-fast-import/export and is much faster in general) but sadly it doesn't
> seem to fit this use case (no incremental/resume, not-so-fast *content*
> rewrite, splitting files is tricky).
>
> Note: this is orthogonal to the split-by-year issue mentioned above, which
> is more involved (full path rewrite, tooling updates, ELTS security-tracker
> fork breakage, etc.)
>
>
> I can re-upload my rewrite back on Salsa, if there's interest?
In case the above was unclear:
$ time git blame 2020/12362
b74ea0a01b9f (security tracker role 2021-02-17 20:10:29 +0000 1)
CVE-2020-12362 (Integer overflow in the firmware for some Intel(R) Graphics
Drivers fo ...)
92c262f6ce6a (security tracker role 2023-04-01 20:10:18 +0000 2)
{DLA-3380-1}
6c233a25aafb (Salvatore Bonaccorso 2022-02-25 07:27:01 +0100 3) - linux
5.14.6-1
6502365f5302 (Moritz Muehlenhoff 2021-07-26 12:08:08 +0200 4)
[bullseye] - linux <ignored> (Too intrusive to backport)
6502365f5302 (Moritz Muehlenhoff 2021-07-26 12:08:08 +0200 5)
[buster] - linux <ignored> (Too intrusive to backport)
ea0228db4ae4 (Moritz Muehlenhoff 2021-03-17 10:11:20 +0100 6) -
firmware-nonfree 20210208-1
573a76415f39 (Ola Lundqvist 2021-05-20 08:35:47 +0200 7)
[stretch] - firmware-nonfree <ignored> (Minor issue, too intrusive to fix since
kernel patch is needed)
bfad1287c924 (Moritz Muehlenhoff 2021-02-10 18:32:30 +0100 8) NOTE:
Short of details:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00438.html
01f4a8757107 (Salvatore Bonaccorso 2021-02-18 13:21:45 +0100 9) NOTE:
Per Intel, this was fixed by a firmware update. v49.0.1 of the
74ce78c24900 (Salvatore Bonaccorso 2021-02-18 20:40:02 +0100 10) NOTE:
firmware is required. The new firmware requires a kernel patch
01f4a8757107 (Salvatore Bonaccorso 2021-02-18 13:21:45 +0100 11) NOTE:
https://git.kernel.org/linus/c784e5249e773689e38d2bc1749f08b986621a26
ea0228db4ae4 (Moritz Muehlenhoff 2021-03-17 10:11:20 +0100 12) NOTE:
Firmware was added via
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c487f7dadcd21116613441ed355b764003b3f57b
6502365f5302 (Moritz Muehlenhoff 2021-07-26 12:08:08 +0200 13) NOTE:
The vulnerability is fixed in firmware, but needs an updated Linux kernel to
load
6502365f5302 (Moritz Muehlenhoff 2021-07-26 12:08:08 +0200 14) NOTE:
the updated firmware, thus also marking linux as affected
real 0m0,506s
user 0m0,399s
sys 0m0,107s
- Sylvain
