Although we support Bazel, we sort of expect that most people would use prebuilt binaries or CMake. IIRC you're actually the first person asking for Bazel.

We restrict access to CleartextKeysetHandle in Bazel because it is useful yet very dangerous. The API is public in CMake or prebuilt binaries because neither provide any access control mechanisms.

If you just want to test out Tink, we can provide a new target for CleartextKeysetHandle with testonly = 1. As hinted, you can only use this target in cc_test. Does that work for you?

If you want to use Tink in production, we recommend protecting your keys by wrapping with a master key or storing keys directly in a KMS. C++ supports AWS KMS and Cloud KMS. You can also easily add support for in-house KMS. Please see https://github.com/google/tink/blob/master/docs/KEY-MANAGEMENT.md for more information.

Thanks for the info! I'll read the documentation link you posted.

For me it would help if the documentation was updated in a way so that the first and main example code doesn't use private APIs. If this API is so dangerous that you want to disallow it in "real" code it's a bit strange that it's completely unrestricted in the main build system and recommended without any comment mentioning its danger in the main tutorial document.

I think there are ways to make this less likely to be missed in CMake as well even though it doesn't support visibility rules like Bazel. You could rename the class to mark it as dangerous, or you could put it in a separate library target which has a name that indicates this.

I think it would be great if we had a better answer here.

In general, there are legitimate use cases for using CleartextKeysetHandle. This is why internally, we allow people to use it -- in case it is one of these cases. In general, we would recommend to review uses of it.

In our open source library, I can see a few options people can do the same:

1. bazel has the option to patch a library on download (Tink uses this at head to patch in a change to the BUILD file of kms).

2. We could add a visibility to an target outside of Tink. Users can then implement this target, exporting CleartextKeysetHandle (using the export directive of bazel).

Maybe there are others, I might have more ideas. Also let me know if you have other ideas.

My use case is very simple: I was just trying to run the example code in the C++ howto. This works on CMake only because the class is public in that build system, but it's private with Bazel.

For these purposes, I think the best fix is probably to fix the documentation to not use a semi-private / not usually recommended API in the only easy to find example code that the documentation provides.

Also, if CleartextKeysetHandle is so discouraged that you think it's a good idea to require Bazel hacks like the ones @tholenst lists in the comment above to use it, it seems like it would be a good idea to at least do something to show that it's not the main API for CMake users, which @thaidn says is the primary build system. At the moment neither CMake itself nor the documentation says anything about this.

Sorry for the slow response, I was out for Lunar New Year.

We've decided to relax the visibility. We're in the middle of moving from single workspace to multi workspaces, so this may be not a straight-forward change, but I'll take a look today.