On Wed, 2022-02-16 at 22:50 -0500, Demi Marie Obenour wrote: > 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. > Fedora Linux user here +1 on these comments by Demi Stephen Snow > _______________________________________________ > 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 _______________________________________________ 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
