git/contrib, branch v2.44.4

Sync with 2.43.7

2025-05-28T18:47:12Z

* maint-2.43: Git 2.43.7 wincred: avoid buffer overflow in wcsncat() bundle-uri: fix arbitrary file writes via parameter injection config: quote values containing CR character git-gui: sanitize 'exec' arguments: convert new 'cygpath' calls git-gui: do not mistake command arguments as redirection operators git-gui: introduce function git_redir for git calls with redirections git-gui: pass redirections as separate argument to git_read git-gui: pass redirections as separate argument to _open_stdout_stderr git-gui: convert git_read*, git_write to be non-variadic git-gui: override exec and open only on Windows gitk: sanitize 'open' arguments: revisit recently updated 'open' calls git-gui: use git_read in githook_read git-gui: sanitize $PATH on all platforms git-gui: break out a separate function git_read_nice git-gui: assure PATH has only absolute elements. git-gui: remove option --stderr from git_read git-gui: cleanup git-bash menu item git-gui: sanitize 'exec' arguments: background git-gui: avoid auto_execok in do_windows_shortcut git-gui: sanitize 'exec' arguments: simple cases git-gui: avoid auto_execok for git-bash menu item git-gui: treat file names beginning with "|" as relative paths git-gui: remove unused proc is_shellscript git-gui: remove git config --list handling for git < 1.5.3 git-gui: remove special treatment of Windows from open_cmd_pipe git-gui: remove HEAD detachment implementation for git < 1.5.3 git-gui: use only the configured shell git-gui: remove Tcl 8.4 workaround on 2>@1 redirection git-gui: make _shellpath usable on startup git-gui: use [is_Windows], not bad _shellpath git-gui: _which, only add .exe suffix if not present gitk: encode arguments correctly with "open" gitk: sanitize 'open' arguments: command pipeline gitk: collect construction of blameargs into a single conditional gitk: sanitize 'open' arguments: simple commands, readable and writable gitk: sanitize 'open' arguments: simple commands with redirections gitk: sanitize 'open' arguments: simple commands gitk: sanitize 'exec' arguments: redirect to process gitk: sanitize 'exec' arguments: redirections and background gitk: sanitize 'exec' arguments: redirections gitk: sanitize 'exec' arguments: 'eval exec' gitk: sanitize 'exec' arguments: simple cases gitk: have callers of diffcmd supply pipe symbol when necessary gitk: treat file names beginning with "|" as relative paths Signed-off-by: Taylor Blau

wincred: avoid buffer overflow in wcsncat()

2025-05-28T16:57:36Z

The wincred credential helper uses a static buffer ("target") as a unique key for storing and comparing against internal storage. It does this by building up a string is supposed to look like: git:$PROTOCOL://$USERNAME@$HOST/@PATH However, the static "target" buffer is declared as a wide string with no more than 1,024 wide characters. The first call to wcsncat() is almost correct (it copies no more than ARRAY_SIZE(target) wchar_t's), but does not account for the trailing NUL, introducing an off-by-one error. But subsequent calls to wcsncat() have an additional problem on top of the off-by-one. They do not account for the length of the existing wide string being built up in 'target'. So the following: $ perl -e ' my $x = "x" x 1_000; print "protocol=$x\nhost=$x\nusername=$x\npath=$x\n" ' | C\:/Program\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe get will result in a segmentation fault from over-filling buffer. This bug is as old as the wincred helper itself, dating back to a6253da0f3 (contrib: add win32 credential-helper, 2012-07-27). Commit 8b2d219a3d (wincred: improve compatibility with windows versions, 2013-01-10) replaced the use of strncat() with wcsncat(), but retained the buggy behavior. Fix this by using a "target_append()" helper which accounts for both the length of the existing string within the buffer, as well as the trailing NUL character. Reported-by: David Leadbeater Helped-by: David Leadbeater Helped-by: Jeff King Signed-off-by: Taylor Blau

Merge branch 'pb/complete-config'

2024-02-14T23:36:06Z

The command line completion script (in contrib/) learned to complete configuration variable names better. * pb/complete-config: completion: add and use __git_compute_second_level_config_vars_for_section completion: add and use __git_compute_first_level_config_vars_for_section completion: complete 'submodule.*' config variables completion: add space after config variable names also in Bash 3

Merge branch 'bk/complete-bisect'

2024-02-12T21:16:10Z

Command line completion support (in contrib/) has been updated for "git bisect". * bk/complete-bisect: completion: bisect: recognize but do not complete view subcommand completion: bisect: complete log opts for visualize subcommand completion: new function __git_complete_log_opts completion: bisect: complete missing --first-parent and - -no-checkout options completion: bisect: complete custom terms and related options completion: bisect: complete bad, new, old, and help subcommands completion: tests: always use 'master' for default initial branch name

completion: add and use __git_compute_second_level_config_vars_for_section

2024-02-12T17:43:42Z

In a previous commit we removed some hardcoded config variable names from function __git_complete_config_variable_name in the completion script by introducing a new function, __git_compute_first_level_config_vars_for_section. The remaining hardcoded config variables are "second level" configuration variables, meaning 'branch..upstream', 'remote..url', etc. where is a user-defined name. Making use of the new existing --config flag to 'git help', add a new function, __git_compute_second_level_config_vars_for_section. This function takes as argument a config section name and computes the corresponding second-level config variables, i.e. those that contain a '<' which indicates the start of a placeholder. Note that as in __git_compute_first_level_config_vars_for_section added previsouly, we use indirect expansion instead of associative arrays to stay compatible with Bash 3 on which macOS is stuck for licensing reasons. As explained in the previous commit, we use the existing pattern in the completion script of using global variables to cache the list of variables for each section. Use this new function and the variables it defines in __git_complete_config_variable_name to remove hardcoded config variables, and add a test to verify the new function. Use a single 'case' for all sections with second-level variables names, since the code for each of them is now exactly the same. Adjust the name of a test added in a previous commit to reflect that it now tests the added function. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

completion: add and use __git_compute_first_level_config_vars_for_section

2024-02-12T17:43:42Z

The function __git_complete_config_variable_name in the Bash completion script hardcodes several config variable names. These variables are those in config sections where user-defined names can appear, such as "branch.". These sections are treated first by the case statement, and the two last "catch all" cases are used for other sections, making use of the __git_compute_config_vars and __git_compute_config_sections function, which omit listing any variables containing wildcards or placeholders. Having hardcoded config variables introduces the risk of the completion code becoming out of sync with the actual config variables accepted by Git. To avoid these hardcoded config variables, introduce a new function, __git_compute_first_level_config_vars_for_section, making use of the existing __git_config_vars variable. This function takes as argument a config section name and computes the matching "first level" config variables for that section, i.e. those _not_ containing any placeholder, like 'branch.autoSetupMerge, 'remote.pushDefault', etc. Use this function and the variables it defines in the 'branch.*', 'remote.*' and 'submodule.*' switches of the case statement instead of hardcoding the corresponding config variables. Note that we use indirect expansion to create a variable for each section, instead of using a single associative array indexed by section names, because associative arrays are not supported in Bash 3, on which macOS is stuck for licensing reasons. Use the existing pattern in the completion script of using global variables to cache the list of config variables for each section. The rationale for such caching is explained in eaa4e6ee2a (Speed up bash completion loading, 2009-11-17), and the current approach to using and defining them via 'test -n' is explained in cf0ff02a38 (completion: work around zsh option propagation bug, 2012-02-02). Adjust the name of one of the tests added in the previous commit, reflecting that it now also tests the new function. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

completion: complete 'submodule.*' config variables

2024-02-12T17:43:42Z

In the Bash completion script, function __git_complete_config_variable_name completes config variables and has special logic to deal with config variables involving user-defined names, like branch..* and remote..*. This special logic is missing for submodule-related config variables. Add the appropriate branches to the case statement, making use of the in-tree '.gitmodules' to list relevant submodules. Add corresponding tests in t9902-completion.sh, making sure we complete both first level submodule config variables as well as second level variables involving submodule names. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

completion: add space after config variable names also in Bash 3

2024-02-12T17:43:41Z

In be6444d1ca (completion: bash: add correct suffix in variables, 2021-08-16), __git_complete_config_variable_name was changed to use "${sfx- }" instead of "$sfx" as the fourth argument of _gitcomp_nl and _gitcomp_nl_append, such that this argument evaluates to a space if sfx is unset. This was to ensure that e.g. git config branch.autoSetupMe[TAB] correctly completes to 'branch.autoSetupMerge ' with the trailing space. This commits notes that the fix only works in Bash 4 because in Bash 3 the 'local sfx' construct at the beginning of __git_complete_config_variable_name creates an empty string. Make the fix also work for Bash 3 by using the "unset or null' parameter expansion syntax ("${sfx:- }"), such that the parameter is also expanded to a space if it is set but null, as is the behaviour of 'local sfx' in Bash 3. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano

Merge branch 'sh/completion-with-reftable' into maint-2.43

2024-02-09T00:22:04Z

Command line completion script (in contrib/) learned to work better with the reftable backend. * sh/completion-with-reftable: completion: support pseudoref existence checks for reftables completion: refactor existence checks for pseudorefs

Merge branch 'tz/send-email-negatable-options' into maint-2.43

2024-02-09T00:22:01Z

Newer versions of Getopt::Long started giving warnings against our (ab)use of it in "git send-email". Bump the minimum version requirement for Perl to 5.8.1 (from September 2002) to allow simplifying our implementation. * tz/send-email-negatable-options: send-email: avoid duplicate specification warnings perl: bump the required Perl version to 5.8.1 from 5.8.0