1. 24 9月, 2015 2 次提交
    • J
      submodule: allow only certain protocols for submodule fetches · 33cfccbb
      Jeff King 提交于
      Some protocols (like git-remote-ext) can execute arbitrary
      code found in the URL. The URLs that submodules use may come
      from arbitrary sources (e.g., .gitmodules files in a remote
      repository). Let's restrict submodules to fetching from a
      known-good subset of protocols.
      
      Note that we apply this restriction to all submodule
      commands, whether the URL comes from .gitmodules or not.
      This is more restrictive than we need to be; for example, in
      the tests we run:
      
        git submodule add ext::...
      
      which should be trusted, as the URL comes directly from the
      command line provided by the user. But doing it this way is
      simpler, and makes it much less likely that we would miss a
      case. And since such protocols should be an exception
      (especially because nobody who clones from them will be able
      to update the submodules!), it's not likely to inconvenience
      anyone in practice.
      Reported-by: NBlake Burkhart <bburky@bburky.com>
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      33cfccbb
    • J
      transport: add a protocol-whitelist environment variable · a5adaced
      Jeff King 提交于
      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: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a5adaced
  2. 05 9月, 2015 7 次提交
  3. 04 9月, 2015 1 次提交
    • J
      verify_absent: allow filenames longer than PATH_MAX · f514ef97
      Jeff King 提交于
      When unpack-trees wants to know whether a path will
      overwrite anything in the working tree, we use lstat() to
      see if there is anything there. But if we are going to write
      "foo/bar", we can't just lstat("foo/bar"); we need to look
      for leading prefixes (e.g., "foo"). So we use the lstat cache
      to find the length of the leading prefix, and copy the
      filename up to that length into a temporary buffer (since
      the original name is const, we cannot just stick a NUL in
      it).
      
      The copy we make goes into a PATH_MAX-sized buffer, which
      will overflow if the prefix is longer than PATH_MAX. How
      this happens is a little tricky, since in theory PATH_MAX is
      the biggest path we will have read from the filesystem. But
      this can happen if:
      
        - the compiled-in PATH_MAX does not accurately reflect
          what the filesystem is capable of
      
        - the leading prefix is not _quite_ what is on disk; it
          contains the next element from the name we are checking.
          So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb"
          exists, the prefix of interest is "aaa/bbb/ccc". If
          "aaa/bbb" approaches PATH_MAX, then "ccc" can overflow
          it.
      
      So this can be triggered, but it's hard to do. In
      particular, you cannot just "git clone" a bogus repo. The
      verify_absent checks happen before unpack-trees writes
      anything to the filesystem, so there are never any leading
      prefixes during the initial checkout, and the bug doesn't
      trigger. And by definition, these files are larger than
      PATH_MAX, so writing them will fail, and clone will
      complain (though it may write a partial path, which will
      cause a subsequent "git checkout" to hit the bug).
      
      We can fix it by creating the temporary path on the heap.
      The extra malloc overhead is not important, as we are
      already making at least one stat() call (and probably more
      for the prefix discovery).
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f514ef97
  4. 12 5月, 2015 5 次提交
    • J
      Git 2.3.8 · 9a3d6375
      Junio C Hamano 提交于
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9a3d6375
    • J
      Merge branch 'mm/usage-log-l-can-take-regex' into maint-2.3 · 811ce1b4
      Junio C Hamano 提交于
      Documentation fix.
      
      * mm/usage-log-l-can-take-regex:
        log -L: improve error message on malformed argument
        Documentation: change -L:<regex> to -L:<funcname>
      811ce1b4
    • J
      Merge branch 'jc/diff-no-index-d-f' into maint-2.3 · cd012085
      Junio C Hamano 提交于
      The usual "git diff" when seeing a file turning into a directory
      showed a patchset to remove the file and create all files in the
      directory, but "git diff --no-index" simply refused to work.  Also,
      when asked to compare a file and a directory, imitate POSIX "diff"
      and compare the file with the file with the same name in the
      directory, instead of refusing to run.
      
      * jc/diff-no-index-d-f:
        diff-no-index: align D/F handling with that of normal Git
        diff-no-index: DWIM "diff D F" into "diff D/F F"
      cd012085
    • J
      Merge branch 'oh/fix-config-default-user-name-section' into maint-2.3 · 1add9aed
      Junio C Hamano 提交于
      The default $HOME/.gitconfig file created upon "git config --global"
      that edits it had incorrectly spelled user.name and user.email
      entries in it.
      
      * oh/fix-config-default-user-name-section:
        config: fix settings in default_user_config template
      1add9aed
    • J
      Merge branch 'jc/epochtime-wo-tz' into maint-2.3 · 13ec221d
      Junio C Hamano 提交于
      "git commit --date=now" or anything that relies on approxidate lost
      the daylight-saving-time offset.
      
      * jc/epochtime-wo-tz:
        parse_date_basic(): let the system handle DST conversion
        parse_date_basic(): return early when given a bogus timestamp
      13ec221d
  5. 28 4月, 2015 4 次提交
  6. 22 4月, 2015 10 次提交
  7. 21 4月, 2015 2 次提交
  8. 18 4月, 2015 1 次提交
  9. 16 4月, 2015 2 次提交
  10. 15 4月, 2015 1 次提交
  11. 13 4月, 2015 1 次提交
  12. 09 4月, 2015 1 次提交
  13. 05 4月, 2015 1 次提交
    • K
      diff-highlight: do not split multibyte characters · 8d00662d
      Kyle J. McKay 提交于
      When the input is UTF-8 and Perl is operating on bytes instead of
      characters, a diff that changes one multibyte character to another
      that shares an initial byte sequence will result in a broken diff
      display as the common byte sequence prefix will be separated from
      the rest of the bytes in the multibyte character.
      
      For example, if a single line contains only the unicode character
      U+C9C4 (encoded as UTF-8 0xEC, 0xA7, 0x84) and that line is then
      changed to the unicode character U+C9C0 (encoded as UTF-8 0xEC,
      0xA7, 0x80), when operating on bytes diff-highlight will show only
      the single byte change from 0x84 to 0x80 thus creating invalid UTF-8
      and a broken diff display.
      
      Fix this by putting Perl into character mode when splitting the line
      and then back into byte mode after the split is finished.
      
      The utf8::xxx functions require Perl 5.8 so we require that as well.
      
      Also, since we are mucking with code in the split_line function, we
      change a '*' quantifier to a '+' quantifier when matching the $COLOR
      expression which has the side effect of speeding everything up while
      eliminating useless '' elements in the returned array.
      Reported-by: NYi EungJun <semtlenori@gmail.com>
      Signed-off-by: NKyle J. McKay <mackyle@gmail.com>
      Acked-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8d00662d
  14. 03 4月, 2015 1 次提交
  15. 02 4月, 2015 1 次提交