linux-kernel - Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

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, 7 Jul 2020 01:58:21 +0200
From:   Tibor Raschko <tibrasch@...il.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        torvalds@...ux-foundation.org,
        ksummit-discuss@...ts.linuxfoundation.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        tech-board-discuss@...ts.linuxfoundation.org,
        Chris Mason <clm@...clm>, skhan@...uxfoundation.org
Subject: Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

> The suggestions you made will help us adapt inclusive terminology
> for the current times, and also help us move toward terms that are
> intuitive and easier to understand keeping our global developer
> community in mind.

> Allowlist/denylist terms are intuitive and action based which have a
> globally uniform meaning.

Nobody has a problem understanding "blacklist" and "whitelist". These
are universally understood words even outside of computing. Claiming
that we need clearer alternatives is smoke and mirrors.

> Terms such as "whitelist" etc are contextual, hence assume contextual
> knowledge on the part of the reader.

We are talking about the source code of and interacting with an
operating system kernel. Naturally, most things here are contextual and
require domain knowledge to be understood correctly. Not requiring
contextual knowledge when reading the kernel sources doesn't sound like
a realistic argument.

Raschko T.