CVEs have been assigned for several security issues in the GIMP: http://openwall.com/lists/oss-security/2017/12/20/1 It sounds like there are fixes only for a couple of them but upstream has been mostly unresponsive.
Assigning to the registered gimp maintainer.
CC: (none) => marja11Assignee: bugsquad => shlomif
Debian has issued an advisory for this on December 30: https://www.debian.org/security/2017/dsa-4077 Patched packages uploaded for Mageia 5 and Cauldron. Mageia 6 is having a build issue: http://pkgsubmit.mageia.org/uploads/failure/6/core/updates_testing/20171231164202.luigiwalser.duvel.5773/log/gimp-2.8.22-1.1.mga6/build.0.20171231164233.log Mageia 5 update moved to Bug 22291.
Version: Cauldron => 6
Shlomi tried building this locally, i586 and x86_64, including installing the same updates from updates_testing that the rpm-qa log on pkgsubmit shows were installed in the buildroot for this build attempt, just to make sure it builds locally and that another update candidate doesn't cause the breakage. In all cases, it built fine for him. It only doesn't build on the build system. Can the sysadmins please look into this?
CC: (none) => sysadmin-bugs
We should go ahead and disable webkit1 in gimp in Mageia 6 (as was already done in Cauldron), like openSUSE did on January 9: https://lists.opensuse.org/opensuse-updates/2018-01/msg00014.html
Status comment: (none) => Doesn't build on our build system, does locally
Fedora has issued an advisory for this on February 27: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/MP5AWS3ANA7XBBGT27RH23QM6IR2ZW3H/
Does it still not build on our build server? The logs from the failure in December are no longer available, btw, so without new logs there is nothing a sysadmin can look into.
gimp now built fine for mga6 - http://pkgsubmit.mageia.org/
We still need to diable webkit1 as I mentioned in Comment 4. Saving the advisory for what we have so far. Advisory: ======================== Updated gimp packages fix security vulnerabilities: Several vulnerabilities were discovered in GIMP which could result in denial of service (application crash) or potentially the execution of arbitrary code if malformed files are opened (CVE-2017-17784, CVE-2017-17785, CVE-2017-17786, CVE-2017-17787, CVE-2017-17788, CVE-2017-17789). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17784 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17785 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17786 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17787 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17788 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17789 https://www.debian.org/security/2017/dsa-4077 ======================== Updated packages in core/updates_testing: ======================== gimp-2.8.22-1.1.mga6 libgimp2.0-devel-2.8.22-1.1.mga6 libgimp2.0_0-2.8.22-1.1.mga6 gimp-python-2.8.22-1.1.mga6 from gimp-2.8.22-1.1.mga6.src.rpm
Done. Advisory: ======================== Updated gimp packages fix security vulnerabilities: Several vulnerabilities were discovered in GIMP which could result in denial of service (application crash) or potentially the execution of arbitrary code if malformed files are opened (CVE-2017-17784, CVE-2017-17785, CVE-2017-17786, CVE-2017-17787, CVE-2017-17788, CVE-2017-17789). Also, the webkit1-based help browser plugin has been disabled in favor of using an external browser for the help pages. This is due to security issues in webkit. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17784 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17785 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17786 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17787 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17788 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17789 https://www.debian.org/security/2017/dsa-4077 https://lists.opensuse.org/opensuse-updates/2018-01/msg00014.html ======================== Updated packages in core/updates_testing: ======================== gimp-2.8.22-1.2.mga6 libgimp2.0-devel-2.8.22-1.2.mga6 libgimp2.0_0-2.8.22-1.2.mga6 gimp-python-2.8.22-1.2.mga6 from gimp-2.8.22-1.2.mga6.src.rpm
CC: marja11, sysadmin-bugs => shlomifAssignee: shlomif => qa-bugs
This update testing app, installs and starts without issue in the MATE VM I do not have images in this VM, because of this, I will download some images and make further tests
CC: (none) => neoser10
MGA6-32 on IBM Thinkpad R50e MATE No installation issues. Tested 2 jpeg pictures: first changed color levels and exported as gif, this opened correctly in eom. Also saved xcf file, closed gimp and reopened xcf OK second picture rotated with cropping adjusted, adjusted canvas to layer and exported as png. This also opens correctly in eom. Good enough for me.
CC: (none) => herman.viaeneWhiteboard: (none) => MGA6-32-OK
I had just the thing to check this out - a farm crop map. Color-coded as to crop, it has a satellite photo of the farm for a base layer, with 70 layers above it, most of which are field labels. The timing is perfect, as I am in the process of editing this year's plan to reflect changes that have occurred in practice. Eventually, this map will go to the USDA as a part of a report on what we planted where, and how much. Updated packages installed cleanly. Did several edits, including redrawing parts of several layers, bucket fills, creating new text layers (field labels), resizing the text, moving layers, drawing lines, saving results. Everything worked as expected. The one thing that no longer works is access to the local help manual files. This, I assume, is the result of disabling the internal browser. Online help is still accessible through Firefox, but that won't help those who, for whatever reason, are attempting to use it without Internet access. If there is a way to tell The Gimp to use Firefox to access the local manual, it certainly isn't obvious.
CC: (none) => andrewsfarm
Jani should be able to address the last paragraph, as the patch came from him.
CC: (none) => jani.valimaa
(In reply to Thomas Andrews from comment #12) > > The one thing that no longer works is access to the local help manual files. > This, I assume, is the result of disabling the internal browser. Online help > is still accessible through Firefox, but that won't help those who, for > whatever reason, are attempting to use it without Internet access. If there > is a way to tell The Gimp to use Firefox to access the local manual, it > certainly isn't obvious. Local help is provided by package gimp-help. If gimp-help isn't installed, online version is offered.
But gimp-help-en-2.8.2-4 *is* installed. On another machine with the non-updated Gimp, it works. I see the local manual. On the test machine, I get a box that says, "Calling error for procedure 'plug-in-web-browser': No application is registered as handling this file"
That "No application is registered as handling this file" sounds like a desktop configuration issue. If you log in as another or a new user does that work better? Or if you try to set program for filetype? When i press F1 i get Firefox loading a local help page, if i select help in menu it opens file:///usr/share/gimp/2.0/help/sv/index.html This test system is 64 bit and fully updated to everything in testing, if that matters. Using Plasma, swedish locale.
CC: (none) => fri
Hmmm. Yes, after doing the update on the second machine from Comment 15, local Help is called in Firefox, just as you describe. This machine does not have everything from testing, just the stuff I've been testing. These are all html files, and on the failing machine there are a host of file associations with those file types, with Firefox at the top of the list. If I navigate to the help files in Dolphin and click on one, it loads into Firefox, as it should. I admit I failed to check the local help actions on this machine before getting the update, so it's possible they have never worked. Since the file associations are OK, and I have no trouble with html files anywhere else, I believe it's the Gimp configuration that's at fault. It acts to me like it's using the wrong file extension to call for help. Now to decide the best way to confirm that, and to fix it. In the meantime, since the problem I'm seeing seems to be isolated to a single machine and install, I'll give this a 64-bit OK. I considered validating, but perhaps it would be better for me to conclude my research first, just to make sure.
Whiteboard: MGA6-32-OK => MGA6-64-OK MGA6-32-OK
On my system, prior to this update selecting Help in the main toolbar opened the "Gimp Help Browser", which appeared to be integral to Gimp. After updating Gimp, selecting Help opens the local help (file:///usr/share/gimp/2.0/help/en/index.html) in Firefox. $ rpm -qa | grep gimp gimp-2.8.22-1.2.mga6 gimp-help-en-2.8.2-4.mga6 ufraw-gimp-0.22-5.mga6 lib64gimp2.0_0-2.8.22-1.2.mga6
CC: (none) => jim
(In reply to Morgan Leijström from comment #16) > That "No application is registered as handling this file" sounds like a > desktop configuration issue. > > If you log in as another or a new user does that work better? > I had forgotten all about Mr. Clunky, the user I created for test purposes a while back. When I check with him, on the same problem machine, he doesn't see the problem. So that means it's confined to a single user, no doubt a corrupted config file. Good enough for me. Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Advisory from comment 9 uploaded
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0273.html
Status: NEW => RESOLVEDResolution: (none) => FIXED