ReleaseCycle
6451
Comment:
|
6396
|
Deletions are marked like this. | Additions are marked like this. |
Line 40: | Line 40: |
* make sure MoM is updated for -security pockets according to EndOfLifeProcess | |
Line 42: | Line 41: |
* update architectures in [[https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures|SecurityTeam/FAQ]] | * update architectures to include "EOL" footnote in [[https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures|SecurityTeam/FAQ]] |
How the Security Team interacts with the regular Ubuntu Release Cycle.
Security Updates
pre-feature-freeze
- request syncs for issues fixed in stable releases that are not fixed in the development release, but are fixed in upstream versions.
post-feature-freeze
- request feature-freeze exceptions for upstream security fixes, or push security patches, depending on extent of upstream changes.
post-beta
- focus security updates on any updates still missing from devel release that are present in stable updates
Regression Testing
pre-alpha 6
- run regression tests when any major changes are noticed
between alpha 6 and beta
- run regression tests on at least kernel and glibc security protections on multiple architecture/kernel combinations (i386 w/o PAE, i386 w/ PAE, amd64).
post-beta
- run full set of existing regression tests and get them either updated or real bugs fixed
run test-rng.py --all --report from qa-regression-testing (takes many days, so may want to spread across multiple machines) and put the results in qa-regression-testing/results/test-rng.py/<release number>. This is likely a good use of EC2 (but keep in mind as of 2009/04/27 it costs ~ $100).
run qa-regression-testing/install/get_file_info.sh and see if any problems
post-rc1
run install/get_file_info.sh and record results in qa-regression-testing/install/get_file_info_results (see qa-regression-testing/install/README for details). This also needs to be done on the final images
EOL Checklist
Infrastructure (EOL)
- from ubuntu-cve-tracker's README section "End of Life":
mark any active CVEs for that release with an EOL comment: ./scripts/sync-from-eol.py -WUu -r $RELEASE
- add release to 'eol_releases' in scripts/cve_lib.py
- run a CVE retirement cycle
remove release from boilerplates: sed -i "/^<release>_\(.*\): /d" ./active/00boilerplate*
- update ubuntu-cve-tools/scripts/packages-mirror to lose old release
update architectures to include "EOL" footnote in SecurityTeam/FAQ
regenerate Security/Features from $UCT/scripts/dump-features --editmoin
update people:~ubuntu-security/.ubuntu-security-tools.conf settings for:
- "release_list" loses EOL release name
Individuals (EOL)
update ~/.ubuntu-security-tools.conf settings for:
- "release_list" loses EOL release name
- update debmirror/apt-cacher lists to drop old release
- delete VMs and schroots from old release
Release Checklist
Infrastructure (release)
update scripts/cve_lib.py:
add the new release in releases
devel_release is emptied
Add release entry and timestamp to release_stamps. (The time stamp can be generated based of the date stamp of the release file rounded up to the next hour; e.g. echo "(($(date -r /PATH/TO/UBUNTU/ARCHIVE/dists/RELEASE/Release.gpg +%s) / 3600 ) + 1) * 3600" | /usr/bin/bc
- move all active CVEs and boilerplates from "devel" to release state:
./scripts/release-cycle-released $RELEASE
- update usn-tool for publication
update templates/html-drupal.html (add to release_list div, add a new stanza in the 'for each' part of that div, and add a show_binaries entry). This is no longer used by the security team, but might be in landscape (TODO: check).
update templates/email-maria.txt (add a new stanza to the 'affected releases' section, add a show_packages entry, and add a show_release_urls entry). This is no longer used by the security team, but might be in landscape (TODO: check).
update templates/email-new-format.txt (add a new stanza to the 'affected releases' section, add a show_packages entry, add a show_package_description entry, add a show_source_link entry)
pull these changes down on people (this happens automatically, but it will need to happen before a USN publication):
$ cd /home/ubuntu-security/bzr-pulls/usn-tool/ $ sudo -u ubuntu-security bzr pull
update architectures in SecurityTeam/FAQ
update security-tools/build-tools/security-fake-sync for new stable release (ubuntu_version() and next_release())
update people:~ubuntu-security/.ubuntu-security-tools.conf settings for:
release_devel is emptied
Individuals (release)
update ~/.ubuntu-security-tools.conf settings for:
release_devel is emptied
add security-RELEASE and security-proposed-RELEASE sections to ~/.dput.cf
- pull infrastructure changes (from above):
- usn-tool
- ubuntu-cve-tracker
- security-tools
Devel Opens
Infrastructure (devel)
fill in releases and devel_release in ubuntu-cve-tools/scripts/cve_lib.py
add release to non-ports and ports section of ubuntu-cve-tools/scripts/packages-mirror
update security-tools/build-tools/security-fake-sync for new release (next_release())
update graphing scripts on people in ~ubuntu-security/graphing
supported.data.template:
copy last line of supported.data to populate the commented out release, and uncomment it
- add the new release column
- add the new devel line, commented out
supported-src.data.template:
copy last line of supported-src.data to populate the commented out release, and uncomment it
- add the new release column
- add the new devel line, commented out
update.sh REL updated, INDEX incremented by 1 (to match column in the .template files)
regenerate Security/Features/Historical from $UCT/scripts/dump-features --historical
Individuals (devel)
- update debmirror/apt-cacher lists to include new release
update ~/.ubuntu-security-tools.conf settings for:
release_list gains new release name
release_devel gains new release name
- build new VMs and schroots for new release
SecurityTeam/ReleaseCycle (last edited 2024-01-29 10:29:06 by ebarretto)