Revision c62bc49139f1d18e922fc98e35bb08b1aadbcafc authored by Junio C Hamano on 02 August 2019, 20:12:02 UTC, committed by Junio C Hamano on 02 August 2019, 20:12:02 UTC
Support building Git with Visual Studio

The bits about .git/branches/* have been dropped from the series.
We may want to drop the support for it, but until that happens, the
tests should rely on the existence of the support to pass.

* js/visual-studio: (23 commits)
  git: avoid calling aliased builtins via their dashed form
  bin-wrappers: append `.exe` to target paths if necessary
  .gitignore: ignore Visual Studio's temporary/generated files
  .gitignore: touch up the entries regarding Visual Studio
  vcxproj: also link-or-copy builtins
  msvc: add a Makefile target to pre-generate the Visual Studio solution
  contrib/buildsystems: add a backend for modern Visual Studio versions
  contrib/buildsystems: handle options starting with a slash
  contrib/buildsystems: also handle -lexpat
  contrib/buildsystems: handle libiconv, too
  contrib/buildsystems: handle the curl library option
  contrib/buildsystems: error out on unknown option
  contrib/buildsystems: optionally capture the dry-run in a file
  contrib/buildsystems: redirect errors of the dry run into a log file
  contrib/buildsystems: ignore gettext stuff
  contrib/buildsystems: handle quoted spaces in filenames
  contrib/buildsystems: fix misleading error message
  contrib/buildsystems: ignore irrelevant files in Generators/
  contrib/buildsystems: ignore invalidcontinue.obj
  Vcproj.pm: urlencode '<' and '>' when generating VC projects
  ...
2 parent s 9b274e2 + b914084
Raw File
transfer-data-leaks.txt
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.
back to top