1. 15 Feb, 2019 5 commits
    • maps: use high-level function to check existence of keys · c50a8ac2
      Some callers were still using the tightly-coupled pattern of `lookup_index` and
      `valid_index` to verify that an entry exists in a map. Instead, use the more
      high-level `exists` functions to decouple map users from its implementation.
      Patrick Steinhardt committed
    • strmap: introduce high-level setter for key/value pairs · 03555830
      Currently, one would use the function `git_strmap_insert` to insert key/value
      pairs into a map. This function has historically been a macro, which is why its
      syntax is kind of weird: instead of returning an error code directly, it instead
      has to be passed a pointer to where the return value shall be stored. This does
      not match libgit2's common idiom of directly returning error codes.
      
      Introduce a new function `git_strmap_set`, which takes as parameters the map,
      key and value and directly returns an error code. Convert all callers of
      `git_strmap_insert` to make use of it.
      Patrick Steinhardt committed
    • strmap: introduce `git_strmap_get` and use it throughout the tree · ef507bc7
      The current way of looking up an entry from a map is tightly coupled with the
      map implementation, as one first has to look up the index of the key and then
      retrieve the associated value by using the index. As a caller, you usually do
      not care about any indices at all, though, so this is more complicated than
      really necessary. Furthermore, it invites for errors to happen if the correct
      error checking sequence is not being followed.
      
      Introduce a new high-level function `git_strmap_get` that takes a map and a key
      and returns a pointer to the associated value if such a key exists. Otherwise,
      a `NULL` pointer is returned. Adjust all callers that can trivially be
      converted.
      Patrick Steinhardt committed
    • maps: provide a uniform entry count interface · 7e926ef3
      There currently exist two different function names for getting the entry count
      of maps, where offmaps offset and string maps use `num_entries` and OID maps use
      `size`. In most programming languages with built-in map types, this is simply
      called `size`, which is also shorter to type. Thus, this commit renames the
      other two functions `num_entries` to match the common way and adjusts all
      callers.
      Patrick Steinhardt committed
    • maps: use uniform lifecycle management functions · 351eeff3
      Currently, the lifecycle functions for maps (allocation, deallocation, resize)
      are not named in a uniform way and do not have a uniform function signature.
      Rename the functions to fix that, and stick to libgit2's naming scheme of saying
      `git_foo_new`. This results in the following new interface for allocation:
      
      - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an
        error code if we ran out of memory
      
      - `void git_<t>map_free(git_<t>map *map)` to free a map
      
      - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map
      
      This commit also fixes all existing callers.
      Patrick Steinhardt committed
  2. 22 Jan, 2019 1 commit
  3. 04 Jan, 2019 1 commit
  4. 01 Dec, 2018 2 commits
  5. 28 Nov, 2018 2 commits
  6. 05 Oct, 2018 1 commit
    • submodule: ignore path and url attributes if they look like options · c8ca3cae
      These can be used to inject options in an implementation which performs a
      recursive clone by executing an external command via crafted url and path
      attributes such that it triggers a local executable to be run.
      
      The library is not vulnerable as we do not rely on external executables but a
      user of the library might be relying on that so we add this protection.
      
      This matches this aspect of git's fix for CVE-2018-17456.
      Carlos Martín Nieto committed
  7. 28 Sep, 2018 1 commit
    • config: rename "config_file.h" to "config_backend.h" · b944e137
      The header "config_file.h" has a list of inline-functions to access the
      contents of a config backend without directly messing with the struct's
      function pointers. While all these functions are called
      "git_config_file_*", they are in fact completely backend-agnostic and
      don't care whether it is a file or not. Rename all the function to
      instead be backend-agnostic versions called "git_config_backend_*" and
      rename the header to match.
      Patrick Steinhardt committed
  8. 21 Sep, 2018 1 commit
    • submodule: fix submodule names depending on config-owned memory · 0b9c68b1
      When populating the list of submodule names, we use the submodule
      configuration entry's name as the key in the map of submodule names.
      This creates a hidden dependency on the liveliness of the configuration
      that was used to parse the submodule, which is fragile and unexpected.
      
      Fix the issue by duplicating the string before writing it into the
      submodule name map.
      Patrick Steinhardt committed
  9. 06 Jul, 2018 1 commit
  10. 10 Jun, 2018 1 commit
  11. 30 May, 2018 3 commits
    • submodule: remove useless mask computations · 9c698a25
      Previous to dfda2f68 (submodule: remove the per-repo cache,
      2015-04-27), we tried to cache our submodules per repository to avoid
      having to reload it too frequently. As it created some headaches with
      regards to multithreading, we removed that cache.
      
      Previous to that removal, we had to compute what submodule status to
      refresh. The mask computation was not removed, though, resulting in
      confusing and actually dead code. While it seems like the mask is
      currently in use in a conditional, it is not, as we unconditionally
      assign to the mask previous to that condition.
      
      Remove all mask computations to clean up stale code.
      Patrick Steinhardt committed
    • submodule: refactor loading submodule names · cf5030a3
      The function `load_submodule_names` was always being called with a
      newly allocated string map, which was then getting filled by the
      function. Move the string map allocation into `load_submodule_names`,
      instead, and pass the whole map back to the caller in case no error
      occurs. This change helps to avoid misuse by handing in pre-populated
      maps.
      Patrick Steinhardt committed
    • submodule: detect duplicated submodule paths · b2a389c8
      When loading submodule names, we build a map of submodule paths and
      their respective names. While looping over the configuration keys,
      we do not check though whether a submodule path was seen already. This
      leads to a memory leak in case we have multiple submodules with the same
      path, as we just overwrite the old value in the map in that case.
      
      Fix the error by verifying that the path to be added is not yet part of
      the string map. Git does not allow to have multiple submodules for a
      path anyway, so we now do the same and detect this duplication,
      reporting it to the user.
      Patrick Steinhardt committed
  12. 24 May, 2018 3 commits
  13. 23 May, 2018 1 commit
  14. 14 May, 2018 1 commit
  15. 09 May, 2018 1 commit
    • submodule: ignore submodules which include path traversal in their name · 6b15ceac
      If the we decide that the "name" of the submodule (i.e. its path inside
      `.git/modules/`) is trying to escape that directory or otherwise trick us, we
      ignore the configuration for that submodule.
      
      This leaves us with a half-configured submodule when looking it up by path, but
      it's the same result as if the configuration really were missing.
      
      The name check is potentially more strict than it needs to be, but it lets us
      re-use the check we're doing for the checkout. The function that encapsulates
      this logic is ready to be exported but we don't want to do that in a security
      release so it remains internal for now.
      Carlos Martín Nieto committed
  16. 28 Mar, 2018 1 commit
  17. 27 Mar, 2018 6 commits
  18. 09 Oct, 2017 1 commit
    • config: pass repository when opening config files · 529e873c
      Our current configuration logic is completely oblivious of any
      repository, but only cares for actual file paths. Unfortunately, we are
      forced to break this assumption by the introduction of conditional
      includes, which are evaluated in the context of a repository. Right now,
      only one conditional exists with "gitdir:" -- it will only include the
      configuration if the current repository's git directory matches the
      value passed to "gitdir:".
      
      To support these conditionals, we have to break our API and make the
      repository available when opening a configuration file. This commit
      extends the `open` call of configuration backends to include another
      repository and adjusts existing code to have it available. This includes
      the user-visible functions `git_config_add_file_ondisk` and
      `git_config_add_backend`.
      Patrick Steinhardt committed
  19. 25 Aug, 2017 1 commit
    • submodule: refuse lookup in bare repositories · 477b3e04
      While it is technically possible to look up submodules inside of a
      bare repository by reading the submodule configuration of a specific
      commit, we do not offer this functionality right now. As such, calling
      both `git_submodule_lookup` and `git_submodule_foreach` should error out
      early when these functions encounter a bare repository. While
      `git_submodule_lookup` already does return an error due to not being
      able to parse the configuration, `git_submodule_foreach` simply returns
      success and never invokes the callback function.
      
      Fix the issue by having both functions check whether the repository is
      bare and returning an error in that case.
      Patrick Steinhardt committed
  20. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  21. 17 Mar, 2017 1 commit
    • submodule: resolve URLs relative to main worktree · b0c9bc92
      It is possible to specify submodule URLs relative to the repository
      location. E.g. having a submodule with URL "../submodule" will look for
      the submodule at "repo/../submodule".
      
      With the introduction of worktrees, though, we cannot simply resolve the
      URL relative to the repository location itself. If the repository for
      which a URL is to be resolved is a working tree, we have to resolve the
      URL relative to the parent's repository path. Otherwise, the URL would
      change depending on where the working tree is located.
      
      Fix this by special-casing when we have a working tree while getting the
      URL base.
      Patrick Steinhardt committed
  22. 14 Mar, 2017 1 commit
    • submodule: catch when submodule is not staged on update · 32ecc98e
      When calling `git_submodule_update` on a submodule, we have to retrieve
      the ID of the submodule entry in the index. If the function is called on
      a submodule which is only partly initialized, the submodule entry may
      not be added to the index yet. This leads to an assert when trying to
      look up the blob later on.
      
      Fix the issue by checking if the index actually holds the submodule's
      ID and erroring out if it does not.
      Patrick Steinhardt committed
  23. 17 Feb, 2017 3 commits