)]}'
{
  "commit": "1a9edc3e3b1024af4f6dc1ed6bb391510cb494ba",
  "tree": "0e27e2b9c665eac06629a3d69af5675d32ba27c1",
  "parents": [
    "b8912d713cb82a748bbe63f28f28b17632c70964"
  ],
  "author": {
    "name": "Theo Buehler",
    "email": "theorbuehler@gmail.com",
    "time": "Mon May 06 06:47:08 2024 +0200"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed May 15 20:19:46 2024 +0000"
  },
  "message": "Document and test stance on non-canonical base64\n\nFrom RFC 4648:\n\n3.5. Canonical Encoding\n\n   The padding step in base 64 and base 32 encoding can, if improperly\n   implemented, lead to non-significant alterations of the encoded data.\n   For example, if the input is only one octet for a base 64 encoding,\n   then all six bits of the first symbol are used, but only the first\n   two bits of the next symbol are used.  These pad bits MUST be set to\n   zero by conforming encoders, which is described in the descriptions\n   on padding below.  If this property do not hold, there is no\n   canonical representation of base-encoded data, and multiple base-\n   encoded strings can be decoded to the same binary data.  If this\n   property (and others discussed in this document) holds, a canonical\n   encoding is guaranteed.\n\n   In some environments, the alteration is critical and therefore\n   decoders MAY chose to reject an encoding if the pad bits have not\n   been set to zero.  The specification referring to this may mandate a\n   specific behaviour.\n\nOpenSSL\u0027s decoder has always accepted non-canonical encodings and it\nstill appears to be the prevalent practice in 2024. In particular Go\u0027s\nencoding/base64 package requires you to opt into strict mode (which\nencoding/pem does not use). Also, Bouncy Castle and NSS accept such\nencodings.\n\nSo add a comment to the code that this is a deliberate, if perhaps\nbegrudging, choice and encode this in regress with a few test cases\nthat are more obviously of a degenerate nature than the current\nnon-canonical forms.\n\nAlso, group the test vectors straight from RFC 4648 section 10 together.\n\nChange-Id: Ibcc22b7feed86fe1cb0fd51a1d61ec0c60dc8672\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68247\nAuto-Submit: Theo Buehler \u003ctheorbuehler@gmail.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Bob Beck \u003cbbe@google.com\u003e\nReviewed-by: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "666f832692a9f6fb234adbff99dfdb48a42c32f7",
      "old_mode": 33188,
      "old_path": "crypto/base64/base64.c",
      "new_id": "26ad9749aac1cb22199fc436257107cdbdccf917",
      "new_mode": 33188,
      "new_path": "crypto/base64/base64.c"
    },
    {
      "type": "modify",
      "old_id": "6484dc6a801cb458375b62220501f8f504ed4265",
      "old_mode": 33188,
      "old_path": "crypto/base64/base64_test.cc",
      "new_id": "f24660566edae06da74bf9dd20a0d989478f00d6",
      "new_mode": 33188,
      "new_path": "crypto/base64/base64_test.cc"
    }
  ]
}