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 previous commit exposed an issue with the region test
does not take into account the scale down factor.
Not a @fix in itself, as it depends on the previous patch.
Summary:
If both region and scale_down has set, ERR would be returned by loader of jpeg.
@fix
Test Plan: sample code
Reviewers: raster, jypark, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4200
A small hack to the toolchain allows us to generate enums with eolian
for use by Eet and Emile (internal or otherwise non-eo libraries).
Thanks to how BUILT_SOURCES works, the eo.h files required by Emile
will be generated before they are used.
This adds a partial dependency on eo for eet and emile:
- package dependency
- include dependency
There is no library link dependency.
SSLv3 has been compromised a year ago by what is known as POODLE
(https://en.wikipedia.org/wiki/POODLE). Every major browser have now
dropped support for SSLv3 and distribution are starting to do so also.
It is a good timing for us to do so, especially as it breaks build on
some distribution.
Typos, lack of NULL check, excessive sizeof(type) not matching
the object type, no border set, etc... This all lead to a crash
and then no render (with an error message and then without...).
This also simplifies the implicit loading of ETC1 as ETC2 when
supported by the driver.
@fix
This seems to come from some intention to fetch dh from openssl somewhow but
it was never implemented. fh always stays 0 since its init and thus we can
remove the code it guards.
CID: 1288930
IFD offset is 4 byte.
But just one byte is checked for it in previous patch.
Reviewers: Hermet, jypark, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3053
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
IFD offset of jpeg is not fixed.
But emile support only 0x8 on now
Reviewers: jypark, cedric, Hermet
Reviewed By: Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3000
Summary:
If you try to load the jpeg image with an orientation mode defined
using elm_photocam, you can see the broken image(in canse of 90 degree)
or even segmentation fault can happen (in case of 180,270 degree)
@fix
Test Plan: photocam menu on elementary_test
Reviewers: Hermet, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2593
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: This fixes Coverity CID1288919 where buffer variable was
being leaked if emile failed to load the image due to corrupt file.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This fixes Coverity CID1288918 where data_start variable was
being leaked if the rectangles did not intersect.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When reading the head of a file, we may get the error that it is
not a JPEG image (which is normal), so we should not print any ERR.
The JPEG header read function can indeed be called to test whether a
file can be opened by the JPEG loader or not (any file).
Note that JPEG files don't have reliable magic numbers, so we
don't check them, but rely on libjpeg instead.
Fixes T2290
Get rid of warning inside of the jpeg loader that result of it. I do believe
this is not an ABI break on the loader API. If you disagree, please raise your
voice.
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.
Gustavo Sverzut Barbieri
jiin.moon
Jean-Philippe Andre
Cedric BAIL
junsu choi
Vincent Torri
Srivardhan Hebbar
Stefan Schmidt
ChunEon Park
Chris Michael
Vincent Torri
Cedric BAIL