Toon ClaesandJohannes Schindelin
8bfbb74442
Like so many other open source projects, the Git project has seen an ever-increasing flood of security reports. Many of those reports describe valid bugs yet are redirected from the git-security mailing list because they are deemed "not vulnerabilities". While some Git contributors seem to have a very concrete idea how to discern between bugs that constitute vulnerabilities (and hence must be fixed in secret, to keep Git users safe) from bugs that can be fixed in the open, most reporters must be quite puzzled because the Git project provides no clear document to help define the security boundaries Git tries to guarantee. Of course, there _are_ hints and bits and pieces of documentation: Git's security guidance has accumulated across individual fixes. Some might be tempted to describe the boundary as "before clone" versus "after clone", but history establishes a more precise distinction.e69ac42fcc(docs: document security issues around untrusted .git dirs, 2024-04-16) explains why cloned content can generally be inspected with `git log`: repository-local hooks and configuration are not copied, whereas an untrusted `.git` directory remains unsafe.779ea9303a(Documentation: define protected configuration, 2022-07-14) likewise ties trust to configuration scope rather than timing alone. State the governing principle in one place: Git's security boundary concerns unexpected or implicit execution of attacker-controlled code. A theoretical opportunity to inspect repository contents is not consent to execute them. Conversely, explicitly choosing an execution-capable mechanism is materially different. Execution after clone is therefore not inherently a vulnerability. This distinction underlies4cd1cf31ef(Git 2.20.2, 2019-12-04), which describes CVE-2019-19604 as code running during recursive clone plus a submodule update "without the user explicitly having asked for that".a1d4f67c12(transport: make protocol.file.allow be user by default, 2022-07-29) likewise contrasts direct user action with recursion lacking user input.e4930e86c0(t5510: verify that D/F confusion cannot lead to an RCE, 2024-03-24) similarly frames remote code execution as code run by an operation not expected to run it. Timing remains relevant when it removes any meaningful choice.873a466ea3(clone: drop the protections where hooks aren't run, 2024-05-20) notes that clone-time hook execution leaves no chance to inspect first. Conversely,8d1a744820(setup.c: create safe.bareRepository, 2022-07-14) addresses post-clone use of embedded bare repositories. Together these cases show why timing alone cannot define the boundary. Assisted-by: GPT-5.6 Sol Helped-by: Patrick Steinhardt <ps@pks.im> Helped-by: Junio C Hamano <gitster@pobox.com> Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Toon Claes <toon@iotcl.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git - fast, scalable, distributed revision control system
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.
Please read the file INSTALL for installation instructions.
Many Git online resources are accessible from https://git-scm.com/ including full documentation and Git related tools.
See Documentation/gittutorial.adoc to get started, then see
Documentation/giteveryday.adoc for a useful minimum set of commands, and
Documentation/git-<commandname>.adoc for documentation of each command.
If git has been correctly installed, then the tutorial can also be
read with man gittutorial or git help tutorial, and the
documentation of each command with man git-<commandname> or git help <commandname>.
CVS users may also want to read Documentation/gitcvs-migration.adoc
(man gitcvs-migration or git help cvs-migration if git is
installed).
The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission and Documentation/CodingGuidelines).
Those wishing to help with error message, usage and informational message
string translations (localization l10) should see po/README.md
(a po file is a Portable Object file that holds the translations).
To subscribe to the list, send an email to git+subscribe@vger.kernel.org (see https://subspace.kernel.org/subscribing.html for details). The mailing list archives are available at https://lore.kernel.org/git/, https://marc.info/?l=git and other archival sites.
Issues which are security relevant should be disclosed privately to the Git Security mailing list git-security@googlegroups.com.
The maintainer frequently sends the "What's cooking" reports that list the current status of various development topics to the mailing list. The discussion following them give a good reference for project status, development direction and remaining tasks.
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks