The $dir_pw_third_party/boringssl module provides the build files to compile and use BoringSSL. The source code of BoringSSL needs to be provided by the user. It is recommended to download it via Git submodules.

Build support#

This module provides support to compile BoringSSL with GN. This is required when compiling backends modules that use BoringSSL, such as some facades in pw_crypto


The recommended way to include BoringSSL source code is to add it as a submodule:

git submodule add \


The GN build file depends on a generated file called BUILD.generated.gni with the list of the different types of source files for the selected BoringSSL version.

cd third_party/boringssl
python src/util/ gn

The GN variables needed are defined in $dir_pw_third_party/boringssl/boringssl.gni:

  1. Set the GN dir_pw_third_party_boringssl to the path of the BoringSSL installation.

    • If using the submodule path from above, add the following to the default_args in the project’s .gn:

      dir_pw_third_party_boringssl = "//third_party/boringssl/src"
  2. Having a non-empty dir_pw_third_party_boringssl variable causes GN to attempt to include the BUILD.generated.gni file from the sources even during the bootstrap process before the source package is installed by the bootstrap process. To avoid this problem, set this variable to the empty string during bootstrap by adding it to the virtualenv.gn_args setting in the env_setup.json file:

      "virtualenv": {
        "gn_args": [
  3. Alternatively, set the GN pw_third_party_boringssl_ALIAS to your boringssl build target if you would like to use your own build target instead of the one provided by Pigweed. This should be used instead of dir_pw_third_party_boringssl. This fixes diamond dependency conflicts caused by two build targets using the same source files.

After this is done a pw_source_set for the BoringSSL library is created at $dir_pw_third_party/boringssl.