diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/CodingGuidelines | 37 | ||||
| -rw-r--r-- | Documentation/RelNotes/2.11.1.txt | 165 | ||||
| -rw-r--r-- | Documentation/config.txt | 43 | ||||
| -rw-r--r-- | Documentation/date-formats.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-bisect.txt | 4 | ||||
| -rw-r--r-- | Documentation/git-commit.txt | 3 | ||||
| -rw-r--r-- | Documentation/git-fetch-pack.txt | 6 | ||||
| -rw-r--r-- | Documentation/git-fetch.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-gc.txt | 34 | ||||
| -rw-r--r-- | Documentation/git-pull.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-push.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-svn.txt | 8 | ||||
| -rw-r--r-- | Documentation/git.txt | 9 | ||||
| -rw-r--r-- | Documentation/gitattributes.txt | 4 | ||||
| -rw-r--r-- | Documentation/gitcore-tutorial.txt | 12 | ||||
| -rw-r--r-- | Documentation/gitnamespaces.txt | 20 | ||||
| -rw-r--r-- | Documentation/technical/api-in-core-index.txt | 21 | ||||
| -rw-r--r-- | Documentation/transfer-data-leaks.txt | 30 |
18 files changed, 328 insertions, 76 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 4cd95da6b1..a4191aa388 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -206,11 +206,38 @@ For C programs: x = 1; } - is frowned upon. A gray area is when the statement extends - over a few lines, and/or you have a lengthy comment atop of - it. Also, like in the Linux kernel, if there is a long list - of "else if" statements, it can make sense to add braces to - single line blocks. + is frowned upon. But there are a few exceptions: + + - When the statement extends over a few lines (e.g., a while loop + with an embedded conditional, or a comment). E.g.: + + while (foo) { + if (x) + one(); + else + two(); + } + + if (foo) { + /* + * This one requires some explanation, + * so we're better off with braces to make + * it obvious that the indentation is correct. + */ + doit(); + } + + - When there are multiple arms to a conditional and some of them + require braces, enclose even a single line block in braces for + consistency. E.g.: + + if (foo) { + doit(); + } else { + one(); + two(); + three(); + } - We try to avoid assignments in the condition of an "if" statement. diff --git a/Documentation/RelNotes/2.11.1.txt b/Documentation/RelNotes/2.11.1.txt new file mode 100644 index 0000000000..28240cdd24 --- /dev/null +++ b/Documentation/RelNotes/2.11.1.txt @@ -0,0 +1,165 @@ +Git v2.11.1 Release Notes +========================= + +Fixes since v2.11 +----------------- + + * The default Travis-CI configuration specifies newer P4 and GitLFS. + + * The character width table has been updated to match Unicode 9.0 + + * Update the isatty() emulation for Windows by updating the previous + hack that depended on internals of (older) MSVC runtime. + + * "git rev-parse --symbolic" failed with a more recent notation like + "HEAD^-1" and "HEAD^!". + + * An empty directory in a working tree that can simply be nuked used + to interfere while merging or cherry-picking a change to create a + submodule directory there, which has been fixed.. + + * The code in "git push" to compute if any commit being pushed in the + superproject binds a commit in a submodule that hasn't been pushed + out was overly inefficient, making it unusable even for a small + project that does not have any submodule but have a reasonable + number of refs. + + * "git push --dry-run --recurse-submodule=on-demand" wasn't + "--dry-run" in the submodules. + + * The output from "git worktree list" was made in readdir() order, + and was unstable. + + * mergetool.<tool>.trustExitCode configuration variable did not apply + to built-in tools, but now it does. + + * "git p4" LFS support was broken when LFS stores an empty blob. + + * Fix a corner case in merge-recursive regression that crept in + during 2.10 development cycle. + + * Update the error messages from the dumb-http client when it fails + to obtain loose objects; we used to give sensible error message + only upon 404 but we now forbid unexpected redirects that needs to + be reported with something sensible. + + * When diff.renames configuration is on (and with Git 2.9 and later, + it is enabled by default, which made it worse), "git stash" + misbehaved if a file is removed and another file with a very + similar content is added. + + * "git diff --no-index" did not take "--no-abbrev" option. + + * "git difftool --dir-diff" had a minor regression when started from + a subdirectory, which has been fixed. + + * "git commit --allow-empty --only" (no pathspec) with dirty index + ought to be an acceptable way to create a new commit that does not + change any paths, but it was forbidden, perhaps because nobody + needed it so far. + + * A pathname that begins with "//" or "\\" on Windows is special but + path normalization logic was unaware of it. + + * "git pull --rebase", when there is no new commits on our side since + we forked from the upstream, should be able to fast-forward without + invoking "git rebase", but it didn't. + + * The way to specify hotkeys to "xxdiff" that is used by "git + mergetool" has been modernized to match recent versions of xxdiff. + + * Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back + to where cherry-pick started while picking multiple changes, when + the cherry-pick stopped to ask for help from the user, and the user + did "git reset --hard" to a different commit in order to re-attempt + the operation. + + * Code cleanup in shallow boundary computation. + + * A recent update to receive-pack to make it easier to drop garbage + objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot + have a pathname with a colon in it (no surprise!), and this in turn + made it impossible to push into a repository at such a path. This + has been fixed by introducing a quoting mechanism used when + appending such a path to the colon-separated list. + + * The function usage_msg_opt() has been updated to say "fatal:" + before the custom message programs give, when they want to die + with a message about wrong command line options followed by the + standard usage string. + + * "git index-pack --stdin" needs an access to an existing repository, + but "git index-pack file.pack" to generate an .idx file that + corresponds to a packfile does not. + + * Fix for NDEBUG builds. + + * A lazy "git push" without refspec did not internally use a fully + specified refspec to perform 'current', 'simple', or 'upstream' + push, causing unnecessary "ambiguous ref" errors. + + * "git p4" misbehaved when swapping a directory and a symbolic link. + + * Even though an fix was attempted in Git 2.9.3 days, but running + "git difftool --dir-diff" from a subdirectory never worked. This + has been fixed. + + * "git p4" that tracks multile p4 paths imported a single changelist + that touches files in these multiple paths as one commit, followed + by many empty commits. This has been fixed. + + * A potential but unlikely buffer overflow in Windows port has been + fixed. + + * When the http server gives an incomplete response to a smart-http + rpc call, it could lead to client waiting for a full response that + will never come. Teach the client side to notice this condition + and abort the transfer. + + * Some platforms no longer understand "latin-1" that is still seen in + the wild in e-mail headers; replace them with "iso-8859-1" that is + more widely known when conversion fails from/to it. + + * Update the procedure to generate "tags" for developer support. + + * Update the definition of the MacOSX test environment used by + TravisCI. + + * A few git-svn updates. + + * Compression setting for producing packfiles were spread across + three codepaths, one of which did not honor any configuration. + Unify these so that all of them honor core.compression and + pack.compression variables the same way. + + * "git fast-import" sometimes mishandled while rebalancing notes + tree, which has been fixed. + + * Recent update to the default abbreviation length that auto-scales + lacked documentation update, which has been corrected. + + * Leakage of lockfiles in the config subsystem has been fixed. + + * It is natural that "git gc --auto" may not attempt to pack + everything into a single pack, and there is no point in warning + when the user has configured the system to use the pack bitmap, + leading to disabling further "gc". + + * "git archive" did not read the standard configuration files, and + failed to notice a file that is marked as binary via the userdiff + driver configuration. + + * "git blame --porcelain" misidentified the "previous" <commit, path> + pair (aka "source") when contents came from two or more files. + + * "git rebase -i" with a recent update started showing an incorrect + count when squashing more than 10 commits. + + * "git <cmd> @{push}" on a detached HEAD used to segfault; it has + been corrected to error out with a message. + + * Tighten a test to avoid mistaking an extended ERE regexp engine as + a PRE regexp engine. + + +Also contains various documentation updates and code clean-ups. diff --git a/Documentation/config.txt b/Documentation/config.txt index a0ab66aae7..1fee83ca42 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -783,10 +783,11 @@ core.sparseCheckout:: linkgit:git-read-tree[1] for more information. core.abbrev:: - Set the length object names are abbreviated to. If unspecified, - many commands abbreviate to 7 hexdigits, which may not be enough - for abbreviated object names to stay unique for sufficiently long - time. + Set the length object names are abbreviated to. If + unspecified or set to "auto", an appropriate value is + computed based on the approximate number of packed objects + in your repository, which hopefully is enough for + abbreviated object names to stay unique for some time. add.ignoreErrors:: add.ignore-errors (deprecated):: @@ -1409,7 +1410,9 @@ gc.pruneExpire:: Override the grace period with this config variable. The value "now" may be used to disable this grace period and always prune unreachable objects immediately, or "never" may be used to - suppress pruning. + suppress pruning. This feature helps prevent corruption when + 'git gc' runs concurrently with another process writing to the + repository; see the "NOTES" section of linkgit:git-gc[1]. gc.worktreePruneExpire:: When 'git gc' is run, it calls @@ -1891,6 +1894,16 @@ http.userAgent:: of common USER_AGENT strings (but not including those like git/1.7.1). Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable. +http.followRedirects:: + Whether git should follow HTTP redirects. If set to `true`, git + will transparently follow any redirect issued by a server it + encounters. If set to `false`, git will treat all redirects as + errors. If set to `initial`, git will follow redirects only for + the initial request to a remote, but not for subsequent + follow-up HTTP requests. Since git uses the redirected URL as + the base for the follow-up requests, this is generally + sufficient. The default is `initial`. + http.<url>.*:: Any of the http.* options above can be applied selectively to some URLs. For a config key to match a URL, each element of the config key is @@ -2930,6 +2943,11 @@ is omitted from the advertisements but `refs/heads/master` and `refs/namespaces/bar/refs/heads/master` are still advertised as so-called "have" lines. In order to match refs before stripping, add a `^` in front of the ref name. If you combine `!` and `^`, `!` must be specified first. ++ +Even if you hide refs, a client may still be able to steal the target +objects via the techniques described in the "SECURITY" section of the +linkgit:gitnamespaces[7] man page; it's best to keep private data in a +separate repository. transfer.unpackLimit:: When `fetch.unpackLimit` or `receive.unpackLimit` are @@ -2939,7 +2957,7 @@ transfer.unpackLimit:: uploadarchive.allowUnreachable:: If true, allow clients to use `git archive --remote` to request any tree, whether reachable from the ref tips or not. See the - discussion in the `SECURITY` section of + discussion in the "SECURITY" section of linkgit:git-upload-archive[1] for more details. Defaults to `false`. @@ -2953,12 +2971,23 @@ uploadpack.allowTipSHA1InWant:: When `uploadpack.hideRefs` is in effect, allow `upload-pack` to accept a fetch request that asks for an object at the tip of a hidden ref (by default, such a request is rejected). - see also `uploadpack.hideRefs`. + See also `uploadpack.hideRefs`. Even if this is false, a client + may be able to steal objects via the techniques described in the + "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's + best to keep private data in a separate repository. uploadpack.allowReachableSHA1InWant:: Allow `upload-pack` to accept a fetch request that asks for an object that is reachable from any ref tip. However, note that calculating object reachability is computationally expensive. + Defaults to `false`. Even if this is false, a client may be able + to steal objects via the techniques described in the "SECURITY" + section of the linkgit:gitnamespaces[7] man page; it's best to + keep private data in a separate repository. + +uploadpack.allowAnySHA1InWant:: + Allow `upload-pack` to accept a fetch request that asks for any + object at all. Defaults to `false`. uploadpack.keepAlive:: diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index 35e8da2010..6926e0a4c8 100644 --- a/Documentation/date-formats.txt +++ b/Documentation/date-formats.txt @@ -11,7 +11,7 @@ Git internal format:: It is `<unix timestamp> <time zone offset>`, where `<unix timestamp>` is the number of seconds since the UNIX epoch. `<time zone offset>` is a positive or negative offset from UTC. - For example CET (which is 2 hours ahead UTC) is `+0200`. + For example CET (which is 1 hour ahead of UTC) is `+0100`. RFC 2822:: The standard email format as described by RFC 2822, for example diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 2bb9a577a2..bdd915a66b 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -18,8 +18,8 @@ on the subcommand: git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>] [--no-checkout] [<bad> [<good>...]] [--] [<paths>...] - git bisect (bad|new) [<rev>] - git bisect (good|old) [<rev>...] + git bisect (bad|new|<term-new>) [<rev>] + git bisect (good|old|<term-old>) [<rev>...] git bisect terms [--term-good | --term-bad] git bisect skip [(<rev>|<range>)...] git bisect reset [<commit>] diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index f2ab0ee2e7..4f8f20a360 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -265,7 +265,8 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) If this option is specified together with `--amend`, then no paths need to be specified, which can be used to amend the last commit without committing changes that have - already been staged. + already been staged. If used together with `--allow-empty` + paths are also not required, and an empty commit will be created. -u[<mode>]:: --untracked-files[=<mode>]:: diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index d45f6adc69..f7ebe36a7b 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -119,9 +119,9 @@ be in a separate packet, and the list must end with a flush packet. $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When unspecified, update from all heads the remote side has. + -If the remote has enabled the options `uploadpack.allowTipSHA1InWant` or -`uploadpack.allowReachableSHA1InWant`, they may alternatively be 40-hex -sha1s present on the remote. +If the remote has enabled the options `uploadpack.allowTipSHA1InWant`, +`uploadpack.allowReachableSHA1InWant`, or `uploadpack.allowAnySHA1InWant`, +they may alternatively be 40-hex sha1s present on the remote. SEE ALSO -------- diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index 9e4216999d..b153aefa68 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -192,6 +192,8 @@ The first command fetches the `maint` branch from the repository at objects will eventually be removed by git's built-in housekeeping (see linkgit:git-gc[1]). +include::transfer-data-leaks.txt[] + BUGS ---- Using --recurse-submodules can only fetch new commits in already checked diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index bed60f471c..852b72c679 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -63,11 +63,10 @@ automatic consolidation of packs. --prune=<date>:: Prune loose objects older than date (default is 2 weeks ago, overridable by the config variable `gc.pruneExpire`). - --prune=all prunes loose objects regardless of their age (do - not use --prune=all unless you know exactly what you are doing. - Unless the repository is quiescent, you will lose newly created - objects that haven't been anchored with the refs and end up - corrupting your repository). --prune is on by default. + --prune=all prunes loose objects regardless of their age and + increases the risk of corruption if another process is writing to + the repository concurrently; see "NOTES" below. --prune is on by + default. --no-prune:: Do not prune any loose objects. @@ -138,17 +137,36 @@ default is "2 weeks ago". Notes ----- -'git gc' tries very hard to be safe about the garbage it collects. In +'git gc' tries very hard not to delete objects that are referenced +anywhere in your repository. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by 'git filter-branch' in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). - -If you are expecting some objects to be collected and they aren't, check +If you are expecting some objects to be deleted and they aren't, check all of those locations and decide whether it makes sense in your case to remove those references. +On the other hand, when 'git gc' runs concurrently with another process, +there is a risk of it deleting an object that the other process is using +but hasn't created a reference to. This may just cause the other process +to fail or may corrupt the repository if the other process later adds a +reference to the deleted object. Git has two features that significantly +mitigate this problem: + +. Any object with modification time newer than the `--prune` date is kept, + along with everything reachable from it. + +. Most operations that add an object to the database update the + modification time of the object if it is already present so that #1 + applies. + +However, these features fall short of a complete solution, so users who +run commands concurrently have to live with some risk of corruption (which +seems to be low in practice) unless they turn off automatic garbage +collection with 'git config gc.auto 0'. + HOOKS ----- diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index d033b258e5..4470e4b574 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -237,6 +237,8 @@ If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with 'git reset'. +include::transfer-data-leaks.txt[] + BUGS ---- Using --recurse-submodules can only fetch new commits in already checked diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 47b77e693b..8eefabd0d1 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -559,6 +559,8 @@ Commits A and B would no longer belong to a branch with a symbolic name, and so would be unreachable. As such, these commits would be removed by a `git gc` command on the origin repository. +include::transfer-data-leaks.txt[] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 5f9e65b0c4..9bee9b0c4c 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -664,13 +664,19 @@ creating the branch or tag. When retrieving svn commits into Git (as part of 'fetch', 'rebase', or 'dcommit' operations), look for the first `From:` or `Signed-off-by:` line in the log message and use that as the author string. ++ +[verse] +config key: svn.useLogAuthor + --add-author-from:: When committing to svn from Git (as part of 'commit-diff', 'set-tree' or 'dcommit' operations), if the existing log message doesn't already have a `From:` or `Signed-off-by:` line, append a `From:` line based on the Git commit's author string. If you use this, then `--use-log-author` will retrieve a valid author string for all commits. - ++ +[verse] +config key: svn.addAuthorFrom ADVANCED OPTIONS ---------------- diff --git a/Documentation/git.txt b/Documentation/git.txt index af191c51b1..bdab261515 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -44,9 +44,10 @@ unreleased) version of Git, that is available from the 'master' branch of the `git.git` repository. Documentation for older releases are available here: -* link:v2.11.0/git.html[documentation for release 2.11] +* link:v2.11.1/git.html[documentation for release 2.11.1] * release notes for + link:RelNotes/2.11.1.txt[2.11.1], link:RelNotes/2.11.0.txt[2.11]. * link:v2.10.2/git.html[documentation for release 2.10.2] @@ -871,6 +872,12 @@ Git so take care if using a foreign front-end. specifies a ":" separated (on Windows ";" separated) list of Git object directories which can be used to search for Git objects. New objects will not be written to these directories. ++ + Entries that begin with `"` (double-quote) will be interpreted + as C-style quoted paths, removing leading and trailing + double-quotes and respecting backslash escapes. E.g., the value + `"path-with-\"-and-:-in-it":vanilla-path` has two paths: + `path-with-"-and-:-in-it` and `vanilla-path`. `GIT_DIR`:: If the `GIT_DIR` environment variable is set then it diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 976243a63e..e0b66c1220 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -435,7 +435,9 @@ to filter relative to the repository root. Right after the flush packet Git sends the content split in zero or more pkt-line packets and a flush packet to terminate content. Please note, that the filter must not send any response before it received the content and the -final flush packet. +final flush packet. Also note that the "value" of a "key=value" pair +can contain the "=" character whereas the key would never contain +that character. ------------------------ packet: git> command=smudge packet: git> pathname=path/testfile.dat diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 4546fa0d75..22309cfb48 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -25,7 +25,7 @@ you want to understand Git's internals. The core Git is often called "plumbing", with the prettier user interfaces on top of it called "porcelain". You may not want to use the plumbing directly very often, but it can be good to know what the -plumbing does for when the porcelain isn't flushing. +plumbing does when the porcelain isn't flushing. Back when this document was originally written, many porcelain commands were shell scripts. For simplicity, it still uses them as @@ -1368,7 +1368,7 @@ $ git repack will do it for you. If you followed the tutorial examples, you would have accumulated about 17 objects in `.git/objects/??/` directories by now. 'git repack' tells you how many objects it -packed, and stores the packed file in `.git/objects/pack` +packed, and stores the packed file in the `.git/objects/pack` directory. [NOTE] @@ -1478,7 +1478,7 @@ You can repack this private repository whenever you feel like. A recommended work cycle for a "subsystem maintainer" who works on that project and has an own "public repository" goes like this: -1. Prepare your work repository, by 'git clone' the public +1. Prepare your work repository, by running 'git clone' on the public repository of the "project lead". The URL used for the initial cloning is stored in the remote.origin.url configuration variable. @@ -1543,9 +1543,9 @@ like this: Working with Others, Shared Repository Style -------------------------------------------- -If you are coming from CVS background, the style of cooperation +If you are coming from a CVS background, the style of cooperation suggested in the previous section may be new to you. You do not -have to worry. Git supports "shared public repository" style of +have to worry. Git supports the "shared public repository" style of cooperation you are probably more familiar with as well. See linkgit:gitcvs-migration[7] for the details. @@ -1635,7 +1635,7 @@ $ git show-branch ++* [master~2] Pretty-print messages. ------------ -Note that you should not do Octopus because you can. An octopus +Note that you should not do Octopus just because you can. An octopus is a valid thing to do and often makes it easier to view the commit history if you are merging more than two independent changes at the same time. However, if you have merge conflicts diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt index 7685e3651a..b614969ad2 100644 --- a/Documentation/gitnamespaces.txt +++ b/Documentation/gitnamespaces.txt @@ -61,22 +61,4 @@ For a simple local test, you can use linkgit:git-remote-ext[1]: git clone ext::'git --namespace=foo %s /tmp/prefixed.git' ---------- -SECURITY --------- - -Anyone with access to any namespace within a repository can potentially -access objects from any other namespace stored in the same repository. -You can't directly say "give me object ABCD" if you don't have a ref to -it, but you can do some other sneaky things like: - -. Claiming to push ABCD, at which point the server will optimize out the - need for you to actually send it. Now you have a ref to ABCD and can - fetch it (claiming not to have it, of course). - -. Requesting other refs, claiming that you have ABCD, at which point the - server may generate deltas against ABCD. - -None of this causes a problem if you only host public repositories, or -if everyone who may read one namespace may also read everything in every -other namespace (for instance, if everyone in an organization has read -permission to every repository). +include::transfer-data-leaks.txt[] diff --git a/Documentation/technical/api-in-core-index.txt b/Documentation/technical/api-in-core-index.txt deleted file mode 100644 index adbdbf5d75..0000000000 --- a/Documentation/technical/api-in-core-index.txt +++ /dev/null @@ -1,21 +0,0 @@ -in-core index API -================= - -Talk about <read-cache.c> and <cache-tree.c>, things like: - -* cache -> the_index macros -* read_index() -* write_index() -* ie_match_stat() and ie_modified(); how they are different and when to - use which. -* index_name_pos() -* remove_index_entry_at() -* remove_file_from_index() -* add_file_to_index() -* add_index_entry() -* refresh_index() -* discard_index() -* cache_tree_invalidate_path() -* cache_tree_update() - -(JC, Linus) diff --git a/Documentation/transfer-data-leaks.txt b/Documentation/transfer-data-leaks.txt new file mode 100644 index 0000000000..914bacc39e --- /dev/null +++ b/Documentation/transfer-data-leaks.txt @@ -0,0 +1,30 @@ +SECURITY +-------- +The fetch and push protocols are not designed to prevent one side from +stealing data from the other repository that was not intended to be +shared. If you have private data that you need to protect from a malicious +peer, your best option is to store it in another repository. This applies +to both clients and servers. In particular, namespaces on a server are not +effective for read access control; you should only grant read access to a +namespace to clients that you would trust with read access to the entire +repository. + +The known attack vectors are as follows: + +. The victim sends "have" lines advertising the IDs of objects it has that + are not explicitly intended to be shared but can be used to optimize the + transfer if the peer also has them. The attacker chooses an object ID X + to steal and sends a ref to X, but isn't required to send the content of + X because the victim already has it. Now the victim believes that the + attacker has X, and it sends the content of X back to the attacker + later. (This attack is most straightforward for a client to perform on a + server, by creating a ref to X in the namespace the client has access + to and then fetching it. The most likely way for a server to perform it + on a client is to "merge" X into a public branch and hope that the user + does additional work on this branch and pushes it back to the server + without noticing the merge.) + +. As in #1, the attacker chooses an object ID X to steal. The victim sends + an object Y that the attacker already has, and the attacker falsely + claims to have X and not Y, so the victim sends Y as a delta against X. + The delta reveals regions of X that are similar to Y to the attacker. |