⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.
wiki:QtWebKitSecurity

QtWebKit Security Policy

QtWebKit follows WebKit's security policy, which is documented in ​http://www.webkit.org/security/

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 WebKit.org 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 cherry-pick-into-release-branch.py 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)
$ cherry-pick-into-release-branch.py --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 cherry-pick-into-release-branch.py --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 cherry-pick-into-release-branch.py 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):

$ cherry-pick-into-release-branch.py --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.

Last modified 10 years ago Last modified on Mar 16, 2017, 11:01:42 AM
Note: See TracWiki for help on using the wiki.