Link libthemis_jni.so dynamically

[ilammy]

Do not embed Themis, Soter, and cryptographic backend (if present) into libthemis_jni shared object. Instead, link it dynamically against Themis like a proper library.

It has been a nice experiment to provide self-contained library for Java. However, we are going to distribute the library as a proper system package and for that we will need to have it properly linked against its dependencies. Themis Core will be installed by the package manager so all dependencies are going to be satisfied.

Checklist

• Change is covered by automated tests
• Benchmark results are attached (if applicable)
• The coding guidelines are followed
• Public API has proper documentation
• Example projects and code samples are updated if needed (in case of API changes)
• Changelog is updated if needed minor change, will be included into packaging PR

[ilammy]

Also, export some private functions to make dynamic linkage possible. These are currently used by Themis JNI wrapper in order to operate secure_session_load() correctly. Strictly speaking, we should not be using these functions, but currently there is no way to allocate Secure Session instance suitable for secure_session_load() without using private header <themis/secure_session_t.h>. These functions are exported from the shared library, but we make no commitment to keeping them exported. They should be hidden back once secure_session_load() gets a better API.

[vixentael]

Changes LGTM, but need to test that building process works on different machines.

[Lagovas]

Strictly speaking, we should not be using these functions, but currently there is no way to allocate Secure Session instance suitable for secure_session_load() without using private header <themis/secure_session_t.h>.

can you explain why we need to export secure_session_<init|cleanup> to use secure_session_load? I don't see where these functions used in load/save implementations: https://github.com/cossacklabs/themis/blob/b9062e512aa39a284fa4177a6dc4ca9a34f72c83/src/themis/secure_session_serialize.c

[ilammy]

can you explain why we need to export secure_session_<init|cleanup> to use secure_session_load?

Sure.

They need to be exported because JNI library uses them here:

themis/jni/themis_session.c

Lines 533 to 538 in 0d97f5b

	themis_status = secure_session_init(&(ctx->session),
	id_buf,
	id_length,
	sign_key_buf,
	sign_key_length,
	&(ctx->callbacks));

and here:

themis/jni/themis_session.c

Lines 575 to 576 in 0d97f5b

	secure_session_cleanup(&(ctx->session));
	(*env)->SetLongField(env, thiz, session_field_id, 0);

Note that JNI library does not use secure_session_create() and secure_session_destroy(), and it stores secure_session_t directly, not a pointer to it like any other wrapper:

themis/jni/themis_session.c

Lines 40 to 45 in 0d97f5b

	struct session_with_callbacks_type {
	secure_session_t session;
	secure_session_user_callbacks_t callbacks;
	JNIEnv* env;
	jobject thiz;
	};

All of this is because secure_session_load() accepts a pointer to an allocated instance of secure_session_t. We need to allocate enough memory for Secure Session object in order to use that function, and currently the only way to do this is to include a private header <themis/secure_session_t.h> which defines the layout of secure_session_t. Allocating secure_session_t in that way requires secure_session_init() and secure_session_cleanup() to be used instead of secure_session_create() and secure_session_destroy().

This is problematic because:

• we need to export functions that are considered private API
• we need to expose implementation details of secure_session_t
• we cannot change layout of secure_session_t in any way
• we cannot compile JNI library and Themis Core separately

This PR exports the functions as an easy way out and maintains status quo. A proper solution would involve hiding the implementation details and reengineering secure_session_load() so that it does not depend on those details to be known by the users.

[shadinua]

LGTM

[Lagovas]

discussed with @ilammy that will be better if we will add a new function which will create secure session from the dumped buffer and return a pointer. after that, we will update jni to use this new function without usage of private api secure session to be consistent with other public api and deprecate old function.