Changes between Version 7 and Version 8 of QtWebKitSecurity
- Timestamp:
- Sep 27, 2011 2:06:59 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
QtWebKitSecurity
v7 v8 3 3 !QtWebKit follows WebKit's security policy, which is documented in http://www.webkit.org/security/ 4 4 5 The !QtWebKit project makes only source-code releases and is not responsible for delivering binary updates to end users. The end-users should get theirupdates from their respective vendor (Linux distributions, device vendor, etc).5 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). 6 6 7 !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.7 !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. 8 8 9 9 == Security Announcements == … … 12 12 13 13 * None yet (this will be a list of links to the announcements mailing list) 14 15 === Investigating and cherry-picking security fixes === 16 17 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. 18 19 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): 20 21 {{{ 22 $ # inside the stable branch, master is the trunk mirror 23 $ BASE_COMMIT=$(git merge-base HEAD master) 24 $ cherry-pick-into-release-branch.py --list-only --security-bugs-from $BASE_COMMIT..master 25 }}} 26 27 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). 28 29 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. 30 31 The list of security bugs pending cherry-picking should be kept outside of the bugzilla master-bugs for two reasons: 32 * Avoid spaming developers with useless blocking/unblocking notification e-mails; 33 * Avoid listing security bugs which are not public yet. 34 35 However, we do add cherry-pick comments to them once the fix is in the public branch. 14 36 15 37 === Preparing Security Announcements === … … 31 53 * The researchers who should receive credit. 32 54 33 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.55 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.