On 2/17/22 06:46 AM, Stephen Snow wrote:
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
That is a good point. KiCad now plans to have annual major version bumps - these will naturally not coincide with Fedora releases. Thus I expect that Fedora will often have unsupported versions of KiCad for long periods of time, going forward.
Is approval from FESCO or other group needed to permit major version bumps in a stable Fedora release?
Steve
_______________________________________________
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
