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

Re: Intricacies of submodules

From
JMJeremy Maitin-Shepard <jbms@cmu.edu>
Date
Apr 17, 2008, 18:09 UTC
Message-ID
<87lk3c4ali.fsf@jeremyms.com>
In-Reply-To
<1208317795.26863.91.camel@goose.sun.com>
"Roman V. Shaposhnik" <rvs@sun.com> writes:
[snip]
Show 7 quoted lines
> I'm sorry, but I don't buy this argument. If you have a malicious user
> gaining access to the repository all bets are off. To single out 
> in-tree .gitconfig as the only place which could be hacked seems to
> be a bit shortsighted and unfair. Any "executable" portion of your
> project that rarely gets eyeballed (such as Makefile infrastrucutre)
> could be used. In fact, under your scenario in-tree .gitconfig is
> likely to be the least of your worries. 
> 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.

Obviously actually executing untrusted code is unsafe regardless of whether you type "git clone" or "make" to do it, but not everyone intends to type "make" after checking out an unknown repository, and the user is explicitly invoking make with the knowledge that it is running whatever code is in the repository. Similarly, if the user explicitly calls some shell script in order to set things up, he is conscious that he is performing a potentially unsafe operation.

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.

[snip]
Show 8 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.

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.

-- 
Jeremy Maitin-Shepard
Previous: Roman V. ShaposhnikNext: Linus Torvalds
Message 24 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.