Changes between Version 4 and Version 5 of QtWebKitSecurity

Timestamp:

Sep 27, 2011, 1:28:23 PM (13 years ago)

Author:

Ademar Reis

Comment:

--

QtWebKitSecurity

@@ -3 +3 @@
 !QtWebKit follows WebKit's security policy, which is documented in http://www.webkit.org/security/
 
-!QtWebKit-2.2.0 is up-to-date regarding security vulnerabilities found in the WebKit codebase. Later updates on the 2.2 series are in the section below.
+!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 ==
 
   * 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 should always be discussed in the [mailto:security@webkit.org WebKit Security Mailing List].