Can this rule be moved into the BUILD file in your extension directory?

My bazel skills are somewhat limited, so please tell if I'm not understanding everything here, but is the idea that only the envoy_cmake rule would be moved? The source URL would still be in bazel/repository_locations.bzl and the python build rule in bazel/repositories.bzl? I was trying to see what the other contrib extensions are doing, and it seems that at least sqlparser BUILD file is in bazel/external directory.

We don't want core docs to link to contrib extensions. However, I would encourage you to put a README.md in contrib/cryptomb.

Hmm, is this rule only for new contrib extensions? It seems to me that core docs are linking to old contrib extensions such as mysql and squash. Or is it just that the .rst files are located within the docs directory, but the document TOC tree isn't linking to it? The contrib google doc says:

contrib/ extensions will have a new top level documentation section categorized by extension type. Extensions with documentation will put their documentation in that section. This will make it easy for users to see what extra extensions are available in the envoy-contrib images.

However, I don't seem to find that section, so maybe it's not there yet. Maybe in the interim just remove the docs and add them in another PR when the contrib doc section is there?

I think that's because those filters existed before we had contrib, so their docs are still in core docs. That should get cleaned up at some point. But new contrib extensions shouldn't add core docs.

Ok, I reverted the docs change. I think we can re-add the docs when the contrib doc section is there.

@agl @davidben Hi Adam and David! Do you think it would be possible to expose ec_random_nonzero_scalar(), ec_scalar_to_bytes() and the related EC_SCALAR data type in BoringSSL public API? They are required if you want to calculate ECDSA ephemeral keys the way BoringSSL does it.

I don't think we're likely to do that because we keep eyeing whether we can put a version-skew coupling around the FIPS module.

(And it goes without saying that copy-pasting bits of internal headers is invalid and this change cannot land while doing that.)

In this case, do you think there could be some other way how BoringSSL could provide access to this functionality? It seems to me that the only non-trivial function needed for this is bn_rand_range_words() and the functions it calls. I would love to use ready-made functions rather than implementing it myself. OpenSSL has library access to ECDSA ephemeral key generation, and I think I can't be the only person needing this.