From ee0384740f3006281f1df4867d556c7dc4614478 Mon Sep 17 00:00:00 2001 From: Andre Klapper Date: Tue, 2 Sep 2025 09:42:09 +0200 Subject: [PATCH] Diviner: Replace Whitelist and Blacklist with Allowlist and Denylist Summary: Allowlist and Denylist are much more descriptive when it comes to their actual meanings. (Plus some folks may interpret Whitelist and Blacklist as language which perpetuates discrimination.) Refs T16252 Test Plan: Read the docs; run `./bin/diviner generate`. Reviewers: O1 Blessed Committers, valerio.bozzolan Reviewed By: O1 Blessed Committers, valerio.bozzolan Subscribers: tobiaswiese, valerio.bozzolan, Matthew, Cigaryno Maniphest Tasks: T16252 Differential Revision: https://we.phorge.it/D26313 --- .../flavor/things_you_should_do_now.diviner | 18 +++++++++--------- src/docs/user/cluster/cluster.diviner | 10 +++++----- .../configuring_inbound_email.diviner | 2 +- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/docs/flavor/things_you_should_do_now.diviner b/src/docs/flavor/things_you_should_do_now.diviner index 58a5b8eaea..8848de3b6f 100644 --- a/src/docs/flavor/things_you_should_do_now.diviner +++ b/src/docs/flavor/things_you_should_do_now.diviner @@ -79,35 +79,35 @@ everything, just the basics. Your language probably already has a function which does the sanitizing for you. -= Never Design a Blacklist-Based Security System = += Never Design a Denylist-Based Security System = When you have an alternative, don't design security systems which are default -permit, blacklist-based, or otherwise attempt to enumerate badness. When -Facebook launched Platform, it launched with a blacklist-based CSS filter, which +permit, denylist-based, or otherwise attempt to enumerate badness. When +Facebook launched Platform, it launched with a denylist-based CSS filter, which basically tried to enumerate all the "bad" parts of CSS and filter them out. This was a poor design choice and lead to basically infinite security holes for all time. It is very difficult to enumerate badness in a complex system and badness is -often a moving target. Instead of trying to do this, design whitelist-based +often a moving target. Instead of trying to do this, design allowlist-based security systems where you list allowed things and reject anything you don't understand. Assume things are bad until you verify that they're OK. -It's tempting to design blacklist-based systems because they're easier to write +It's tempting to design denylist-based systems because they're easier to write and accept more inputs. In the case of the CSS filter, the product goal was for users to just be able to use CSS normally and feel like this system was no -different from systems they were familiar with. A whitelist-based system would +different from systems they were familiar with. An allowlist-based system would reject some valid, safe inputs and create product friction. -But this is a much better world than the alternative, where the blacklist-based +But this is a much better world than the alternative, where the denylist-based system fails to reject some dangerous inputs and creates //security holes//. It //also// creates product friction because when you fix those holes you break existing uses, and that backward-compatibility friction makes it very difficult -to move the system from a blacklist to a whitelist. So you're basically in +to move the system from a denylist to an allowlist. So you're basically in trouble no matter what you do, and have a bunch of security holes you need to unbreak immediately, so you won't even have time to feel sorry for yourself. -Designing blacklist-based security is one of the worst now-vs-future tradeoffs +Designing denylist-based security is one of the worst now-vs-future tradeoffs you can make. See also "The Six Dumbest Ideas in Computer Security": http://www.ranum.com/security/computer_security/ diff --git a/src/docs/user/cluster/cluster.diviner b/src/docs/user/cluster/cluster.diviner index 10f8e98e4c..c7d22d2110 100644 --- a/src/docs/user/cluster/cluster.diviner +++ b/src/docs/user/cluster/cluster.diviner @@ -62,10 +62,10 @@ This option should contain a list of network address blocks which are considered to be part of the cluster. Hosts in this list are allowed to bend (or even break) some of the security and policy rules when they make requests to other hosts in the cluster, so this list should be as small as possible. See "Cluster -Whitelist Security" below for discussion. +Allowlist Security" below for discussion. If you are deploying hardware in EC2, a reasonable approach is to launch a -dedicated Phorge VPC, whitelist the whole VPC as a Phorge cluster, +dedicated Phorge VPC, put the whole VPC into the allowlist as a Phorge cluster, and then deploy only Phorge services into that VPC. If you have additional auxiliary hosts which run builds and tests via Drydock, @@ -77,7 +77,7 @@ Most other clustering features will not work until you define a cluster by configuring `cluster.addresses`. -Cluster Whitelist Security +Cluster Allowlist Security ======================== When you configure `cluster.addresses`, you should keep the list of trusted @@ -91,7 +91,7 @@ balancer is deployed. In particular, clients can set `X-Forwarded-For` to any value and spoof traffic from arbitrary remotes. These headers are trusted when they are received from a host on the cluster -address whitelist. This allows requests from cluster loadbalancers to be +address allowlist. This allows requests from cluster loadbalancers to be interpreted correctly by default without requiring additional custom code or configuration. @@ -117,7 +117,7 @@ the user within the cluster. These mechanisms are still authenticated (and use asymmetric keys, like SSH does), so access to a host in the cluster address block does not mean that an attacker can immediately compromise the cluster. However, an over-broad cluster -address whitelist may give an attacker who gains some access additional tools +address allowlist may give an attacker who gains some access additional tools to escalate access. Note that if an attacker gains access to an actual cluster host, these extra diff --git a/src/docs/user/configuration/configuring_inbound_email.diviner b/src/docs/user/configuration/configuring_inbound_email.diviner index 75338f149e..301461965c 100644 --- a/src/docs/user/configuration/configuring_inbound_email.diviner +++ b/src/docs/user/configuration/configuring_inbound_email.diviner @@ -198,7 +198,7 @@ https:///mail/postmark/ ``` See also the Postmark section in @{article:Configuring Outbound Email} for -discussion of the remote address whitelist used to verify that requests this +discussion of the remote address allowlist used to verify that requests this endpoint receives are authentic requests originating from Postmark. -- 2.51.2