On Thu, Feb 23, 2017 at 03:03:58PM -0800, Jonathan Tan wrote: > If a server sets allowtipsha1inwant (or allowreachablesha1inwant), a > client can call "git fetch <server> <SHA-1>" where SHA-1 is the hash of > a blob (reachable or unreachable) to obtain it. The test below (which > passes) demonstrates that. Thanks for a nice demonstration. TBH, I think the whole "we will not give you unreachable things" is overblown as a security measure. There are a lot of ways to leak information out of the repo. E.g., claiming you _do_ have the unreachable thing, at which point pack-objects may create a delta against it. Done repeatedly, it works as an oracle by which you can guess the contents of the unreachable thing. > This happens most likely because the "rev-list" call in > "do_reachable_revlist" (called through "has_unreachable") is invoked > without the "--objects" argument. "has_unreachable" determines that an > object is unreachable if nothing is printed to stdout, which normally > works, except that "rev-list" prints nothing when asked which commits > are reachable from a blob (which makes sense). > > Adding "--objects" works, and all existing tests pass, except for the > potential performance issue and the side effect that even fetching a > reachable blob no longer works. This is due to a possible bug where a > call like "git rev-list --objects $tree ^master" (where $tree is the > tree object corresponding to master) prints out objects even though all > objects reachable from the tree are also reachable from master. (There > should be no issue with "get_reachable_list", the other invoker of > "do_reachable_revlist", because non-commits in the command's stdout are > skipped.) I think "--objects --use-bitmap-index" would be faster. If you have bitmaps. -Peff