)]}'
{
  "commit": "af3578a8355499a38bd976ea60563ebafe98f2b7",
  "tree": "027a42cbc343f8373d3a1ac05ddf797eaa35cfe2",
  "parents": [
    "294ab9730c570213b496cfc2fc14b3c0bfcd4bcc"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Thu Feb 13 18:39:45 2025 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Thu Feb 20 09:41:11 2025 -0800"
  },
  "message": "Support PBES2 schemes in PKCS12_create\n\nWe were able to decrypt them, but not create them. This adds support for\ncreating them. They are a little goofy because OpenSSL has two different\nconventions for specifying PBES schemes. Decryption just requires\nparsing out the AlgorithmIdentifier structure embedded in the input,\nwhile encryption requires some way for the caller to specify the\nalgorithms.\n\nPKCS#12 files could be encrypted with two different PBES (password-based\nencryption scheme) schemes from PKCS#5: PBES1 and PBES2. Where PBES1 was\nfully described by a single OID, PBES2 is itself parameterized by a KDF\nand a cipher[*].\n\nOpenSSL first added PBES2 encrypting support in\nhttps://github.com/openssl/openssl/commit/8eb57af5fed7a133cdb2a968081c355249c00b98,\nbut only added it to PKCS8_encrypt, for encrypting PKCS#8 blobs. This\nwas early so they were willing to break their public APIs. They chose a\nconvention where you passed both a NID and an EVP_CIPHER. If the NID was\n-1, the cipher would be used instead with PBES2, hardcoding PBKDF2 with,\nat the time, HMAC-SHA1. We implement this API.\n\nLater, OpenSSL added PBES2 encrypting to PKCS12_create in\nhttps://github.com/openssl/openssl/commit/b0e69a05008531c51180cf8fc10694871d33eaa8,\nbut now backwards compatibility does not allow adding an EVP_CIPHER\nparameter to PKCS12_create. OpenSSL instead decided that if the NID\nmatched a known EVP_CIPHER (e.g. NID_aes_256_cbc), it would implicitly\npick PBES2, the way -1 and an EVP_CIPHER specified it before.\n\nThis CL implements that behavior. I\u0027ve opted to keep the PKCS8_encrypt\ncalling convention and just translate to it for now. But we really\nshould pick a less chaotic calling convention (we\u0027re C++ now, so we\ncould even use std::variant...) at least for the internals.\n\nFor now, the defaults are still at the values they were in older\nOpenSSL. I\u0027ve filed https://crbug.com/396434682 to track that. (Only\nreason to do it separately is to have something easily revertible and\ndecide when to do the low-but-nonzero-risk change.)\n\nAs an aside, OpenSSL later further complicated this (still not\ndocumenting anything) with\nhttps://github.com/openssl/openssl/commit/5693a30813a031d3921a016a870420e7eb93ec90\n\nThere was no way to specify the PBKDF2 PRF function. So they overloaded\nthe NID parameter, to specify that. Now the decision tree is:\n\n- If the NID is -1, PBES2 with the cipher and the default PBKDF2\n- If the NID is a PRF algorithm, PBES2 with the cipher and that PRF as\n  the PBKDF2 PRF\n- Otherwise, PBES1 with the NID specifying the PBES1 scheme\n\nThis CL does not implement that extra feature. This calling convention\nis a mess.\n\n[*] To be honest, I\u0027m not sure what PBES2 even specifies. The operation\nin RFC 8018, Section 6.2.1 is pretty much meaningless. Use the selected\nKDF to derive a key, then use the selected cipher to encrypt it. PBES2\ndoes not actually come with any choices of KDF or cipher, you have to\npick them when formulating a PBES2 scheme. PBES2 appears to just\ndescribe sticking the two together generically.\n\nFixed: 394337104\nChange-Id: I1380b339d398783ee65cde3d9f526b9d8fc1c2d4\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76307\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Bob Beck \u003cbbe@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0c729470d92d2fbdaf03c2fceb7a61a07030d98b",
      "old_mode": 33188,
      "old_path": "crypto/pkcs8/internal.h",
      "new_id": "20f76cd89de1a354c14cd59aa84f3f63ea6c2cfa",
      "new_mode": 33188,
      "new_path": "crypto/pkcs8/internal.h"
    },
    {
      "type": "modify",
      "old_id": "bd0868b37cbb61661b01aa4e8a182db5af1958c8",
      "old_mode": 33188,
      "old_path": "crypto/pkcs8/p5_pbev2.cc",
      "new_id": "71177637b21141d8f01368deaf9fa51661199cff",
      "new_mode": 33188,
      "new_path": "crypto/pkcs8/p5_pbev2.cc"
    },
    {
      "type": "modify",
      "old_id": "e8d2c1bb4750e767027c949b38c659193f9924db",
      "old_mode": 33188,
      "old_path": "crypto/pkcs8/pkcs12_test.cc",
      "new_id": "b7b136ab34730def046123960906bef1dfd2f826",
      "new_mode": 33188,
      "new_path": "crypto/pkcs8/pkcs12_test.cc"
    },
    {
      "type": "modify",
      "old_id": "525b7eacffbbf958d8c96ba29af26ac6a84188ec",
      "old_mode": 33188,
      "old_path": "crypto/pkcs8/pkcs8.cc",
      "new_id": "d2dddc1a15b28bbc367227f63e7ad8fb7156df9b",
      "new_mode": 33188,
      "new_path": "crypto/pkcs8/pkcs8.cc"
    },
    {
      "type": "modify",
      "old_id": "1e20e7643d37ce66d1d4a456aecb80e19b82bac8",
      "old_mode": 33188,
      "old_path": "crypto/pkcs8/pkcs8_x509.cc",
      "new_id": "3495e5160c6501b0be4c5e2490b97404dcb48fc5",
      "new_mode": 33188,
      "new_path": "crypto/pkcs8/pkcs8_x509.cc"
    },
    {
      "type": "modify",
      "old_id": "173ff9605f41967fb7d7deb6179f8399eebd4962",
      "old_mode": 33188,
      "old_path": "include/openssl/pkcs8.h",
      "new_id": "031fbfa98a4d9c83aa457bdc2220843c2abf20ba",
      "new_mode": 33188,
      "new_path": "include/openssl/pkcs8.h"
    }
  ]
}