Update BoringSSL to a newer version with updated patches
The BoringSSL commit this is based on is now 91a66a59b6c1435120ff83e245d7719411294386.
RPK support has drastically changed and is now more flexible, allowing clients to accept both RPKs and X.509 certificates.
While working on it, I noticed that how we disallowed X.509-related functions on RPK contexts was not as optimal nor as safe as it could be, which led to the second commit of this PR.
I'm going away for 8 months of parental leave on Tuesday so I guess I'll not be the person pushing the big green button on this 😁
Ugh
/Users/runner/work/boring/boring/target/x86_64-unknown-linux-gnu/debug/build/boring-sys-a316eb4dd2685ac9/out/boringssl/crypto/asn1/a_strex.cc:53:41: note: 'PRIX32' is defined in header '<cinttypes>'; did you forget to '#include <cinttypes>'?
53 | snprintf(buf, sizeof(buf), "\\U%04" PRIX32, c);
| ^~~~~~
inttypes.h on some platforms is explicitly designed to not define PRIX32 and friends for C++ without __STDC_FORMAT_MACROS. BoringSSL itself is aware of it but I guess it never gets built on such platforms, or at least not anymore since this commit:
commit 5813c2c10c73d800f1b0d890a7d74ff973abbffc
Author: Adam Langley <[email protected]>
Date: Wed Oct 30 22:48:00 2024
crypto: switch to C++
This change switches nearly all of BoringSSL to use C++. The public
functions still use the C ABI, and so code written in C can still use
BoringSSL. Also the use of the C++ standard library is minimal and no
run-time requirement for it is intended.
Change-Id: I902d2f51a3c8d6bd0dc4aabe1b192a15d7b788e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72747
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
The Android, MinGW and MSVC builds are all failing at link-time.
Android and MinGW missing symbols from the C++ runtime (which is now mandatory).
MSVC is missing __imp___CrtDbgReport.
Using CMAKE_MSVC_RUNTIME_LIBRARY fixed the MSVC builds.
@nox From a quick look the PQ patch looks good to me. Were there merge conflicts or was it a clear rebase?
@nox From a quick look the PQ patch looks good to me. Were there merge conflicts or was it a clear rebase?
Everything changed since last time, as there was no SSL_CREDENTIAL concept in upstream BoringSSL.
Silly me, you are talking about PQ, not RPK. Your patches applied cleanly.
I've rebased c5e80aeefbf10c654d827aff295864e3ae579104 on other CI fixes. Extracted 7e256f6d59ec64ee422785aa20b5aae0ca470c9f to make later patches have smaller conflicts.