#1555 Please clarify updates policy for security issues
Closed None Opened 8 years ago by thozza.

= phenomenon =
The Updates Policy page (https://fedoraproject.org/wiki/Updates_Policy#Security_fixes) discusses the case when backporting a security fix into stable Fedora release is impossible/impractical. In such case the component can be rebased onto the latest supported upstream version. However the judgment of practicality is left up to the maintainer and FESCo.

= background analysis =
The definition is too vague and useless as a guidance for deciding when to go to FESCo for a decision. There are some examples, which provide some idea but one can just guess what is right.

= implementation recommendation =
Have more clear definition of when an explicit FESCo approval is needed and if it is needed at all. This means if there are specific criteria when FESCo have to approve the update before pushing it to updates-testing? Or if FESCo is supposed to step in only after there are complains about the update? In such case I expect it to decide if it is worth to push the update to stable or if to reject the update and keep the vulnerable version in Fedora.


My understanding of this has always been that a maintainer doing a major version update for a security release needs to come to FESCo for approval when the update breaks these criteria already listed:

Package maintainers MUST:
Avoid Major version updates, ABI breakage or API changes if at all possible.
Avoid changing the user experience if at all possible.

So if ABI or API changes happen, or there is a major UX change, then FESCo should be consulted. We can add a sentence to the Security fixes section stating so if that would be helpful.

Stepping in after an update has already hit updates-testing is not an ideal process. It means users are potentially impacted negatively already and may have to resort to manual fallback. We should be able to plan better than simply reacting to complaints.

What about cases when the rebase potentially breaks the backward compatibility of configuration users possibly have? E.g. in case of some network daemons. I guess this counts as a user experience?

Replying to [comment:2 thozza]:

What about cases when the rebase potentially breaks the backward compatibility of configuration users possibly have? E.g. in case of some network daemons. I guess this counts as a user experience?

I was lumping that in with either UX or ABI/API breakage. The same problem exists for things like new db formats, etc. We list those in the section discussing things less likely to get a request granted:

Things that would make it less likely to grant a request:

  • The update converts databases or resources one way to a new format.
  • The update requires admin intervention for the service to keep working (config file format changes, etc)
  • The update causes behavior changes (something that was denied is allowed, etc)
  • The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line)
  • The update fixes bugs that no fedora user has reported nor would affect many fedora users (ie, fixes for other platforms or configurations).

So yes, I would think a FESCo ticket would be appropriate in those situations as well. We can clarify the criteria on the page to be more explicit about those kinds of situations.

Thanks for the pointers. It seems that all the information is there, but it not clear to me, when an explicit approval is required. I can prepare a draft of the change for FESCo if that would be helpful (in case FESCo does not want to have their own wording).

BTW we created https://fedorahosted.org/fesco/ticket/1557

Thank you.

jsmith was going to work on a draft here I think.

Lets remove meeting keyword until thats ready.

jsmith: Have you had any chance to look at some wording?

I'm still working on the wording this morning, but should have something to show publicly in today's meeting.

OK, I think this wording is ready for our meeting today. This wording would replace the "Security Fixes" paragraph that currently exists at ​https://fedoraproject.org/wiki/Updates_Policy#Security_fixes


If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then the package maintainer(s) MUST open a FESCo ticket for approval to rebase the package to a version that upstream supports.

Package maintainers MUST:
Avoid Major version updates, AI breakage, or API changes if at all possible
Avoid changing the user or developer experience if at all possible

FESCo will review the ticket in a timely manner and give guidance as to how the package maintainer(s) should proceed. By way of information, several common items that would make it less likely for FESCo to grant a rebase request are listed below. Please note, however, that this list is not exhaustive.

FESCo will be less likely to grant a rebase request if:
The update requires user or administrator intervention to keep working
The update requires configuration files or databases or other resources to convert to a new format
The update causes policy or behavior changes (such as when something that was previously denied is now allowed, etc.)
The update changes the way the end user interacts with the user interface (such as moving menus or buttons to a new location, changing names of command-line arguments, etc.)
* The update fixes bugs that affect very few Fedora users

Replying to [comment:10 jsmith]:

  • The update fixes bugs that affect very few Fedora users

Can we rephrase this? I assume the intent of the statement is to actually determine the relative value of the update vs. its potential disruption. I also expect that this would have been more clearly stated as "The rebase only addresses issues that are likely to affect a subjectively small number of Fedora users."

OK, here's the updated language, based on sgallagh's suggestion:


If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then the package maintainer(s) MUST open a FESCo ticket for approval to rebase the package to a version that upstream supports.

Package maintainers MUST:

  • Avoid Major version updates, AI breakage, or API changes if at all possible
  • Avoid changing the user or developer experience if at all possible

FESCo will review the ticket in a timely manner and give guidance as to how the package maintainer(s) should proceed. By way of information, several common items that would make it less likely for FESCo to grant a rebase request are listed below. Please note, however, that this list is not exhaustive.

FESCo will be less likely to grant a rebase request if:

  • The update requires user or administrator intervention to keep working
  • The update requires configuration files or databases or other resources to convert to a new format
  • The update causes policy or behavior changes (such as when something that was previously denied is now allowed, etc.)
  • The update changes the way the end user interacts with the user interface (such as moving menus or buttons to a new location, changing names of command-line arguments, etc.)
  • The rebase only addresses issues that are likely to affect a subjectively small number of Fedora users

I presume we'll have standing exceptions for certain packages (Firefox, WebKit, OwnCloud, etc.) to avoid needing to spam FESCo with the same request on a regular basis? E.g. for WebKit we want to do a major upgrade every six months to maintain security support. Firefox would want this every release. etc.

FESCo decided to add "Exceptions to this are listed below" to the final text.

  • AGREED: jsmith to update the text (jsmith, 16:14:16)

Jared, please close this ticket once the wiki is updated.

Jared,
Can you please provide update here?

Login to comment on this ticket.

Metadata