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).

QtWebKit-2.2.0 is up-to-date regarding security vulnerabilities found in the WebKit codebase up to its release in September, 2011. Later updates on the 2.2 series will include security fixes and their announcements will be listed on this page.

Security Announcements

Security reports are sent to the ​QtWebKit Announcements mailing list. Below is a list of announcements made so far:

• None yet (this will be a list of links to the announcements mailing list)

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 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:

• ​Google Chrome
• ​Apple Safari

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.