1. 09 Oct, 2018 2 commits
  2. 26 Jun, 2018 4 commits
  3. 22 May, 2018 1 commit
    • Jeff King's avatar
      submodule-config: verify submodule names as paths · 0383bbb9
      Jeff King authored
      Submodule "names" come from the untrusted .gitmodules file,
      but we blindly append them to $GIT_DIR/modules to create our
      on-disk repo paths. This means you can do bad things by
      putting "../" into the name (among other things).
      Let's sanity-check these names to avoid building a path that
      can be exploited. There are two main decisions:
        1. What should the allowed syntax be?
           It's tempting to reuse verify_path(), since submodule
           names typically come from in-repo paths. But there are
           two reasons not to:
             a. It's technically more strict than what we need, as
                we really care only about breaking out of the
                $GIT_DIR/modules/ hierarchy.  E.g., having a
                submodule named "foo/.git" isn't actually
                dangerous, and it's possible that somebody has
                manually given such a funny name.
             b. Since we'll eventually use this checking logic in
                fsck to prevent downstream repositories, it should
                be consistent across platforms. Because
                verify_path() relies on is_dir_sep(), it wouldn't
                block "foo\..\bar" on a non-Windows machine.
        2. Where should we enforce it? These days most of the
           .gitmodules reads go through submodule-config.c, so
           I've put it there in the reading step. That should
           cover all of the C code.
           We also construct the name for "git submodule add"
           inside the git-submodule.sh script. This is probably
           not a big deal for security since the name is coming
           from the user anyway, but it would be polite to remind
           them if the name they pick is invalid (and we need to
           expose the name-checker to the shell anyway for our
           test scripts).
           This patch issues a warning when reading .gitmodules
           and just ignores the related config entry completely.
           This will generally end up producing a sensible error,
           as it works the same as a .gitmodules file which is
           missing a submodule entry (so "submodule update" will
           barf, but "git clone --recurse-submodules" will print
           an error but not abort the clone.
           There is one minor oddity, which is that we print the
           warning once per malformed config key (since that's how
           the config subsystem gives us the entries). So in the
           new test, for example, the user would see three
           warnings. That's OK, since the intent is that this case
           should never come up outside of malicious repositories
           (and then it might even benefit the user to see the
           message multiple times).
      Credit for finding this vulnerability and the proof of
      concept from which the test script was adapted goes to
      Etienne Stalmans.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
  4. 02 May, 2018 1 commit
  5. 29 Mar, 2018 3 commits
  6. 17 Oct, 2017 1 commit
    • Heiko Voigt's avatar
      implement fetching of moved submodules · c68f8375
      Heiko Voigt authored
      We store the changed submodules paths to calculate which submodule needs
      fetching. This does not work for moved submodules since their paths do
      not stay the same in case of a moved submodules. In case of new
      submodules we do not have a path in the current checkout, since they
      just appeared in this fetch.
      It is more general to collect the submodule names for changes instead of
      their paths to include the above cases. If we do not have a
      configuration for a gitlink we rely on constructing a default name from
      the path if a git repository can be found at its path. We skip
      non-configured gitlinks whose default name collides with a configured
      With the change described above we implement 'on-demand' fetching of
      changes in moved submodules.
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  7. 03 Aug, 2017 2 commits
  8. 02 Aug, 2017 1 commit
    • Brandon Williams's avatar
      submodule: remove submodule.fetchjobs from submodule-config parsing · f20e7c1e
      Brandon Williams authored
      The '.gitmodules' file should only contain information pertinent to
      configuring individual submodules (name to path mapping, URL where to
      obtain the submodule, etc.) while other configuration like the number of
      jobs to use when fetching submodules should be a part of the
      repository's config.
      Remove the 'submodule.fetchjobs' configuration option from the general
      submodule-config parsing and instead rely on using the
      'config_from_gitmodules()' in order to maintain backwards compatibility
      with this config being placed in the '.gitmodules' file.
      Signed-off-by: 's avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  9. 17 Jul, 2017 1 commit
  10. 24 Jun, 2017 1 commit
  11. 23 Jun, 2017 1 commit
  12. 16 Mar, 2017 1 commit
    • Stefan Beller's avatar
      update submodules: add submodule config parsing · d601fd09
      Stefan Beller authored
      Similar to b33a15b0 (push: add recurseSubmodules config option,
      2015-11-17) and 027771fc (submodule: allow erroneous values for the
      fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code
      that is later used to parse whether we are interested in updating
      We need the `die_on_error` parameter to be able to call this parsing
      function for the config file as well, which if incorrect lets Git die.
      As we're just touching the header file, also mark all functions extern.
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  13. 22 Dec, 2016 1 commit
  14. 22 Nov, 2016 1 commit
  15. 01 Aug, 2016 1 commit
  16. 27 May, 2016 1 commit
  17. 01 Mar, 2016 1 commit
  18. 20 Nov, 2015 1 commit
    • Mike Crowe's avatar
      push: add recurseSubmodules config option · b33a15b0
      Mike Crowe authored
      The --recurse-submodules command line parameter has existed for some
      time but it has no config file equivalent.
      Following the style of the corresponding parameter for git fetch, let's
      invent push.recurseSubmodules to provide a default for this
      parameter. This also requires the addition of --recurse-submodules=no to
      allow the configuration to be overridden on the command line when
      The most straightforward way to implement this appears to be to make
      push use code in submodule-config in a similar way to fetch.
      Signed-off-by: Mike Crowe's avatarMike Crowe <mac@mcrowe.com>
      Signed-off-by: 's avatarJeff King <peff@peff.net>
  19. 19 Aug, 2015 3 commits
    • Heiko Voigt's avatar
      submodule: allow erroneous values for the fetchRecurseSubmodules option · 027771fc
      Heiko Voigt authored
      We should not die when reading the submodule config cache since the
      user might not be able to get out of that situation when the
      configuration is part of the history.
      We should handle this condition later when the value is about to be
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Heiko Voigt's avatar
      submodule: use new config API for worktree configurations · 851e18c3
      Heiko Voigt authored
      We remove the extracted functions and directly parse into and read out
      of the cache. This allows us to have one unified way of accessing
      submodule configuration values specific to single submodules. Regardless
      whether we need to access a configuration from history or from the
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Heiko Voigt's avatar
      submodule: implement a config API for lookup of .gitmodules values · 959b5455
      Heiko Voigt authored
      In a superproject some commands need to interact with submodules. They
      need to query values from the .gitmodules file either from the worktree
      of from certain revisions. At the moment this is quite hard since a
      caller would need to read the .gitmodules file from the history and then
      parse the values. We want to provide an API for this so we have one
      place to get values from .gitmodules from any revision (including the
      The API is realized as a cache which allows us to lazily read
      .gitmodules configurations by commit into a runtime cache which can then
      be used to easily lookup values from it. Currently only the values for
      path or name are stored but it can be extended for any value needed.
      It is expected that .gitmodules files do not change often between
      commits. Thats why we lookup the .gitmodules sha1 from a commit and then
      either lookup an already parsed configuration or parse and cache an
      unknown one for each sha1. The cache is lazily build on demand for each
      requested commit.
      This cache can be used for all purposes which need knowledge about
      submodule configurations. Example use cases are:
       * Recursive submodule checkout needs to lookup a submodule name from
         its path when a submodule first appears. This needs be done before
         this configuration exists in the worktree.
       * The implementation of submodule support for 'git archive' needs to
         lookup the submodule name to generate the archive when given a
         revision that is not checked out.
       * 'git fetch' when given the --recurse-submodules=on-demand option (or
         configuration) needs to lookup submodule names by path from the
         database rather than reading from the worktree. For new submodule it
         needs to lookup the name from its path to allow cloning new
         submodules into the .git folder so they can be checked out without
         any network interaction when the user does a checkout of that
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <hvoigt@hvoigt.net>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>