git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Intricacies of submodules

From
RSRoman V. Shaposhnik <rvs@sun.com>
Date
Apr 17, 2008, 19:50 UTC
Message-ID
<1208461808.26863.129.camel@goose.sun.com>
In-Reply-To
<87lk3c4ali.fsf@jeremyms.com>
On Thu, 2008-04-17 at 14:09 -0400, Jeremy Maitin-Shepard wrote:
Show 10 quoted lines
> > 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.

Show 13 quoted lines
> > 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.

Show 6 quoted lines
> 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.

Previous: Junio C HamanoNext: Martin Langhoff
Message 27 of 48 in “Migrating svn to git with heavy use of externals”
  1. D. Stuart FreemanMar 31, 2008
  2. D. Stuart FreemanApr 8, 2008
  3. Avery PennarunApr 8, 2008
  4. D. Stuart FreemanApr 8, 2008
  5. Avery PennarunApr 8, 2008
  6. D. Stuart FreemanApr 8, 2008
  7. Roman ShaposhnikApr 9, 2008
  8. Avery PennarunApr 9, 2008
  9. Roman ShaposhnikApr 9, 2008
  10. Avery PennarunApr 9, 2008
  11. Junio C HamanoApr 9, 2008
  12. Intricacies of submodules [was: Migrating svn to git with heavy use of externals]Roman Shaposhnik, Apr 10, 2008
  13. Junio C HamanoApr 10, 2008
  14. Roman ShaposhnikApr 10, 2008
  15. Junio C HamanoApr 11, 2008
  16. Ping YinApr 11, 2008
  17. Junio C HamanoApr 11, 2008
  18. Roman ShaposhnikApr 12, 2008
  19. Junio C HamanoApr 12, 2008
  20. Roman ShaposhnikApr 14, 2008
  21. Junio C HamanoApr 15, 2008
  22. Ping YinApr 15, 2008
  23. Roman V. ShaposhnikApr 16, 2008
  24. Jeremy Maitin-ShepardApr 17, 2008
  25. Linus TorvaldsApr 17, 2008
  26. Junio C HamanoApr 17, 2008
  27. Roman V. ShaposhnikApr 17, 2008
  28. Martin LanghoffApr 17, 2008
  29. Junio C HamanoApr 17, 2008
  30. Sverre RabbelierApr 17, 2008
  31. Martin LanghoffApr 17, 2008
  32. Sverre RabbelierApr 17, 2008
  33. Martin LanghoffApr 17, 2008
  34. Ping YinApr 18, 2008
  35. Dmitry PotapovApr 17, 2008
  36. Linus TorvaldsApr 17, 2008
  37. Ping YinApr 18, 2008
  38. Jakub NarebskiApr 18, 2008
  39. Ping YinApr 12, 2008
  40. Roman ShaposhnikApr 14, 2008
  41. Ping YinApr 12, 2008
  42. Junio C HamanoApr 12, 2008
  43. Ping YinApr 12, 2008
  44. Ping YinApr 10, 2008
  45. Roman ShaposhnikApr 10, 2008
  46. Intricacies of submodules [was: Migrating svn to git with heavy use of externals]Roman Shaposhnik, Apr 9, 2008
  47. Avery PennarunApr 9, 2008
  48. Avery PennarunApr 18, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.