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" <stevenfa...@gmail.com> 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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
