From: Jarkko Sakkinen <jarkko@kernel.org>
To: Eric Snowberg <eric.snowberg@oracle.com>,
linux-security-module@vger.kernel.org
Cc: dhowells@redhat.com, dwmw2@infradead.org,
herbert@gondor.apana.org.au, davem@davemloft.net,
ardb@kernel.org, paul@paul-moore.com, jmorris@namei.org,
serge@hallyn.com, zohar@linux.ibm.com, roberto.sassu@huawei.com,
dmitry.kasatkin@gmail.com, mic@digikod.net,
casey@schaufler-ca.com, stefanb@linux.ibm.com,
ebiggers@kernel.org, rdunlap@infradead.org,
linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-efi@vger.kernel.org,
linux-integrity@vger.kernel.org
Subject: Re: [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check
Date: Thu, 17 Oct 2024 19:13:21 +0300 [thread overview]
Message-ID: <213ec040cf30ad8af6ea9706b10ced8219f6e3aa.camel@kernel.org> (raw)
In-Reply-To: <20241017155516.2582369-2-eric.snowberg@oracle.com>
On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this
> pattern does not need to be repeated with new code.
>
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
> certs/system_keyring.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 9de610bf1f4b..e344cee10d28 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -24,9 +24,7 @@ static struct key *secondary_trusted_keys;
> #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
> static struct key *machine_trusted_keys;
> #endif
> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
> static struct key *platform_trusted_keys;
> -#endif
>
> extern __initconst const u8 system_certificate_list[];
> extern __initconst const unsigned long system_certificate_list_size;
> @@ -345,11 +343,7 @@ int verify_pkcs7_message_sig(const void *data,
> size_t len,
> trusted_keys = builtin_trusted_keys;
> #endif
> } else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
> trusted_keys = platform_trusted_keys;
> -#else
> - trusted_keys = NULL;
> -#endif
> if (!trusted_keys) {
> ret = -ENOKEY;
> pr_devel("PKCS#7 platform keyring is not
> available\n");
Just to check with the argument that any commit should bring the Git
tree to another "good state". Why this was flagged? What would be the
collateral damage if only this commit was picked and put to a pull
request? No intentions to do that, this more like forming a better
understanding what is at stake here.
I.e. I get that you need this for subsequent commits but I think the
commit message should also have like explanation why this is a legit
change otherwise.
I mean, less flagging better if it does not cause harm is already
great without higher level goals.
BR, Jarkko
next prev parent reply other threads:[~2024-10-17 16:13 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 15:55 [RFC PATCH v3 00/13] Clavis LSM Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check Eric Snowberg
2024-10-17 16:13 ` Jarkko Sakkinen [this message]
2024-10-17 16:50 ` Eric Snowberg
2024-12-23 13:21 ` Mimi Zohar
2025-01-03 23:15 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 02/13] certs: Introduce ability to link to a system key Eric Snowberg
2024-10-17 16:16 ` Jarkko Sakkinen
2024-10-17 16:53 ` Eric Snowberg
2024-12-23 16:11 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis Eric Snowberg
2024-10-17 16:50 ` Jarkko Sakkinen
2024-10-17 20:34 ` Eric Snowberg
2024-10-17 21:16 ` Jarkko Sakkinen
2024-12-24 0:01 ` Mimi Zohar
2025-01-03 23:27 ` Eric Snowberg
2025-01-05 11:43 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE) Eric Snowberg
2024-10-17 19:20 ` Jarkko Sakkinen
2024-10-17 21:42 ` Eric Snowberg
2024-10-17 21:58 ` Jarkko Sakkinen
2024-12-24 0:17 ` Mimi Zohar
2025-01-03 23:28 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl Eric Snowberg
2024-10-18 5:21 ` Ben Boeckel
2024-10-18 15:42 ` Eric Snowberg
2024-10-18 16:55 ` Ben Boeckel
2024-10-18 21:55 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 06/13] clavis: Populate clavis keyring acl with kernel module signature Eric Snowberg
2024-10-17 19:27 ` Jarkko Sakkinen
2024-10-17 15:55 ` [RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key Eric Snowberg
2025-02-06 20:13 ` Jarkko Sakkinen
2025-02-07 23:09 ` Eric Snowberg
2025-02-12 12:42 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis Eric Snowberg
2024-10-23 2:25 ` sergeh
2024-10-23 19:25 ` Eric Snowberg
2024-10-24 19:57 ` sergeh
2024-12-24 17:43 ` Mimi Zohar
2025-01-03 23:32 ` Eric Snowberg
2025-01-05 12:59 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 09/13] clavis: Allow user to define acl at build time Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 10/13] efi: Make clavis boot param persist across kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 11/13] clavis: Prevent boot param change during kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 12/13] clavis: Add function redirection for Kunit support Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 13/13] clavis: " Eric Snowberg
2024-12-24 1:11 ` Mimi Zohar
2024-12-23 12:09 ` [RFC PATCH v3 00/13] Clavis LSM Mimi Zohar
2025-01-03 23:14 ` Eric Snowberg
2025-01-04 4:48 ` Paul Moore
2025-01-06 3:40 ` Paul Moore
2025-01-06 17:15 ` Eric Snowberg
2025-02-27 20:41 ` Mimi Zohar
2025-02-27 22:22 ` Paul Moore
2025-02-28 14:08 ` Mimi Zohar
2025-02-28 16:14 ` Paul Moore
2025-02-28 17:18 ` Mimi Zohar
2025-03-03 22:38 ` Paul Moore
2025-03-04 12:53 ` Mimi Zohar
2025-03-05 0:19 ` Paul Moore
2025-03-05 1:49 ` Mimi Zohar
2025-03-05 2:09 ` Paul Moore
2025-03-05 2:20 ` Mimi Zohar
2025-03-05 2:24 ` Paul Moore
2025-02-28 17:51 ` Eric Snowberg
2025-03-03 22:40 ` Paul Moore
2025-03-04 14:46 ` Eric Snowberg
2025-03-05 0:23 ` Paul Moore
2025-03-05 21:29 ` Eric Snowberg
2025-03-06 1:12 ` Paul Moore
2025-03-06 22:28 ` Eric Snowberg
2025-03-07 2:46 ` Paul Moore
2025-03-20 16:24 ` Eric Snowberg
2025-03-20 21:36 ` Paul Moore
2025-03-21 16:37 ` Eric Snowberg
2025-03-21 18:57 ` Paul Moore
2025-03-21 21:20 ` Eric Snowberg
2025-03-21 22:13 ` Paul Moore
2025-03-21 22:56 ` Eric Snowberg
2025-03-22 2:00 ` Paul Moore
2025-03-21 17:22 ` Jarkko Sakkinen
2025-03-21 19:05 ` Paul Moore
2025-03-20 22:40 ` James Bottomley
2025-03-21 16:40 ` Eric Snowberg
2025-03-21 16:55 ` James Bottomley
2025-03-21 20:15 ` Eric Snowberg
2025-03-21 20:53 ` James Bottomley
2025-03-24 17:44 ` Eric Snowberg
2025-03-21 17:08 ` Jarkko Sakkinen
2025-03-04 22:24 ` Jarkko Sakkinen
2025-03-05 0:25 ` Paul Moore
2025-03-05 0:29 ` Jarkko Sakkinen
2025-03-01 2:20 ` Jarkko Sakkinen
2025-03-01 2:19 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=213ec040cf30ad8af6ea9706b10ced8219f6e3aa.camel@kernel.org \
--to=jarkko@kernel.org \
--cc=ardb@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@kernel.org \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=rdunlap@infradead.org \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=stefanb@linux.ibm.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).