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:	Mon, 10 Oct 2011 10:09:59 -0700
From:	Joe Perches <joe@...ches.com>
To:	Olof Johansson <olof@...om.net>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	apw@...onical.com
Subject: Re: [PATCH] checkpatch: warn on found Change-Id lines

On Sun, 2011-10-09 at 22:56 -0700, Olof Johansson wrote:
> Some external projects use repo, which uses a special-format Change-Id
> field in the commit message for some internal bookkeeping (to re-associate
> patches back to review entries, etc).

I believe Andrew has a patch from me in his queue
somewhere that tries to isolate the commit message
and does a couple of checks just on that content.

> Sometimes they sneak into patches
> going upstream, which is embarrassing for the developer, and annoying
> for the maintainer.
> 
> Add checking for these to checkpatch, to catch them before
> posting. Provide a way to disable the check to keep checkpatch useful
> for intra-project use.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> +my $chk_changeid = 1;

> +  --no-change-id             don't complain about 'Change-Id' lines

Adding piecemeal option overrides could eventually
make these sorts of things quite long.

Perhaps it's better to use:
--ignore=CHANGE_ID

or add a .checkpatch.conf file somewhere with this.

> +	'change-id!'	=> \$chk_changeid,

> +$chk_changeid = 0 if ($file);

> +# Check for Change-Id lines:
> +		if ($line =~ /^\s*change-id:/i && $chk_changeid) {
> +			ERROR("CHANGE_ID", "Found Change-Id line\n", $herecurr);
> +		}

I believe this will also match lines in any
patch context, so maybe this is not good.

I think this should be placed adjacent to the
RCS/CVS check.

Maybe it's better to add some "VCS_CRUFT"
option and track/emit all the RCS/SCCS/PVS/CVS
crud in one bundle.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ