linux-kernel - get_maintainer.pl: penguin chiefs, maintainers and the rest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <AS8PR07MB894183C6DE3473F23D5A046FF9602@AS8PR07MB8941.eurprd07.prod.outlook.com>
Date: Wed, 3 Jan 2024 16:12:18 +0000
From: Anthony LOISEAU <anthony.loiseau@...circuits.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Joe Perches <joe@...ches.com>
Subject: get_maintainer.pl: penguin chiefs, maintainers and the rest

Hello,

I am a little bit cluttered about a few things around get_maintainer.pl and the fact that penguin chiefs may also be maintainers, at least in third party projects also using get_maintainer.pl script. My feeling is that get_maintainer.pl mishandles penguin chiefs without it being an issue for Linux case, therefore a kind of silent bug. But since other projects do use get_maintainer.pl, this "bug" may matter you (upstream).

Penguin chief is an hard-coded list of name:email inside get_maintainer.pl script, which currently only lists Linus. When called with --git-chief-penguins, the script also outputs penguin chiefs alongside found maintainers.

When called with --no-git-chief-penguins (the default), the script actually removes chief penguin from found maintainers. That is, if a penguin chief is also a maintainer of some files within MAINTAINERS file, asking maintainers of those file will not list him/her and may list nobody if he/she was single maintainer for those files.

Hopefully, the issue is either minor or nonexistent/feature with Linux MAINTAINERS file since Linus (hard-coded penguin chief) is only maintainer of "THE REST" final catch-all section. He is the only maintainer of this section, therefore no maintainers at all are returned for files not covered in other sections. Also, thanks to this bug/feature, this catch-all section being somehow broken does not reports Linus as maintainer of every Linux files, which may avoid flooding Linus.

As a first sight I see several options:

1. Upstream (Linux get_maintainer.pl) can be modified to not filter out chiefs within found maintainers.
2. Third-party projects can simply clear their static penguin chief list.

Caution: in both cases (and especially the former), "THE REST" catch-all section will work again, listing Linus in all results, likely flooding him until all git-email --cc-cmd gists are fixed. This can be handled within script since the magic "Buried alive in reporters" section status makes its maintainers getting "chief penguin" role instead of "maintainer". Script can then properly ignore penguin chiefs only when they are referenced as such ("THE REST" case) while still listing the same author when listed as a role maintainer.

At the end, penguin chiefs may even be listed only in MAINTAINERS file, either as today (special S: changing role of M:) or using a dedicated letter (allowing maintainer/chief mix within a section). Script options --git-chief-penguins and --no-git-chief-penguins would then only parse and ignore matching chiefs inside MAINTAINERS, and script array @penguin_chief would disappear.

My feeling is that this would be the cleaner way to address this issue. What is you opinion?

Aside note for curious readers: I actually saw this issue within U-Boot, where Tom Rini (hard-coded penguin chief) is also maintainer of some sections for which get_maintainer.pl does now work as expected.

Regards,
Anthony