2015-03-17 00:49:58 -07:00
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include <config.h>
|
|
|
|
#endif /* ifdef HAVE_CONFIG_H */
|
|
|
|
|
|
|
|
#ifdef HAVE_GNUTLS
|
|
|
|
# include <gnutls/gnutls.h>
|
|
|
|
# include <gnutls/x509.h>
|
|
|
|
# include <gcrypt.h>
|
|
|
|
#endif /* ifdef HAVE_GNUTLS */
|
|
|
|
|
|
|
|
#ifdef HAVE_OPENSSL
|
|
|
|
# include <openssl/ssl.h>
|
|
|
|
# include <openssl/err.h>
|
|
|
|
# include <openssl/evp.h>
|
|
|
|
#endif /* ifdef HAVE_OPENSSL */
|
|
|
|
|
emile: initial introduction of Emile.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
2015-03-17 00:49:57 -07:00
|
|
|
#include <Eina.h>
|
|
|
|
|
|
|
|
#include "Emile.h"
|
2015-03-17 00:49:58 -07:00
|
|
|
#include "emile_private.h"
|
|
|
|
|
2015-03-17 00:50:03 -07:00
|
|
|
static Eina_Bool _emile_cipher_init = EINA_FALSE;
|
emile: initial introduction of Emile.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
2015-03-17 00:49:57 -07:00
|
|
|
static unsigned int _emile_init_count = 0;
|
|
|
|
int _emile_log_dom_global = -1;
|
|
|
|
|
2015-03-17 00:50:06 -07:00
|
|
|
#ifdef HAVE_GNUTLS
|
|
|
|
static int
|
|
|
|
_emile_thread_mutex_init(void **priv)
|
|
|
|
{
|
|
|
|
Eina_Lock *lock;
|
|
|
|
|
|
|
|
lock = malloc(sizeof (Eina_Lock));
|
|
|
|
if (!lock) return ENOMEM;
|
|
|
|
|
|
|
|
if (!eina_lock_new(lock))
|
|
|
|
{
|
|
|
|
free(lock);
|
|
|
|
return ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
*priv = lock;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
_emile_thread_mutex_destroy(void **priv)
|
|
|
|
{
|
|
|
|
eina_lock_free(*priv);
|
|
|
|
free(*priv);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
_emile_thread_mutex_lock(void **priv)
|
|
|
|
{
|
|
|
|
if (eina_lock_take(*priv) == EINA_LOCK_FAIL)
|
|
|
|
return EINVAL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
_emile_thread_mutex_unlock(void **priv)
|
|
|
|
{
|
|
|
|
if (eina_lock_release(*priv) == EINA_LOCK_FAIL)
|
|
|
|
return EINVAL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct gcry_thread_cbs _emile_threads = {
|
|
|
|
(GCRY_THREAD_OPTION_PTHREAD | (GCRY_THREAD_OPTION_VERSION << 8)),
|
|
|
|
NULL, _emile_thread_mutex_init, _emile_thread_mutex_destroy,
|
|
|
|
_emile_thread_mutex_lock, _emile_thread_mutex_unlock,
|
|
|
|
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
|
|
|
|
};
|
|
|
|
#endif /* ifdef HAVE_GNUTLS */
|
|
|
|
|
2015-03-17 00:50:03 -07:00
|
|
|
EAPI Eina_Bool
|
|
|
|
emile_cipher_init(void)
|
emile: initial introduction of Emile.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
2015-03-17 00:49:57 -07:00
|
|
|
{
|
2015-03-17 00:50:03 -07:00
|
|
|
if (_emile_cipher_init) return EINA_TRUE;
|
emile: initial introduction of Emile.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
2015-03-17 00:49:57 -07:00
|
|
|
|
2015-03-17 00:49:58 -07:00
|
|
|
#ifdef HAVE_GNUTLS
|
2015-03-17 00:50:06 -07:00
|
|
|
if (gcry_control(GCRYCTL_SET_THREAD_CBS, &_emile_threads))
|
|
|
|
WRN(
|
|
|
|
"YOU ARE USING PTHREADS, BUT I CANNOT INITIALIZE THREADSAFE GCRYPT OPERATIONS!");
|
|
|
|
|
2015-03-17 00:49:58 -07:00
|
|
|
/* Before the library can be used, it must initialize itself if needed. */
|
|
|
|
if (gcry_control(GCRYCTL_ANY_INITIALIZATION_P) == 0)
|
|
|
|
{
|
|
|
|
gcry_check_version(NULL);
|
|
|
|
/* Disable warning messages about problems with the secure memory subsystem.
|
|
|
|
This command should be run right after gcry_check_version. */
|
|
|
|
if (gcry_control(GCRYCTL_DISABLE_SECMEM_WARN))
|
2015-03-17 00:50:03 -07:00
|
|
|
return EINA_FALSE; /* This command is used to allocate a pool of secure memory and thus
|
2015-03-17 00:49:58 -07:00
|
|
|
enabling the use of secure memory. It also drops all extra privileges the
|
|
|
|
process has (i.e. if it is run as setuid (root)). If the argument nbytes
|
|
|
|
is 0, secure memory will be disabled. The minimum amount of secure memory
|
|
|
|
allocated is currently 16384 bytes; you may thus use a value of 1 to
|
|
|
|
request that default size. */
|
|
|
|
|
|
|
|
if (gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0))
|
|
|
|
WRN(
|
|
|
|
"BIG FAT WARNING: I AM UNABLE TO REQUEST SECMEM, Cryptographic operation are at risk !");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gnutls_global_init())
|
2015-03-17 00:50:03 -07:00
|
|
|
return EINA_FALSE;
|
2015-03-17 00:49:58 -07:00
|
|
|
|
|
|
|
#endif /* ifdef HAVE_GNUTLS */
|
|
|
|
#ifdef HAVE_OPENSSL
|
|
|
|
ERR_load_crypto_strings();
|
2015-03-17 00:49:59 -07:00
|
|
|
SSL_library_init();
|
|
|
|
SSL_load_error_strings();
|
2015-03-17 00:49:58 -07:00
|
|
|
OpenSSL_add_all_algorithms();
|
|
|
|
#endif /* ifdef HAVE_OPENSSL */
|
emile: initial introduction of Emile.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
2015-03-17 00:49:57 -07:00
|
|
|
|
2015-03-17 00:50:03 -07:00
|
|
|
_emile_cipher_init = EINA_TRUE;
|
|
|
|
|
|
|
|
return EINA_TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
EAPI int
|
|
|
|
emile_init(void)
|
|
|
|
{
|
|
|
|
if (++_emile_init_count != 1)
|
|
|
|
return _emile_init_count;
|
|
|
|
|
|
|
|
if (!eina_init())
|
|
|
|
return --_emile_init_count;
|
|
|
|
|
|
|
|
_emile_log_dom_global = eina_log_domain_register("emile", EINA_COLOR_CYAN);
|
|
|
|
if (_emile_log_dom_global < 0)
|
|
|
|
{
|
|
|
|
EINA_LOG_ERR("Emile can not create a general log domain.");
|
|
|
|
goto shutdown_eina;
|
|
|
|
}
|
|
|
|
|
emile: initial introduction of Emile.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
2015-03-17 00:49:57 -07:00
|
|
|
eina_log_timing(_emile_log_dom_global,
|
|
|
|
EINA_LOG_STATE_STOP,
|
|
|
|
EINA_LOG_STATE_INIT);
|
|
|
|
|
|
|
|
return _emile_init_count;
|
|
|
|
|
|
|
|
shutdown_eina:
|
|
|
|
eina_shutdown();
|
|
|
|
|
|
|
|
return --_emile_init_count;
|
|
|
|
}
|
|
|
|
|
|
|
|
EAPI int
|
|
|
|
emile_shutdown(void)
|
|
|
|
{
|
|
|
|
if (--_emile_init_count != 0)
|
|
|
|
return _emile_init_count;
|
|
|
|
|
|
|
|
eina_log_timing(_emile_log_dom_global,
|
|
|
|
EINA_LOG_STATE_START,
|
|
|
|
EINA_LOG_STATE_SHUTDOWN);
|
|
|
|
|
2015-03-17 00:50:03 -07:00
|
|
|
if (_emile_cipher_init)
|
|
|
|
{
|
2015-03-17 00:49:58 -07:00
|
|
|
#ifdef HAVE_GNUTLS
|
2015-03-17 00:50:03 -07:00
|
|
|
/* Note that gnutls has a leak where it doesnt free stuff it alloced
|
|
|
|
* on init. valgrind trace here:
|
|
|
|
* 21 bytes in 1 blocks are definitely lost in loss record 24 of 194
|
|
|
|
* at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
|
|
|
|
* by 0x68AC801: strdup (strdup.c:43)
|
|
|
|
* by 0xD215B6A: p11_kit_registered_module_to_name (in /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0)
|
|
|
|
* by 0x9571574: gnutls_pkcs11_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.21.8)
|
|
|
|
* by 0x955B031: gnutls_global_init (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.21.8)
|
|
|
|
* by 0x6DFD6D0: eet_init (eet_lib.c:608)
|
|
|
|
*
|
|
|
|
* yes - i've tried calling gnutls_pkcs11_deinit() by hand but no luck.
|
|
|
|
* the leak is in there.
|
|
|
|
*/
|
|
|
|
gnutls_global_deinit();
|
2015-03-17 00:49:58 -07:00
|
|
|
#endif /* ifdef HAVE_GNUTLS */
|
|
|
|
#ifdef HAVE_OPENSSL
|
2015-03-17 00:50:03 -07:00
|
|
|
EVP_cleanup();
|
|
|
|
ERR_free_strings();
|
2015-03-17 00:49:58 -07:00
|
|
|
#endif /* ifdef HAVE_OPENSSL */
|
2015-03-17 00:50:03 -07:00
|
|
|
}
|
emile: initial introduction of Emile.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
2015-03-17 00:49:57 -07:00
|
|
|
|
|
|
|
eina_log_domain_unregister(_emile_log_dom_global);
|
|
|
|
_emile_log_dom_global = -1;
|
|
|
|
|
|
|
|
eina_shutdown();
|
|
|
|
|
|
|
|
return _emile_init_count;
|
|
|
|
}
|