openssl3 should now solve licensing issues with openssl. there is no
good reason to keep gnutls support anymore especially since there just
isn't anyoen who wants to maintain that extra ifdef'd code (and that
code has some gotchas that don't match the full features of openssl
too). so this removed "code cruft" to maintain, complexity and
maintenance work as well as build complexity.
emile in these 2 cases allocates an empty uninitilised buffer that
will then be filled - gcc thinks we're passing uninit data to a func -
which is right but intended as it is later filled. disable this
warning for these segments of code.
Summary:
When openssl-1.1.0 is built with `--api=1.1 disable-deprecated`, use of
deprecated APIs leads to build failures.
X-Gentoo-Bug: 606628
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=606628
Subscribers: cedric, jpeg
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D4616
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
emile_binbuf_sha1() was actually doing HMAC version using the given
key. This doesn't work when all you need is just the SHA1 of the input
data.
Then rename emile_binbuf_sha1() to emile_binbuf_hmac_sha1() and
introduce a new version without key/keylen.
This API was marked as BETA and no real users in the codebase, then it
shouldn't cause us problems.
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.
Carsten Haitzler
Hermet Park
Hosang Kim
Gustavo Sverzut Barbieri
Cedric BAIL
Cedric BAIL