)]}'
{
  "commit": "cb4d2d35c4622ec2513c1c352d30ff8f9f9cdb9e",
  "tree": "94174c76470843f451ae0cecd07b717f98cd2ac3",
  "parents": [
    "50d3413740d1da599cdc0106e6e916741394cc98"
  ],
  "author": {
    "name": "Jeff King",
    "email": "peff@peff.net",
    "time": "Tue Dec 06 13:24:45 2016 -0500"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Tue Dec 06 12:32:48 2016 -0800"
  },
  "message": "http: treat http-alternates like redirects\n\nThe previous commit made HTTP redirects more obvious and\ntightened up the default behavior. However, there\u0027s another\nway for a server to ask a git client to fetch arbitrary\ncontent: by having an http-alternates file (or a regular\nalternates file, which is used as a backup).\n\nSimilar to the HTTP redirect case, a malicious server can\nclaim to have refs pointing at object X, return a 404 when\nthe client asks for X, but point to some other URL via\nhttp-alternates, which the client will transparently fetch.\nThe end result is that it looks from the user\u0027s perspective\nlike the objects came from the malicious server, as the\nother URL is not mentioned at all.\n\nWorse, because we feed the new URL to curl ourselves, the\nusual protocol restrictions do not kick in (neither curl\u0027s\ndefault of disallowing file://, nor the protocol\nwhitelisting in f4113cac0 (http: limit redirection to\nprotocol-whitelist, 2015-09-22).\n\nLet\u0027s apply the same rules here as we do for HTTP redirects.\nNamely:\n\n  - unless http.followRedirects is set to \"always\", we will\n    not follow remote redirects from http-alternates (or\n    alternates) at all\n\n  - set CURLOPT_PROTOCOLS alongside CURLOPT_REDIR_PROTOCOLS\n    restrict ourselves to a known-safe set and respect any\n    user-provided whitelist.\n\n  - mention alternate object stores on stderr so that the\n    user is aware another source of objects may be involved\n\nThe first item may prove to be too restrictive. The most\ncommon use of alternates is to point to another path on the\nsame server. While it\u0027s possible for a single-server\nredirect to be an attack, it takes a fairly obscure setup\n(victim and evil repository on the same host, host speaks\ndumb http, and evil repository has access to edit its own\nhttp-alternates file).\n\nSo we could make the checks more specific, and only cover\ncross-server redirects. But that means parsing the URLs\nourselves, rather than letting curl handle them. This patch\ngoes for the simpler approach. Given that they are only used\nwith dumb http, http-alternates are probably pretty rare.\nAnd there\u0027s an escape hatch: the user can allow redirects on\na specific server by setting http.\u003curl\u003e.followRedirects to\n\"always\".\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": "2c721f0c30d786e043dec819dc421788311c7e4b",
      "old_mode": 33188,
      "old_path": "http-walker.c",
      "new_id": "4bff31c444ca1a44a288749189ada02496e91016",
      "new_mode": 33188,
      "new_path": "http-walker.c"
    },
    {
      "type": "modify",
      "old_id": "b99ade5fa83de12a4c86a21c04ec74fb12436c21",
      "old_mode": 33188,
      "old_path": "http.c",
      "new_id": "a9778bfa447f2afe89af3fe1ad3527d5b8d64791",
      "new_mode": 33188,
      "new_path": "http.c"
    },
    {
      "type": "modify",
      "old_id": "ad94ed7b1c35e07e3bbf46cfcd465dd056fe22d0",
      "old_mode": 33261,
      "old_path": "t/t5550-http-fetch-dumb.sh",
      "new_id": "22011f0b68870a2390710f580edec60d0d8066dd",
      "new_mode": 33261,
      "new_path": "t/t5550-http-fetch-dumb.sh"
    }
  ]
}