1. 17 Mar, 2016 2 commits
  2. 04 Jan, 2016 1 commit
  3. 08 Dec, 2015 1 commit
  4. 11 Nov, 2015 1 commit
  5. 05 Nov, 2015 1 commit
  6. 16 Oct, 2015 1 commit
  7. 29 Sep, 2015 1 commit
  8. 28 Sep, 2015 4 commits
  9. 25 Sep, 2015 1 commit
    • Blake Burkhart's avatar
      http: limit redirection to protocol-whitelist · f4113cac
      Blake Burkhart authored
      Previously, libcurl would follow redirection to any protocol
      it was compiled for support with. This is desirable to allow
      redirection from HTTP to HTTPS. However, it would even
      successfully allow redirection from HTTP to SFTP, a protocol
      that git does not otherwise support at all. Furthermore
      git's new protocol-whitelisting could be bypassed by
      following a redirect within the remote helper, as it was
      only enforced at transport selection time.
      
      This patch limits redirects within libcurl to HTTP, HTTPS,
      FTP and FTPS. If there is a protocol-whitelist present, this
      list is limited to those also allowed by the whitelist. As
      redirection happens from within libcurl, it is impossible
      for an HTTP redirect to a protocol implemented within
      another remote helper.
      
      When the curl version git was compiled with is too old to
      support restrictions on protocol redirection, we warn the
      user if GIT_ALLOW_PROTOCOL restrictions were requested. This
      is a little inaccurate, as even without that variable in the
      environment, we would still restrict SFTP, etc, and we do
      not warn in that case. But anything else means we would
      literally warn every time git accesses an http remote.
      
      This commit includes a test, but it is not as robust as we
      would hope. It redirects an http request to ftp, and checks
      that curl complained about the protocol, which means that we
      are relying on curl's specific error message to know what
      happened. Ideally we would redirect to a working ftp server
      and confirm that we can clone without protocol restrictions,
      and not with them. But we do not have a portable way of
      providing an ftp server, nor any other protocol that curl
      supports (https is the closest, but we would have to deal
      with certificates).
      
      [jk: added test and version warning]
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f4113cac
  10. 23 Sep, 2015 1 commit
    • Jeff King's avatar
      transport: add a protocol-whitelist environment variable · a5adaced
      Jeff King authored
      If we are cloning an untrusted remote repository into a
      sandbox, we may also want to fetch remote submodules in
      order to get the complete view as intended by the other
      side. However, that opens us up to attacks where a malicious
      user gets us to clone something they would not otherwise
      have access to (this is not necessarily a problem by itself,
      but we may then act on the cloned contents in a way that
      exposes them to the attacker).
      
      Ideally such a setup would sandbox git entirely away from
      high-value items, but this is not always practical or easy
      to set up (e.g., OS network controls may block multiple
      protocols, and we would want to enable some but not others).
      
      We can help this case by providing a way to restrict
      particular protocols. We use a whitelist in the environment.
      This is more annoying to set up than a blacklist, but
      defaults to safety if the set of protocols git supports
      grows). If no whitelist is specified, we continue to default
      to allowing all protocols (this is an "unsafe" default, but
      since the minority of users will want this sandboxing
      effect, it is the only sensible one).
      
      A note on the tests: ideally these would all be in a single
      test file, but the git-daemon and httpd test infrastructure
      is an all-or-nothing proposition rather than a test-by-test
      prerequisite. By putting them all together, we would be
      unable to test the file-local code on machines without
      apache.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a5adaced
  11. 17 Sep, 2015 1 commit
  12. 04 Sep, 2015 4 commits
  13. 28 Aug, 2015 1 commit
  14. 03 Aug, 2015 1 commit
  15. 27 Jul, 2015 2 commits
  16. 25 Jul, 2015 1 commit
  17. 17 Jul, 2015 1 commit
  18. 15 Jul, 2015 1 commit
  19. 25 Jun, 2015 1 commit
  20. 16 Jun, 2015 2 commits
    • Junio C Hamano's avatar
      Git 2.4.4 · f09bd215
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f09bd215
    • Jeff King's avatar
      pkt-line: support tracing verbatim pack contents · 32359838
      Jeff King authored
      When debugging the pack protocol, it is sometimes useful to
      store the verbatim pack that we sent or received on the
      wire. Looking at the on-disk result is often not helpful for
      a few reasons:
      
        1. If the operation is a clone, we destroy the repo on
           failure, leaving nothing on disk.
      
        2. If the pack is small, we unpack it immediately, and the
           full pack never hits the disk.
      
        3. If we feed the pack to "index-pack --fix-thin", the
           resulting pack has the extra delta bases added to it.
      
      We already have a GIT_TRACE_PACKET mechanism for tracing
      packets. Let's extend it with GIT_TRACE_PACKFILE to dump the
      verbatim packfile.
      
      There are a few other positive fallouts that come from
      rearranging this code:
      
       - We currently disable the packet trace after seeing the
         PACK header, even though we may get human-readable lines
         on other sidebands; now we include them in the trace.
      
       - We currently try to print "PACK ..." in the trace to
         indicate that the packfile has started. But because we
         disable packet tracing, we never printed this line. We
         will now do so.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      32359838
  21. 05 Jun, 2015 1 commit
  22. 26 May, 2015 1 commit
  23. 13 May, 2015 1 commit
  24. 11 May, 2015 1 commit
  25. 30 Apr, 2015 1 commit
  26. 27 Apr, 2015 1 commit
  27. 21 Apr, 2015 1 commit
  28. 31 Mar, 2015 1 commit
  29. 24 Mar, 2015 1 commit
  30. 23 Mar, 2015 1 commit
  31. 20 Mar, 2015 1 commit
    • Jeff King's avatar
      refs: introduce a "ref paranoia" flag · 49672f26
      Jeff King authored
      Most operations that iterate over refs are happy to ignore
      broken cruft. However, some operations should be performed
      with knowledge of these broken refs, because it is better
      for the operation to choke on a missing object than it is to
      silently pretend that the ref did not exist (e.g., if we are
      computing the set of reachable tips in order to prune
      objects).
      
      These processes could just call for_each_rawref, except that
      ref iteration is often hidden behind other interfaces. For
      instance, for a destructive "repack -ad", we would have to
      inform "pack-objects" that we are destructive, and then it
      would in turn have to tell the revision code that our
      "--all" should include broken refs.
      
      It's much simpler to just set a global for "dangerous"
      operations that includes broken refs in all iterations.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      49672f26