PiperOrigin-RevId: 263109082

PiperOrigin-RevId: 263106297

PiperOrigin-RevId: 263101343

Split the cmake presubmit/postsubmit script into two parts. In the presubmit one, only run the unit tests.

This should make the CMake presubmit tests quick enough that we can make them blocking for submit.

PiperOrigin-RevId: 263096295

We guard it with a "#ifndef CPP_TINK_TEMPORARY_STATUS_MUST_NOT_USE_RESULT", so that users can disable this if necessary.

Note that this also only can break the build for users which compile with both -Werror and -Wunused-result -- so another option for users to disable this is to remove -Wunused-result temporarily.

PiperOrigin-RevId: 263090014

PiperOrigin-RevId: 262922614

Add methods HybridTestUtil which allow encrypting then decrypting with a Hybrid{En,De}crypt. This is sometimes useful in tests (you can easily check if two objects fit together.

PiperOrigin-RevId: 262898879

PiperOrigin-RevId: 262647886

PiperOrigin-RevId: 262557105

PiperOrigin-RevId: 262528850

PiperOrigin-RevId: 262516706

PiperOrigin-RevId: 262511503

This was forgotten in a previous cl.

PiperOrigin-RevId: 262357462

We changed the segment size validation in all Tink streaming keys such that the first block always needs to have room for at least 1 byte of ciphertext. Previously it was not consistent. The decision whether to allow empty ciphertexts in the first segment is somewhat arbitrary, but it should be consistent everywhere.

PiperOrigin-RevId: 262315914

We previously used passed an owned raw pointer from registry.h to registry_impl.h, because this makes it possible to infer template parameters (which doesn't work with unique pointers). However, it is better to instead specify the parameters explicitly, which is easiest if we add typedefs to the KeyTypeManager class.

This will also be useful elsewhere (to create [1] automatically).

PiperOrigin-RevId: 262295924

PiperOrigin-RevId: 262222179

These are the fixes in *non-test-code* needed in order to annotate our Status object with ABSL_MUST_USE_RESULT.

Note that most of these cannot trigger anyhow, so nothing bad is uncovered.

PiperOrigin-RevId: 262129168

PiperOrigin-RevId: 261922099

PiperOrigin-RevId: 261895895

PiperOrigin-RevId: 261875364

PiperOrigin-RevId: 261872620

PiperOrigin-RevId: 261862603

These changes are necessary to add ABSL_MUST_USE_RESULT to our util::Status.

I will have to run the main change through a global presubmit, so I want to do the Tink changes first. Also, here we only do the changes *required in tests*.

PiperOrigin-RevId: 261691203

PiperOrigin-RevId: 261648235

PiperOrigin-RevId: 261634206

PiperOrigin-RevId: 261633704

PiperOrigin-RevId: 261312608

PiperOrigin-RevId: 261309194

PiperOrigin-RevId: 261278364

These are not needed anymore, since we simply register all key managers directly; they were only needed for catalogue support.

PiperOrigin-RevId: 260986202

We plan to remove these; so we instead manually register all key managers in python.

PiperOrigin-RevId: 260936807

These are not needed anymore, since we simply register all key managers directly; they were only needed for catalogue support (what's more is: this didn't work properly anyhow, see the explanation in cl/260891485).

PiperOrigin-RevId: 260935372

PiperOrigin-RevId: 260912173

Remove the Register(const KeyTypeEntry&) code and do what we do previously. Also, simply register everything in the Register(const RegistryConfig&) code.

The only way this can break someone we can think of is when the want to register fewer key managers, and have an implementation of one which they want to use instead, so a call to RegisterKeyManager now fails; this seems very unlikely and would be easy to detect and fix.

This should allow me to get rid of the config generation code.

PiperOrigin-RevId: 260902291

PiperOrigin-RevId: 260899742

PiperOrigin-RevId: 260897053

Catalogues are no longer supported, instead we register key managers directly.

Removing these in Java is actually more easy than in C++ because the static initialization basically broke the functionality already: for example, suppose someone calls

Config.register(AeadConfig.TINK_1_0);

Then, presumably he wants to have the Aead's in the binary which were present in Tink 1.0. However, what happens is that due to accessing AeadConfig.TINK_1_0, the static initialized in AeadConfig runs, which calls AeadConfig.register() internally. This then calls Config.register(LATEST), so that the user anyhow gets all the key managers, also those only present in later versions (e.g. XChaCha20Poly1305Key).

PiperOrigin-RevId: 260891485

PiperOrigin-RevId: 260886081

PiperOrigin-RevId: 260727402

PiperOrigin-RevId: 260727250