linux-kernel - Re: [PATCH RFC] kconfig: place git SHA1 in .config output if in git tree

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 2 Mar 2010 16:19:32 +0100
From:	Frans Pop <elendil@...net.nl>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-kernel@...r.kernel.org, zippel@...ux-m68k.org, mingo@...e.hu,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH RFC] kconfig: place git SHA1 in .config output if in git tree

On Tuesday 02 March 2010, Paul E. McKenney wrote:
> Sigh!  Because popen() doesn't fail when the command is bogus, it seems.
> I now do stat() to check for it existing, and that seems to handle the
> remote-output case.

Cool. Did you check if it's really necessary to treat the two cases 
separately? I would expect srctree to always be set, and if I read the 
root Makefile correctly that's indeed the case:
srctree         := $(if $(KBUILD_SRC),$(KBUILD_SRC),$(CURDIR))

Hmm. I see you've switched from SRCTREE to KBUILD_SRC. Is that correct? 
SCRTREE is also used elsewhere in the same file and that's the variable 
(in lower case; the upper case variant is a C define) that's explicitly 
exported in the root Makefile.

> > One other thing. I wonder if this implementation will always reliably
> > result in the *current* SHA1 being included in the .config. AFAICT
> > the .config only actually gets written if there are changes, or if you
> > explicitly do a 'make oldconfig'.
> >
> > But if you e.g. pull a stable update and just run 'make', the .config
> > will likely remain unchanged and will thus still contain the SHA1 from
> > a previous build.
>
> Good point.  But the same is true of the Linux kernel version
> identifier, right?

Right. But the increased precision of the SHA1 IMO also demands an 
increased reliability of its accuracy: if it's not accurate it loses its 
value.

Personally I think that maybe the config file is not the correct place for 
this. For one thing users may well send a config file that's not the 100% 
exact one used to build the kernel when they know it's close enough that 
it makes no practical difference (I know I've done so in the past).

Wouldn't it be more logical to include the line in the dmesg output? My 
preference would be a separate line below the existing (Linux version) 
line. That line could only be output if the kernel was built from a VCS.
It could then even be repeated in oops output.

That would also solve the problem of the config file not being updated.

Paul E. McKenney wrote:
>> I'd hate to have that run every time I make a kernel.
> 
> Good point...  Should we have an environment variable that controls this
> behavior?

I would suggest at most a general enabled/disabled switch (distros might 
prefer to disable it too), and not more detailed settings to control 
whether or not to include dirty or whatnot.

Cheers,
FJP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/