)]}'
{
  "commit": "9c1abbbf55a3de2febee4d1f685b1bda20774c5e",
  "tree": "50b6185c7adf0b2ea67190bb452cc6f65fffd91a",
  "parents": [
    "ddda991ad0f6f0531a6e2058f3f187a552201097"
  ],
  "author": {
    "name": "Timo Rothenpieler",
    "email": "timo@rothenpieler.org",
    "time": "Wed Sep 09 14:16:34 2026 +0200"
  },
  "committer": {
    "name": "LIU Hao",
    "email": "lh_mouse@126.com",
    "time": "Fri Sep 11 19:14:01 2026 +0800"
  },
  "message": "ssp: prioritize stack guard init constructor\n\nOther libraries might also be running constructors, which themselves are built with SSP enabled,\nor are calling functions that are.\nIf those then get ordered befor the ssp constructor, they might crash due to the yet to be initialized\n__stack_chk_guard.\n\nThis at least affects a statically linked glib, which launches a background thread in the\nlibgio constructor.\nIf the ssp constructor then runs at a random point after, it initializes the stack guard, and once\nthe thread returns from whatever function it\u0027s in, it crashes because the stack guard changed.\n\nSigned-off-by: Timo Rothenpieler \u003ctimo.rothenpieler@uni-bremen.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "499f0033b150a728f80a2d0b0f187b974494d1d6",
      "old_mode": 33188,
      "old_path": "mingw-w64-crt/ssp/stack_chk_guard.c",
      "new_id": "adffb537b0b5e3ad99ed8b667c0a8c4a4a9a35db",
      "new_mode": 33188,
      "new_path": "mingw-w64-crt/ssp/stack_chk_guard.c"
    }
  ]
}