)]}'
{
  "commit": "5b0508f29ec17a6a2d4780b3d2715a7feaa99d40",
  "tree": "515ccc82ffdb24abd326dcbb979e06bbf7160bd0",
  "parents": [
    "bdc509820b70d8cb81f04f3d91b334b4e2933708"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Mon Aug 03 14:17:35 2026 -0400"
  },
  "committer": {
    "name": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Aug 05 10:30:11 2026 -0700"
  },
  "message": "Unwind EVP_CIPHER_CTX poisoning\n\nThe original motivation here was that CBC caused the wrapper layer to\ncall into the EVP_CIPHER twice. An error in the second call would put\nthe EVP_CIPHER_CTX in an unpredictable state. And so\nhttps://boringssl-review.googlesource.com/c/boringssl/+/54185 added some\nbasic \"poison\" tracking to try to catch egregious caller mistakes.\n\nThis then got extended significantly in\nhttps://boringssl-review.googlesource.com/c/boringssl/+/83447 to catch\nall failures. Extending it caused some problems, both in Conscrypt:\n\n1. This changed public API at the Conscrypt level if a Java Cipher\n   object was called after an error. See b/504728350. While somewhat\n   questionable caller behavior, it was an unexpected behavior change.\n\n2. The Java Cipher APIs promise that you can retry after a\n   ShortBufferException. See [0]. Conscrypt currently does all the\n   bounds checks itself, but this is itself problematic, so we\u0027d rather\n   shift that into BoringSSL, which is better suited to calculate this.\n\nhttps://boringssl-review.googlesource.com/c/boringssl/+/99648 patched\nthis with further complexity to the \u0027poisoned\u0027 bit, but it turns out\nthis was all unnecessary. If we look at where cipher_update is\n*actually* fallible, it turns out:\n\n- Almost every cipher_update is infallible, notably all the CBC ones.\n\n- AES-GCM and AES-XTS check if their keys have been initialized. (The\n  others should but don\u0027t. We should probably have a better notion of\n  when the EVP_CIPHER_CTX has been initialized. Either way, this is not\n  a pattern of failure that can trigger our problem.)\n\n- AES-XTS checks if its input is long enough.\n\n- AES-GCM checks if the input is too long.\n\nOur XTS implementation doesn\u0027t support streaming anyway, and GCM is not\npadded or block-buffered, so the motivation for poisoning doesn\u0027t apply.\nTHat means this was all moot. Indeed it\u0027s telling that the only positive\ntest for poisoning had to make a custom EVP_CIPHER, and supporting\ncustom EVP_CIPHERs is explicitly out of scope.\n\nUnwind the whole poisoning machinery entirely. Also fix some of the\ntests added in 99648 to actually test what [0] needs: that retrying the\noperation gives the same thing. Also fix a bug, caught by asserts, in\nthe EVP_EncryptUpdate_ex length check: EVP_CIPHER_CTX_max_next_update\nchecks ctx-\u003eencrypt, but decrypt calls into encrypt.\n\n[0] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/javax/crypto/Cipher.html#:~:text\u003dat%20outputOffset%20inclusive.-,If%20the%20output%20buffer%20is%20too%20small%20to%20hold%20the%20result%2C%20a%20ShortBufferException%20is%20thrown.%20In%20this%20case%2C%20repeat%20this%20call%20with%20a%20larger%20output%20buffer.%20Use%20getOutputSize%20to%20determine%20how%20big%20the%20output%20buffer%20should%20be.,-If%20inputLen%20is\n\nFixed: 520121641\nChange-Id: I7c1c4138d2553fbd9ea72013962f60fa9a3e628c\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/99990\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Rudolf Polzer \u003crpolzer@google.com\u003e\nPresubmit-BoringSSL-Verified: boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com \u003cboringssl-scoped@luci-project-accounts.iam.gserviceaccount.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a55b502eee235a80fe2883b9425763191b4f15b4",
      "old_mode": 33188,
      "old_path": "crypto/cipher/cipher_test.cc",
      "new_id": "692902e0ff4f9b270ca9fd6070b2a7d82dc0ce2b",
      "new_mode": 33188,
      "new_path": "crypto/cipher/cipher_test.cc"
    },
    {
      "type": "modify",
      "old_id": "bda33dc27e7a37aa4d9f4330e492f729444d2535",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/cipher/cipher.cc.inc",
      "new_id": "56d950156d00a6e3de74f293ce5209222b8f5b25",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/cipher/cipher.cc.inc"
    },
    {
      "type": "modify",
      "old_id": "74738f8be1db178d4b890f24f89c02ac19db729c",
      "old_mode": 33188,
      "old_path": "include/openssl/cipher.h",
      "new_id": "1410f33d7fc6545a94b1b30cea21f21cbaa71644",
      "new_mode": 33188,
      "new_path": "include/openssl/cipher.h"
    }
  ]
}