git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
	"Jeff Hostetler" <jeffhost@microsoft.com>,
	"Jeff Hostetler" <git@jeffhostetler.com>,
	"Jonathan Tan" <jonathantanmy@google.com>,
	"Matthew DeVore" <matvore@google.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Christian Couder" <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2] list-objects-filter: disable 'sparse:path' filters
Date: Tue, 28 May 2019 12:41:58 -0700	[thread overview]
Message-ID: <xmqqo93m1i49.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190525142834.6168-1-chriscool@tuxfamily.org> (Christian Couder's message of "Sat, 25 May 2019 16:28:34 +0200")

Christian Couder <christian.couder@gmail.com> 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 <matvore@google.com>
> Helped-by: Jeff Hostetler <git@jeffhostetler.com>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
>
> 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/t5317-pack-objects-filter-objects.sh | 71 +++++---------------------
>  t/t6112-rev-list-filters-objects.sh    | 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.

Thanks.


 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.
 
 --no-filter::
 	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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqo93m1i49.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=jeffhost@microsoft.com \
    --cc=jonathantanmy@google.com \
    --cc=matvore@google.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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).