From: "Roman V. Shaposhnik" <rvs@sun•com>
To: Jeremy Maitin-Shepard <jbms@cmu•edu>
Cc: Junio C Hamano <gitster@pobox•com>,
Ping Yin <pkufranky@gmail•com>,
Avery Pennarun <apenwarr@gmail•com>,
stuart.freeman@et•gatech.edu, git@vger•kernel.org
Subject: Re: Intricacies of submodules
Date: Thu, 17 Apr 2008 12:50:08 -0700 [thread overview]
Message-ID: <1208461808.26863.129.camel@goose.sun.com> (raw)
In-Reply-To: <87lk3c4ali.fsf@jeremyms.com>
On Thu, 2008-04-17 at 14:09 -0400, Jeremy Maitin-Shepard wrote:
> > And here's one more thing: in-tree .gitconfig and in-tree
> > update-my-git-settings.sh are absolutely identical as far
> > as their security ramifications are concerned. If you really paranoid
> > you have to eyeball either of them.
>
> There is a huge difference: if you allow in-tree .gitconfig by default,
> then git clone <some-repository> becomes an unsafe operation. I can't
> even inspect some arbitrary repository to _see_ if I like the code and
> think it is safe very easily, since I'd normally do that by cloning the
> repository.
Are you saying that a *remote* in-tree .gitconfig would be capable of
affecting *local* system before the end of the clone operation? I find
it very hard to believe. And if it is so, I'd love to be educated on the
subject matter. What I (and to some extent Ping Yin) have been proposing
is a completely different semantics -- the in-tree .gitconfig would only
be able to affect your *local* operations. Doing clone of the *remote*
repository is a safe operation under such assumptions. Once you cloned
it, you might need to eyeball the content of .gitconfig if you're really
paranoid.
> As a silly analogy, it is currently perfectly safe to clone a repository
> that has a text document containing instructions about committing
> suicide, because there is the assumption that the instructions are not
> automatically executed simply because they are on the user's hard drive.
Same holds true for the semantics being proposed. The intsructions are
*not* executed until you actually try to do something with your
repository. There's a window of opportunity in which inspecting the
content of .gitconfig is absolutely possible.
> > Why? I'm really confused here. Unless I'm given a clear example of at
> > least one setting that somehow becomes dangerous when stored inside
> > in-tree .gitconfig, I really do consider such an enforcement to be
> > as meaningful as enforcing that Git MUST manage source code and nothing
> > else. You seemed to mention the trust issue. Well, why don't you trust
> > the user to place whatever he wants in in-tree .gitconfig? And yes,
> > we are talking about trustworthy users here and repositories that
> > haven't been compromised.
>
> Obviously any configuration option that specifies a shell command to run
> is unsafe to specify in an in-tree .gitconfig. As Junio noted,
> smudge/clean commands are especially unsafe because they will be
> executed even if the user only uses the clone command.
I'm sorry but I guess that went over my head. Is this the example of
something that can affect local repository (and host!) during the
clone operation? I tried to find documentation on the subject but
googling for "git smudge" returns very few useful hits and the bits
of documentation in gitattributes(5) don't really explain much.
> You actually seem to be the one assuming that a Git repository must
> store source code (in particular source code that is then blindly
> executed by anyone that clones the repository), as that is the only case
> in which an in-tree .gitconfig can introduce no additional security
> risk, since your security is then already completely dependent on
> trusting the contents of the repository.
There are two things at play: first of all, I usually *do* trust the
content of the repository. Call it matter of personal preference,
but *for me* if you start with distrust -- there's very little you
can do with that repository to begin with. To me it is a bit of
red herring. On the other hand I understand where you're coming from
and I definitely appreciate the need for a clone operation to be
safe. So far, the only example of an unsafe setting that I have been
given is smudge/clean filters. May be this is enough to shoot the
very idea of an in-tree .gitconfig down, but I still don't really
understand the *complete* semantics of these things. Can somebody
explain, please?
I hope this is not too much to ask.
Thanks,
Roman.
next prev parent reply other threads:[~2008-04-17 19:40 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 20:59 Migrating svn to git with heavy use of externals D. Stuart Freeman
2008-04-08 18:07 ` D. Stuart Freeman
2008-04-08 20:06 ` Avery Pennarun
2008-04-08 20:49 ` D. Stuart Freeman
2008-04-08 21:01 ` Avery Pennarun
2008-04-08 22:47 ` D. Stuart Freeman
2008-04-09 3:03 ` Roman Shaposhnik
2008-04-09 3:33 ` Avery Pennarun
2008-04-09 4:39 ` Roman Shaposhnik
2008-04-09 6:34 ` Avery Pennarun
2008-04-09 6:43 ` Junio C Hamano
2008-04-10 3:43 ` Intricacies of submodules [was: Migrating svn to git with heavy use of externals] Roman Shaposhnik
2008-04-10 5:53 ` Intricacies of submodules Junio C Hamano
2008-04-10 20:32 ` Roman Shaposhnik
2008-04-11 5:20 ` Junio C Hamano
2008-04-11 16:04 ` Ping Yin
2008-04-11 22:32 ` Junio C Hamano
2008-04-12 3:13 ` Roman Shaposhnik
2008-04-12 5:11 ` Junio C Hamano
2008-04-14 19:52 ` Roman Shaposhnik
2008-04-15 1:13 ` Junio C Hamano
2008-04-15 2:13 ` Ping Yin
2008-04-16 3:49 ` Roman V. Shaposhnik
2008-04-17 18:09 ` Jeremy Maitin-Shepard
2008-04-17 19:06 ` Linus Torvalds
2008-04-17 20:04 ` Junio C Hamano
[not found] ` <32541b130804181128j57d76edcsbbd5fb8d4c782ae7@mail.gmail.com>
2008-04-18 18:30 ` Avery Pennarun
2008-04-17 19:50 ` Roman V. Shaposhnik [this message]
2008-04-17 20:06 ` Martin Langhoff
2008-04-17 20:44 ` Junio C Hamano
2008-04-17 21:00 ` Sverre Rabbelier
2008-04-17 21:25 ` Martin Langhoff
2008-04-17 21:27 ` Sverre Rabbelier
2008-04-17 21:31 ` Martin Langhoff
2008-04-18 1:41 ` Ping Yin
2008-04-17 22:29 ` Dmitry Potapov
2008-04-17 22:32 ` Linus Torvalds
2008-04-18 1:48 ` Ping Yin
2008-04-18 14:02 ` Jakub Narebski
2008-04-12 3:20 ` Ping Yin
2008-04-14 19:56 ` Roman Shaposhnik
2008-04-12 4:02 ` Ping Yin
2008-04-12 5:25 ` Junio C Hamano
2008-04-12 6:26 ` Ping Yin
2008-04-10 16:07 ` Intricacies of submodules [was: Migrating svn to git with heavy use of externals] Ping Yin
2008-04-10 19:27 ` Roman Shaposhnik
2008-04-09 19:57 ` Roman Shaposhnik
2008-04-09 20:27 ` Avery Pennarun
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1208461808.26863.129.camel@goose.sun.com \
--to=rvs@sun$(echo .)com \
--cc=apenwarr@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jbms@cmu$(echo .)edu \
--cc=pkufranky@gmail$(echo .)com \
--cc=stuart.freeman@et$(echo .)gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox