Activity for EXIF Tag Parsing Library
-
EXIF Tag Parsing Library updated /README.md
-
Dan Fandrich created a blog post
Moved to Github
-
-
hkirsman created ticket #18
Add .heic support
-
libexif-0.6.21 Heap Buffer Overflow due to a programming mistake
-
This is fixed in 0.6.22
-
Heap Out-of-Bounds Memory Access
-
This was fixed in commit d0ec90fd.
-
Timeout (78443587)
-
The fix mentioned in the previous comment was submitted as commit 6aa11df5.
-
Timeout (37792047)
-
The fix mentioned in the previous comment was submitted as commit 6aa11df5/
-
exif crashes when removing thumbnail from jpeg image
-
I'm attaching a file that seems to show the issue here, although it doesn't give me a SIGSEGV (yet) but does show a lot of Conditional jump or move depends on uninitialised value(s) errors under valgrind. The underlying issue was solved in commit 72e9fb36 by ensuring the size parameter is initialized to 0.
-
Here is the proposed patch in unified diff form. Rather than 0xffff & does it work with an explicit cast to the enum type? And is that change really necessary on entry->components since both sides are unsigned?
-
exif --xml-output should escape field values
-
This is fixed in commit c62b9a73. Thanks for reporting it!
-
EXIF not read if Photoshop IRB Marker is present
-
The problem was solved in a more general way in commit a774b0d4.
-
Integer overflow in libexif/canon/exif-mnote-data-canon.c
-
Command line exif program removes XMP information in generated JPEGs.
-
The attached image doesn't have an XMP section but I was able to easily reproduce the problem. The issue is probably that XMP and EXIF are both stored in an APP1 but exif only cares about EXIF. I agree, it should preserve any sections it doesn't recognize, including APP1 sections that are not EXIF.
-
The library lags behind from the exif standard.
-
Shutterspeeds are rounded to nearby rational number
-
That example images contains no EXIF tags, so I can't see what you mean. The only code I see that touches an existing EXIF_TAG_EXPOSURE_TIME tag is exif_entry_fix() and that will only convert a signed rational into a directly equivalent unsigned rational; it won't scale the values at all. You might be talking about exif_entry_get_value(), which will round up values >=1 to the nearest second and those <1 second to the nearest 1/N. I agree, this is suboptimal, especially for values 0.1<N<10.
-
Heap Out-of-Bounds Memory Access
-
Timeout (37792047)
-
Timeout (78443587)
-
Out-of-Bounds Read - exif_data_save_data_entry
-
exif_tag_table_count fails to link with non-gcc compilers
-
Fixed in 80ed9dff. Thanks for the report!
-
-
Duplicate of https://sourceforge.net/p/libexif/bugs/117/
-
libexif v0.6.21: fails to build with VS2008 (patch attached)
-
libexif-0.6.21 Heap Buffer Overflow due to a programming mistake
-
[exif] fails to remove all tags
-
Pushed in c7fdec3c. Thanks for the patch!
-
I have a fix for this issue queued for release. I'm planning on making a release within 2 weeks to fix this and several other security issues. Would it be possible to delay disclosure of this for a short time to give time for the release?
-
Heap Out-of-Bounds Memory Access
-
Timeout (37792047)
-
Timeout (78443587)
-
The problem has been further mitigated (a further reduction in the maximum recursive parsing depth) queued for submission as a fix for issue #134. It would be great to announce this one simultaneously with #134 since it's effectively the same problem.
-
A fix for this issue is queued up for the next release.
-
This problem has been addressed in commit 5d28011c40ec86cf52cffad541093d37c263898a that is publically available.
-
Google-Autofuzz posted a comment on ticket #132
Hi there, As we're quickly approaching the 90 day disclosure deadline(today is 77 days since disclosure), wanted to check-in on whether or not someone has had an opportunity to look into this report. Thanks, Google AutoFuzz Team
-
jidanni created ticket #17
longitude and latitude in DD.DDDD format
-
Timeout (78443587)
-
Timeout (37792047)
-
Heap Out-of-Bounds Memory Access
-
Joaquim Espinhara posted a comment on ticket #129
Hi Marcus/other. Since the bug was fixed, do you mind in close the ticket and change from private to public?
-
Marcus posted a comment on ticket #131
Please disregard the previous attachment, which somehow got corrupted... exif-remove2.patch is correct.
-
[exif] fails to remove all tags
-
Lili posted a comment on ticket #130
RedHat Security Team has assigned a CVE number to this issue. The CVE number is CVE-2017-7544.
-
cool! well done
-
Marcus Meissner posted a comment on ticket #129
same as bug 130 i applied this fix.
-
I applied this fix to CVS.
-
not sure if it's the same bug, but looks like the same based on the description. Check the bug report #129.
-
will be taking this (even if the bvugtracker does not let me assign myself :)
-
aiwarrior posted a comment on ticket #88
Patch for support.
-
Hi Dan, hope you're doing great. Looks like someone else create an open ticket with public visibility, reading the description looks like the same bug but I'm not sure if it is, however just notice that the zip file is password protected. https://sourceforge.net/p/libexif/bugs/130/ Cheers. On Tue, May 30, 2017 at 6:24 AM, Dan Fandrich dfandrich@users.sf.net wrote: I'm looking at a similar issue now. I hope to have the time to investigate this by next week. [bugs:#129] https://sourceforge.net/p/libexif/bugs/129/...
-
libexif-0.6.21 Heap Buffer Overflow due to a programming mistake
-
I'm looking at a similar issue now. I hope to have the time to investigate this by next week.
-
Out-of-Bounds Read - exif_data_save_data_entry
-
A patch (unified diff format is best) is preferred over posting the complete modified file since it's easier to see what has changed, especially if the original file has changed compared to the version you originally modified. But free free to attach the entire file if you can't easily make a patch.
-
Mihail Naydenov posted a comment on ticket #126
I see. Yes, in general works fine, but Apple now uses these latest tags and they show up with empty names and the value is in numeric instead of textual one. In what form do you prefer the patch? I think in this case only the exif-tag.h/c need to be changed. I might try to modify it and post them here. Will this be ok?
-
libexif hasn't had a release lately because there haven't patches submitted recently, presumably because no-one misses those features. Like most Open Source projects, libexif is maintained by volunteers and driven by the needs of its users as expressed through bug reports and patches. If you have need for better support for these tags or find their handling buggy, feel free to submit a patch or open a bug report with details!
-
The library lags behind from the exif standard.
-
TmTFx created ticket #16
friulian translation
-
Andre John Mas posted a comment on ticket #15
I have draft changes here: https://github.com/ajmas/exif/tree/json-output Not ready...
-
Provide support for exporting to JSON
-
-
Typo in message text
-
Applied—thanks!
-
Jan Doerntlein created ticket #124
libexif v0.6.21: fails to build with VS2008 (patch attached)
-
Sebastian Rasmussen created ticket #123
Typo in message text
-
Mads Dyrmann created ticket #122
Shutterspeeds are rounded to nearby rational number
-
-
-
-
-
-
