= 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 updates to end users. The end-users should get their 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. 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)

=== 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. Preferably one or two days before making it public. Exceptions and any topics regarding the security policy can be also discussed there.