1. 22 May, 2018 2 commits
    • Jeff King's avatar
      verify_path: disallow symlinks in .gitmodules · 10ecfa76
      Jeff King authored
      There are a few reasons it's not a good idea to make
      .gitmodules a symlink, including:
        1. It won't be portable to systems without symlinks.
        2. It may behave inconsistently, since Git may look at
           this file in the index or a tree without bothering to
           resolve any symbolic links. We don't do this _yet_, but
           the config infrastructure is there and it's planned for
           the future.
      With some clever code, we could make (2) work. And some
      people may not care about (1) if they only work on one
      platform. But there are a few security reasons to simply
      disallow it:
        a. A symlinked .gitmodules file may circumvent any fsck
           checks of the content.
        b. Git may read and write from the on-disk file without
           sanity checking the symlink target. So for example, if
           you link ".gitmodules" to "../oops" and run "git
           submodule add", we'll write to the file "oops" outside
           the repository.
      Again, both of those are problems that _could_ be solved
      with sufficient code, but given the complications in (1) and
      (2), we're better off just outlawing it explicitly.
      Note the slightly tricky call to verify_path() in
      update-index's update_one(). There we may not have a mode if
      we're not updating from the filesystem (e.g., we might just
      be removing the file). Passing "0" as the mode there works
      fine; since it's not a symlink, we'll just skip the extra
      Signed-off-by: default avatarJeff King <peff@peff.net>
    • Johannes Schindelin's avatar
      is_ntfs_dotgit: match other .git files · e7cb0b44
      Johannes Schindelin authored
      When we started to catch NTFS short names that clash with .git, we only
      looked for GIT~1. This is sufficient because we only ever clone into an
      empty directory, so .git is guaranteed to be the first subdirectory or
      file in that directory.
      However, even with a fresh clone, .gitmodules is *not* necessarily the
      first file to be written that would want the NTFS short name GITMOD~1: a
      malicious repository can add .gitmodul0000 and friends, which sorts
      before `.gitmodules` and is therefore checked out *first*. For that
      reason, we have to test not only for ~1 short names, but for others,
      It's hard to just adapt the existing checks in is_ntfs_dotgit(): since
      Windows 2000 (i.e., in all Windows versions still supported by Git),
      NTFS short names are only generated in the <prefix>~<number> form up to
      number 4. After that, a *different* prefix is used, calculated from the
      long file name using an undocumented, but stable algorithm.
      For example, the short name of .gitmodules would be GITMOD~1, but if it
      is taken, and all of ~2, ~3 and ~4 are taken, too, the short name
      GI7EBA~1 will be used. From there, collisions are handled by
      incrementing the number, shortening the prefix as needed (until ~9999999
      is reached, in which case NTFS will not allow the file to be created).
      We'd also want to handle .gitignore and .gitattributes, which suffer
      from a similar problem, using the fall-back short names GI250A~1 and
      GI7D29~1, respectively.
      To accommodate for that, we could reimplement the hashing algorithm, but
      it is just safer and simpler to provide the known prefixes. This
      algorithm has been reverse-engineered and described at
      https://usn.pw/blog/gen/2015/06/09/filenames/, which is defunct but
      still available via https://web.archive.org/.
      These can be recomputed by running the following Perl script:
      -- snip --
      use warnings;
      use strict;
      sub compute_short_name_hash ($) {
              my $checksum = 0;
              foreach (split('', $_[0])) {
                      $checksum = ($checksum * 0x25 + ord($_)) & 0xffff;
              $checksum = ($checksum * 314159269) & 0xffffffff;
              $checksum = 1 + (~$checksum & 0x7fffffff) if ($checksum & 0x80000000);
              $checksum -= (($checksum * 1152921497) >> 60) * 1000000007;
              return scalar reverse sprintf("%x", $checksum & 0xffff);
      print compute_short_name_hash($ARGV[0]);
      -- snap --
      E.g., running that with the argument ".gitignore" will
      result in "250a" (which then becomes "gi250a" in the code).
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJeff King <peff@peff.net>
  2. 21 May, 2018 1 commit
  3. 16 May, 2018 1 commit
  4. 13 May, 2018 1 commit
  5. 09 May, 2018 7 commits
  6. 02 May, 2018 7 commits
  7. 26 Apr, 2018 3 commits
  8. 16 Apr, 2018 1 commit
    • Duy Nguyen's avatar
      pack-objects: turn type and in_pack_type to bitfields · fd9b1bae
      Duy Nguyen authored
      An extra field type_valid is added to carry the equivalent of OBJ_BAD
      in the original "type" field. in_pack_type always contains a valid
      type so we only need 3 bits for it.
      A note about accepting OBJ_NONE as "valid" type. The function
      read_object_list_from_stdin() can pass this value [1] and it
      eventually calls create_object_entry() where current code skip setting
      "type" field if the incoming type is zero. This does not have any bad
      side effects because "type" field should be memset()'d anyway.
      But since we also need to set type_valid now, skipping oe_set_type()
      leaves type_valid zero/false, which will make oe_type() return
      OBJ_BAD, not OBJ_NONE anymore. Apparently we do care about OBJ_NONE in
      prepare_pack(). This switch from OBJ_NONE to OBJ_BAD may trigger
          fatal: unable to get type of object ...
      Accepting OBJ_NONE [2] does sound wrong, but this is how it is has
      been for a very long time and I haven't time to dig in further.
      [1] See 5c49c116 (pack-objects: better check_object() performances -
      [2] 21666f1a (convert object type handling from a string to a number
          - 2007-02-26)
      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>
  9. 12 Apr, 2018 1 commit
  10. 11 Apr, 2018 2 commits
    • Dan Jacques's avatar
      exec_cmd: RUNTIME_PREFIX on some POSIX systems · 226c0ddd
      Dan Jacques authored
      Enable Git to resolve its own binary location using a variety of
      OS-specific and generic methods, including:
      - procfs via "/proc/self/exe" (Linux)
      - _NSGetExecutablePath (Darwin)
      - KERN_PROC_PATHNAME sysctl on BSDs.
      - argv0, if absolute (all, including Windows).
      This is used to enable RUNTIME_PREFIX support for non-Windows systems,
      notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will
      do a best-effort resolution of its executable path and automatically use
      this as its "exec_path" for relative helper and data lookups, unless
      explicitly overridden.
      Small incidental formatting cleanup of "exec_cmd.c".
      Signed-off-by: default avatarDan Jacques <dnj@google.com>
      Thanks-to: Robbie Iannucci <iannucci@google.com>
      Thanks-to: Junio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Derrick Stolee's avatar
      commit-graph: add core.commitGraph setting · 1b70dfd5
      Derrick Stolee authored
      The commit graph feature is controlled by the new core.commitGraph config
      setting. This defaults to 0, so the feature is opt-in.
      The intention of core.commitGraph is that a user can always stop checking
      for or parsing commit graph files if core.commitGraph=0.
      Signed-off-by: Derrick Stolee's avatarDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  11. 30 Mar, 2018 1 commit
    • Jeff King's avatar
      set_git_dir: die when setenv() fails · 48988c4d
      Jeff King authored
      The set_git_dir() function returns an error if setenv()
      fails, but there are zero callers who pay attention to this
      return value. If this ever were to happen, it could cause
      confusing results, as sub-processes would see a potentially
      stale GIT_DIR (e.g., if it is relative and we chdir()-ed to
      the root of the working tree).
      We _could_ try to fix each caller, but there's really
      nothing useful to do after this failure except die. Let's
      just lump setenv() failure into the same category as malloc
      failure: things that should never happen and cause us to
      abort catastrophically.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  12. 26 Mar, 2018 3 commits
  13. 23 Mar, 2018 1 commit
  14. 14 Mar, 2018 9 commits