KiCad release policy request

stevenfalco commented

2022-02-17 15:25:29 +00:00

There are several CVE's against KiCad: CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947.

These have been fixed in KiCad version 6.0.2, but I haven't pushed 6.0.2 into F34 and F35 because that would be a major version update; KiCad is currently at 5.1.12 in F34 and F35.

Upstream no longer maintains 5.1.12, and I've unsuccessfully attempted to cherry pick the 6.0.2 fixes into 5.1.12.

KiCad is a "leaf node". There are some UI changes between 5.1.12 and 6.0.2 - personally I don't find the UI changes to be problematic - the overall look and feel is consistent. Files written by 6.0.2 cannot be read by 5.1.12, but files written by 5.1.12 are perfectly readable in 6.0.2. No administrator activity would be needed; there are no system configuration files involved.

KiCad has announced that they plan to do annual major version updates that will not align with Fedora releases, therefore I think maintenance will continue to be a problem in the future.

Therefore, I'd like to request that KiCad be exempted from the policy prohibiting major version changes during stable Fedora releases.

There are several CVE's against KiCad: CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947. These have been fixed in KiCad version 6.0.2, but I haven't pushed 6.0.2 into F34 and F35 because that would be a major version update; KiCad is currently at 5.1.12 in F34 and F35. Upstream no longer maintains 5.1.12, and I've unsuccessfully attempted to cherry pick the 6.0.2 fixes into 5.1.12. KiCad is a "leaf node". There are some UI changes between 5.1.12 and 6.0.2 - personally I don't find the UI changes to be problematic - the overall look and feel is consistent. Files written by 6.0.2 cannot be read by 5.1.12, but files written by 5.1.12 are perfectly readable in 6.0.2. No administrator activity would be needed; there are no system configuration files involved. KiCad has announced that they plan to do annual major version updates that will not align with Fedora releases, therefore I think maintenance will continue to be a problem in the future. Therefore, I'd like to request that KiCad be exempted from the policy prohibiting major version changes during stable Fedora releases.

stevenfalco commented

2022-02-17 15:29:16 +00:00

Author

I should point out that there are also bugs regarding these CVE's:

I should point out that there are also bugs regarding these CVE's: https://bugzilla.redhat.com/show_bug.cgi?id=2054956 https://bugzilla.redhat.com/show_bug.cgi?id=2054957 https://bugzilla.redhat.com/show_bug.cgi?id=2054959 https://bugzilla.redhat.com/show_bug.cgi?id=2054960 https://bugzilla.redhat.com/show_bug.cgi?id=2054955 https://bugzilla.redhat.com/show_bug.cgi?id=2054973 https://bugzilla.redhat.com/show_bug.cgi?id=2054974 https://bugzilla.redhat.com/show_bug.cgi?id=2054979 https://bugzilla.redhat.com/show_bug.cgi?id=2054980 https://bugzilla.redhat.com/show_bug.cgi?id=2054958 https://bugzilla.redhat.com/show_bug.cgi?id=2054972 https://bugzilla.redhat.com/show_bug.cgi?id=2054978

ngompa commented

2022-02-17 15:30:38 +00:00

Owner

I think this is fine, so...

+1

I think this is fine, so... +1

sgallagh commented

2022-02-17 15:36:39 +00:00

Owner

I don't have a problem exempting this package from the stable updates policy, but I wonder if it might not be a better long-term solution to package it as a Flatpak instead?

Anyway, +1 so as not to block the immediate solution.

I don't have a problem exempting this package from the stable updates policy, but I wonder if it might not be a better long-term solution to package it as a Flatpak instead? Anyway, +1 so as not to block the immediate solution.

zbyszek commented

2022-02-17 16:52:36 +00:00

Owner

+1

(I don't think flatpak vs. rpms matters here: the issue is that upstream updates with a faster cadence than we'd like and it is too hard to provide support for older releases. With flatpaks only the latest version would be supported, so users will have as much or even less choice than with rpms.)

+1 (I don't think flatpak vs. rpms matters here: the issue is that upstream updates with a faster cadence than we'd like and it is too hard to provide support for older releases. With flatpaks only the latest version would be supported, so users will have as much or even less choice than with rpms.)

decathorpe commented

2022-02-18 18:02:18 +00:00

Owner

Upstream no longer maintains 5.1.12, and I've unsuccessfully attempted to cherry pick the 6.0.2 fixes into 5.1.12.

These two facts taken together make this a clear +1 for me.

> Upstream no longer maintains 5.1.12, and I've unsuccessfully attempted to cherry pick the 6.0.2 fixes into 5.1.12. These two facts taken together make this a clear +1 for me.

churchyard commented

2022-02-18 18:07:23 +00:00

+1

stevenfalco commented

2022-02-19 15:50:21 +00:00

Author

So far, I've seen 5 positive votes and no negative votes here. That is encouraging.

Will there be a FESCo meeting on Tuesday? Will this issue get a final decision then?

I'm not trying to rush the process, but I'd naturally like to move forward as soon as I can.

So far, I've seen 5 positive votes and no negative votes here. That is encouraging. Will there be a FESCo meeting on Tuesday? Will this issue get a final decision then? I'm not trying to rush the process, but I'd naturally like to move forward as soon as I can.

churchyard commented

2022-02-19 20:29:06 +00:00

There are multiple paths forward:

If nothing special happens, and nobody votes against it, this ticket will be approved 7 days after it was created. If all 9 FESCo members vote +1, it is approved immediately, but that rarely ever happens.
If you want to move forward quickly, we can tag this ticket with "fast track" -- that means if this gains +7 before anybody votes against it, it's approved immediately. This currently requires additional 2 positive votes and fallbacks to a full week if not received.
Alternatively, we can tag this ticket with "meeting" to rubber-stamp it on Tuesday, however, there are no other meeting-tagged tickets, so I'd rather not ask ~9 people to sit down at the same moment just to approve this one.

There are multiple paths forward: - If nothing special happens, and nobody votes against it, this ticket will be approved 7 days after it was created. If all 9 FESCo members vote +1, it is approved immediately, but that rarely ever happens. - If you want to move forward quickly, we can tag this ticket with "fast track" -- that means if this gains +7 before anybody votes against it, it's approved immediately. This currently requires additional 2 positive votes and fallbacks to a full week if not received. - Alternatively, we can tag this ticket with "meeting" to rubber-stamp it on Tuesday, however, there are no other meeting-tagged tickets, so I'd rather not ask ~9 people to sit down at the same moment just to approve this one.

kevin commented

2022-02-19 20:49:02 +00:00

Owner

I'm +1 to this case, but I would urge the maintainer to not just always update it, even if it's release cycle is off from fedoras. If there's serious bugs fixed then sure, but if not, letting stable release users use an old version for a few months would be better than always updating them in the middle of a stable release.

stevenfalco commented

2022-02-19 22:25:58 +00:00

Author

@churchyard - thanks for explaining the process. I hadn't known about the automatic 7 day approval period or fast track tags; I thought a formal meeting was needed. And I agree that forcing a meeting just for this issue is inappropriate.

Because the CVE's do represent some risk to users, and because there is no good way to make the users aware of the risk, perhaps the "fast track" tag is appropriate - we are currently 1 vote shy by my count.

@kevin - I understand and agree with your point. I won't use the exemption, should it be granted, unless there is a serious bug that cannot be dealt with any other way.

@churchyard - thanks for explaining the process. I hadn't known about the automatic 7 day approval period or fast track tags; I thought a formal meeting was needed. And I agree that forcing a meeting just for this issue is inappropriate. Because the CVE's do represent some risk to users, and because there is no good way to make the users aware of the risk, perhaps the "fast track" tag is appropriate - we are currently 1 vote shy by my count. @kevin - I understand and agree with your point. I won't use the exemption, should it be granted, unless there is a serious bug that cannot be dealt with any other way.

churchyard commented

2022-02-19 22:27:03 +00:00

Metadata Update from @churchyard:

Issue tagged with: fast track

**Metadata Update from @churchyard**: - Issue tagged with: fast track

stevenfalco commented

2022-02-28 19:54:06 +00:00

Author

Has this been approved based on elapsed time with no negative votes? Can I proceed with the build?

churchyard commented

2022-02-28 20:09:58 +00:00

Yes, it was. Yes, you can. Sorry for the delay.

APPROVED (+6,0,-0)

Yes, it was. Yes, you can. Sorry for the delay. APPROVED (+6,0,-0)

churchyard commented

2022-02-28 20:09:59 +00:00

Metadata Update from @churchyard:

Issue untagged with: fast track
Issue tagged with: pending announcement

**Metadata Update from @churchyard**: - Issue **un**tagged with: fast track - Issue tagged with: pending announcement

churchyard commented

2022-02-28 20:10:10 +00:00

Metadata Update from @churchyard:

Issue tagged with: document it

**Metadata Update from @churchyard**: - Issue tagged with: document it

stevenfalco commented

2022-02-28 20:19:24 +00:00

Author

Thanks!

stevenfalco commented

2022-02-28 21:56:31 +00:00

Author

Normally, there is a 7 day delay between a build going into testing and then going into stable - we never get enough karma to shorten that.

Given that these builds are to address CVE's, should that interval be shortened, or should some other parameter be changed?

If so, since I've never done that before, would I specify the parameters when I do the "fedpkg update"?

Normally, there is a 7 day delay between a build going into testing and then going into stable - we never get enough karma to shorten that. Given that these builds are to address CVE's, should that interval be shortened, or should some other parameter be changed? If so, since I've never done that before, would I specify the parameters when I do the "fedpkg update"?

churchyard commented

2022-03-01 10:01:36 +00:00

That will not work. You can lower the karma limits and ask somebody to test it.

ngompa commented

2022-03-01 16:49:06 +00:00

Owner

This is now announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WUNDVPZNIV3UK5HOQ4YXWBWOEQLIUJMC/

ngompa commented

2022-03-01 16:49:06 +00:00

Owner

Metadata Update from @ngompa:

Issue close_status updated to: Accepted
Issue status updated to: Closed (was: Open)

**Metadata Update from @ngompa**: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)

churchyard commented

2022-03-01 16:55:16 +00:00

But still needs to be documented?

churchyard commented

2022-03-01 16:55:16 +00:00

Metadata Update from @churchyard:

Issue untagged with: pending announcement
Issue status updated to: Open (was: Closed)

**Metadata Update from @churchyard**: - Issue **un**tagged with: pending announcement - Issue status updated to: Open (was: Closed)

ngompa commented

2022-03-01 17:06:17 +00:00

Owner

Blech, you're right.

stevenfalco commented

2022-03-08 19:14:36 +00:00

Author

I've opened a PR to document the exception. I'm not sure if that is my responsibility to merge, or if I even have that authorization. Anyway, here is the PR: https://pagure.io/fesco/fesco-docs/pull-request/60

churchyard commented

2022-03-08 20:46:05 +00:00

Thanks.

churchyard commented

2022-03-08 20:46:05 +00:00

Metadata Update from @churchyard:

Issue close_status updated to: Accepted
Issue status updated to: Closed (was: Open)

**Metadata Update from @churchyard**: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)

Rows
Columns

KiCad release policy request #2762