Re: [PATCH] Makefile: mrproper deletes signing_key.x509

[Nathan Chancellor <nathan@kernel.org>]

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