git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com,
	Derrick Stolee <derrickstolee@github.com>,
	Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH 3/3] *: use allowlist and denylist
Date: Wed, 13 Jul 2022 15:27:02 +0200 (CEST)	[thread overview]
Message-ID: <r5351157-0p62-7rp4-p254-04rn0r63o515@tzk.qr> (raw)
In-Reply-To: <8aaceedb7a8f9d95550ef4a2d147c837ede6acec.1657718450.git.gitgitgadget@gmail.com>

Hi Stolee,

On Wed, 13 Jul 2022, Derrick Stolee via GitGitGadget wrote:

> From: Derrick Stolee <derrickstolee@github.com>
>
> Using "allowlist" and "denylist" is a more precise definition of the
> functionality they provide. The previous color-based words assume
> cultural interpretation to provide the meaning.
>
> These changes to the Git codebase are mostly cosmetic. Several comments
> are updated. The renamed protocol_allowlist() method is local to
> transport.c so does not update any header file API definition. There are
> some untranslated error messages that are reworded, so this _might_
> affect error parsers. However, two of the three error messages are
> around option parsing, so they are "fast failures". The one perhaps
> meaningful change is the logerror() in daemon.c.

I do consider `git daemon` less important these days because we have two
transports that are secure (which `git://` is not): HTTPS and SSH. That
suggests that the `daemon.c` change might have a very low impact to begin
with.

The other changes affect `cvsserver` which I consider even less important.
In fact, I would be in favor of deprecating it soon and of deleting it in
due time.

All the changes in this patch look good to me: ACK!

Thank you!
Dscho

>
> After this change, the only remaining uses of the previous words are
> in release notes for older versions of Git.
>
> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
> ---
>  daemon.c           |  8 ++++----
>  git-cvsserver.perl |  2 +-
>  sha1dc/sha1.c      | 12 ++++++------
>  transport.c        |  8 ++++----
>  4 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/daemon.c b/daemon.c
> index 58f1077885c..ed7c53b1110 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -279,7 +279,7 @@ static const char *path_ok(const char *directory, struct hostinfo *hi)
>  		/* The validation is done on the paths after enter_repo
>  		 * appends optional {.git,.git/.git} and friends, but
>  		 * it does not use getcwd().  So if your /pub is
> -		 * a symlink to /mnt/pub, you can whitelist /pub and
> +		 * a symlink to /mnt/pub, you can allowlist /pub and
>  		 * do not have to say /mnt/pub.
>  		 * Do not say /pub/.
>  		 */
> @@ -298,7 +298,7 @@ static const char *path_ok(const char *directory, struct hostinfo *hi)
>  			return path;
>  	}
>
> -	logerror("'%s': not in whitelist", path);
> +	logerror("'%s': not in allowlist", path);
>  	return NULL;		/* Fallthrough. Deny by default */
>  }
>
> @@ -403,7 +403,7 @@ static int run_service(const char *dir, struct daemon_service *service,
>  	 * a "git-daemon-export-ok" flag that says that the other side
>  	 * is ok with us doing this.
>  	 *
> -	 * path_ok() uses enter_repo() and does whitelist checking.
> +	 * path_ok() uses enter_repo() and does allowlist checking.
>  	 * We only need to make sure the repository is exported.
>  	 */
>
> @@ -1444,7 +1444,7 @@ int cmd_main(int argc, const char **argv)
>  		cred = prepare_credentials(user_name, group_name);
>
>  	if (strict_paths && (!ok_paths || !*ok_paths))
> -		die("option --strict-paths requires a whitelist");
> +		die("option --strict-paths requires a allowlist");
>
>  	if (base_path && !is_directory(base_path))
>  		die("base-path '%s' does not exist or is not a directory",
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index 4c8118010a8..7d13b0a5ac1 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -152,7 +152,7 @@ $state->{allowed_roots} = [ @ARGV ];
>
>  # don't export the whole system unless the users requests it
>  if ($state->{'export-all'} && !@{$state->{allowed_roots}}) {
> -    die "--export-all can only be used together with an explicit whitelist\n";
> +    die "--export-all can only be used together with an explicit allowlist\n";
>  }
>
>  # Environment handling for running under git-shell
> diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
> index dede2cbddf9..b4a5f23c1ec 100644
> --- a/sha1dc/sha1.c
> +++ b/sha1dc/sha1.c
> @@ -86,30 +86,30 @@
>         defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || \
>         defined(__sparc))
>  /*
> - * Should define Big Endian for a whitelist of known processors. See
> + * Should define Big Endian for a allowlist of known processors. See
>   * https://sourceforge.net/p/predef/wiki/Endianness/ and
>   * http://www.oracle.com/technetwork/server-storage/solaris/portingtosolaris-138514.html
>   */
>  #define SHA1DC_BIGENDIAN
>
> -/* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */
> +/* Not under GCC-alike or glibc or *BSD or newlib or <processor allowlist> */
>  #elif (defined(_AIX) || defined(__hpux))
>
>  /*
> - * Defines Big Endian on a whitelist of OSs that are known to be Big
> + * Defines Big Endian on a allowlist of OSs that are known to be Big
>   * Endian-only. See
>   * https://lore.kernel.org/git/93056823-2740-d072-1ebd-46b440b33d7e@felt.demon.nl/
>   */
>  #define SHA1DC_BIGENDIAN
>
> -/* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> */
> +/* Not under GCC-alike or glibc or *BSD or newlib or <processor allowlist> or <os allowlist> */
>  #elif defined(SHA1DC_ON_INTEL_LIKE_PROCESSOR)
>  /*
>   * As a last resort before we do anything else we're not 100% sure
> - * about below, we blacklist specific processors here. We could add
> + * about below, we denylist specific processors here. We could add
>   * more, see e.g. https://wiki.debian.org/ArchitectureSpecificsMemo
>   */
> -#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> or <processor blacklist> */
> +#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor allowlist> or <os allowlist> or <processor denylist> */
>
>  /* We do nothing more here for now */
>  /*#error "Uncomment this to see if you fall through all the detection"*/
> diff --git a/transport.c b/transport.c
> index 52db7a3cb09..321bbe382cc 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -940,7 +940,7 @@ static int external_specification_len(const char *url)
>  	return strchr(url, ':') - url;
>  }
>
> -static const struct string_list *protocol_whitelist(void)
> +static const struct string_list *protocol_allowlist(void)
>  {
>  	static int enabled = -1;
>  	static struct string_list allowed = STRING_LIST_INIT_DUP;
> @@ -1020,9 +1020,9 @@ static enum protocol_allow_config get_protocol_config(const char *type)
>
>  int is_transport_allowed(const char *type, int from_user)
>  {
> -	const struct string_list *whitelist = protocol_whitelist();
> -	if (whitelist)
> -		return string_list_has_string(whitelist, type);
> +	const struct string_list *allowlist = protocol_allowlist();
> +	if (allowlist)
> +		return string_list_has_string(allowlist, type);
>
>  	switch (get_protocol_config(type)) {
>  	case PROTOCOL_ALLOW_ALWAYS:
> --
> gitgitgadget
>

  reply	other threads:[~2022-07-13 13:27 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13 13:20 [PATCH 0/3] Use "allowlist" and "denylist" tree-wide Derrick Stolee via GitGitGadget
2022-07-13 13:20 ` [PATCH 1/3] Documentation: use allowlist and denylist Derrick Stolee via GitGitGadget
2022-07-13 15:21   ` Jeff King
2022-07-13 18:34     ` Derrick Stolee
2022-07-13 20:20   ` Junio C Hamano
2022-07-13 13:20 ` [PATCH 2/3] t/*: use allowlist Derrick Stolee via GitGitGadget
2022-07-13 13:20 ` [PATCH 3/3] *: use allowlist and denylist Derrick Stolee via GitGitGadget
2022-07-13 13:27   ` Johannes Schindelin [this message]
2022-07-13 15:23   ` Jeff King
2022-07-13 13:29 ` [PATCH 0/3] Use "allowlist" and "denylist" tree-wide Johannes Schindelin
2022-07-13 16:18 ` Junio C Hamano
2022-07-13 18:33   ` Derrick Stolee
2022-07-13 20:32     ` Junio C Hamano
2022-07-13 19:42 ` Ævar Arnfjörð Bjarmason
2022-07-13 22:28   ` Junio C Hamano
2022-07-15  2:25     ` Derrick Stolee
2022-07-13 20:02 ` Ævar Arnfjörð Bjarmason
2022-07-15  2:38 ` [PATCH v2 0/3] Remove use of "whitelist" Derrick Stolee via GitGitGadget
2022-07-15  2:38   ` [PATCH v2 1/3] Documentation: remove use of whitelist Derrick Stolee via GitGitGadget
2022-07-15 10:47     ` Ævar Arnfjörð Bjarmason
2022-07-19 14:21       ` Derrick Stolee
2022-07-15  2:38   ` [PATCH v2 2/3] t/*: avoid "whitelist" Derrick Stolee via GitGitGadget
2022-07-15 11:02     ` Ævar Arnfjörð Bjarmason
2022-07-19 15:09       ` Derrick Stolee
2022-07-19 15:26         ` Ævar Arnfjörð Bjarmason
2022-07-19 15:42           ` Derrick Stolee
2022-07-19 19:44         ` Junio C Hamano
2022-07-15  2:38   ` [PATCH v2 3/3] *: " Derrick Stolee via GitGitGadget
2022-07-15 11:19     ` Ævar Arnfjörð Bjarmason
2022-07-15  6:30   ` [PATCH v2 0/3] Remove use of "whitelist" Junio C Hamano
2022-07-15 16:16     ` Phillip Wood
2022-07-19 18:32   ` [PATCH v3 0/5] " Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 1/5] daemon: clarify directory arguments Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 2/5] git-cvsserver: clarify directory list Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 3/5] git.txt: remove redundant language Derrick Stolee via GitGitGadget
2022-07-31  0:35       ` Jeff King
2022-07-19 18:32     ` [PATCH v3 4/5] t: avoid "whitelist" Derrick Stolee via GitGitGadget
2022-07-19 18:32     ` [PATCH v3 5/5] transport.c: " Derrick Stolee via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=r5351157-0p62-7rp4-p254-04rn0r63o515@tzk.qr \
    --to=johannes.schindelin@gmx.de \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).