linux-kernel - Re: Linux kernel DCO

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: <c1bf62a2-e381-c796-2219-17a578987a76@marcan.st>
Date:   Thu, 2 Mar 2023 12:35:15 +0900
From:   Hector Martin <marcan@...can.st>
To:     Richard Acayan <mailingradian@...il.com>,
        linux-kernel@...r.kernel.org
Cc:     Asahi Lina <lina@...hilina.net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Michael Dolan <mdolan@...uxfoundation.org>
Subject: Re: Linux kernel DCO

On 02/03/2023 12.19, Richard Acayan wrote:
>> I agree that this should be changed (for many reasons, I could write
>> about this at length), and as I'm sure you can imagine, such change
>> would probably have to be a coordinated push with buy-in from several
>> kernel stakeholders. So I would appreciate it if you don't turn this
>> into a public discussion at this time, and let us figure out how to deal
>> with it when the time comes.
> 
> Sorry to bother you, but what happened?

An offline discussion happened ;)

> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330
> 
> Two Acked-by's are a bit underwhelming for a coordinated push with
> buy-in from several kernel stakeholders.

The patch is by Linus, it's acked by Greg (who originally introduced the
"real name" wording) and by Mike (SVP of Projects & Legal at the Linux
Foundation, i.e. a lawyer). What more do you want?

Things don't always happen as one envisioned, but now the problem is
fixed either way. Linus ultimately gets to write the rules on this,
there's no need for more acks.

> Of course, it's easy to call this naive and ignorant. I accepted this
> explanation and respected this request to not turn this into a public
> discussion until the time comes. Now, I wonder if this patch was written
> and applied later than it should have been because we misunderstood the
> kernel contribution process as an aristocracy for this specific case.

Ultimately the reality is that enforcement of the "real name" rule has
been wildly inconsistent and some subsystems (like DRM) have always
accepted pseudonyms. The original wording was misguided and conflated
names with identity, leading to the eventual divergence of opinion on
how it should be enforced. The subject came up offline, and now the
official wording has been changed to match reality (i.e. that what the
kernel actually wants is knowing who people are in an abstract sense of
trust/continuity/reachability, not their "real" name whatever that might
mean).

- Hector