1. 21 May, 2018 1 commit
  2. 24 Apr, 2018 1 commit
  3. 16 Apr, 2018 1 commit
    • Duy Nguyen's avatar
      connect.c: mark die_initial_contact() NORETURN · d2bff22c
      Duy Nguyen authored
      There is a series running in parallel with this one that adds code
      like this
      
          switch (...) {
          case ...:
              die_initial_contact();
          case ...:
      
      There is nothing wrong with this. There is no actual falling
      through. But since gcc is not that smart and gcc 7.x introduces
      -Wimplicit-fallthrough, it raises a false alarm in this case.
      
      This class of warnings may be useful elsewhere, so instead of
      suppressing the whole class, let's try to fix just this code. gcc is
      smart enough to realize that no execution can continue after a
      NORETURN function call and no longer raises the warning.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d2bff22c
  4. 15 Mar, 2018 4 commits
  5. 14 Mar, 2018 3 commits
  6. 21 Nov, 2017 8 commits
  7. 17 Oct, 2017 3 commits
    • Brandon Williams's avatar
      ssh: introduce a 'simple' ssh variant · 94b8ae5a
      Brandon Williams authored
      When using the 'ssh' transport, the '-o' option is used to specify an
      environment variable which should be set on the remote end.  This allows
      git to send additional information when contacting the server,
      requesting the use of a different protocol version via the
      'GIT_PROTOCOL' environment variable like so: "-o SendEnv=GIT_PROTOCOL".
      
      Unfortunately not all ssh variants support the sending of environment
      variables to the remote end.  To account for this, only use the '-o'
      option for ssh variants which are OpenSSH compliant.  This is done by
      checking that the basename of the ssh command is 'ssh' or the ssh
      variant is overridden to be 'ssh' (via the ssh.variant config).
      
      Other options like '-p' and '-P', which are used to specify a specific
      port to use, or '-4' and '-6', which are used to indicate that IPV4 or
      IPV6 addresses should be used, may also not be supported by all ssh
      variants.
      
      Currently if an ssh command's basename wasn't 'plink' or
      'tortoiseplink' git assumes that the command is an OpenSSH variant.
      Since user configured ssh commands may not be OpenSSH compliant, tighten
      this constraint and assume a variant of 'simple' if the basename of the
      command doesn't match the variants known to git.  The new ssh variant
      'simple' will only have the host and command to execute ([username@]host
      command) passed as parameters to the ssh command.
      
      Update the Documentation to better reflect the command-line options sent
      to ssh commands based on their variant.
      Reported-by: default avatarJeffrey Yasskin <jyasskin@google.com>
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      94b8ae5a
    • Brandon Williams's avatar
      connect: tell server that the client understands v1 · 0c2f0d27
      Brandon Williams authored
      Teach the connection logic to tell a serve that it understands protocol
      v1.  This is done in 2 different ways for the builtin transports, both
      of which ultimately set 'GIT_PROTOCOL' to 'version=1' on the server.
      
      1. git://
         A normal request to git-daemon is structured as
         "command path/to/repo\0host=..\0" and due to a bug introduced in
         49ba83fb (Add virtualization support to git-daemon, 2006-09-19) we
         aren't able to place any extra arguments (separated by NULs) besides
         the host otherwise the parsing of those arguments would enter an
         infinite loop.  This bug was fixed in 73bb33a9 (daemon: Strictly
         parse the "extra arg" part of the command, 2009-06-04) but a check
         was put in place to disallow extra arguments so that new clients
         wouldn't trigger this bug in older servers.
      
         In order to get around this limitation git-daemon was taught to
         recognize additional request arguments hidden behind a second
         NUL byte.  Requests can then be structured like:
         "command path/to/repo\0host=..\0\0version=1\0key=value\0".
         git-daemon can then parse out the extra arguments and set
         'GIT_PROTOCOL' accordingly.
      
         By placing these extra arguments behind a second NUL byte we can
         skirt around both the infinite loop bug in 49ba83fb (Add
         virtualization support to git-daemon, 2006-09-19) as well as the
         explicit disallowing of extra arguments introduced in 73bb33a9
         (daemon: Strictly parse the "extra arg" part of the command,
         2009-06-04) because both of these versions of git-daemon check for a
         single NUL byte after the host argument before terminating the
         argument parsing.
      
      2. ssh://, file://
         Set 'GIT_PROTOCOL' environment variable with the desired protocol
         version.  With the file:// transport, 'GIT_PROTOCOL' can be set
         explicitly in the locally running git-upload-pack or git-receive-pack
         processes.  With the ssh:// transport and OpenSSH compliant ssh
         programs, 'GIT_PROTOCOL' can be sent across ssh by using '-o
         SendEnv=GIT_PROTOCOL' and having the server whitelist this
         environment variable.
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      0c2f0d27
    • Brandon Williams's avatar
      connect: teach client to recognize v1 server response · 2609043d
      Brandon Williams authored
      Teach a client to recognize that a server understands protocol v1 by
      looking at the first pkt-line the server sends in response.  This is
      done by looking for the response "version 1" send by upload-pack or
      receive-pack.
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2609043d
  8. 27 Sep, 2017 1 commit
    • Jonathan Tan's avatar
      connect: in ref advertisement, shallows are last · 0cd83283
      Jonathan Tan authored
      Currently, get_remote_heads() parses the ref advertisement in one loop,
      allowing refs and shallow lines to intersperse, despite this not being
      allowed by the specification. Refactor get_remote_heads() to use two
      loops instead, enforcing that refs come first, and then shallows.
      
      This also makes it easier to teach get_remote_heads() to interpret other
      lines in the ref advertisement, which will be done in a subsequent
      patch.
      
      As part of this change, this patch interprets capabilities only on the
      first line in the ref advertisement, printing a warning message when
      encountering capabilities on other lines.
      Signed-off-by: default avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      0cd83283
  9. 06 Sep, 2017 1 commit
  10. 28 Jul, 2017 4 commits
    • Jeff King's avatar
      connect: reject paths that look like command line options · aeeb2d49
      Jeff King authored
      If we get a repo path like "-repo.git", we may try to invoke
      "git-upload-pack -repo.git". This is going to fail, since
      upload-pack will interpret it as a set of bogus options. But
      let's reject this before we even run the sub-program, since
      we would not want to allow any mischief with repo names that
      actually are real command-line options.
      
      You can still ask for such a path via git-daemon, but there's no
      security problem there, because git-daemon enters the repo itself
      and then passes "."  on the command line.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      aeeb2d49
    • Jeff King's avatar
      connect: reject dashed arguments for proxy commands · 3be4cf09
      Jeff King authored
      If you have a GIT_PROXY_COMMAND configured, we will run it
      with the host/port on the command-line. If a URL contains a
      mischievous host like "--foo", we don't know how the proxy
      command may handle it. It's likely to break, but it may also
      do something dangerous and unwanted (technically it could
      even do something useful, but that seems unlikely).
      
      We should err on the side of caution and reject this before
      we even run the command.
      
      The hostname check matches the one we do in a similar
      circumstance for ssh. The port check is not present for ssh,
      but there it's not necessary because the syntax is "-p
      <port>", and there's no ambiguity on the parsing side.
      
      It's not clear whether you can actually get a negative port
      to the proxy here or not. Doing:
      
        git fetch git://remote:-1234/repo.git
      
      keeps the "-1234" as part of the hostname, with the default
      port of 9418. But it's a good idea to keep this check close
      to the point of running the command to make it clear that
      there's no way to circumvent it (and at worst it serves as a
      belt-and-suspenders check).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3be4cf09
    • Jeff King's avatar
      connect: factor out "looks like command line option" check · 2491f77b
      Jeff King authored
      We reject hostnames that start with a dash because they may
      be confused for command-line options. Let's factor out that
      notion into a helper function, as we'll use it in more
      places. And while it's simple now, it's not clear if some
      systems might need more complex logic to handle all cases.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2491f77b
    • Junio C Hamano's avatar
      connect: reject ssh hostname that begins with a dash · 820d7650
      Junio C Hamano authored
      When commands like "git fetch" talk with ssh://$rest_of_URL/, the
      code splits $rest_of_URL into components like host, port, etc., and
      then spawns the underlying "ssh" program by formulating argv[] array
      that has:
      
       - the path to ssh command taken from GIT_SSH_COMMAND, etc.
      
       - dashed options like '-batch' (for Tortoise), '-p <port>' as
         needed.
      
       - ssh_host, which is supposed to be the hostname parsed out of
         $rest_of_URL.
      
       - then the command to be run on the other side, e.g. git
         upload-pack.
      
      If the ssh_host ends up getting '-<anything>', the argv[] that is
      used to spawn the command becomes something like:
      
          { "ssh", "-p", "22", "-<anything>", "command", "to", "run", NULL }
      
      which obviously is bogus, but depending on the actual value of
      "<anything>", will make "ssh" parse and use it as an option.
      
      Prevent this by forbidding ssh_host that begins with a "-".
      
      Noticed-by: Joern Schneeweisz of Recurity Labs
      Reported-by: Brian at GitLab
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      820d7650
  11. 15 Jun, 2017 1 commit
  12. 26 May, 2017 1 commit
    • Jeff King's avatar
      connect.c: fix leak in parse_one_symref_info() · ef4fe561
      Jeff King authored
      If we successfully parse a symref value like
      "HEAD:refs/heads/master", we add the result to a string
      list. But because the string list is marked
      STRING_LIST_INIT_DUP, the string list code will make a copy
      of the string and add the copy.
      
      This patch fixes it by adding the entry with
      string_list_append_nodup(), which lets the string list take
      ownership of our newly allocated string. There are two
      alternatives that seem like they would work, but aren't the
      right solution.
      
      The first is to initialize the list with the "NODUP"
      initializer. That would avoid the copy, but then the string
      list would not realize that it owns the strings. When we
      eventually call string_list_clear(), it would not free the
      strings, causing a leak.
      
      The second option would be to use the normal
      string_list_append(), but free the local copy in our
      function. We can't do this because the local copy actually
      contains _two_ strings; the symref name and its target. We
      point to the target pointer via the "util" field, and its
      memory must last as long as the string list does.
      
      You may also wonder whether it's safe to ever free the local
      copy, since the target points into it. The answer is yes,
      because we duplicate it in annotaate_refs_with_symref_info
      before clearing the string list.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ef4fe561
  13. 21 Apr, 2017 1 commit
  14. 17 Apr, 2017 1 commit
    • Jeff King's avatar
      connect.c: handle errors from split_cmdline · 22e5ae5c
      Jeff King authored
      Commit e9d9a8a4 (connect: handle putty/plink also in
      GIT_SSH_COMMAND, 2017-01-02) added a call to
      split_cmdline(), but checks only for a non-zero return to
      see if we got any output. Since the function returns
      negative values (and a NULL argv) on error, we end up
      dereferencing NULL and segfaulting.
      
      Arguably we could report on the parsing error here, but it's
      probably not worth it. This is a best-effort attempt to see
      if we are using plink. So we can simply return here with
      "no, it wasn't plink" and let the shell actually complain
      about the bogus quoting.
      Reported-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      22e5ae5c
  15. 31 Mar, 2017 2 commits
  16. 10 Feb, 2017 1 commit
    • Junio C Hamano's avatar
      connect.c: stop conflating ssh command names and overrides · 486c8e8c
      Junio C Hamano authored
      dd33e077 ("connect: Add the envvar GIT_SSH_VARIANT and ssh.variant
      config", 2017-02-01) attempted to add support for configuration and
      environment variable to override the different handling of
      port_option and needs_batch settings suitable for variants of the
      ssh implementation that was autodetected by looking at the ssh
      command name.  Because it piggybacked on the code that turns command
      name to specific override (e.g. "plink.exe" and "plink" means
      port_option needs to be set to 'P' instead of the default 'p'), yet
      it defined a separate namespace for these overrides (e.g. "putty"
      can be usable to signal that port_option needs to be 'P'), however,
      it made the auto-detection based on the command name less robust
      (e.g. the code now accepts "putty" as a SSH command name and applies
      the same override).
      
      Separate the code that interprets the override that was read from
      the configuration & environment from the original code that handles
      the command names, as they are in separate namespaces, to fix this
      confusion.
      
      This incidentally also makes it easier for future enhancement of the
      override syntax (e.g. "port_option=p,needs_batch=1" may want to be
      accepted as a more explicit syntax) without affecting the code for
      auto-detection based on the command name.
      
      While at it, update the return type of the handle_ssh_variant()
      helper function to void; the caller does not use it, and the
      function does not return any meaningful value.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      486c8e8c
  17. 01 Feb, 2017 2 commits
  18. 26 Jan, 2017 1 commit
    • Junio C Hamano's avatar
      connect: rename tortoiseplink and putty variables · 6a4f3a9e
      Junio C Hamano authored
      One of these two may have originally been named after "what exact
      SSH implementation do we have?" so that we can tweak the command
      line options for that exact implementation.  But "putty=1" no longer
      means "We are using the plink SSH implementation that comes with
      PuTTY" these days.  It is set when we guess that either PuTTY plink
      or Tortoiseplink is in use.
      
      Rename them after what effect is desired.  The current 'putty'
      option is about using "-P <port>" when OpenSSH would use "-p <port>",
      so rename it to 'port_option' whose value is either 'p' or 'P".  The
      other one is about passing an extra command line option "-batch",
      so rename it to 'needs_batch'.
      
      [jes: wrapped overly-long line]
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6a4f3a9e
  19. 25 Jan, 2017 1 commit
    • Segev Finer's avatar
      connect: handle putty/plink also in GIT_SSH_COMMAND · e9d9a8a4
      Segev Finer authored
      Git for Windows has special support for the popular SSH client PuTTY:
      when using PuTTY's non-interactive version ("plink.exe"), we use the -P
      option to specify the port rather than OpenSSH's -p option. TortoiseGit
      ships with its own, forked version of plink.exe, that adds support for
      the -batch option, and for good measure we special-case that, too.
      
      However, this special-casing of PuTTY only covers the case where the
      user overrides the SSH command via the environment variable GIT_SSH
      (which allows specifying the name of the executable), not
      GIT_SSH_COMMAND (which allows specifying a full command, including
      additional command-line options).
      
      When users want to pass any additional arguments to (Tortoise-)Plink,
      such as setting a private key, they are required to either use a shell
      script named plink or tortoiseplink or duplicate the logic that is
      already in Git for passing the correct style of command line arguments,
      which can be difficult, error prone and annoying to get right.
      
      This patch simply reuses the existing logic and expands it to cover
      GIT_SSH_COMMAND, too.
      
      Note: it may look a little heavy-handed to duplicate the entire
      command-line and then split it, only to extract the name of the
      executable. However, this is not a performance-critical code path, and
      the code is much more readable this way.
      Signed-off-by: default avatarSegev Finer <segev208@gmail.com>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e9d9a8a4
  20. 17 Oct, 2016 1 commit
  21. 19 Sep, 2016 1 commit