[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CZLBOJEYP2M1.I4A9D5M5MR01@suppilovahvero>
Date: Tue, 05 Mar 2024 00:35:05 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "David Gstir" <david@...ma-star.at>, "Mimi Zohar" <zohar@...ux.ibm.com>,
"James Bottomley" <jejb@...ux.ibm.com>, "Herbert Xu"
<herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>
Cc: "Shawn Guo" <shawnguo@...nel.org>, "Jonathan Corbet" <corbet@....net>,
"Sascha Hauer" <s.hauer@...gutronix.de>, "Pengutronix Kernel Team"
<kernel@...gutronix.de>, "Fabio Estevam" <festevam@...il.com>, "NXP Linux
Team" <linux-imx@....com>, "Ahmad Fatoum" <a.fatoum@...gutronix.de>, "sigma
star Kernel Team" <upstream+dcp@...ma-star.at>, "David Howells"
<dhowells@...hat.com>, "Li Yang" <leoyang.li@....com>, "Paul Moore"
<paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>, "Serge E.
Hallyn" <serge@...lyn.com>, "Paul E. McKenney" <paulmck@...nel.org>, "Randy
Dunlap" <rdunlap@...radead.org>, "Catalin Marinas"
<catalin.marinas@....com>, "Rafael J. Wysocki"
<rafael.j.wysocki@...el.com>, "Tejun Heo" <tj@...nel.org>, "Steven Rostedt
(Google)" <rostedt@...dmis.org>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-integrity@...r.kernel.org>,
<keyrings@...r.kernel.org>, <linux-crypto@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <linuxppc-dev@...ts.ozlabs.org>,
<linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v5 2/6] KEYS: trusted: improve scalability of trust
source config
On Fri Dec 15, 2023 at 1:06 PM EET, David Gstir wrote:
> Checking if at least one valid trust source is selected does not scale
> and becomes hard to read. This improves this in preparation for the DCP
> trust source.
This commit needs a complete rewrite and I do not have time and
energy to propose one but here's what it should contain:
1. Add HAVE_TRUSTED_KEYS to th trusted-keys/Kconfig.
2. The use and purpose of HAVE_TRUSTED_KEYS.
If you read your commit message, do you see anything at all concerning
the code change? It only tells a story about something that is not
properly being defined to be "hard to read", which is no rationale to
change anything at all in the kernel.
If you put factors more focus on being as straight and easy to get
in the commit messages, it will also improve the round-trip time
between sending the patch set and getting reviewed, because people
with limited time at their hands tend to pick the low-hanging fruit
first.
BR, Jarkko
Powered by blists - more mailing lists