)]}'
{
  "commit": "50d3413740d1da599cdc0106e6e916741394cc98",
  "tree": "7dc809e6d3e5cb84a29e68047d4c38e3ce2e4d16",
  "parents": [
    "fcaa6e64b3f5eecde2b818385ec6f374f61ee7b2"
  ],
  "author": {
    "name": "Jeff King",
    "email": "peff@peff.net",
    "time": "Tue Dec 06 13:24:41 2016 -0500"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Tue Dec 06 12:32:48 2016 -0800"
  },
  "message": "http: make redirects more obvious\n\nWe instruct curl to always follow HTTP redirects. This is\nconvenient, but it creates opportunities for malicious\nservers to create confusing situations. For instance,\nimagine Alice is a git user with access to a private\nrepository on Bob\u0027s server. Mallory runs her own server and\nwants to access objects from Bob\u0027s repository.\n\nMallory may try a few tricks that involve asking Alice to\nclone from her, build on top, and then push the result:\n\n  1. Mallory may simply redirect all fetch requests to Bob\u0027s\n     server. Git will transparently follow those redirects\n     and fetch Bob\u0027s history, which Alice may believe she\n     got from Mallory. The subsequent push seems like it is\n     just feeding Mallory back her own objects, but is\n     actually leaking Bob\u0027s objects. There is nothing in\n     git\u0027s output to indicate that Bob\u0027s repository was\n     involved at all.\n\n     The downside (for Mallory) of this attack is that Alice\n     will have received Bob\u0027s entire repository, and is\n     likely to notice that when building on top of it.\n\n  2. If Mallory happens to know the sha1 of some object X in\n     Bob\u0027s repository, she can instead build her own history\n     that references that object. She then runs a dumb http\n     server, and Alice\u0027s client will fetch each object\n     individually. When it asks for X, Mallory redirects her\n     to Bob\u0027s server. The end result is that Alice obtains\n     objects from Bob, but they may be buried deep in\n     history. Alice is less likely to notice.\n\nBoth of these attacks are fairly hard to pull off. There\u0027s a\nsocial component in getting Mallory to convince Alice to\nwork with her. Alice may be prompted for credentials in\naccessing Bob\u0027s repository (but not always, if she is using\na credential helper that caches). Attack (1) requires a\ncertain amount of obliviousness on Alice\u0027s part while making\na new commit. Attack (2) requires that Mallory knows a sha1\nin Bob\u0027s repository, that Bob\u0027s server supports dumb http,\nand that the object in question is loose on Bob\u0027s server.\n\nBut we can probably make things a bit more obvious without\nany loss of functionality. This patch does two things to\nthat end.\n\nFirst, when we encounter a whole-repo redirect during the\ninitial ref discovery, we now inform the user on stderr,\nmaking attack (1) much more obvious.\n\nSecond, the decision to follow redirects is now\nconfigurable. The truly paranoid can set the new\nhttp.followRedirects to false to avoid any redirection\nentirely. But for a more practical default, we will disallow\nredirects only after the initial ref discovery. This is\nenough to thwart attacks similar to (2), while still\nallowing the common use of redirects at the repository\nlevel. Since c93c92f30 (http: update base URLs when we see\nredirects, 2013-09-28) we re-root all further requests from\nthe redirect destination, which should generally mean that\nno further redirection is necessary.\n\nAs an escape hatch, in case there really is a server that\nneeds to redirect individual requests, the user can set\nhttp.followRedirects to \"true\" (and this can be done on a\nper-server basis via http.*.followRedirects config).\n\nReported-by: Jann Horn \u003cjannh@google.com\u003e\nSigned-off-by: Jeff King \u003cpeff@peff.net\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f4721a048b4c413767c0f069d07005c8948244dd",
      "old_mode": 33188,
      "old_path": "Documentation/config.txt",
      "new_id": "81533364352ec51c55291138987506ce41cc9ef4",
      "new_mode": 33188,
      "new_path": "Documentation/config.txt"
    },
    {
      "type": "modify",
      "old_id": "718d2109bcd1d6f2a887b180aea094e8b4d8e4d1",
      "old_mode": 33188,
      "old_path": "http.c",
      "new_id": "b99ade5fa83de12a4c86a21c04ec74fb12436c21",
      "new_mode": 33188,
      "new_path": "http.c"
    },
    {
      "type": "modify",
      "old_id": "36f558bfb379a990ec4d4aa0d871edd2a6d250a1",
      "old_mode": 33188,
      "old_path": "http.h",
      "new_id": "31b4cc94be7a1a0b4024eb8f5dbbc534092da530",
      "new_mode": 33188,
      "new_path": "http.h"
    },
    {
      "type": "modify",
      "old_id": "e3803daa3e0d1635e61490c4d0d60316e2ca06da",
      "old_mode": 33188,
      "old_path": "remote-curl.c",
      "new_id": "05ae8dead777a36eb726d2a8c7681274ae0169de",
      "new_mode": 33188,
      "new_path": "remote-curl.c"
    },
    {
      "type": "modify",
      "old_id": "9a355fb1c0f028e20b0ee6ee6016ecb9b15c28da",
      "old_mode": 33188,
      "old_path": "t/lib-httpd/apache.conf",
      "new_id": "5b408d6495e87346d0a0d5f756f8d076b54925c8",
      "new_mode": 33188,
      "new_path": "t/lib-httpd/apache.conf"
    },
    {
      "type": "modify",
      "old_id": "3484b6f0f3cf04a9cf831a5d91c31486efebcc38",
      "old_mode": 33261,
      "old_path": "t/t5550-http-fetch-dumb.sh",
      "new_id": "ad94ed7b1c35e07e3bbf46cfcd465dd056fe22d0",
      "new_mode": 33261,
      "new_path": "t/t5550-http-fetch-dumb.sh"
    }
  ]
}