Permanent Updates Policy exception for WebKitGTK #3565

Closed
opened 2026-02-10 16:58:24 +00:00 by catanzaro · 10 comments

Hi, I request a permanent updates policy exception for WebKitGTK. I've been ignoring the updates policy for about a decade now, continuously updating to the latest stable release even when that requires a rebase in stable versions of Fedora. This violates the updates policy.

I think an exception should be uncontroversial because (a) WebKitGTK updates often fix many CVEs, and (b) library ABI is carefully maintained, and (c) so far so good: updating has worked well so far, sometimes things break, but we don't get too many complaints. The following points from the updates policy apply:

  • "The update fixes a security issue that would affect a large number of users." The large volume of WebKit CVEs is the primary motivation for regular rebasing. (A new major version is released every 6 months, in March and September.)
  • "The update doesn’t change ABI/API and nothing needs to be rebuilt against the new version." Stable library ABI is maintained.

One of the negative points also applies: "The update causes behavior changes (something that was denied is allowed, etc.)" Behavior changes can occur even in stable updates, but it's more likely in major version updates. I believe this risk is outweighed by the security benefit of regularly updating.

Hi, I request a [permanent updates policy exception](https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions) for WebKitGTK. I've been ignoring the updates policy for about a decade now, continuously updating to the latest stable release even when that requires a rebase in stable versions of Fedora. This violates the updates policy. I think an exception should be uncontroversial because (a) WebKitGTK updates often fix many CVEs, and (b) library ABI is carefully maintained, and (c) so far so good: updating has worked well so far, sometimes things break, but we don't get too many complaints. The following points from the updates policy apply: * "The update fixes a security issue that would affect a large number of users." The large volume of WebKit CVEs is the primary motivation for regular rebasing. (A new major version is released every 6 months, in March and September.) * "The update doesn’t change ABI/API and nothing needs to be rebuilt against the new version." Stable library ABI is maintained. One of the negative points also applies: "The update causes behavior changes (something that was denied is allowed, etc.)" Behavior changes can occur even in stable updates, but it's more likely in major version updates. I believe this risk is outweighed by the security benefit of regularly updating.
Owner

+1

+1
Owner

+1

+1
Owner

Metadata Update from @decathorpe:

  • Issue tagged with: updates policy exception
**Metadata Update from @decathorpe**: - Issue tagged with: updates policy exception
Owner

+1

+1
Owner

+1

+1
Owner

+1

+1
Owner

Approved (almost a week ago, actually) (+5, 0, -0)

Approved (almost a week ago, actually) (+5, 0, -0)
Owner

Metadata Update from @sgallagh:

  • Issue tagged with: pending announcement
**Metadata Update from @sgallagh**: - Issue tagged with: pending announcement
Owner

Metadata Update from @sgallagh:

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

Created fesco/docs#127, thanks.

Warning: I notice the live site https://docs.fedoraproject.org/en-US/fesco/ is still backed by the old Pagure repo https://pagure.io/fesco/fesco-docs rather than the new repo https://forge.fedoraproject.org/fesco/docs

Created https://forge.fedoraproject.org/fesco/docs/pulls/127, thanks. Warning: I notice the live site https://docs.fedoraproject.org/en-US/fesco/ is still backed by the old Pagure repo https://pagure.io/fesco/fesco-docs rather than the new repo https://forge.fedoraproject.org/fesco/docs
Sign in to join this conversation.
No milestone
No project
No assignees
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
fesco/tickets#3565
No description provided.