efl/src/lib/emile/emile_main.c

156 lines
3.7 KiB
C
Raw Normal View History

#ifdef HAVE_CONFIG_H
# include <config.h>
#endif /* ifdef HAVE_CONFIG_H */
#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"
#include "emile_private.h"
static Eina_Bool _emile_cipher_inited = 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;
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
{
if (_emile_cipher_inited)
return EINA_TRUE;
if (!_emile_cipher_init())
return 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
_emile_cipher_inited = EINA_TRUE;
return EINA_TRUE;
}
EAPI Emile_Cipher_Backend
emile_cipher_module_get(void)
{
#ifdef HAVE_OPENSSL
return EMILE_OPENSSL;
#else
return EMILE_NONE;
#endif
}
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;
}
eina_log_timing(_emile_log_dom_global, EINA_LOG_STATE_STOP, EINA_LOG_STATE_INIT);
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
return _emile_init_count;
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_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);
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:13 -07:00
if (_emile_cipher_inited)
{
#if defined(HAVE_OPENSSL) && (OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER))
EVP_cleanup();
ERR_free_strings();
#endif /* if defined(HAVE_OPENSSL) && (OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)) */
}
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;
}
/* For the moment, we have just one function shared accross both cipher
* backend, so here it is. */
Eina_Bool
emile_pbkdf2_sha1(const char *key, unsigned int key_len, const unsigned char *salt, unsigned int salt_len, unsigned int iter, unsigned char *res, unsigned int res_len)
{
Eina_Binbuf *step1, *step2;
unsigned char *buf;
unsigned char *p = res;
unsigned char digest[20];
unsigned char tab[4];
unsigned int len = res_len;
unsigned int tmp_len;
unsigned int i, j, k;
// this warning is wrong here so disable it
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
buf = alloca(salt_len + 4);
step1 = eina_binbuf_manage_new(buf, salt_len + 4, EINA_TRUE);
#pragma GCC diagnostic pop
if (!step1)
return EINA_FALSE;
step2 = eina_binbuf_manage_new(digest, 20, EINA_TRUE);
if (!step2)
{
eina_binbuf_free(step1);
return EINA_FALSE;
}
for (i = 1; len; len -= tmp_len, p += tmp_len, i++)
{
tmp_len = (len > 20) ? 20 : len;
tab[0] = (unsigned char)(i & 0xff000000) >> 24;
tab[1] = (unsigned char)(i & 0x00ff0000) >> 16;
tab[2] = (unsigned char)(i & 0x0000ff00) >> 8;
tab[3] = (unsigned char)(i & 0x000000ff) >> 0;
memcpy(buf, salt, salt_len);
memcpy(buf + salt_len, tab, 4);
if (!emile_binbuf_hmac_sha1(key, key_len, step1, digest))
return EINA_FALSE;
memcpy(p, digest, tmp_len);
for (j = 1; j < iter; j++)
{
if (!emile_binbuf_hmac_sha1(key, key_len, step2, digest))
return EINA_FALSE;
for (k = 0; k < tmp_len; k++)
p[k] ^= digest[k];
}
}
eina_binbuf_free(step1);
eina_binbuf_free(step2);
return EINA_TRUE;
}