git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/3] Use "allowlist" and "denylist" tree-wide

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Jul 13, 2022, 19:42 UTC
Message-ID
<220713.86wncg3hnj.gmgdl@evledraar.gmail.com>
In-Reply-To
<pull.1274.git.1657718450.gitgitgadget@gmail.com>
On Wed, Jul 13 2022, Derrick Stolee via GitGitGadget wrote:
> The terms "allowlist" and "denylist" are self-defining. One "allows" things
> while the other "denies" things.

I've got a preference for things that can be found in widely available dictionaries, these words seem to be tech neologisms.

The resulting wording also seems a bit ackward to me, e.g. we now say that some tests are "allowlisted [...] as passing with no memory leaks". Are we denying or allowing them to pass? No, they're going to either pass or not.

So to me "whitelist" or "blacklist" is more natural when used in the descriptive sense, whereas "allow" and "deny" are verbs, so that seems to impart a sense of actively allowing or denying something.

> These are better terms over "whitelist" and "blacklist" which require prior
> knowledge of the terms or cultural expectations around what each color
> "means".

Apparently whitelist is defined in terms of blacklist, which per Wikipedia originates in some 17th century play: https://en.wikipedia.org/wiki/Blacklisting#Origins_of_the_term

Show 6 quoted lines
> [...]
> Some recommend using "blocklist", but I personally prefer "denylist". To me,
> "blocking" something seems permanent. "Denying" something seems ephemeral
> and related to a specific request being denied due to some (possibly
> mutable) state. I'm open to suggestions here. There are many fewer
> replacements needed in this case.

I suspect the actual motivation is closer to that summarized in : https://en.wikipedia.org/wiki/Whitelist#Controversy

Personally I'd really prefer if we didn't take these sort of changes, and took the view that if something was readily understood that it was good enough.

The CodingGuidelines note that we use a mix of US & UK english, so forbidding certain words & basically requiring some of us to keep abreast of the latest political trends in America is a bit too much. I'd just like to write code, please...

> I did not make any change to our CodingGuidelines. Hopefully having clear
> usage throughout the codebase will be enough to promote using consistent
> terminology.

...particularly since I think what's being implied here is that we can expect interested parties to be setting up the relevant E-Mail filters, and asking patch submitters to change wording in the same way as this series does.

We also have 30-40 uses of both terms in-tree, so it seems implausible that people are mainly copying existing wording.

A few of the hunks here are changing docs I added, and I just added those "naturally", i.e. I happened to think of those words to describe what I was trying to get across).

Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 38 in “Use "allowlist" and "denylist" tree-wide”
  1. 0/3 Use "allowlist" and "denylist" tree-wideDerrick Stolee via GitGitGadget, Jul 13, 2022
  2. 1/3 Documentation: use allowlist and denylistDerrick Stolee via GitGitGadget, Jul 13, 2022
  3. Jeff KingJul 13, 2022
  4. Derrick StoleeJul 13, 2022
  5. Junio C HamanoJul 13, 2022
  6. 2/3 t/*: use allowlistDerrick Stolee via GitGitGadget, Jul 13, 2022
  7. 3/3 *: use allowlist and denylistDerrick Stolee via GitGitGadget, Jul 13, 2022
  8. Johannes SchindelinJul 13, 2022
  9. Jeff KingJul 13, 2022
  10. Johannes SchindelinJul 13, 2022
  11. Junio C HamanoJul 13, 2022
  12. Derrick StoleeJul 13, 2022
  13. Junio C HamanoJul 13, 2022
  14. Ævar Arnfjörð BjarmasonJul 13, 2022
  15. Junio C HamanoJul 13, 2022
  16. Derrick StoleeJul 15, 2022
  17. Ævar Arnfjörð BjarmasonJul 13, 2022
  18. 0/3 Remove use of "whitelist"Derrick Stolee via GitGitGadget, Jul 15, 2022
  19. 1/3 Documentation: remove use of whitelistDerrick Stolee via GitGitGadget, Jul 15, 2022
  20. Ævar Arnfjörð BjarmasonJul 15, 2022
  21. Derrick StoleeJul 19, 2022
  22. 2/3 t/*: avoid "whitelist"Derrick Stolee via GitGitGadget, Jul 15, 2022
  23. Ævar Arnfjörð BjarmasonJul 15, 2022
  24. Derrick StoleeJul 19, 2022
  25. Ævar Arnfjörð BjarmasonJul 19, 2022
  26. Derrick StoleeJul 19, 2022
  27. Junio C HamanoJul 19, 2022
  28. 3/3 *: avoid "whitelist"Derrick Stolee via GitGitGadget, Jul 15, 2022
  29. Ævar Arnfjörð BjarmasonJul 15, 2022
  30. Junio C HamanoJul 15, 2022
  31. Phillip WoodJul 15, 2022
  32. 0/5 Remove use of "whitelist"Derrick Stolee via GitGitGadget, Jul 19, 2022
  33. 1/5 daemon: clarify directory argumentsDerrick Stolee via GitGitGadget, Jul 19, 2022
  34. 2/5 git-cvsserver: clarify directory listDerrick Stolee via GitGitGadget, Jul 19, 2022
  35. 3/5 git.txt: remove redundant languageDerrick Stolee via GitGitGadget, Jul 19, 2022
  36. Jeff KingJul 31, 2022
  37. 4/5 t: avoid "whitelist"Derrick Stolee via GitGitGadget, Jul 19, 2022
  38. 5/5 transport.c: avoid "whitelist"Derrick Stolee via GitGitGadget, Jul 19, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.