1. 21 May, 2018 1 commit
  2. 11 Apr, 2018 1 commit
  3. 12 Sep, 2017 1 commit
    • Jeff King's avatar
      shell: drop git-cvsserver support by default · 9a42c03c
      Jeff King authored
      The git-cvsserver script is old and largely unmaintained
      these days. But git-shell allows untrusted users to run it
      out of the box, significantly increasing its attack surface.
      Let's drop it from git-shell's list of internal handlers so
      that it cannot be run by default.  This is not backwards
      compatible. But given the age and development activity on
      CVS-related parts of Git, this is likely to impact very few
      users, while helping many more (i.e., anybody who runs
      git-shell and had no intention of supporting CVS).
      There's no configuration mechanism in git-shell for us to
      add a boolean and flip it to "off". But there is a mechanism
      for adding custom commands, and adding CVS support here is
      fairly trivial. Let's document it to give guidance to
      anybody who really is still running cvsserver.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  4. 05 May, 2017 1 commit
    • Jeff King's avatar
      shell: disallow repo names beginning with dash · 3ec80449
      Jeff King authored
      When a remote server uses git-shell, the client side will
      connect to it like:
        ssh server "git-upload-pack 'foo.git'"
      and we literally exec ("git-upload-pack", "foo.git"). In
      early versions of upload-pack and receive-pack, we took a
      repository argument and nothing else. But over time they
      learned to accept dashed options. If the user passes a
      repository name that starts with a dash, the results are
      confusing at best (we complain of a bogus option instead of
      a non-existent repository) and malicious at worst (the user
      can start an interactive pager via "--help").
      We could pass "--" to the sub-process to make sure the
      user's argument is interpreted as a branch name. I.e.:
        git-upload-pack -- -foo.git
      But adding "--" automatically would make us inconsistent
      with a normal shell (i.e., when git-shell is not in use),
      where "-foo.git" would still be an error. For that case, the
      client would have to specify the "--", but they can't do so
      reliably, as existing versions of git-shell do not allow
      more than a single argument.
      The simplest thing is to simply disallow "-" at the start of
      the repo name argument. This hasn't worked either with or
      without git-shell since version 1.0.0, and nobody has
      Note that this patch just applies to do_generic_cmd(), which
      runs upload-pack, receive-pack, and upload-archive. There
      are two other types of commands that git-shell runs:
        - do_cvs_cmd(), but this already restricts the argument to
          be the literal string "server"
        - admin-provided commands in the git-shell-commands
          directory. We'll pass along arbitrary arguments there,
          so these commands could have similar problems. But these
          commands might actually understand dashed arguments, so
          we cannot just block them here. It's up to the writer of
          the commands to make sure they are safe. With great
          power comes great responsibility.
      Reported-by: BlueC0re's avatarTimo Schmid <tschmid@ernw.de>
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  5. 01 Jul, 2016 4 commits
    • Jeff King's avatar
      common-main: call git_setup_gettext() · 5ce5f5fa
      Jeff King authored
      This should be part of every program, as otherwise users do
      not get translated error messages. However, some external
      commands forgot to do so (e.g., git-credential-store). This
      fixes them, and eliminates the repeated code in programs
      that did remember to use it.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      common-main: call sanitize_stdfds() · 57f5d52a
      Jeff King authored
      This is setup that should be done in every program for
      safety, but we never got around to adding it everywhere (so
      builtins benefited from the call in git.c, but any external
      commands did not). Putting it in the common main() gives us
      this safety everywhere.
      Note that the case in daemon.c is a little funny. We wait
      until we know whether we want to daemonize, and then either:
       - call daemonize(), which will close stdio and reopen it to
         /dev/null under the hood
       - sanitize_stdfds(), to fix up any odd cases
      But that is way too late; the point of sanitizing is to give
      us reliable descriptors on 0/1/2, and we will already have
      executed code, possibly called die(), etc. The sanitizing
      should be the very first thing that happens.
      With this patch, git-daemon will sanitize first, and can
      remove the call in the non-daemonize case. It does mean that
      daemonize() may just end up closing the descriptors we
      opened, but that's not a big deal (it's not wrong to do so,
      nor is it really less optimal than the case where our parent
      process redirected us from /dev/null ahead of time).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      common-main: call git_extract_argv0_path() · 650c4492
      Jeff King authored
      Every program which links against libgit.a must call this
      function, or risk hitting an assert() in system_path() that
      checks whether we have configured argv0_path (though only
      when RUNTIME_PREFIX is defined, so essentially only on
      Looking at the diff, you can see that putting it into the
      common main() saves us having to do it individually in each
      of the external commands. But what you can't see are the
      cases where we _should_ have been doing so, but weren't
      (e.g., git-credential-store, and all of the t/helper test
      This has been an accident-waiting-to-happen for a long time,
      but wasn't triggered until recently because it involves one
      of those programs actually calling system_path(). That
      happened with git-credential-store in v2.8.0 with ae5f6776
      (lazily load core.sharedrepository, 2016-03-11). The
        - takes a lock file, which...
        - opens a tempfile, which...
        - calls adjust_shared_perm to fix permissions, which...
        - lazy-loads the config (as of ae5f6776), which...
        - calls system_path() to find the location of
      On systems with RUNTIME_PREFIX, this means credential-store
      reliably hits that assert() and cannot be used.
      We never noticed in the test suite, because we set
      GIT_CONFIG_NOSYSTEM there, which skips the system_path()
      lookup entirely.  But if we were to tweak git_config() to
      find /etc/gitconfig even when we aren't going to open it,
      then the test suite shows multiple failures (for
      credential-store, and for some other test helpers). I didn't
      include that tweak here because it's way too specific to
      this particular call to be worth carrying around what is
      essentially dead code.
      The implementation is fairly straightforward, with one
      exception: there is exactly one caller (git.c) that actually
      cares about the result of the function, and not the
      side-effect of setting up argv0_path. We can accommodate
      that by simply replacing the value of argv[0] in the array
      we hand down to cmd_main().
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      add an extra level of indirection to main() · 3f2e2297
      Jeff King authored
      There are certain startup tasks that we expect every git
      process to do. In some cases this is just to improve the
      quality of the program (e.g., setting up gettext()). In
      others it is a requirement for using certain functions in
      libgit.a (e.g., system_path() expects that you have called
      Most commands are builtins and are covered by the git.c
      version of main(). However, there are still a few external
      commands that use their own main(). Each of these has to
      remember to include the correct startup sequence, and we are
      not always consistent.
      Rather than just fix the inconsistencies, let's make this
      harder to get wrong by providing a common main() that can
      run this standard startup.
      We basically have two options to do this:
       - the compat/mingw.h file already does something like this by
         adding a #define that replaces the definition of main with a
         wrapper that calls mingw_startup().
         The upside is that the code in each program doesn't need
         to be changed at all; it's rewritten on the fly by the
         The downside is that it may make debugging of the startup
         sequence a bit more confusing, as the preprocessor is
         quietly inserting new code.
       - the builtin functions are all of the form cmd_foo(),
         and git.c's main() calls them.
         This is much more explicit, which may make things more
         obvious to somebody reading the code. It's also more
         flexible (because of course we have to figure out _which_
         cmd_foo() to call).
         The downside is that each of the builtins must define
         cmd_foo(), instead of just main().
      This patch chooses the latter option, preferring the more
      explicit approach, even though it is more invasive. We
      introduce a new file common-main.c, with the "real" main. It
      expects to call cmd_main() from whatever other objects it is
      linked against.
      We link common-main.o against anything that links against
      libgit.a, since we know that such programs will need to do
      this setup. Note that common-main.o can't actually go inside
      libgit.a, as the linker would not pick up its main()
      function automatically (it has no callers).
      The rest of the patch is just adjusting all of the various
      external programs (mostly in t/helper) to use cmd_main().
      I've provided a global declaration for cmd_main(), which
      means that all of the programs also need to match its
      signature. In particular, many functions need to switch to
      "const char **" instead of "char **" for argv. This effect
      ripples out to a few other variables and functions, as well.
      This makes the patch even more invasive, but the end result
      is much better. We should be treating argv strings as const
      anyway, and now all programs conform to the same signature
      (which also matches the way builtins are defined).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  6. 15 Jan, 2016 1 commit
    • Junio C Hamano's avatar
      strbuf: introduce strbuf_getline_{lf,nul}() · 8f309aeb
      Junio C Hamano authored
      The strbuf_getline() interface allows a byte other than LF or NUL as
      the line terminator, but this is only because I wrote these
      codepaths anticipating that there might be a value other than NUL
      and LF that could be useful when I introduced line_termination long
      time ago.  No useful caller that uses other value has emerged.
      By now, it is clear that the interface is overly broad without a
      good reason.  Many codepaths have hardcoded preference to read
      either LF terminated or NUL terminated records from their input, and
      then call strbuf_getline() with LF or NUL as the third parameter.
      This step introduces two thin wrappers around strbuf_getline(),
      namely, strbuf_getline_lf() and strbuf_getline_nul(), and
      mechanically rewrites these call sites to call either one of
      them.  The changes contained in this patch are:
       * introduction of these two functions in strbuf.[ch]
       * mechanical conversion of all callers to strbuf_getline() with
         either '\n' or '\0' as the third parameter to instead call the
         respective thin wrapper.
      After this step, output from "git grep 'strbuf_getline('" would
      become a lot smaller.  An interim goal of this series is to make
      this an empty set, so that we can have strbuf_getline_crlf() take
      over the shorter name strbuf_getline().
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  7. 19 Jun, 2014 1 commit
  8. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      The change can be recreated by mechanically applying this:
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  9. 17 Jul, 2013 1 commit
  10. 10 Mar, 2013 1 commit
    • Jonathan Nieder's avatar
      shell: new no-interactive-login command to print a custom message · 35297089
      Jonathan Nieder authored
      If I disable git-shell's interactive mode by removing the
      ~/git-shell-commands directory, attempts to ssh in to the service
      produce a message intended for the administrator:
      	$ ssh git@myserver
      	fatal: Interactive git shell is not enabled.
      	hint: ~/git-shell-commands should exist and have read and execute access.
      That is helpful for the new admin who is wondering "What? Why isn't
      the git-shell I just set up working?", but once the site setup is
      complete, it would be better to give the user a friendly hint that she
      is on the right track, like GitHub does.
      	Hi <username>! You've successfully authenticated, but
      	GitHub does not provide shell access.
      An appropriate greeting might even include more complex dynamic
      information, like gitolite's list of repositories the user has access
      to.  Add support for a ~/git-shell-commands/no-interactive-login
      command that generates an arbitrary greeting.  When the user tries to
      log in:
       * If the file ~/git-shell-commands/no-interactive-login exists,
         run no-interactive-login to let the server say what it likes,
         then hang up.
       * Otherwise, if ~/git-shell-commands/ is present, start an
         interactive read-eval-print loop.
       * Otherwise, print the usual configuration hint and hang up.
      Reported-by: Ethan Reesor's avatarEthan Reesor <firelizzard@gmail.com>
      Signed-off-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Improved-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  11. 06 Dec, 2011 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      i18n: add infrastructure for translating Git with gettext · 5e9637c6
      Ævar Arnfjörð Bjarmason authored
      Change the skeleton implementation of i18n in Git to one that can show
      localized strings to users for our C, Shell and Perl programs using
      either GNU libintl or the Solaris gettext implementation.
      This new internationalization support is enabled by default. If
      gettext isn't available, or if Git is compiled with
      NO_GETTEXT=YesPlease, Git falls back on its current behavior of
      showing interface messages in English. When using the autoconf script
      we'll auto-detect if the gettext libraries are installed and act
      This change is somewhat large because as well as adding a C, Shell and
      Perl i18n interface we're adding a lot of tests for them, and for
      those tests to work we need a skeleton PO file to actually test
      translations. A minimal Icelandic translation is included for this
      purpose. Icelandic includes multi-byte characters which makes it easy
      to test various edge cases, and it's a language I happen to
      The rest of the commit message goes into detail about various
      sub-parts of this commit.
      = Installation
      Gettext .mo files will be installed and looked for in the standard
      $(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
      override that, but that's only intended to be used to test Git itself.
      = Perl
      Perl code that's to be localized should use the new Git::I18n
      module. It imports a __ function into the caller's package by default.
      Instead of using the high level Locale::TextDomain interface I've
      opted to use the low-level (equivalent to the C interface)
      Locale::Messages module, which Locale::TextDomain itself uses.
      Locale::TextDomain does a lot of redundant work we don't need, and
      some of it would potentially introduce bugs. It tries to set the
      $TEXTDOMAIN based on package of the caller, and has its own
      hardcoded paths where it'll search for messages.
      I found it easier just to completely avoid it rather than try to
      circumvent its behavior. In any case, this is an issue wholly
      internal Git::I18N. Its guts can be changed later if that's deemed
      See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
      a further elaboration on this topic.
      = Shell
      Shell code that's to be localized should use the git-sh-i18n
      library. It's basically just a wrapper for the system's gettext.sh.
      If gettext.sh isn't available we'll fall back on gettext(1) if it's
      available. The latter is available without the former on Solaris,
      which has its own non-GNU gettext implementation. We also need to
      emulate eval_gettext() there.
      If neither are present we'll use a dumb printf(1) fall-through
      = About libcharset.h and langinfo.h
      We use libcharset to query the character set of the current locale if
      it's available. I.e. we'll use it instead of nl_langinfo if
      HAVE_LIBCHARSET_H is set.
      The GNU gettext manual recommends using langinfo.h's
      nl_langinfo(CODESET) to acquire the current character set, but on
      systems that have libcharset.h's locale_charset() using the latter is
      either saner, or the only option on those systems.
      GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
      but MinGW and some others need to use libcharset.h's locale_charset()
      This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
      did the initial Makefile / C work, and a lot of comments from the Git
      mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
      Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
      [jc: squashed a small Makefile fix from Ramsay]
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: 's avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  12. 05 May, 2011 1 commit
  13. 27 Aug, 2010 1 commit
  14. 24 Aug, 2010 1 commit
  15. 12 Aug, 2010 2 commits
  16. 27 Jun, 2009 1 commit
  17. 11 Apr, 2009 1 commit
  18. 30 Aug, 2008 1 commit
  19. 29 Aug, 2008 1 commit
    • Paolo Bonzini's avatar
      make git-shell paranoid about closed stdin/stdout/stderr · 0cfeed2e
      Paolo Bonzini authored
      It is in general unsafe to start a program with one or more of file
      descriptors 0/1/2 closed.  Karl Chen for example noticed that stat_command
      does this in order to rename a pipe file descriptor to 0:
          dup2(from, 0);
      ... but if stdin was closed (for example) from == 0, so that
          dup2(0, 0);
      just ends up closing the pipe.  Another extremely rare but nasty problem
      would occur if an "important" file ends up in file descriptor 2, and is
      corrupted by a call to die().
      Fixing this in git was considered to be overkill, so this patch works
      around it only for git-shell.  The fix is simply to open all the "low"
      descriptors to /dev/null in main.
      Signed-off-by: Paolo Bonzini's avatarPaolo Bonzini <bonzini@gnu.org>
      Acked-by: 's avatarStephen R. van den Berg <srb@cuci.nl>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  20. 26 Aug, 2008 1 commit
    • Junio C Hamano's avatar
      Revert "Build-in "git-shell"" · 1e7abc59
      Junio C Hamano authored
      This reverts commit daa0cc9a.
      It was a stupid idea to do this; when run as a log-in shell,
      it is spawned with argv[0] set to "-git-shell", so the usual
      name-based dispatch would not work to begin with.
  21. 20 Aug, 2008 2 commits
  22. 26 Jul, 2008 1 commit
  23. 28 Jun, 2008 1 commit
    • Dmitry Potapov's avatar
      shrink git-shell by avoiding redundant dependencies · 5b8e6f85
      Dmitry Potapov authored
      A lot of modules that have nothing to do with git-shell functionality
      were linked in, bloating git-shell more than 8 times.
      This patch cuts off redundant dependencies by:
      1. providing stubs for three functions that make no sense for git-shell;
      2. moving quote_path_fully from environment.c to quote.c to make the
         later self sufficient;
      3. moving make_absolute_path into a new separate file.
      The following numbers have been received with the default optimization
      settings on master using GCC 4.1.2:
         text    data     bss     dec     hex filename
       143915    1348   93168  238431   3a35f git-shell
         text    data     bss     dec     hex filename
        17670     788    8232   26690    6842 git-shell
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  24. 26 Jun, 2008 1 commit
  25. 24 Jun, 2008 1 commit
  26. 30 Oct, 2007 1 commit
  27. 16 Oct, 2007 1 commit
  28. 21 Feb, 2007 1 commit
    • Junio C Hamano's avatar
      Mechanical conversion to use prefixcmp() · cc44c765
      Junio C Hamano authored
      This mechanically converts strncmp() to use prefixcmp(), but only when
      the parameters match specific patterns, so that they can be verified
      easily.  Leftover from this will be fixed in a separate step, including
      idiotic conversions like
          if (!strncmp("foo", arg, 3))
          if (!(-prefixcmp(arg, "foo")))
      This was done by using this script in px.perl
         #!/usr/bin/perl -i.bak -p
         if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
                 s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
         if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
                 s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
      and running:
         $ git grep -l strncmp -- '*.c' | xargs perl px.perl
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
  29. 05 Mar, 2006 1 commit
    • Junio C Hamano's avatar
      Const tightening. · 9201c707
      Junio C Hamano authored
      Mark Wooding noticed there was a type mismatch warning in git.c; this
      patch does things slightly differently (mostly tightening const) and
      was what I was holding onto, waiting for the setup-revisions change
      to be merged into the master branch.
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
  30. 14 Jan, 2006 1 commit
    • Michal Ostrowski's avatar
      Exec git programs without using PATH. · 77cb17e9
      Michal Ostrowski authored
      The git suite may not be in PATH (and thus programs such as
      git-send-pack could not exec git-rev-list).  Thus there is a need for
      logic that will locate these programs.  Modifying PATH is not
      desirable as it result in behavior differing from the user's
      intentions, as we may end up prepending "/usr/bin" to PATH.
      - git C programs will use exec*_git_cmd() APIs to exec sub-commands.
      - exec*_git_cmd() will execute a git program by searching for it in
        the following directories:
      	1. --exec-path (as used by "git")
      	2. The GIT_EXEC_PATH environment variable.
      	3. $(gitexecdir) as set in Makefile (default value $(bindir)).
      - git wrapper will modify PATH as before to enable shell scripts to
        invoke "git-foo" commands.
      Ideally, shell scripts should use the git wrapper to become independent
      of PATH, and then modifying PATH will not be necessary.
      [jc: with minor updates after a brief review.]
      Signed-off-by: 's avatarMichal Ostrowski <mostrows@watson.ibm.com>
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
  31. 26 Nov, 2005 1 commit
  32. 24 Oct, 2005 1 commit
    • Linus Torvalds's avatar
      Add git-shell. · 35eb2d36
      Linus Torvalds authored
      This adds a very git specific restricted shell, that can be
      added to /etc/shells and set to the pw_shell in the /etc/passwd
      file, to give users ability to push into repositories over ssh
      without giving them full interactive shell acount.
      [jc: I updated Linus' patch to match what the current sq_quote()
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>