Version 17 (modified by Konstantin Tokarev, 7 years ago) (diff)

Removed info about 2.2.0 that is not the latest stable release for a loong time

QtWebKit Security Policy

QtWebKit follows WebKit's security policy, which is documented in

The QtWebKit project makes only source-code releases and is not responsible for delivering binary packages to end users, which should get updates from their respective vendor (Linux distributions, device vendor, etc).

Investigating and cherry-picking security fixes

Security issues are constantly found and fixed on trunk. In order to keep a supported version of QtWebKit up-to-date, these issues have to be investigated and, if it's found that they affect QtWebKit, cherry-picked or backported into the stable branch.

IMPORTANT: Per policy, security bugs and vulnerability details are not listed in public announcements until vendors agree on a time and date for disclosure. Bugs usually remain closed to public scrutiny indefinitely. Special care should be taken when making release announcements, specially semi-automated weekly announcements, where security bugs should have their titles omitted.

To monitor trunk, we can use the script. The option --security-bugs-from allows the filtering of a range of git commits to list which ones are security related. For example, to extract a list of security issues fixed in trunk since the branch creation, we can use the following command (notice you'll need proper bugzilla privileges and this will take a while, so you may want to do it incrementally):

$ # inside the stable branch, master is the trunk mirror
$ BASE_COMMIT=$(git merge-base HEAD master)
$ --list-only --security-bugs-from $BASE_COMMIT..master

Most security issues affect all ports. The ones specific to one vendor usually include a prefix (such as [v8], [chromium] or [safari]). Some issues require a bit more investigation because the affected feature may be disabled in QtWebKit (for example, fullscreen support or webgl).

Once the bugs are filtered out, they can be cherry-picked as usual with --bugs or git cherry-pick directly.

The list of security bugs pending cherry-picking should be kept outside of the bugzilla master-bugs for two reasons:

  • Avoid spaming developers with useless blocking/unblocking notification e-mails;
  • Avoid listing security bugs which are not public yet.

However, we do add cherry-pick comments to them once the fix is in the public branch.

Preparing Security Announcements

Part of the release-notes of patch-level releases (such as QtWebKit-2.2.1, QtWebKit-2.2.2, etc) should be dedicated to the security problems which have been fixed. It's standard procedure to include a list of issues (including the CVE Id) and give credit to the researchers who discovered and reported it.

Examples of security announcements:

The list of security bugs fixed in the branch since the last release can be extracted from the git changelog using the script. For example, to extract a list of all security issues fixed from the tag qtwebkit-2.2.0 until now (notice you'll need proper bugzilla privileges):

$ --no-git-pull --list-only --security-bugs-from qtwebkit-2.2.0..

With this list in hand, we can go to Bugzilla and find out, manually:

  • The CVE Id of the issue;
  • The researchers who should receive credit.

Once the release notes is ready, it should be sent to the WebKit Security mailing list for peer review and coordination. To make sure we're not disclosing information prematurely, it should be sent one or two days before we make a public announcement. Exceptions and any topics regarding the security policy can be also discussed there.