)]}'
{
  "commit": "0dece5c1bd398890de191e10d59ad3e43829ee6e",
  "tree": "714a72f38fcaaeeec9109db7083a60256fdee3f1",
  "parents": [
    "3c56557fb8b3e5ed363e7a967207a6096eaed8d5"
  ],
  "author": {
    "name": "Sergey Kandaurov",
    "email": "pluknet@nginx.com",
    "time": "Fri May 29 23:10:20 2020 +0300"
  },
  "committer": {
    "name": "Sergey Kandaurov",
    "email": "pluknet@nginx.com",
    "time": "Fri May 29 23:10:20 2020 +0300"
  },
  "message": "Tests: fixed ssl_certificate.t with LibreSSL client.\n\nNet::SSLeay::connect() that manages TLS handshake could return unexpected\nerror when receiving server alert, as seen in server certificate tests if\nit could not been selected.  Typically, it returns the expected error -1,\nbut with certain libssl implementations it can be 0, as explained below.\n\nThe error is propagated from libssl\u0027s SSL_connect(), which is usually -1.\nIn modern OpenSSL versions, it is the default error code used in the state\nmachine returned when something went wrong with parsing TLS message header.\nIn versions up to OpenSSL 1.0.2, with SSLv23_method() used by default, -1\nis the only error code in the ssl_connect() method implementation which is\nused as well if receiving alert while parsing ServerHello.  BoringSSL also\nseems to return -1.  But it is not so with LibreSSL that returns zero.\n\nPreviously, tests failed with client built with LibreSSL with SSLv3 removed.\nHere, the error is propagated directly from ssl_read_bytes() method, which\nis always implemented as ssl3_read_bytes() in all TLS methods.  It could be\nalso seen with OpenSSL up to 1.0.2 with non-default methods explicitly set.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5d8bde84323f7b0a38363ad36eeb3f8f6edbd4e0",
      "old_mode": 33188,
      "old_path": "ssl_certificate.t",
      "new_id": "80e7c885b496f7ee4f64709359e17645396fe323",
      "new_mode": 33188,
      "new_path": "ssl_certificate.t"
    }
  ]
}