linux-kernel - Re: [PATCH RFC] kbuild: prevent git private tag altering kernelrelease

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

Message-ID: <20131027193907.GA2710@afzal-ThinkPad-R50e>
Date:	Mon, 28 Oct 2013 01:09:07 +0530
From:	Afzal Mohammed <afzal.mohd.ma@...il.com>
To:	Michal Marek <mmarek@...e.cz>
Cc:	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
	Christophe Leroy <christophe.leroy@....fr>,
	Christian Kujau <lists@...dbynature.de>
Subject: Re: [PATCH RFC] kbuild: prevent git private tag altering
 kernelrelease

Hi Michal,

On Wed, Oct 23, 2013 at 03:21:00PM +0200, Michal Marek wrote:
> On 13.9.2013 23:49, Afzal Mohammed wrote:

> > If a private tag is created after the most recent kernelversion tag, a
> > commit after this private tag would feed kernelrelease with commits
> > after private tag and kernelversion tag. This may confuse user relying
> > on kernelrelease (mostly a developer while debugging), mainly if HEAD
> > has a private tag and otherwise w.r.t git distance from kernelversion
> > tag.
> 
> The solution is simple: Do not use private annotated tags. Or rather, if
> you are creating an annotated tag, modify EXTRAVERSION accordingly. Any
> automagic based on the tag name is going to fail in some way.

Here private tags, although not a proper term, (my description wasn't
clear) was referring to any annotated/signed tag that does not match
kernelversion.

Reason for this patch was to determine the exact source from kernel
logs easily while working over subystem maintainer trees (especially
useful when checking older logs and testing). More than my private tags,
it is the tags of subystem maintainers which never is a kernelversion
that made it difficult to determine the source from logs. Presence of
those tags misleads one about the source.

Modifying EXTRAVERSION would make it dirty, else commiting only for
the sake of avoiding dirty would be required to track the git source
and chances are high that git gc may eat those commits.

> With your change, the script considers e.g. the next-YYYYMMDD tags
> "private."

Although next tags were not causing much problem (due to
localversion-next file and as no direct development over next),
maintainer tags like this without localversion-* files were the ones
that was being mostly targeted by this change.

> >  define filechk_kernel.release
> > -	echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))"
> > +	echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree) $(KERNELVERSION))" > $@
> >  endef
> 
> The >$@ should not be there.

Yes, crap, happened while rebasing - punishment for coding without
proper understanding.

Regards
Afzal
--
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/