| Summary: | autotrace new security issue CVE-2016-7392 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, lewyssmith, sysadmin-bugs |
| Version: | 5 | Keywords: | validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://lwn.net/Vulnerabilities/700836/ | ||
| Whiteboard: | MGA5-64-OK advisory | ||
| Source RPM: | autotrace-0.31.1-48.mga6.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2016-09-15 19:39:15 CEST
David Walser
2016-09-15 19:39:27 CEST
Whiteboard:
(none) =>
MGA5TOO Should be fixed in Cauldron in autotrace-0.31.1-49. I also submitted autotrace-0.31.1-46.1.mga5 to updates_testing. Assigning to QA and I'll prepare an advisory later. Version:
Cauldron =>
5 Testing Mageia 5 x64 real AMD/ATI/Radeon video The input file formats for autotrace are bizarre; I chose to play with BMP and PBM. I converted a large (essentially greyscale, of angular content) 13Mb JPG file with 'convert' to both BMP (42Mb) and BPM (17Mb). Both these files were viewable with image viewers: the BMP one was much smoother than the PMB one, which was much more contrasty & grainy. BEFORE update: autotrace-0.31.1-46.mga5 lib64autotrace3-0.31.1-46.mga5 $ autotrace -input-format BMP -output-format SVG -output-file tuesday-w2.svg tuesday-w2.bmp Error reading BMP file header [unhelpful] $ autotrace -input-format PBM -output-format SVG -output-file tuesday-w2.svg tuesday-w2.pbm [took a *long* time, but worked] The O/P SVG file was 22Mb. I opened the SVG file with Inkscape & Gimp. Both took *very* long, minutes, but the displayed result was surprisingly good. AFTER update: autotrace-0.31.1-46.1.mga5 lib64autotrace3-0.31.1-46.1.mga5 Selecting *just* autotrace in the MCC/Software/Update System pkg list did *not* automatically include the library (but I guess this *was* done for installing it in the first place via urpmi). Is there a missing dependancy? The end result was the same as before the update (for better or worse). So there is no reversion, and the update is inherently OK. @shlomi I prefer feedback about the 'dependancy' question before OK'ing this. CC:
(none) =>
lewyssmith On M5 x64, further to Comment 2. There is definitely an inconsistency in this update about the dependance of autotrace on its library lib64autotrace3. I removed both of these, and re-installed just autotrace from current release repos. Both MCC/Add software and # urpmi automatically pulled in the library. autotrace-0.31.1-46.mga5 lib64autotrace3-0.31.1-46.mga5 Testing this update using MCC/Update System, and selecting *just* autotrace, did NOT automatically pull in its library. This needed selecting specifically. My guess is that the necessary dependancy has got lost. Shlomi please comment. Whiteboard:
(none) =>
feedback Packages don't have hardcoded %version-%release dependencies on their libraries, they have unversioned automatically generated dependencies on them. When you test packages in updates_testing *you* have to click each package that is involved in the testing, including libraries. Whiteboard:
feedback =>
(none) Despite which, one often sees when selecting packages from long lists from one SRPM in Updates Testing that other dependant pkgs are signalled & marked for inclusion. My only worry was that the library could get overlooked, but I suppose in a real 'Update System' situation, both componenents, being present, would be updated. So am OK'ing this. Whiteboard:
(none) =>
MGA5-64-OK
Dave Hodgins
2016-09-28 04:17:29 CEST
Keywords:
(none) =>
validated_update An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0327.html Status:
NEW =>
RESOLVED |