Changes between Version 4 and Version 5 of QtWebKitSecurity


Ignore:
Timestamp:
Sep 27, 2011 1:28:23 PM (8 years ago)
Author:
Ademar Reis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • QtWebKitSecurity

    v4 v5  
    33!QtWebKit follows WebKit's security policy, which is documented in http://www.webkit.org/security/
    44
    5 !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.
     5!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.
    66
    77== Security Announcements ==
    88
    99  * None yet (this will be a list of links to the announcements mailing list)
     10
     11=== Preparing Security Announcements ===
     12
     13Part 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.
     14
     15Examples of security announcements:
     16   * [http://googlechromereleases.blogspot.com/2011/08/stable-channel-update_22.html Google Chrome]
     17   * [http://support.apple.com/kb/HT4808 Apple Safari]
     18
     19The 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:
     20(notice you'll need proper bugzilla privileges)
     21
     22{{{
     23$ cherry-pick-into-release-branch.py --no-git-pull --list-only --security-bugs-from qtwebkit-2.2.0..
     24}}}
     25
     26With this list in hand, we can go to Bugzilla and find out, manually:
     27  * The CVE Id of the issue;
     28  * The researchers who should receive credit;
     29
     30Once 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.
     31
     32Exceptions should always be discussed in the [mailto:security@webkit.org WebKit Security Mailing List].