On 2/16/22 18:05, Adam Williamson wrote: > On Wed, 2022-02-16 at 14:20 -0500, Steven A. Falco wrote: >> On 2/16/22 01:58 PM, Dan Horák wrote: >>> On Wed, 16 Feb 2022 13:53:04 -0500 >>> "Steven A. Falco" <stevenfalco@xxxxxxxxx> wrote: >>> >>>> There are some CVE's against KiCad that have been fixed in the latest version, namely KiCad 6.0.2. I've built that for F36 and Rawhide. >>>> >>>> I have not released KiCad 6.0.2 into Fedora 34 and 35, because my understanding is that by policy, we don't generally allow "major version" updates in stable Fedora releases. Thus F34 and F35 still ship KiCad 5.1.12, which is affected by the CVE's. >>>> >>>> I could easily build KiCad 6.0.2 for F34 / F35 - in fact, I have done so in the KiCad Copr repository. >>>> >>>> So, should this situation be an exception to the policy of "no major version changes in a stable release"? >>> >>> as often, it depends :-) >>> >>> - what's the severity level of the CVEs? >>> - does KiCad 6 come with substantial changes like UI redesign, >>> compatibility issues with previous release, etc? >> >> The vulnerability is rated as "7.8 - CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", whatever that means. :-) >> >> Basically, attempting to read a malicious file can cause a buffer overflow, and then execute malicious code. >> >> KiCad is not suid, so the risk would be to an individual user rather than the whole system. As shown in https://xkcd.com/1200/, this is not a mitigation in practice, because most Linux systems are single-user, which means that a user compromise is effectively equivalent to root compromise >> KiCad 6 does have UI changes and files it creates cannot be read by KiCad 5 or earlier. >> >> I contacted upstream, and I know what patches form a part of the solution, but they don't apply cleanly to KiCad 5. I might be able to sort them out... > > The 'ideal' solution is to backport the security fix, yes. If you're > not able to do this, or find anyone else who can do it for you, I guess > it kinda becomes a judgment call whether fixing the security issue is > "worth" the compatibility problems. I don't think we have a definite > guide/policy to what to do if the optimal solution isn't practical, > here? Security researcher here. My view is that there are some packages for which the release cycle needs to be that of upstream, even if Fedora has a different one. Browser engines and the Linux kernel certainly fall into that category, and complex desktop software such as KiCad might as well. I would rather take the compatibility breakage a bit early than have an insecure system. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
