From: "longguang.yue" <bigclouds@163.com>
To: "Nathan Chancellor" <nathan@kernel.org>
Cc: "Nicolas Schier" <nicolas.schier@linux.dev>,
linux-kbuild@vger.kernel.org, masahiroy@kernel.org,
"David Howells" <dhowells@redhat.com>,
"David Woodhouse" <dwmw2@infradead.org>,
keyrings@vger.kernel.org
Subject: Re:Re: [PATCH] Makefile: mrproper deletes signing_key.x509
Date: Tue, 12 Aug 2025 10:22:52 +0800 (CST) [thread overview]
Message-ID: <787c311e.22c0.1989c166d01.Coremail.bigclouds@163.com> (raw)
In-Reply-To: <20250811191408.GA169691@ax162>
At 2025-08-12 03:14:08, "Nathan Chancellor" <nathan@kernel.org> wrote:
>On Mon, Aug 11, 2025 at 03:59:23PM +0200, Nicolas Schier wrote:
>> Cc: certs/ people
>>
>> [re-ordered quote]
>> On Mon, Aug 11, 2025 at 02:28:56PM +0800, longguang.yue wrote:
>> > At 2025-08-10 04:11:57, "Nicolas Schier" <nicolas.schier@linux.dev> wrote:
>> > > On Sat, Aug 09, 2025 at 08:04:05PM +0800 longguang.yue wrote:
>> > > > deletes temporary signing_key.x509 and reserves user-defined x509.genkey
>> > >
>> > > can you elaborate the actual problem with some more details?
>> > >
>> > > certs/signing_key.x509 is removed during 'make clean' which is a dependency
>> > > of 'mrproper'.
>> > >
>> > > 'mrproper' is meant to remove everything that might influence a subsequent
>> > > call of kbuild for the sane architecture.
>> > >
>> > > Without further details I cannot see any problem here.
>> > >
>> > > Kind regards,
>> > > Nicolas
>> [...]
>> >
>> > It should not delete x509.genkey because of its exsitence in gitignore.
>> > Normally, users want to keep a self-defined x509.genkey, but mrproper deletes it, only default_x509.genkey is effective.
>> > After applying this patch, users just need to copy self-defined x509.genkey into certs directory once.
>>
>> 'make mrproper' is meant to prepare the source tree to be as pristine as
>> possible for the given architecture. This includes removal of any
>> configuration file(s) that influence subsequent builds. From kbuild
>> point of view, certs/x509.genkey is also a kind of a configuration file,
>> as leaving it in tree after mrproper creates different build results
>> compared to a build from a really pristine source tree.
>
>Agreed, I think it is intentional that this is in mrproper and not
>clean, so I don't think we can accept this change as is, but I am happy
>to be told otherwise from the certs maintainers.
>
>> Iff the certs/ maintainers think that retaining a user x509.genkey file
>> over a mrproper makes sense, then we should probably adjust the rule for
>> generating $(objtree)/certs/x509.genkey, e.g. by allowing to provide one
>> by environment variable.
>>
>> David or David, do you have an opinion on this?
>
>Furthermore, if the user wanted to use a predefined x509 configuration,
>why can't they generate their own signing key and provide it via
>CONFIG_MODULE_SIG_KEY, instead of hijacking the default logic of
>certs/signing_key.pem? Based on my reading of certs/Makefile, it sounds
>like the default logic is mostly there just for allyesconfig or
>randconfig.
>
>Cheers,
>Nathan
Ok, It needs to copy x509.genkey to certs after mrproper.
As above, signing_key.x509 should be deleted, it denpends on x509.genkey and is a configuration file.
Adjust this fix to delete signing_key.x509 only, is it acceptable?
Thanks.
next prev parent reply other threads:[~2025-08-12 2:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250809120405.22957-1-bigclouds@163.com>
[not found] ` <aJerjQGmXXcpTtBB@fjasle.eu>
[not found] ` <1ac1d3e3.58ad.19897d159ff.Coremail.bigclouds@163.com>
2025-08-11 13:59 ` [PATCH] Makefile: mrproper deletes signing_key.x509 Nicolas Schier
2025-08-11 19:14 ` Nathan Chancellor
2025-08-12 2:22 ` longguang.yue [this message]
2025-08-12 9:31 ` David Howells
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=787c311e.22c0.1989c166d01.Coremail.bigclouds@163.com \
--to=bigclouds@163.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).