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

PiperOrigin-RevId: 260722972

PiperOrigin-RevId: 260715588

PiperOrigin-RevId: 260714877

PiperOrigin-RevId: 260713425

PiperOrigin-RevId: 260709761

PiperOrigin-RevId: 260707041

PiperOrigin-RevId: 260703166

PiperOrigin-RevId: 260703107

PiperOrigin-RevId: 260688736

Updated description of Register() method because now it also registers
primitive wrapper(s).

PiperOrigin-RevId: 260678130

Removed Config::RegisterWrapper because wrappers are now registered with
Register() for the primitive.

PiperOrigin-RevId: 260668934

We decided to not support the catalogues in the future. Instead, we will simply register the key managers directly in the config.

PiperOrigin-RevId: 260665577

PiperOrigin-RevId: 260661496

PiperOrigin-RevId: 260566041

PiperOrigin-RevId: 260535454

We decided to not support the catalogues in the future. Instead, we will simply register the key managers directly in the config.

PiperOrigin-RevId: 260490775

PiperOrigin-RevId: 260483519

We decided to not support the catalogues in the future. Instead, we will simply register the key managers directly in the config.

PiperOrigin-RevId: 260476427

Apparently I forgot to test parts -- it's really simple here, so it should be done.

PiperOrigin-RevId: 260463651

We decided to not support the catalogues in the future. Instead, we will simply register the key managers directly in the config. This removes the first catalogue.

PiperOrigin-RevId: 260452741

We decided to not support the catalogues in the future. Instead, we will simply register the key managers directly in the config.

PiperOrigin-RevId: 260451820

We decided to not support the catalogues in the future. Instead, we will simply register the key managers directly in the config.

PiperOrigin-RevId: 260450792

PiperOrigin-RevId: 260140909

PiperOrigin-RevId: 260140481

I plan to remove the catalogue (in upcoming changes). For this, I need to untangle some of the dependencies, and this is easiest if I add a new BUILD target which only creates a Tink Key Type.

PiperOrigin-RevId: 260116920

PiperOrigin-RevId: 259902862

PiperOrigin-RevId: 259902290

Previously this was forgotten. I noticed it when the the benchmarks failed. We add this here.

PiperOrigin-RevId: 259762823