[[PageOutline]]

= QtWebKit Security Policy =

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

The !QtWebKit project makes only [wiki:QtWebKitReleases 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 [wiki:QtWebKitReleases#Proceduresforcherry-pickingandweeklyreleasing 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 [wiki:QtWebKitReleases 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 [http://cve.mitre.org/ 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.