mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Christian Couder <>
Cc:, "Jeff King" <>,
	"Jeff Hostetler" <>,
	"Jeff Hostetler" <>,
	"Jonathan Tan" <>,
	"Matthew DeVore" <>,
	"Ævar Arnfjörð Bjarmason" <>,
	"Christian Couder" <>
Subject: Re: [PATCH v2] list-objects-filter: disable 'sparse:path' filters
Date: Tue, 28 May 2019 12:41:58 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Christian Couder's message of "Sat, 25 May 2019 16:28:34 +0200")

Christian Couder <> writes:

> If someone wants to use as a filter a sparse file that is in the
> repository, something like "--filter=sparse:oid=<ref>:<path>"
> already works.
> So 'sparse:path' is only interesting if the sparse file is not in
> the repository. In this case though the current implementation has
> a big security issue, as it makes it possible to ask the server to
> read any file, like for example /etc/password, and to explore the
> filesystem, as well as individual lines of files.
> If someone is interested in using a sparse file that is not in the
> repository as a filter, then at the minimum a config option, such
> as "uploadpack.sparsePathFilter", should be implemented first to
> restrict the directory from which the files specified by
> 'sparse:path' can be read.
> For now though, let's just disable 'sparse:path' filters.
> Helped-by: Matthew DeVore <>
> Helped-by: Jeff Hostetler <>
> Signed-off-by: Christian Couder <>
> ---
> Changes since the RFC version are the following:
>   - improved the error message when 'sparse:path' is used,
>   - updated "git-completion.bash",
>   - freed "sparse_path_value" field in list_objects_filter_release(),
>   - updated tests (t5317 and t6112).
> Thanks to Matthew and Jeff for the suggestions.
>  contrib/completion/git-completion.bash |  2 +-
>  list-objects-filter-options.c          | 10 ++--
>  list-objects-filter-options.h          |  2 -
>  list-objects-filter.c                  | 22 --------
>  t/ | 71 +++++---------------------
>  t/    | 39 +++++---------
>  6 files changed, 33 insertions(+), 113 deletions(-)

What is curious is that this does not touch Documentation/ hierarchy
at all---is that a sign that nobody makes any serious use of the
--filter=... thing and we can freely drop "features" around it when
we see it necessary (like in this case)?

Or do we need something like this on top (or squashed in)?  I can
live with or without "Note that..." myself.


 Documentation/rev-list-options.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index ddbc1de43f..73aafea8d6 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -725,9 +725,6 @@ specification contained in the blob (or blob-expression) '<blob-ish>'
 to omit blobs that would not be not required for a sparse checkout on
 the requested refs.
-The form '--filter=sparse:path=<path>' similarly uses a sparse-checkout
-specification contained in <path>.
 The form '--filter=tree:<depth>' omits all blobs and trees whose depth
 from the root tree is >= <depth> (minimum depth if an object is located
 at multiple depths in the commits traversed). <depth>=0 will not include
@@ -737,6 +734,9 @@ tree and blobs which are referenced directly by a commit reachable from
 <commit> or an explicitly-given object. <depth>=2 is like <depth>=1
 while also including trees and blobs one more level removed from an
 explicitly-given commit or tree.
+Note that the form '--filter=sparse:path=<path>' that wants to read from
+an arbitrary path on the filesystem is not supported, for security reasons.
 	Turn off any previous `--filter=` argument.

  parent reply	other threads:[~2019-05-28 19:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-25 14:28 [PATCH v2] list-objects-filter: disable 'sparse:path' filters Christian Couder
2019-05-28  6:30 ` Jeff King
2019-05-28 19:41 ` Junio C Hamano [this message]
2019-05-29  7:29   ` Christian Couder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).