Meder Kydyraliev (Google Security) reported an integer overflow in exiv2. Attaching upstream committed patch, one line change was necessary to get it to apply to 0.13. Stefan, please advise.
Created attachment 138527 [details, diff] exiv2-CVE-2007-6353.patch
That patch won't compile due to wrong usage of static_cast, I will upload the fixed patch.
Created attachment 138536 [details, diff] Fix static_cast usage
ok, I have a look at it and try to commit that fix asap. Thanks for reporting.
one question: is this bug already fixed in exiv2-0.15? if so, then I would suggest to get 0.15 stable and remove 0.13. IMHO that would be the best solution.
(In reply to comment #5) > one question: is this bug already fixed in exiv2-0.15? > > if so, then I would suggest to get 0.15 stable and remove 0.13. IMHO that would > be the best solution. No, it is not. The patch should apply to 0.15 though. If you are more comfortable with bumping to an actual release than patching, you could ask upstream for a security release.
Oh, and Ismail - thanks for the corrected patch!
(In reply to comment #7) > Oh, and Ismail - thanks for the corrected patch! Thats my pleasure.
ok, currently we have 3 versions in portage. 0.13 which is stable and 0.14/0.15 which are testing. So I will remove 0.14 and patch 0.13. But what to do with 0.15? Is there a patch already or can I use the 0.13 patch also?
(In reply to comment #9) > ok, currently we have 3 versions in portage. 0.13 which is stable and 0.14/0.15 > which are testing. So I will remove 0.14 and patch 0.13. > > But what to do with 0.15? Is there a patch already or can I use the 0.13 patch > also? Since src/exif.cpp did not change at all between 0.13 and 0.15, whichever you patch is fine. There are several options, it's your choice as maintainer: 1) Patch 0.13, remove 0.14 and 0.15. 2) Patch 0.13, patch 0.15 with 0.13 staying stable. (remove 0.14 after that) 3) Patch 0.15 with 0.15 going stable. (remove 0.13 and 0.14 after that) I'd go with (3) if you would stable 0.15 anyway soon, otherwise (2). (1) if you are lazy, but it will mean ~arch user's are going to downgrade their copies.
ok, what I did: 1. removed 0.14 completely 2. revbumped 0.15 to 0.15-1 and removed 0.15 3. revbumped 0.13 to 0.13-1 and switched to testing since the patch looks sane, it should be easy to stablize 0.13-r1 after a few tests. Furthermore, we should stabalize 0.15-r1 afterwards.
(In reply to comment #8) > (In reply to comment #7) > > Oh, and Ismail - thanks for the corrected patch! > > Thats my pleasure. Did you contact upstream about the issue in the patch or does this only affect the releases?
(In reply to comment #12) > (In reply to comment #8) > > (In reply to comment #7) > > > Oh, and Ismail - thanks for the corrected patch! > > > > Thats my pleasure. > > Did you contact upstream about the issue in the patch or does this only affect > the releases? I didn't contact upstream as I guessed they would fix it once it fails to compile as the error is obvious.
(In reply to comment #13) > I didn't contact upstream as I guessed they would fix it once it fails to > compile as the error is obvious. Hm, the trunk compiles fine for me. However, you are right, on the releases, the patch won't work.
Arches, please test and mark stable media-gfx/exiv2-0.13-r1. Target keywords : "alpha amd64 ia64 ppc sparc x86"
x86 stable
Stable for sparc. Everything as expected.
alpha/ia64 stable
ppc stable
amd64 stable
All arches done, GLSA request filed.
GLSA 200712-16
Does not affect current (2008.0) release. Removing release.
