= 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 [http://lists.qt.nokia.com/mailman/listinfo/qtwebkit-announce 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. 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 security issues fixed (including the CVE Id) and give credit to the researchers who discovered and reported it. Examples of security announcements: * [http://googlechromereleases.blogspot.com/2011/08/stable-channel-update_22.html Google Chrome] * [http://support.apple.com/kb/HT4808 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 [mailto:security@webkit.org 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.