From ${URL} : heap-buffer-overflow in parse_dict_node https://github.com/libimobiledevice/libplist/issues/89 memory allocation error https://github.com/libimobiledevice/libplist/issues/88 issue in plist_free_data plist.c:185 https://github.com/libimobiledevice/libplist/issues/86 heap-buffer-overflow https://github.com/libimobiledevice/libplist/issues/87 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
All reported vulnerabilities are fixed in v2.0.0 which is now available in the repository (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b7d7cf44be09d4e31261c8adfdcced02a73d8585). This package has currently no maintainer so we will wait until 2017-06-09 before starting stabilization.
friendly reminder: "This package has currently no maintainer so we will wait until 2017-06-09 before starting stabilization."
(In reply to Sławomir Nizio from comment #2) > friendly reminder: > > "This package has currently no maintainer so we will wait until 2017-06-09 > before starting stabilization." no maintainer in this case should probably also consider lastriting, or one of the reverse dependencies should pick it up. In particular since it is likely difficult to test for non-specific use. All of the reverse deps where its not a USE flag are also lacking maintainer, so in favor of removal, inter alia, app-pda/ideviceinstaller, app-pda/libimobiledevice, app-pda/ifuse, app-pda/libusbmuxd, media-libs/libgpod, app-pda/usbmuxd, media-libs/libgpod https://qa-reports.gentoo.org/output/genrdeps/rindex/app-pda/libplist This seems like a candidate for lastriting (including all rdeps)
Until someone does the work to remove this package if necessary (considering there's revdeps of revdeps), let's just stabilise the new version so we can clean up old.
amd64 stable
x86 stable
ppc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Cleanup done.
Downgraded to B3. No PoC for RCE/ACE which is also shown in the reported CVE's. GLSA Vote: No
