1. 15 Jul, 2013 1 commit
  2. 03 May, 2012 1 commit
  3. 21 Nov, 2011 1 commit
    • Jeff King's avatar
      archive: don't let remote clients get unreachable commits · ee27ca4a
      Jeff King authored
      Usually git is careful not to allow clients to fetch
      arbitrary objects from the database; for example, objects
      received via upload-pack must be reachable from a ref.
      Upload-archive breaks this by feeding the client's tree-ish
      directly to get_sha1, which will accept arbitrary hex sha1s,
      reflogs, etc.
      This is not a problem if all of your objects are publicly
      reachable anyway (or at least public to anybody who can run
      upload-archive). Or if you are making the repo available by
      dumb protocols like http or rsync (in which case the client
      can read your whole object db directly).
      But for sites which allow access only through smart
      protocols, clients may be able to fetch trees from commits
      that exist in the server's object database but are not
      referenced (e.g., because history was rewound).
      This patch tightens upload-archive's lookup to use dwim_ref
      rather than get_sha1. This means a remote client can only
      fetch the tip of a named ref, not an arbitrary sha1 or
      reflog entry.
      This also restricts some legitimate requests, too:
        1. Reachable non-tip commits, like:
              git archive --remote=$url v1.0~5
        2. Sub-trees of reachable commits, like:
              git archive --remote=$url v1.7.7:Documentation
      Local requests continue to use get_sha1, and are not
      restricted at all.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 22 Jun, 2011 4 commits
    • Jeff King's avatar
      upload-archive: allow user to turn off filters · 7b97730b
      Jeff King authored
      Some tar filters may be very expensive to run, so sites do
      not want to expose them via upload-archive. This patch lets
      users configure tar.<filter>.remote to turn them off.
      By default, gzip filters are left on, as they are about as
      expensive as creating zip archives.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      archive: move file extension format-guessing lower · 56baa61d
      Jeff King authored
      The process for guessing an archive output format based on
      the filename is something like this:
        a. parse --output in cmd_archive; check the filename
           against a static set of mapping heuristics (right now
           it just matches ".zip" for zip files).
        b. if found, stick a fake "--format=zip" at the beginning
           of the arguments list (if the user did specify a
           --format manually, the later option will override our
           fake one)
        c. if it's a remote call, ship the arguments to the remote
           (including the fake), which will call write_archive on
           their end
        d. if it's local, ship the arguments to write_archive
      There are two problems:
        1. The set of mappings is static and at too high a level.
           The write_archive level is going to check config for
           user-defined formats, some of which will specify
           extensions. We need to delay lookup until those are
           parsed, so we can match against them.
        2. For a remote archive call, our set of mappings (or
           formats) may not match the remote side's. This is OK in
           practice right now, because all versions of git
           understand "zip" and "tar". But as new formats are
           added, there is going to be a mismatch between what the
           client can do and what the remote server can do.
      To fix (1), this patch refactors the location guessing to
      happen at the write_archive level, instead of the
      cmd_archive level. So instead of sticking a fake --format
      field in the argv list, we actually pass a "name hint" down
      the callchain; this hint is used at the appropriate time to
      guess the format (if one hasn't been given already).
      This patch leaves (2) unfixed. The name_hint is converted to
      a "--format" option as before, and passed to the remote.
      This means the local side's idea of how extensions map to
      formats will take precedence.
      Another option would be to pass the name hint to the remote
      side and let the remote choose. This isn't a good idea for
      two reasons:
        1. There's no room in the protocol for passing that
           information. We can pass a new argument, but older
           versions of git on the server will choke on it.
        2. Letting the remote side decide creates a silent
           inconsistency in user experience. Consider the case
           that the locally installed git knows about the "tar.gz"
           format, but a remote server doesn't.
           Running "git archive -o foo.tar.gz" will use the tar.gz
           format. If we use --remote, and the local side chooses
           the format, then we send "--format=tar.gz" to the
           remote, which will complain about the unknown format.
           But if we let the remote side choose the format, then
           it will realize that it doesn't know about "tar.gz" and
           output uncompressed tar without even issuing a warning.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      archive: pass archiver struct to write_archive callback · 4d7c9898
      Jeff King authored
      The current archivers are very static; when you are in the
      write_tar_archive function, you know you are writing a tar.
      However, to facilitate runtime-configurable archivers
      that will share a common write function we need to tell the
      function which archiver was used.
      As a convenience, we also provide an opaque data pointer in
      the archiver struct so that individual archivers can put
      something useful there when they register themselves.
      Technically they could just use the "name" field to look in
      an internal map of names to data, but this is much simpler.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      archive: refactor list of archive formats · 13e0f88d
      Jeff King authored
      Most of the tar and zip code was nicely split out into two
      abstracted files which knew only about their specific
      formats. The entry point to this code was a single "write
      archive" function.
      However, as these basic formats grow more complex (e.g., by
      handling multiple file extensions and format names), a
      static list of the entry point functions won't be enough.
      Instead, let's provide a way for the tar and zip code to
      tell the main archive code what they support by registering
      archiver names and functions.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 18 Apr, 2009 1 commit
  6. 26 Jul, 2008 4 commits
  7. 19 Jul, 2008 1 commit
    • René Scharfe's avatar
      archive: make zip compression level independent from core git · 3a176c6c
      René Scharfe authored
      zlib_compression_level is the compression level used for git's object store.
      It's 1 by default, which is the fastest setting.  This variable is also used
      as the default compression level for ZIP archives created by git archive.
      For archives, however, zlib's own default of 6 is more appropriate, as it's
      favouring small size over speed -- archive creation is not that performance
      critical most of the time.
      This patch makes git archive independent from git's internal compression
      level setting.  It affects invocations of git archive without explicitly
      specified compression level option, only.
      Signed-off-by: default avatarRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 15 Jul, 2008 5 commits
  9. 09 Jun, 2008 1 commit
  10. 03 Sep, 2007 1 commit
    • René Scharfe's avatar
      archive: specfile support (--pretty=format: in archive files) · 8460b2fc
      René Scharfe authored
      Add support for a new attribute, specfile.  Files marked as being
      specfiles are expanded by git-archive when they are written to an
      archive.  It has no effect on worktree files.  The same placeholders
      as those for the option --pretty=format: of git-log et al. can be
      The attribute is useful for creating auto-updating specfiles.  It is
      limited by the underlying function format_commit_message(), though.
      E.g. currently there is no placeholder for git-describe like output,
      and expanded specfiles can't contain NUL bytes.  That can be fixed
      in format_commit_message() later and will then benefit users of
      git-log, too.
      Signed-off-by: default avatarRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  11. 05 Nov, 2006 1 commit
  12. 10 Sep, 2006 2 commits
  13. 09 Sep, 2006 4 commits