linux-kernel - Re: Problematic culture around Signed-off-by

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]

Message-ID: <20170731133411.3uvgi4sf5h4jwh4m@angband.pl>
Date:   Mon, 31 Jul 2017 15:34:11 +0200
From:   Adam Borowski <kilobyte@...band.pl>
To:     Pavel Machek <pavel@....cz>
Cc:     Ian Molton <spyro2@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Problematic culture around Signed-off-by

On Sun, Jul 30, 2017 at 08:52:36PM +0200, Pavel Machek wrote:
> > I've been away from kernel development for a bit, but I've returned and
> > I'm troubled by what seems to be an entrenched and widespread (IMO)
> > misuse of the "Signed-off-by:" in commits.
> > 
> > I've now either been asked to sign off RFC quality patches "because its
> > quicker" on more than one occasion in the last week or so, and I've seen
> > others signing off code which clearly has no hope of going anywhere near
> > the kernel. (eg. // commented out lines)
> > 
> > I was of the impression that Signed-off-by: was intended to be used on
> > essentially *finished* commits, indicating both readiness for inclusion
> > upstream and ones ownership of the copyright.
> > 
> > Even if the intent is *purely* a copyright isue, Signing off
> > *everything* surely makes it far too easy for people to get junk into
> > the kernel.
> 
> I normally sign-off everything... because getting patch without
> sign-off is nasty. If maintainer gets unclean, but signed-off patch,
> he can just clean it up, add his sign-off and continue normally.

Yet there are cases with known but unobvious breakage (see below).

> That may or may not be allowed if patch is not signed-off. (We are in
> lawyer teritory now.)
> 
> So I'd recommend signing everything, and if patch is considered "not
> ready", make it clear in some other way.

I think it'd be much better if you could suggest a new marker.  Something
like "Copyright-but-not-Readiness-Signed-off-by:", "RFC-Signed-off-by:",
"WIP-Signed-off-by:", etc.

And having a common, agreed upon marker would avoid confusion.

For example, I'm currently messing with a patch set that appears to give a
nice speed-up for the O_PONIES issue, but it messes with parts of the kernel
I'm really unfamiliar with.  Moreover, I know of data-loss scenarios in my
current version (I have naive ideas for a fix), but these scenarios are
irrelevant for a RFC.  Thus, it's imperative these patches do not get into
any non-experimental tree -- yet it's also likely that, if the concept
proves as good as it seems, that one of kernel devs with more skill would
take my work and beat it into sanity.

Cases like this just scream for a "Here-be-Dragons-but-Signed-off-Copyright-
Wise:" line.

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water