Upgrade boringssl

example/pubspec.lock

@@ -198,10 +198,10 @@ packages:
     dependency: transitive
     description:
       name: matcher
-      sha256: dc0b7dc7651697ea4ff3e69ef44b0407ea32c487a39fff6a4004fa585e901861
+      sha256: "31bd099b47c10cd1aeb55146a2d46ce0277630ecef3f7dae54ad7873f36696cd"
       url: "https://pub.dev"
     source: hosted
-    version: "0.12.19"
+    version: "0.12.20"
   material_color_utilities:
     dependency: transitive
     description:
@@ -214,10 +214,10 @@ packages:
     dependency: transitive
     description:
       name: meta
-      sha256: "1741988757a65eb6b36abe716829688cf01910bbf91c34354ff7ec1c3de2b349"
+      sha256: df0c643f44ad098eb37988027a8e2b2b5a031fd3977f06bbfd3a76637e8df739
       url: "https://pub.dev"
     source: hosted
-    version: "1.18.0"
+    version: "1.18.2"
   native_toolchain_cmake:
     dependency: transitive
     description:
@@ -323,10 +323,10 @@ packages:
     dependency: transitive
     description:
       name: test_api
-      sha256: "8161c84903fd860b26bfdefb7963b3f0b68fee7adea0f59ef805ecca346f0c7a"
+      sha256: "2a122cbe059f8b610d3a5415f42e255b6c17b1f21eee1d960f31080237fb4f11"
       url: "https://pub.dev"
     source: hosted
-    version: "0.7.10"
+    version: "0.7.12"
   typed_data:
     dependency: transitive
     description:
@@ -339,10 +339,10 @@ packages:
     dependency: transitive
     description:
       name: vector_math
-      sha256: d530bd74fea330e6e364cda7a85019c434070188383e1cd8d9777ee586914c5b
+      sha256: "47a1b32ee755c3fcffa33db52a7258c137f97bdb2209a1075be847809fac4ccf"
       url: "https://pub.dev"
     source: hosted
-    version: "2.2.0"
+    version: "2.3.0"
   vm_service:
     dependency: transitive
     description:

third_party/boringssl/INCORPORATING.md

@@ -0,0 +1,121 @@
+# Incorporating BoringSSL into a project
+
+**Note**: if your target project is not a Google project then first read the
+[main README](./README.md) about the purpose of BoringSSL.
+
+If you are porting BoringSSL to a new platform see
+["go/boringssl-on-new-platform"](https://goto.corp.google.com/boringssl-on-new-platform) (Google
+Internal) for information about porting BoringSSL to a new platform for a Google
+project.
+
+## Which branch to use
+
+BoringSSL usage typically follows a
+["live at head"](https://abseil.io/about/philosophy#we-recommend-that-you-choose-to-live-at-head)
+model. Projects pin to whatever the current latest of BoringSSL is at the time
+of update, and regularly update it to pick up new changes.
+
+Some systems cannot consume git revisions and expect git tags. BoringSSL tags
+periodic snapshots as "releases", to meet the needs of those systems. These
+versions do not represent any kind of stability or development milestone.
+BoringSSL does not branch at these releases and will not cherry-pick bugfixes to
+them. Unless there is a technical constraint to use one of these revisions,
+projects should simply use the latest untagged revision when updating.
+
+While the BoringSSL repository may contain project-specific branches, e.g.
+`chromium-2214`, those are _not_ supported release branches and must not as
+such. In rare cases, BoringSSL will temporarily maintain a short-lived branch on
+behalf of a project. Most such branches are no longer updated, because the
+corresponding project no longer needs them, and we do not create new ones to
+replace the ones that are no longer updated. E.g., not every Chromium release
+branch has a corresponding BoringSSL `chromium-*` branch. Even while active, the
+branch may not contain all changes relevant to a general BoringSSL consumer.
+
+## Bazel
+
+If you are using [Bazel](https://bazel.build) then you can use the [boringssl
+module](https://registry.bazel.build/modules/boringssl) in the Bazel Central
+Registry with bzlmod. Look up the latest version and add the following to your
+`MODULE.bazel` file:
+
+    bazel_dep(name = "boringssl", version = "INSERT_VERSION_HERE")
+
+Substitute the latest version in for `INSERT_VERSION_HERE`.
+
+BoringSSL will periodically ship snapshots to Bazel Central Registry. As with
+other dependencies, periodically keep the referenced version up-to-date.
+
+## Directory layout
+
+Typically projects create a `third_party/boringssl` directory to put
+BoringSSL-specific files into. The source code of BoringSSL itself goes into
+`third_party/boringssl/src`, either by copying or as a
+[submodule](https://git-scm.com/docs/git-submodule).
+
+It's generally a mistake to put BoringSSL's source code into
+`third_party/boringssl` directly because custom build files need to go somewhere
+and merging these with the BoringSSL source code makes updating things more
+complex.
+
+## Build support
+
+BoringSSL is designed to work with many different build systems. The project
+currently has [CMake](https://cmake.org/) and [Bazel](https://bazel.build/)
+builds checked in. Other build systems, and embedders with custom build needs,
+are supported by separating the source list, maintained by BoringSSL, and the
+top-level build logic, maintained by the embedder.
+
+Source lists for various build systems are pre-generated and live in the `gen`
+directory. For example, source lists for
+[GN](https://gn.googlesource.com/gn/+/main/docs/quick_start.md) live in
+[gen/sources.gni](./gen/sources.gni). There is also a generic
+[gen/sources.json](./gen/sources.json) file for projects to consume if needed.
+[util/build/build.go](./util/build/build.go) describes what the various source
+lists mean. Most projects should concatenate the `bcm` and `crypto` targets.
+
+If you don't use any of the supported build systems, you should augment the
+[util/pregenerate](./util/pregenerate) tool to support it, or
+consume [gen/sources.json](./gen/sources.json).
+
+Historically, source lists were generated at update time with the
+[`util/generate_build_files.py`](./util/generate_build_files.py) script. We are
+in the process of transitioning builds to the pre-generated files, so that
+embedders do not need to run a custom script when updating BoringSSL.
+
+## Defines
+
+BoringSSL does not present a lot of configurability in order to reduce the
+number of configurations that need to be tested. But there are a couple of
+\#defines that you may wish to set:
+
+`OPENSSL_NO_ASM` prevents the use of assembly code (although it's up to you to
+ensure that the build system doesn't link it in if you wish to reduce binary
+size). This will have a significant performance impact but can be useful if you
+wish to use tools like
+[AddressSanitizer](http://clang.llvm.org/docs/AddressSanitizer.html) that
+interact poorly with assembly code.
+
+`OPENSSL_SMALL` removes some code that is especially large at some performance
+cost.
+
+## Symbols
+
+You cannot link multiple versions of BoringSSL or OpenSSL into a single binary
+without dealing with symbol conflicts. If you are statically linking multiple
+versions together, there's not a lot that can be done because C doesn't have a
+module system.
+
+If you are using multiple versions in a single binary, in different shared
+objects, ensure you build BoringSSL with `-fvisibility=hidden` and do not
+export any of BoringSSL's symbols. This will prevent any collisions with other
+versions that may be included in other shared objects. Note that this requires
+that all callers of BoringSSL APIs live in the same shared object as BoringSSL.
+
+If you require that BoringSSL APIs be used across shared object boundaries,
+continue to build with `-fvisibility=hidden` but define
+`BORINGSSL_SHARED_LIBRARY` in both BoringSSL and consumers. BoringSSL's own
+source files (but *not* consumers' source files) must also build with
+`BORINGSSL_IMPLEMENTATION` defined. This will export BoringSSL's public symbols
+in the resulting shared object while hiding private symbols. However note that,
+as with a static link, this precludes dynamically linking with another version
+of BoringSSL or OpenSSL.