summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-11-27t/lib-git-daemon: fix signal checkingLibravatar SZEDER Gábor1-1/+1
Test scripts checking 'git daemon' stop the daemon with a TERM signal, and the 'stop_git_daemon' helper checks the daemon's exit status to make sure that it indeed died because of that signal. This check is bogus since 03c39b3458 (t/lib-git-daemon: use test_match_signal, 2016-06-24), for two reasons: - Right after killing 'git daemon', 'stop_git_daemon' saves its exit status in a variable, but since 03c39b3458 the condition checking the exit status looks at '$?', which at this point is not the exit status of 'git daemon', but that of the variable assignment, i.e. it's always 0. - The unexpected exit status should abort the whole test script with 'error', but it doesn't, because 03c39b3458 forgot to negate 'test_match_signal's exit status in the condition. This patch fixes both issues. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27Git 2.18.1Libravatar Junio C Hamano3-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27Sync with 2.17.2Libravatar Junio C Hamano9-0/+142
* maint-2.17: Git 2.17.2 fsck: detect submodule paths starting with dash fsck: detect submodule urls starting with dash Git 2.16.5 Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options
2018-09-27Git 2.17.2Libravatar Junio C Hamano3-2/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27fsck: detect submodule paths starting with dashLibravatar Jeff King2-0/+15
As with urls, submodule paths with dashes are ignored by git, but may end up confusing older versions. Detecting them via fsck lets us prevent modern versions of git from being a vector to spread broken .gitmodules to older versions. Compared to blocking leading-dash urls, though, this detection may be less of a good idea: 1. While such paths provide confusing and broken results, they don't seem to actually work as option injections against anything except "cd". In particular, the submodule code seems to canonicalize to an absolute path before running "git clone" (so it passes /your/clone/-sub). 2. It's more likely that we may one day make such names actually work correctly. Even after we revert this fsck check, it will continue to be a hassle until hosting servers are all updated. On the other hand, it's not entirely clear that the behavior in older versions is safe. And if we do want to eventually allow this, we may end up doing so with a special syntax anyway (e.g., writing "./-sub" in the .gitmodules file, and teaching the submodule code to canonicalize it when comparing). So on balance, this is probably a good protection. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27fsck: detect submodule urls starting with dashLibravatar Jeff King2-0/+22
Urls with leading dashes can cause mischief on older versions of Git. We should detect them so that they can be rejected by receive.fsckObjects, preventing modern versions of git from being a vector by which attacks can spread. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27Sync with 2.16.5Libravatar Junio C Hamano7-0/+93
* maint-2.16: Git 2.16.5 Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options
2018-09-27Git 2.16.5Libravatar Junio C Hamano3-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27Sync with 2.15.3Libravatar Junio C Hamano6-0/+87
* maint-2.15: Git 2.15.3 Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options
2018-09-27Git 2.15.3Libravatar Junio C Hamano3-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27Sync with Git 2.14.4Libravatar Junio C Hamano5-0/+81
* maint-2.14: Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options
2018-09-27Git 2.14.5Libravatar Junio C Hamano3-2/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27submodule-config: ban submodule paths that start with a dashLibravatar Jeff King2-0/+22
We recently banned submodule urls that look like command-line options. This is the matching change to ban leading-dash paths. As with the urls, this should not break any use cases that currently work. Even with our "--" separator passed to git-clone, git-submodule.sh gets confused. Without the code portion of this patch, the clone of "-sub" added in t7417 would yield results like: /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s Fetched in submodule path '-sub', but it did not contain b56243f8f4eb91b2f1f8109452e659f14dd3fbe4. Direct fetching of that commit failed. Moreover, naively adding such a submodule doesn't work: $ git submodule add $url -sub The following path is ignored by one of your .gitignore files: -sub even though there is no such ignore pattern (the test script hacks around this with a well-placed "git mv"). Unlike leading-dash urls, though, it's possible that such a path _could_ be useful if we eventually made it work. So this commit should be seen not as recommending a particular policy, but rather temporarily closing off a broken and possibly dangerous code-path. We may revisit this decision later. There are two minor differences to the tests in t7416 (that covered urls): 1. We don't have a "./-sub" escape hatch to make this work, since the submodule code expects to be able to match canonical index names to the path field (so you are free to add submodule config with that path, but we would never actually use it, since an index entry would never start with "./"). 2. After this patch, cloning actually succeeds. Since we ignore the submodule.*.path value, we fail to find a config stanza for our submodule at all, and simply treat it as inactive. We still check for the "ignoring" message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27submodule-config: ban submodule urls that start with dashLibravatar Jeff King2-0/+42
The previous commit taught the submodule code to invoke our "git clone $url $path" with a "--" separator so that we aren't confused by urls or paths that start with dashes. However, that's just one code path. It's not clear if there are others, and it would be an easy mistake to add one in the future. Moreover, even with the fix in the previous commit, it's quite hard to actually do anything useful with such an entry. Any url starting with a dash must fall into one of three categories: - it's meant as a file url, like "-path". But then any clone is not going to have the matching path, since it's by definition relative inside the newly created clone. If you spell it as "./-path", the submodule code sees the "/" and translates this to an absolute path, so it at least works (assuming the receiver has the same filesystem layout as you). But that trick does not apply for a bare "-path". - it's meant as an ssh url, like "-host:path". But this already doesn't work, as we explicitly disallow ssh hostnames that begin with a dash (to avoid option injection against ssh). - it's a remote-helper scheme, like "-scheme::data". This _could_ work if the receiver bends over backwards and creates a funny-named helper like "git-remote--scheme". But normally there would not be any helper that matches. Since such a url does not work today and is not likely to do anything useful in the future, let's simply disallow them entirely. That protects the existing "git clone" path (in a belt-and-suspenders way), along with any others that might exist. Our tests cover two cases: 1. A file url with "./" continues to work, showing that there's an escape hatch for people with truly silly repo names. 2. A url starting with "-" is rejected. Note that we expect case (2) to fail, but it would have done so even without this commit, for the reasons given above. So instead of just expecting failure, let's also check for the magic word "ignoring" on stderr. That lets us know that we failed for the right reason. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27submodule--helper: use "--" to signal end of clone optionsLibravatar Jeff King1-0/+1
When we clone a submodule, we call "git clone $url $path". But there's nothing to say that those components can't begin with a dash themselves, confusing git-clone into thinking they're options. Let's pass "--" to make it clear what we expect. There's no test here, because it's actually quite hard to make these names work, even with "git clone" parsing them correctly. And we're going to restrict these cases even further in future commits. So we'll leave off testing until then; this is just the minimal fix to prevent us from doing something stupid with a badly formed entry. Reported-by: joernchen <joernchen@phenoelit.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-21Git 2.18Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19Merge branch 'en/rename-directory-detection-reboot'Libravatar Junio C Hamano0-0/+0
* en/rename-directory-detection-reboot: merge-recursive: use xstrdup() instead of fixed buffer
2018-06-19Merge tag 'l10n-2.18.0-rnd3.1' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano2-2522/+3541
Merge Korean translation for l10n of Git 2.18.0 round 3 * tag 'l10n-2.18.0-rnd3.1' of git://github.com/git-l10n/git-po: l10n: ko.po: Update Korean translation
2018-06-19Merge branch 'cf/submodule-progress-dissociate'Libravatar Junio C Hamano1-2/+4
* cf/submodule-progress-dissociate: t7400: encapsulate setup code in test_expect_success
2018-06-19Merge branch 'js/rebase-i-root-fix'Libravatar Junio C Hamano1-1/+2
* js/rebase-i-root-fix: t3404: check root commit in 'rebase -i --root reword root commit'
2018-06-19t7400: encapsulate setup code in test_expect_successLibravatar Stefan Beller1-2/+4
When running t7400 in a shell you observe more output than expected: ... ok 8 - setup - hide init subdirectory ok 9 - setup - repository to add submodules to ok 10 - submodule add [master (root-commit) d79ce16] one Author: A U Thor <author@example.com> 1 file changed, 1 insertion(+) create mode 100644 one.t ok 11 - redirected submodule add does not show progress ok 12 - redirected submodule add --progress does show progress ok 13 - submodule add to .gitignored path fails ... Fix the output by encapsulating the setup code in test_expect_success Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19t3404: check root commit in 'rebase -i --root reword root commit'Libravatar Todd Zullinger1-1/+2
When testing a reworded root commit, ensure that the squash-onto commit which is created and amended is still the root commit. Suggested-by: Phillip Wood <phillip.wood@talktalk.net> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19doc: fix typos in documentation and release notesLibravatar Karthikeyan Singaravelan4-4/+4
Signed-off-by: Karthikeyan Singaravelan <tir.karthi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18Almost 2.18 finalLibravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18Merge branch 'es/make-no-iconv'Libravatar Junio C Hamano1-10/+12
"make NO_ICONV=NoThanks" did not override NEEDS_LIBICONV (i.e. linkage of -lintl, -liconv, etc. that are platform-specific tweaks), which has been corrected. * es/make-no-iconv: Makefile: make NO_ICONV really mean "no iconv"
2018-06-18Merge branch 'sg/t7406-chain-fix'Libravatar Junio C Hamano1-6/+6
Test fix. * sg/t7406-chain-fix: t7406-submodule-update: fix broken &&-chains
2018-06-18Merge branch 'ks/branch-set-upstream'Libravatar Junio C Hamano1-1/+1
A test title has been reworded to clarify it. * ks/branch-set-upstream: t3200: clarify description of --set-upstream test
2018-06-18Merge branch 'js/rebase-i-root-fix'Libravatar Junio C Hamano2-1/+10
A regression to "rebase -i --root" introduced during this cycle has been fixed. * js/rebase-i-root-fix: rebase --root: fix amending root commit messages rebase --root: demonstrate a bug while amending root commit messages
2018-06-18Merge branch 'jk/ewah-bounds-check'Libravatar Junio C Hamano5-7/+38
The code to read compressed bitmap was not careful to avoid reading past the end of the file, which has been corrected. * jk/ewah-bounds-check: ewah: adjust callers of ewah_read_mmap() ewah_read_mmap: bounds-check mmap reads
2018-06-18Merge tag 'l10n-2.18.0-rnd3' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano10-17929/+26095
l10n for Git 2.18.0 round 3 * tag 'l10n-2.18.0-rnd3' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.18.0 l10n round 1 to 3 l10n: bg.po: Updated Bulgarian translation (3608t) l10n: vi.po(3608t): Update Vietnamese translation for v2.18.0 round 3 l10n: fr.po v2.18.0 round 3 l10n: es.po: Spanish update for v2.18.0 round 3 l10n: git.pot: v2.18.0 round 3 (1 new, 1 removed) l10n: vi.po(3608t): Update Vietnamese translation for v2.18.0 round2 l10n: bg.po: Updated Bulgarian translation (3608t) l10n: es.po: Spanish update for v2.18.0 round 2 l10n: sv.po: Update Swedish translation (3608t0f0u) l10n: sv.po: Update Swedish translation (3470t0f0u) l10n: git.pot: v2.18.0 round 2 (144 new, 6 removed) l10n: fr.po v2.18 round 1 l10n: vi(3470t): Updated Vietnamese translation for v2.18.0 l10n: es.po: Spanish update for v2.18.0 round 1 l10n: git.pot: v2.18.0 round 1 (108 new, 14 removed) l10n: TEAMS: remove inactive de team members l10n: de.po: fix typos l10n: Update Catalan translation
2018-06-18A bunch of micro-fixes before going 2.18 finalLibravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19l10n: ko.po: Update Korean translationLibravatar Changwoo Ryu2-2522/+3541
Update the Korean translation and change the team leader to Gwan-gyeong Mun. Signed-off-by: Gwan-gyeong Mun <elongbug@gmail.com> Signed-off-by: Changwoo Ryu <cwryu@debian.org> Reviewed-by: Gwan-gyeong Mun <elongbug@gmail.com>
2018-06-18Merge branch 'sb/blame-color'Libravatar Junio C Hamano1-0/+1
Leakfix. * sb/blame-color: blame: release string_list after use in parse_color_fields()
2018-06-18Merge branch 'mw/doc-merge-enumfix'Libravatar Junio C Hamano1-1/+1
Fix old merge glitch in Documentation during v2.13-rc0 era. * mw/doc-merge-enumfix: doc: update the order of the syntax `git merge --continue`
2018-06-18Merge branch 'en/rename-directory-detection'Libravatar Junio C Hamano1-5/+5
Newly added codepath in merge-recursive had potential buffer overrun, which has been fixed. * en/rename-directory-detection: merge-recursive: use xstrdup() instead of fixed buffer
2018-06-18Merge branch 'rd/doc-remote-tracking-with-hyphen'Libravatar Junio C Hamano3-5/+5
Doc update. * rd/doc-remote-tracking-with-hyphen: Use hyphenated "remote-tracking branch" (docs and comments)
2018-06-18Merge branch 'jl/zlib-restore-nul-termination'Libravatar Junio C Hamano1-0/+3
Make zlib inflate codepath more robust against versions of zlib that clobber unused portion of outbuf. * jl/zlib-restore-nul-termination: packfile: correct zlib buffer handling
2018-06-18Merge branch 'ab/cred-netrc-no-autodie'Libravatar Junio C Hamano1-1/+0
Hotfix for contrib/ stuff broken by this cycle. * ab/cred-netrc-no-autodie: git-credential-netrc: remove use of "autodie"
2018-06-18Merge branch 'km/doc-workflows-typofix'Libravatar Junio C Hamano1-1/+1
Typofix. * km/doc-workflows-typofix: gitworkflows: fix grammar in 'Merge upwards' rule
2018-06-18Merge branch 'ld/git-p4-updates'Libravatar Junio C Hamano5-24/+307
"git p4" updates. * ld/git-p4-updates: git-p4: auto-size the block git-p4: narrow the scope of exceptions caught when parsing an int git-p4: raise exceptions from p4CmdList based on error from p4 server git-p4: better error reporting when p4 fails git-p4: add option to disable syncing of p4/master with p4 git-p4: disable-rebase: allow setting this via configuration git-p4: add options --commit and --disable-rebase
2018-06-18Merge branch 'rd/diff-options-typofix'Libravatar Junio C Hamano1-4/+4
Typofix. * rd/diff-options-typofix: diff-options.txt: fix minor typos, font inconsistencies, in docs
2018-06-18Merge branch 'rd/comment-typofix-in-sha1-file'Libravatar Junio C Hamano1-1/+1
In code comment typofix * rd/comment-typofix-in-sha1-file: sha1-file.c: correct $GITDIR to $GIT_DIR in a comment
2018-06-18merge-recursive: use xstrdup() instead of fixed bufferLibravatar René Scharfe1-5/+5
Paths can be longer than PATH_MAX. Avoid a buffer overrun in check_dir_renamed() by using xstrdup() to make a private copy safely. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18RelNotes 2.18: minor fix to entry about dynamically loading completionsLibravatar SZEDER Gábor1-1/+1
It was not "newer versions of bash" but newer versions of bash-completion that made commit 085e2ee0e6 (completion: load completion file for external subcommand, 2018-04-29) both necessary and possible. Update the corresponding RelNotes entry accordingly. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18t7406-submodule-update: fix broken &&-chainsLibravatar SZEDER Gábor1-6/+6
Three tests in 't7406-submodule-update' contain broken &&-chains, but since they are all in subshells, chain-lint couldn't notice them. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18rebase --root: fix amending root commit messagesLibravatar Johannes Schindelin2-2/+2
The code path that triggered that "BUG" really does not want to run without an explicit commit message. In the case where we want to amend a commit message, we have an *implicit* commit message, though: the one of the commit to amend. Therefore, this code path should not even be entered. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18rebase --root: demonstrate a bug while amending root commit messagesLibravatar Todd Zullinger1-0/+9
When splitting a repository, running `git rebase -i --root` to reword the initial commit, Git dies with BUG: sequencer.c:795: root commit without message. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18ewah: adjust callers of ewah_read_mmap()Libravatar Jeff King2-2/+3
The return value of ewah_read_mmap() is now an ssize_t, since we could (in theory) process up to 32GB of data. This would never happen in practice, but a corrupt or malicious .bitmap or index file could convince us to do so. Let's make sure that we don't stuff the value into an int, which would cause us to incorrectly move our pointer forward. We'd always move too little, since negative values are used for reporting errors. So the worst case is just that we end up reporting a corrupt file, not an out-of-bounds read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18ewah_read_mmap: bounds-check mmap readsLibravatar Jeff King3-5/+35
The on-disk ewah format tells us how big the ewah data is, and we blindly read that much from the buffer without considering whether the mmap'd data is long enough, which can lead to out-of-bound reads. Let's make sure we have data available before reading it, both for the ewah header/footer as well as for the bit data itself. In particular: - keep our ptr/len pair in sync as we move through the buffer, and check it before each read - check the size for integer overflow (this should be impossible on 64-bit, as the size is given as a 32-bit count of 8-byte words, but is possible on a 32-bit system) - return the number of bytes read as an ssize_t instead of an int, again to prevent integer overflow - compute the return value using a pointer difference; this should yield the same result as the existing code, but makes it more obvious that we got our computations right The included test is far from comprehensive, as it just picks a static point at which to truncate the generated bitmap. But in practice this will hit in the middle of an ewah and make sure we're at least exercising this code. Reported-by: Luat Nguyen <root@l4w.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18t3200: clarify description of --set-upstream testLibravatar Kaartic Sivaraam1-1/+1
Support for the --set-upstream option was removed in 52668846ea (builtin/branch: stop supporting the "--set-upstream" option, 2017-08-17). The change did not completely remove the command due to an issue noted in the commit's log message. So, a test was added to ensure that a command which uses the '--set-upstream' option fails instead of silently acting as an alias for the '--set-upstream-to' option due to option parsing features. To avoid confusion, clarify that the option is disabled intentionally in the corresponding test description. The test is expected to be around as long as we intentionally fail on seeing the '--set-upstream' option which in turn we expect to do for a period of time after which we can be sure that existing users of '--set-upstream' are aware that the option is no longer supported. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>