)]}'
{
  "commit": "f47975106fc439d0ddc65bb7850f1a1d68c93e78",
  "tree": "b641b19e6875003e3b200313d86e791b521c187d",
  "parents": [
    "8fa7162be556f60fdbd146d2a38c1c7e776ead36"
  ],
  "author": {
    "name": "Jan Beulich",
    "email": "jbeulich@suse.com",
    "time": "Mon Apr 14 14:24:28 2025 +0200"
  },
  "committer": {
    "name": "Jan Beulich",
    "email": "jbeulich@suse.com",
    "time": "Mon Apr 14 14:24:28 2025 +0200"
  },
  "message": "ld/PE: restrict non-zero default DLL characteristics to MinGW\n\nWhile commit ef6379e16dd1 (\"Set the default DLL chracteristics to 0 for\nCygwin based targets\") tried to undo the too broad earlier 514b4e191d5f\n(\"Change the default characteristics of DLLs built by the linker to more\nsecure settings\"), it didn\u0027t go quite far enough. Apparently the\nassumption was that if it\u0027s not MinGW, it must be Cygwin. Whether it\nreally is okay to default three of the flags to non-zero on MinGW also\nremains unclear - sadly neither of the commits came with any description\nwhatsoever. (Documentation also wasn\u0027t updated to indicate the restored\ndefault.)\n\nSetting effectively any of the DLL characteristics flags depends on\nproperties of the binary being linked. While defaulting to \"more secure\"\nis a fair goal, it\u0027s only the programmer who can know whether their code\nis actually compatible with the respective settings. On the assumption\nthat the change of defaults was indeed deliberate (and justifiable) for\nMinGW, limit them to just that. In particular, don\u0027t default any of the\nflags to set also for non-MinGW, non-Cygwin targets, like e.g. UEFI. At\nleast the mere applicability of the high-entropy-VA bit is pretty\nquestionable there in the first place - UEFI applications, after all,\nrun in \"physical mode\", i.e. either unpaged or (where paging is a\nrequirement, like for x86-64) direct-mapped.\n\nThe situation is particularly problematic with NX-compat: Many UEFI\nimplementations respect the \"physical mode\" property, where permissions\ncan\u0027t be enforced anyway. Some, like reportedly OVMF, even have a build\noption to behave either way. Hence successfully testing a UEFI binary on\nany number of systems does not guarantee it won\u0027t crash elsewhere if the\nflag is wrongly set.\n\nGet rid of excess semicolons as well.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "9a2b576a6ac7084fa62032b07e403c98c99214da",
      "old_mode": 33188,
      "old_path": "ld/emultempl/pe.em",
      "new_id": "50bb082770da9202b47a797b30b86dbb8a4b5bf8",
      "new_mode": 33188,
      "new_path": "ld/emultempl/pe.em"
    },
    {
      "type": "modify",
      "old_id": "440c0bf5fc4ce1c5a020804fac7bcf704e8167ca",
      "old_mode": 33188,
      "old_path": "ld/emultempl/pep.em",
      "new_id": "60a833947bd524d06241d9d54f5999f69594643d",
      "new_mode": 33188,
      "new_path": "ld/emultempl/pep.em"
    },
    {
      "type": "modify",
      "old_id": "29bd0e1bb1e65387ae3e4d85cf538e0d2614da38",
      "old_mode": 33188,
      "old_path": "ld/ld.texi",
      "new_id": "e8e09f8ec1cbbfaf43bea72951eebb22f7999308",
      "new_mode": 33188,
      "new_path": "ld/ld.texi"
    }
  ]
}