)]}'
{
  "commit": "5f14300d2ba3681f14af8a97ec2026bc6ac2249b",
  "tree": "5be4cf24904df2c0a35b7244aff3c97e33dff616",
  "parents": [
    "bc4c09df6416a3a0d0cf321c6c13023c77e2fec4"
  ],
  "author": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Tue Oct 15 12:31:14 2019 -0700"
  },
  "committer": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Wed Oct 23 19:32:27 2019 +0000"
  },
  "message": "Fix GRND_NONBLOCK flag when calling getrandom.\n\nI screwed up in 56b6c714c9 and got the direction of this condition\nbackwards. This doesn\u0027t cause a security problem because:\n  a) wait_for_entropy will ensure that the pool is initialised.\n  b) if GRNG_NONBLOCK is set when not expected, any EAGAIN will\n     cause an abort anyway.\n\nHowever, when coupled with opportunistic entropy collection on platforms\nwith RDRAND, this could cause an unexpected blocking getrandom call.\n\nThis this change, `strace -e getrandom bssl rand 1` shows two getrandom\ncalls with GRNG_NONBLOCK set, as expected. (The first being the probe to\ncheck whether the kernel supports getrandom, and the second being the\nopportunistic entropy gathering to augment RDRAND.)\n\nBug: chromium:1016811\nChange-Id: I98ed1cef90df510f24cf2df1fba9b886fcbf3355\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38204\nCommit-Queue: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: David Benjamin \u003cdavidben@google.com\u003e\n(cherry picked from commit f3bd757ee5e7ad409d2fdf7c3bb5fdfa5f0a307a)\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38504\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "33c0b0319740d3aa124d70a38e3239a7debd9103",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/rand/urandom.c",
      "new_id": "4a60eb2f85be268cedbbdeca9b9d08b2429d9a61",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/rand/urandom.c"
    }
  ]
}