I have just seen on oss-security that CVE-2013-2126 affect also darktable, because darktable embed libRaw. This is against the Fedora policy and should be fixed. There is also various others bits there : darktable-1.2.1/src/external $ ls adobe_coeff.c CL colord-gtk dcraw.c LibRaw OpenCL osm-gps-map rawspeed squish update_dcraw.sh And for example, darktable is listed as being GPL v3 or later, while osm-gps-mapis GPL v2 only , thus having incompatible license.
So, after a closer look : - squish is unsuitable for Fedora, snce it implement s3tc, a patented algorithm ( found by Nicolas Chauvet ) - LibRaw is suffering from a security issue - osm-gps-map is GPL v2, so not compatible with GPLv3+ That's serious issues, and I think that darktable will have to be removed from Fedora, maybe moved to rpmfusion ( due to issue of squish ).
Digging a little bit more in the issue, this as brought to developers ( the libraw issue ) and they are against unbundling : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682980
The Debian bug report is very interesting. They need their own libraw to support DNG 16bit reading, if I understand... Are you sure Squish is enabled in the darktable rpm? I've just asked darktable-devel and the answer is it's disabled by default. However I see some build about squish, so I will try to rebuild darktable with cmake -DUSE_SQUISH=off I will add a patch about the LibRaw security issue too.
For osm-gps-map it seems the author want a GPL3 license: http://nzjrs.github.io/osm-gps-map/
Unfortunately, used or not, this is the same, distributing the code that implement is a issue. ( and the code is distributed by SRPM ). While the upstream developer seems to think the issue is not important ( at least what I gather from his commit 52e3da28 ), patents litigations can quickly get expensive and ugly, especially when the company owning them ( in the case of ST3C, this is HTC ) is not going well. I cannot find the exact reference, but you can see on various SEC filling the money paid on such issues (and think that all this money is not money invested in free software, if the defendant is a company making free software), or look on the chilling effect of the SCO case on the whole free software ecosystem a few years ago ( ie, FUD from Microsoft, fear of using free software or to contribute back, etc ). Regarding libraw, if they need to patch then you need to apply to a exception to FESCO, and you should have a provides to show libraw is bundled, to ease the work of the security team, see : https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#When_a_Bundled_Library_is_Discovered_Post-Review
For osm-gps-map, the bundled code say GPL v2, if I didn't read it wrong. So maybe upstream did update the license.
The developer is aware of the problem, but mostly share the debian point of view summarized here http://www.debian.org/reports/patent-faq and http://lists.debian.org/debian-legal/2003/11/msg00081.html This point of view seems less dramatic than the Fedora's. For the moment I have disabled squish, that the least I can do. About LibRaw, darktable needs a specific version of it since the upstream project have removed functionnalities darktable relies on. Same problem on any other distros. So there is no other choice right now. About osm-gps-map, since the upstream is gplv3 now, this is not any more a problem? Should be fixed in future/next darktable releases, since they certainly use a more recent osm-gps-map. This feature was requested by some fedora users.
Debian do not have a US company who is taking the legal risk for them, unlike Fedora. And I think that even if you do not have legal risk for the legal entity behind your distribution ( as Debian is likely not something that would be attacked IMHO ), some of the downstream users will have ( like, for example, a OEM distributing your distribution pre-installed on his computer, or installing one derivative distribution of yours ), so being clear is important, but that's their choice. And no, I think you should remove the code of squish from the tarball : https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code For LibRaw, even if there is no choice because the 2 upstreams are unable to find a common ground regarding the patch, that doesn't change the fact this is bundled and requires a exception. There is several case of such exceptions, see pypdf and calibre. And the same goes for others libraries, they have to be unbundled, even if there is no security/license/patent issues.
Could you provide any reference that the source code included is prohibited? I don't find any.
The whole src/external/squish in the tarball, since http://www.sjbrown.co.uk/squish/ is for DXT/S3TC compression. See https://en.wikipedia.org/wiki/S3_Texture_Compression And https://bugzilla.redhat.com/show_bug.cgi?id=407561 And https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems#S3TC_Texture_Compression
The last one is fine. Thanks. Will build a source without squish code source asap.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still bundling of library.
Did you report to upstream? Not sure I can do anything on my side.
I didn't report to upstream, they made their opinion quite clear on it not being a issue But that doesn't mean the issue should not be fixed downstream. For bundling matter, this should be brought and seen with FPC.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
I sent an e-mail to libraw developers about https://access.redhat.com/security/cve/CVE-2013-2126 As soon they will reply, I will let you know.
============ As stated in CVE, 'LibRaw before 0.15.2'. It was fixed in 0.15.2 (and, 0.16.0 and coming 0.17) Alex Tutubalin, LibRaw team ============
No, the bug is not fixed. The code is still bundled, and that's still against the policy.
(In reply to Michael Scherer from comment #19) > No, the bug is not fixed. The code is still bundled, and that's still > against the policy. Fill another bugreport. The topic of bugreport 972604 is about CVE-2013-2126 security issue
No, this bug report is about bundling. I filled it originally for that. The title is "dark table bundles various library", I detailed why this is a problem for more than security issue, and part of the problem was solved but not all ( since it still bundle various library ). The bug is also linked to a tracker bug for bundling. For the CVE-2013-2126, this is https://bugzilla.redhat.com/show_bug.cgi?id=968385 or one of the linked bug. Now, closing this bug and reopening one would just remove history of the discussion, and I do not think that's a good thing for accountability.
Darktable ships: - opencl (just headers); - rawspeed (not packaged anywhere); - squish (that has been removed); - lua (disabled because not enabled in cmake, so only used if explicitly told); - colord-gtk and osmgpsmap which are not the same as upstream versions of those libraries Next major release won't bundle *anything* but lua. For Darktable 1.6 series it is not possible to do anything
err, it will also bundle rawspeed and opencl. But opencl is still just headers and rawspeed is still not bundled separately in Fedora
OpenCL is easy to fix, I've committed that fix to rawhide. Based on what I see here (https://github.com/klauspost/rawspeed), rawspeed is really intended to be a copylib by the upstream. You should open a bundling ticket with the FPC asking them to permit rawspeed to be treated as a copylib (and thus, okay to bundle in darktable): https://fedorahosted.org/fpc/ That said, the Legal issues in this ticket have been long resolved, so I'm dropping FE-Legal block here.
(In reply to Tom "spot" Callaway from comment #24) > Based on what I see here (https://github.com/klauspost/rawspeed), rawspeed > is really intended to be a copylib by the upstream. You should open a > bundling ticket with the FPC asking them to permit rawspeed to be treated as > a copylib (and thus, okay to bundle in darktable): > > https://fedorahosted.org/fpc/ https://fedorahosted.org/fpc/ticket/550
http://www.darktable.org/2015/06/released-darktable-1-6-7/ and https://github.com/LibRaw/LibRaw/commit/4606c28f494a750892c5c1ac7903e62dd1c6fdb5 It looks like darktable is still bundling libraw and must fix the same security issues...
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Darktable is probably going to be removed from Fedora official repositories after Fedora Packaging Committee decision: https://fedorahosted.org/fpc/ticket/550#comment:6 You can still use Darktable by enabling my personal Copr repository: # dnf copr enable germano/darktable # dnf install darktable Fedora should update your existing Darktable without any problem. You can find the two commands also here http://www.darktable.org/install/#fedora
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
https://fedorahosted.org/fpc/ticket/550#comment:9
Fedora Packaging Committee ticket "Bundling Guidelines Overhaul" https://fedorahosted.org/fpc/ticket/575 states that is no longer required to ask for exception to bundle libraries. Ticket proposal has been accepted and included into guidelines https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries rawspeed bundled library has been documented at http://pkgs.fedoraproject.org/cgit/rpms/darktable.git/tree/darktable.spec#n57