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

Re: [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
May 28, 2024, 15:02 UTC
Message-ID
<8353645a-a684-417a-8b0e-d8cbd7da6b5a@gmail.com>
In-Reply-To
<99225123-70f0-3546-a6fa-b6d1f981b41d@gmx.de>
Hi Johannes
On 27/05/2024 20:51, Johannes Schindelin wrote:
Show 20 quoted lines
> Hi Joey,
> 
> On Thu, 23 May 2024, Joey Hess wrote:
> 
>> Junio C Hamano wrote:
>>>   - The extra check seems to have meant to target the symbolic links
>>>     that point at objects, refs, config, and anything _we_ care
>>>     about, as opposed to random garbage (from _our_ point of view)
>>>     files third-parties throw into .git/ directory.  Would it have
>>>     made a better trade-off if we tried to make the check more
>>>     precise, only complaining about the things we care about (in
>>>     other words, what _we_ use)
>>
>> I wondered about that possibility too. But it's not at all clear to
>> me how a symlink to .git/objects/foo risks any more security problem
>> to git than one to .git/annex/whatever, or indeed to /home/linus/.bashrc.
> 
> It risks more security problems because `.git/objects/??/*` is not
> re-hashed when it is being used by Git. That's a very easy way to slip in
> unwanted file contents.

What checks do we have in place to prevent git checking out blobs and gitlinks to paths under .git/? I'd have thought we should be applying the same restrictions to the target of symbolic links as we do to those.

Show 6 quoted lines
> And there is a good reason _not_ to write stuff inside the `.git/`
> directory unless you happen to be, well, Git itself: Git makes no
> guarantees whatsoever that you can write into that directory whatever you
> want. A future Git version might even write a file `.git/annex`, breaking
> `git-annex`' assumptions, and that'd be totally within the guarantees Git
> makes.

This seems a bit harsh - many tools store their state under .git/ and I think it makes sense for them to do so as it avoids creating untracked files in the working copy. I would hope that we'd be considerate of widely used tools such as 'git annex' when adding new paths under .git/

Best Wishes
Phillip
Previous: Joey HessNext: Junio C Hamano
Message 33 of 36 in “Fix various overly aggressive protections in 2.45.1 and friends”
  1. 00/12 Fix various overly aggressive protections in 2.45.1 and friendsJunio C Hamano, May 21, 2024
  2. 02/12 send-email: avoid creating more than one Term::ReadLine objectJunio C Hamano, May 21, 2024
  3. Dragan SimicMay 22, 2024
  4. 03/12 ci: drop mention of BREW_INSTALL_PACKAGES variableJunio C Hamano, May 21, 2024
  5. 01/12 send-email: drop FakeTerm hackJunio C Hamano, May 21, 2024
  6. Dragan SimicMay 22, 2024
  7. 04/12 ci: avoid bare "gcc" for osx-gcc jobJunio C Hamano, May 21, 2024
  8. 05/12 ci: stop installing "gcc-13" for osx-gccJunio C Hamano, May 21, 2024
  9. 06/12 hook: plug a new memory leakJunio C Hamano, May 21, 2024
  10. 07/12 init: use the correct path of the templates directory againJunio C Hamano, May 21, 2024
  11. 08/12 Revert "core.hooksPath: add some protection while cloning"Junio C Hamano, May 21, 2024
  12. 09/12 tests: verify that `clone -c core.hooksPath=/dev/null` works againJunio C Hamano, May 21, 2024
  13. Brooke KuhlmannMay 21, 2024
  14. 10/12 clone: drop the protections where hooks aren't runJunio C Hamano, May 21, 2024
  15. 11/12 Revert "Add a helper function to compare file contents"Junio C Hamano, May 21, 2024
  16. 12/12 Revert "fetch/clone: detect dubious ownership of local repositories"Junio C Hamano, May 21, 2024
  17. Junio C HamanoMay 21, 2024
  18. Johannes SchindelinMay 22, 2024
  19. Junio C HamanoMay 22, 2024
  20. 13/12 Merge branch 'jc/fix-aggressive-protection-2.39'Junio C Hamano, May 21, 2024
  21. Reviewing merge commits, was Re: [rPATCH 13/12] Merge branch 'jc/fix-aggressive-protection-2.39'Johannes Schindelin, May 23, 2024
  22. Junio C HamanoMay 23, 2024
  23. 14/12 Merge branch 'jc/fix-aggressive-protection-2.40'Junio C Hamano, May 21, 2024
  24. Junio C HamanoMay 21, 2024
  25. Johannes SchindelinMay 21, 2024
  26. Junio C HamanoMay 21, 2024
  27. Junio C HamanoMay 21, 2024
  28. Joey HessMay 22, 2024
  29. Junio C HamanoMay 23, 2024
  30. Joey HessMay 23, 2024
  31. Johannes SchindelinMay 27, 2024
  32. Joey HessMay 28, 2024
  33. Phillip WoodMay 28, 2024
  34. Junio C HamanoMay 28, 2024
  35. Junio C HamanoMay 28, 2024
  36. Junio C HamanoMay 23, 2024

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.