||<>|| 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 (see 'Show all out-of-sync CVEs for the devel release' from $UCT/README for assistance) * add the following to the announcements section of the ubuntu-security weekly meeting: "Ubuntu is scheduled to release in a few weeks. If you are interested, it would be great if people helped make sure that the [[https://launchpad.net/ubuntu-cve-tracker|Ubuntu CVE Tracker]] is up to date for the devel release (particularly for universe/multiverse packages." == Regression Testing == === pre-Alpha 3 === * run regression tests when any major changes are noticed === Alpha 3 === * run kernel hardening regression tests on multiple architecture/kernel combinations (i386 w/o PAE, i386 w/ PAE, amd64) (test-kernel*.py) * run gcc hardening regression tests on amd64 and i386 (test-gcc-security.py) * run glibc hardening regression tests on amd64 and i386 (test-glibc-security.py) * run other user-space hardening tests (eg PIE) on amd64 and i386 (test-built-binaries.py) === Beta 2 === * run kernel hardening regression tests on multiple architecture/kernel combinations (i386 w/o PAE, i386 w/ PAE, amd64) (test-kernel*.py) * run gcc hardening regression tests on amd64 and i386 (test-gcc-security.py) * run glibc hardening regression tests on amd64 and i386 (test-glibc-security.py) * run other user-space hardening tests (eg PIE) on amd64 and i386 (test-built-binaries.py) * run remaining regression tests from qa-regression-testing, updating the tests or reporting bugs against the package * 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/. 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 review for problems * verify guest session is confined === 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 * Review [[https://wiki.ubuntu.com/Kernel/Dev/ABIPackages|supported kernels]] with the kernel team == LTS Release goes to ESM status checklist == === 1 Month before transition === Before the release, verify that the mirroring from the esm-infra-security ppa and https://esm.ubuntu.com/infra/ for the release; if not file an RT to get mirroring set up. All steps here should be complete a month in advance of the date the release goes into ESM status, so customers can ensure their setup is correct. === Infrastructure (ESM) === You will need to configure the ESM release before proceeding: * meta_lists/subprojects.json: * Update the file with a new ``esm-infra/{RELEASE}`` entry. * Change the parent entry for ``esm-apps/{RELEASE}`` to ``esm-infra/{RELEASE}``. * Confirm the release metadata in ubuntu.com/security to indicate the release is now in ESM status: * In `$UCT/scripts/post-release-to-web-cve-tracker.py`, edit the `support_tag` field for the release to contain `ESM` * Double check other information for the release is correct in the table. * Run `$UCT/scripts/post-release-to-web-cve-tracker.py --action validate $RELEASE` to confirm the status is correct. <> In case of any discrepancies, update the `$UCT/scripts/post-release-to-web-cve-tracker.py` script information as published on the website. * Update Emacs and Vim syntax files * Add `esm-infra/{RELEASE}` entry into "cve-mode-all-releases" and "cve-mode-releases" entries present in `$UCT/scripts/cve-mode.el` file. * Update `$UCT/scripts/cve.vim` file with: * Remove `{RELEASE}` from `supported_releases` list * Add `esm-infra/{RELEASE}` to `products` list * Add `{RELEASE}` to the `eol_releases` list * Update your local package-mirror by running `$UCT/scripts/packages-mirror -V` * Add overlay tracking to all active CVEs. Packages supported in the ESM will receive a copy of the package in the base release's CVE state:{{{ $ ./scripts/release-cycle-new-overlay.py -ur esm-infra/${RELEASE} }}} * --(Add esm-infra/${RELEASE}_$PKG to the boilerplates ($UCT/boilerplates/*). [FIXME: add script name])-- * --(Manually update all the boilerplate files according to the ESM support status)-- '''Update in boilerplate folder will be handled by the `release-cycle-new-overlay.py` and `sync-from-eol.py` scripts, no need to manually update it''' * The package state should be "needs-triage" or "needed" for packages that are supported as part of the ESM release * Now in `meta_lists/subprojects.json`, update `ubuntu/{RELEASE}` entry `"eol": True`. * 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` * run a CVE retirement cycle:{{{ $ ./scripts/cve_need_retire -u }}} * update architectures to include "EOL" footnote in [[https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures|SecurityTeam/FAQ]] * regenerate [[Security/Features]] from `$UCT/scripts/dump-features > /tmp/output.txt` and copy-paste the output into the wiki page. * review and optionally closed bug tasks for EOL releases with `$UCT/scripts/report-bugs-for-eol -r $RELEASE` * update $QRT/README.testing to remove EOL release * update `people.canonical.com:~ubuntu-security/.ubuntu-security-tools.conf` settings for (used by `kernel-abi-check`): * "release_list" replace $RELEASE with esm-infra/$RELEASE === Individuals (ESM) === * update `~/.ubuntu-security-tools.conf` settings for: * "release_list" add $RELEASE with esm-infra/$RELEASE * update debmirror/apt-cacher lists to drop old release * delete VMs and schroots from old release * [FIXME - needs a review] create schroot and VM for esm release, please check [[https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Setting_up_a_chroot_for_Extended_Security_Maintenance|here]] and [[https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment#Setting_up_an_ESM_VM|here]] * add to sources.list `deb` and `deb-src` for ESM ppa * Then run `apt-get update` * [FIXME still needed?] adjust daily build systems * remove release from build list for daily ppas (e.g. [[https://code.launchpad.net/~apparmor-dev/+recipe/apparmor-daily/ |apparmor-daily recipe]], [[https://code.launchpad.net/~ecryptfs/+recipe/ecryptfs-utils-daily |ecryptfs-utils-daily recipe]]) and jenkins builds * remove packages built for the old release from daily ppas (e.g. [[https://code.launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-daily-trunk/+packages | apparmor-daily-trunk ppa]], [[https://code.launchpad.net/~ecryptfs/+archive/ubuntu/ecryptfs-utils-daily/+packages |ecryptfs-utils-daily ppa]], [[https://code.launchpad.net/~jdstrand/+recipe/ufw-daily|ufw-daily]]) and jenkins builds == ESM release goes Legacy Checklist == === Infrastructure (ESM to Legacy) === * In $UCT: * copy esm-infra--supported.txt to esm-infra-legacy--supported.txt * copy esm-apps--supported.txt to esm-apps-legacy--supported.txt * In meta_lists/subprojects.json add an entry for esm-infra-legacy/ and esm-apps-legacy/ * Update $UCT/scripts/cve.vim file with: Add esm-infra-legacy/ and esm-apps-legacy/ to products list * $ ./scripts/release-cycle-new-overlay.py -ur esm-infra-legacy/ * $ ./scripts/release-cycle-new-overlay.py -ur esm-apps-legacy/ * In meta_lists/subprojects.json, update subprojects for esm-infra/ entry `"eol": True` * In meta_lists/subprojects.json, update subprojects for esm-apps/ entry `"eol": True` * mark any active CVEs for that esm-infra release with an EOL comment: `./scripts/sync-from-eol.py -WUu -r esm-infra/` * mark any active CVEs for that esm-apps release with an EOL comment: `./scripts/sync-from-eol.py -WUu -r esm-apps/` * run a CVE retirement cycle:{{{ $ ./scripts/cve_need_retire -u }}} * For RELEASE in esm-apps/ and esm-infra/ do the following: * Add overlay tracking to all active CVEs. Packages supported in the ESM will receive a copy of the package in the base release's CVE state: === Individuals (ESM to Legacy) === * update `~/.ubuntu-security-tools.conf` settings for: * "release_list" include new `esm-infra-legacy/` and `esm-apps-legacy/` * pull UCT changes * adjust sources.list to include `deb-src` for new legacy ESM release entries * Then run `apt-get update` == Legacy release goes EOL Checklist == === Infrastructure (Legacy EOL) === * In meta_lists/subprojects.json, update ${RELEASE} entry `"eol": True` * mark any active CVEs for that release with an EOL comment: `./scripts/sync-from-eol.py -WUu -r $RELEASE` * run a CVE retirement cycle:{{{ $ ./scripts/cve_need_retire -u }}} * remove release from boilerplates: `sed -i --follow-symlinks -e '/^_\(.*\): /d' -e '/^#_PKG:/d' ./boilerplates/*` * remove any backport kernels for this release from boilerplates/linux * from meta_lists/kernel_flavor_srcpkg_mapping.json, remove: * any backport kernels for this release from 'kernel_srcs' * from scripts/cve_lib.py, remove: * the meta kernel and any meta backport kernels from the meta_kernels table * update ubuntu-cve-tracker/scripts/packages-mirror to lose old release * update architectures table to remove release in [[https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures|SecurityTeam/FAQ]] * regenerate [[Security/Features]] from `$UCT/scripts/dump-features --editmoin` * review and optionally closed bug tasks for EOL releases with `$UCT/scripts/report-bugs-for-eol -r $RELEASE` * update $QRT/README.testing to remove EOL release * update `people:~ubuntu-security/.ubuntu-security-tools.conf` settings for (used by `kernel-abi-check`): * "release_list" loses EOL release name === Individuals (ESM 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 ESM release * adjust sources.list to remove `deb` and `deb-src` for old ESM release entries * Then run `apt-get update` == EOL Checklist == === Infrastructure (EOL) === * If this is an LTS release that will live on as an ESM release, you need to configure the ESM release before proceeding: * Add ESM release to all_releases and release_names sections of cve_lib.py * Add overlay tracking to all active CVEs. Packages supported in the ESM will receive a copy of the package in the base release's CVE state:{{{ $ ./scripts/release-cycle-new-overlay.py -ur ${RELEASE}/esm }}} * Replace the boilerplate states for the base release with the new overlay release. This is an example command for Precise: {{{ $ sed -i -e 's/^precise_\(.*\): \(.*\)$/precise\/esm_\1: \2/g' \ -e 's/^#precise_PKG:/#precise\/esm_PKG:/g' \ boilerplates/* }}} * Manually update all the boilerplate files according to the ESM support status * The package state should be "DNE" for packages that are not supported as part of the ESM release * The package state should be "needs-triage" or "needed" for packages that are supported as part of the ESM release * update usn.py in the usn-tool tree for proper USN publication * update the corresponding value of the '''get_codename_to_version_dict()''' function by adding a conditional re-assignment towards the bottom of the function * see the inline comments about how to select the right date to compare against * pull these changes down on people (this happens automatically, but it will need to happen before a USN publication): {{{ $ cd /home/ubuntu-security/git-pulls/usn-tool/ $ sudo -H -u ubuntu-security git pull --ff-only }}} * 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` * within meta_lists/subprojects.json, update the appropriate release entry in the subprojects JSON. Each release dictionary contains an `eol` bool, set this to `True` for the release being EOL'd. * run a CVE retirement cycle:{{{ $ ./scripts/cve_need_retire -u }}} * remove release from boilerplates: `sed -i --follow-symlinks -e '/^_\(.*\): /d' -e '/^#_PKG:/d' ./boilerplates/*` * remove any backport kernels for this release from boilerplates/linux * from meta_lists/kernel_flavor_srcpkg_mapping.json, remove: * any backport kernels for this release from 'kernel_srcs' * from cve_lib.py, remove: * the meta kernel and any meta backport kernels from the meta_kernels table * update ubuntu-cve-tracker/scripts/packages-mirror to lose old release * update architectures to include "EOL" footnote in [[https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures|SecurityTeam/FAQ]] * regenerate [[Security/Features]] from `$UCT/scripts/dump-features --editmoin` * review and optionally closed bug tasks for EOL releases with $UCT/scripts/report-bugs-for-eol -r $RELEASE * update $QRT/README.testing to remove EOL release * update `people:~ubuntu-security/.ubuntu-security-tools.conf` settings for (used by `kernel-abi-check`): * "release_list" loses EOL release name * update `$UST/build-tools/security-fake-sync` to ensure LTS releases point to the right place (`next_release()`) * remove release from either [[https://git.launchpad.net/review-tools/tree/reviewtools/usn.py#n22|tracked_releases]] (if this is an LTS release) or [[https://git.launchpad.net/review-tools/tree/reviewtools/usn.py#n25|non_lts_tracked_releases]] (if this is an interim release) of review-tools so it is not considered by the USNs notification service anymore. === Individuals (EOL) === * update `~/.ubuntu-security-tools.conf` settings for: * "release_list" loses EOL release name * if this is an LTS release that will live on as an ESM release, then you might want to add RELEASE/esm (where RELEASE is the release name) to release_list. * '''No longer required with uvt''': update `~/.uqt-vm-tools.conf` settings for: * "vm_release_list" loses EOL release name * update debmirror/apt-cacher lists to drop old release * delete VMs and schroots from old release * if this is an LTS release that will live on as an ESM release, then you will probably want to create schroot and VM for it, please check [[https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Setting_up_a_chroot_for_Extended_Security_Maintenance|here]] and [[https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment#Setting_up_an_ESM_VM|here]] * delete old release umt autopkgtest images from `~/images/` * adjust sources.list to remove `deb` and `deb-src` for old release * if this is an LTS release that will live on as an ESM release, then add ESM ppa to sources.list * Then run `apt-get update` * adjust daily build systems * remove release from build list for daily ppas (e.g. [[https://code.launchpad.net/~apparmor-dev/+recipe/apparmor-daily/ |apparmor-daily recipe]], [[https://code.launchpad.net/~ecryptfs/+recipe/ecryptfs-utils-daily |ecryptfs-utils-daily recipe]]) and jenkins builds * remove packages built for the old release from daily ppas (e.g. [[https://code.launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-daily-trunk/+packages | apparmor-daily-trunk ppa]], [[https://code.launchpad.net/~ecryptfs/+archive/ubuntu/ecryptfs-utils-daily/+packages |ecryptfs-utils-daily ppa]], [[https://code.launchpad.net/~jdstrand/+recipe/ufw-daily|ufw-daily]]) and jenkins builds == New LTS Release Checklist == Follow the steps from a new Standard Support release, as well as the additonal steps listed here === Three Months before release === * Prepare a no-change rebuild of the [[ https://launchpad.net/ubuntu/+source/hello | hello ]] package from the LTS release under developement in the esm-infra-security-staging ppa * `umt changelog --esm --build` should help to create the proper version and changelog message, e.g: {{{ hello (2.10-3build1~esm1) noble-security; urgency=medium * No-change re-build to populate ESM archives in prep for upcoming release. }}} * Publish (binary copy) this package to all of the ESM ppas: {{{ ./unembargo --esm-infra -r $RELEASE $SRCPKG ./unembargo --ppa=ubuntu-esm/esm-infra-security-staging --destination=ubuntu-esm/esm-apps-security -- pocket=Release -r $RELEASE $SRCPKG ./unembargo --ppa=ubuntu-esm/esm-infra-security-staging --destination=ubuntu-esm/esm-infra-updates -- pocket=Release -r $RELEASE $SRCPKG ./unembargo --ppa=ubuntu-esm/esm-infra-security-staging --destination=ubuntu-esm/esm-apps-updates --pocket=Release -r $RELEASE $SRCPKG }}} == New Standard Support Release Checklist == === Infrastructure (release) === * update `$UCT/meta_lists/subprojects.json`: * edit the new release entry in the JSON data: * should be of the form '''ubuntu/codename''' (where codename is something like jammy or kinetic) * '''devel''' status for the just released version should be changed from '''True''' to '''False''' * Add a '''stamp''' field with a timestamp for when the release was released. Generate the timestamp based on the date stmp of the release file rounded up to the next hour via {{{echo "(($(date -r /PATH/TO/UBUNTU/ARCHIVE/dists/RELEASE/Release.gpg +%s) / 3600 ) + 1) * 3600" | /usr/bin/bc}}} * if this is an LTS release, also add a new release entry of the form '''esm-apps/codename''' (where codename is something like jammy or kinetic). * it should have the following structure {{{ "esm-apps/": { "eol": False, "oval": True, "components": ["universe", "multiverse"], "packages": ["esm-apps--supported.txt"], "name": "Ubuntu YY.MM LTS", #same as 'ubuntu/codename' "codename": "...", # same as 'ubuntu/' "ppas": [ {"ppa": "ubuntu-esm/esm-apps-security", "pocket": "security"}, {"ppa": "ubuntu-esm/esm-apps-updates", "pocket": "updates"} ], "parent": "ubuntu/", "description": "Available with Ubuntu Pro: https://ubuntu.com/pro", "stamp": ..., # same as 'ubuntu/' }, }}} * update '''release_expectations''' for the new release * update `$UCT/scripts/kernel_lib.py`: * add release's kernels under '''!MetaKernelTable''' (based on [[https://kernel.ubuntu.com/gitea/kernel/kernel-versions/src/branch/main/info/kernel-series.yaml|the kernel team's meta info file]]) for both this release and any LTS kernels * Update the release metadata in ubuntu.com/security to indicate the release is no longer in a development status * In the `releases` table in `$UCT/scripts/post-release-to-web-cve-tracker.py`, edit the `development` field for the release from `True` to `False` * Double check other information for the release is correct in the table. * Run `$UCT/scripts/post-release-to-web-cve-tracker.py --action update $RELEASE` <> * move all active CVEs and boilerplates from "devel" to release state: * `cd $UCT ; ./scripts/release-cycle-released $RELEASE` * Note that this also touchs the emabargoed tree, so will need to commit and push there * If release is LTS, also create the esm-apps--supported.txt and add it to the CVE files * `cd $UCT ; ./scripts/generate-supported-list.py -r -p esm-apps ; ./scripts/release-cycle-new-overlay.py -ur esm-apps/codename` * Update 'releases' in `$UCT/scripts/report-todo-recommend` to contain the most recent LTS and most recent non-LTS in check for `if not opt.all_releases:` * Update `$UCT/scripts/cve.vim` and `$UCT/scripts/cve-mode.el` to include the new release. * If LTS, also add an entry for the 'esm-apps/codename' * update usn.py in the usn-tool tree for proper USN publication * add a new element at the front of the '''codename_to_version''' dictionary in the '''get_codename_to_version_dict()''' function * pull these changes down on people (this does '''NOT''' happen automatically, it will need to happen before a USN publication): {{{ $ cd /home/ubuntu-security/git-pulls/usn-tool/ $ sudo -H -u ubuntu-security git pull --ff-only }}} * update architectures in [[https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures|SecurityTeam/FAQ]] * update `$UST/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 * On people, run: {{{ $ sudo -H -u ubuntu-security /home/ubuntu-security/bin/scripts-diff.sh # review the changes, if good: $ sudo -H -u ubuntu-security /home/ubuntu-security/bin/scripts-diff.sh --update }}} * Update AppArmor * Update UncomplicatedFirewall * Verify versions for !AppArmor in $UCT/scripts/dump-features and regenerate Security/Features from $UCT/scripts/dump-features --editmoin * Update list of syscalls for the supported kernel for the new release: * grabbing `linux-libc-dev` for all architectures from the `linux` package for new release and putting them in a folder (eg, '4.9') * generate the syscall list (eg, 4.9.syscalls) by following http://people.canonical.com/~ubuntu-security/syscalls/README and placing the results in that directory * update [[SecurityTeam/KnowledgeBase/AppArmorProfiles]] * eg, https://codesearch.debian.net/search?q=apparmor.d&literal=1 and look for new stuff in Ubuntu or... * if have local mirror, use 'for-archive' from UST with the following: {{{ export GREP="egrep"; do for comp in main universe multiverse; do $HOME/bin/for-archive-tools/for-archive $archive_mirror/dists/$RELEASE/$comp/binary-amd64/Packages.gz $archive_mirror $HOME/bin/for-archive-tools/unpack-list 'apparmor.d'; done | tee ~/apparmor.d-$RELEASE.log }}} * Send notifications to: * the security-private-announcements mattermost channel * the security crew list === Individuals (release) === * update `~/.ubuntu-security-tools.conf` settings for: * '''release_devel''' is emptied * If new release is LTS, don't forget to add esm-apps/codename to your release_list. * add `security-RELEASE` and `security-proposed-RELEASE` sections to `~/.dput.cf` (not normally needed if using [[https://wiki.ubuntu.com/SecurityTeam/UpdatePublication#Local_Configuration|recommended dput setup]]) * pull infrastructure changes (from above): * usn-tool * ubuntu-cve-tracker * ubuntu-security-tools * ubuntu-qa-tools * VIM users should copy the new `$UCT/scripts/cve.vim` to `~/.vim/syntax/` * [optional] download final ISO images * [optional] build new clean chroots * [optional] build new clean VMs == Devel Opens == === Infrastructure (devel) === * fill in '''all_releases''', '''flavor_releases''', '''devel_release''', '''release_names''' and '''release_expectations''' in `${UCT}/scripts/cve_lib.py` * add symlinks for the release and its updates and security pockets to `${UCT}/test/test-source-map-data/dists/` * Add the devel release to ubuntu.com/security * Add a new entry to the `releases` table in `$UCT/scripts/post-release-to-web-cve-tracker.py` * Ensure the `development` field is set to `True` * Run `$UCT/scripts/post-release-to-web-cve-tracker.py --action add $RELEASE` <> * Move all active CVEs and boilerplates from latest release to devel state: * `./scripts/release-cycle-devel-opens $LATEST_STABLE_RELEASE` * add release to non-ports and ports section, as well as the compressed_ext() function, of `${UCT}/scripts/packages-mirror` * It is helpful to run packages-mirror in the background now as the results are used in several future steps * `$UCT/scripts/packages-mirror -p -r ; $UCT/scripts/packages-mirror -r ` * update `$UST/build-tools/security-fake-sync` for new release (`next_release()`) * update graphing scripts on `people` in `~ubuntu-security/graphing` (see `~ubuntu-security/graphing/README` for details) * `supported.data.template` has the binary package counts. To update: * determine the binary package counts ($packages_mirror is set in `~/.ubuntu-cve-tracker.conf`): {{{ $ cd $packages_mirror ; zcat ./dists/$LATEST_STABLE_RELEASE/main/binary-*/Packages.gz ./dists/$LATEST_STABLE_RELEASE/restricted/binary-*/Packages.gz | grep '^Package:' | sort -u | wc -l }}} * in the .template file, take the last line of the file and duplicate it at the end of the file * in the .template file, uncomment the second to last line (formerly the last line) and add the package counts for the latest stable release * in the .template file, update the last line's commented out release name to be the new devel release and adjust counts for EOL releases * in the .template file, add the new devel release column header name * in the .template file, add a 0 column to all lines (except the last uncommented line), making sure everything is sensible for package counts * `supported-src.data.template`: * determine the source package counts: {{{ $ cd $packages_mirror ; zcat ./dists/$LATEST_STABLE_RELEASE/main/source/Sources.gz ./dists/$LATEST_STABLE_RELEASE/restricted/source/Sources.gz | grep '^Package:' | sort -u | wc -l }}} * in the .template file, take the last line of the file and duplicate it at the end of the file * in the .template file, uncomment the second to last line (formerly the last line) and add the package counts for the latest stable release * in the .template file, update the last line's commented out release name to be the new devel release and adjust counts for EOL releases * in the .template file, add the new devel release column header name * in the .template file, add a 0 column to all lines (except the last uncommented line), making sure everything is sensible for package counts * `update.sh`: * '''REL''' updated to dev release name * '''RELTAG''' gets the version of the newly opened dev release (e.g. 18.10) * '''INDEX''' incremented by 1 (to match column in the .template files excluding the newly added devel release, since we don't know its package counts yet)) * add to .bzrignore:{{{ $NEW_RELEASE-src.data $NEW_RELEASE.data }}} * commit the changes with `bzr ci -m 'LATEST_STABLE_RELEASE released, NEW_RELEASE opens'` replacing with appropriate release names * update `people:~ubuntu-security/.ubuntu-security-tools.conf` settings for: * '''release_list''' gains new release name (and any overlay releases, eg 'vivid/stable-phone-overlay', 'xenial/stable-phone-overlay', etc) * '''release_devel''' gains new release name (without overlay releases) * regenerate [[Security/Features]] from `$UCT/scripts/dump-features` * regenerate [[Security/Features/Historical]] from `$UCT/scripts/dump-features --historical` * create new release in apparmor-profiles and copy profiles over from previous release * Make sure lp:ubuntu-qa-tools/responses/update-bug includes the new release * update $QRT/README.testing for new development release * use `cd $UCT && ./scripts/sync-from-versions.py -s not-affected`. If satisfied with the result, use `cd $UCT && ./scripts/sync-from-versions.py -s not-affected -u` * use `cd $UCT && ./scripts/sync-from-versions.py -r $RELEASE -s not-affected`. If satisfied with the result, use `cd $UCT && ./scripts/sync-from-versions.py -r $RELEASE -s not-affected -u` * until snapcraft adds the Ubuntu release codename: * update OS_RELEASE_MAP in common.py of the [[https://git.launchpad.net/review-tools/tree/reviewtools/common.py#n83|review-tools]]. * include the new release name in either [[https://git.launchpad.net/review-tools/tree/reviewtools/usn.py#n22|tracked_releases]] (if this is an LTS release) or [[https://git.launchpad.net/review-tools/tree/reviewtools/usn.py#n25|non_lts_tracked_releases]] (if this is an interim release) of review-tools so it is considered by the USNs notification service. * Before committing, perform '`make check`' * after pushed to master, trigger [[https://code.launchpad.net/~myapps-reviewers/+snap/review-tools|snap builds in LP]] * smoke test the snap with: {{{ $ sudo snap install review-tools --edge # s/install/refresh/ if already installed $ cd /path/to/git/checkout $ make functest-system }}} * once tested, release to the beta channel with: '`for i in $REVISIONS ; do snapcraft release review-tools $i beta ; done`' (can obtain the revisions with '`snapcraft list-revisions review-tools | head`' === Individuals (devel) === * pull infrastructure changes (from above): * ubuntu-cve-tracker * ubuntu-security-tools * ubuntu-qa-tools * qa-regression-testing * 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 (remembering to update 'vm_release_list' in '~/.uqt-vm-tools.conf' (not needed if using uvt)) * debootstrap is likely to not yet know about the new dev release and will cause mk-sbuild to fail. Create a symlink in `/usr/share/debootstrap/scripts/` that points to the same file as the latest stable release's symlink. * install images for the dev release are not likely to exist towards the start of the development cycle. Try using `uvt clone` to create a new VM based on the latest stable release. After cloning the VM, start the new vm, log in and follow these steps: 1. Generate new SSH host keys: {{{ $ sudo rm /etc/ssh/ssh_host_*key* $ sudo ssh-keygen -A}}} 1. Update `/etc/apt/sources.list` and `/etc/apt/sources.list.d/*` to replace the latest stable release name with the new dev release name and then update: {{{ $ sudo apt update $ sudo apt dist-upgrade}}} 1. Shut the VM down and use `uvt snapshot` in your host environment to preserve your changes * update your packages mirror with `$UCT/scripts/packages-mirror -r $NEW_RELEASE` * update your partner packages mirror with `$UCT/scripts/packages-mirror -p` * update your sources.list to have the appropriate deb-src lines for the new release (eg use `$UST/build-tools/build-sources-list` output in `/etc/apt/sources.list.d/ubuntu-security.list`; you can use `$UST/build-tools/build-sources-list.install` to install; note that if ESM PPAs are included you may need to import PPA keys.) * Then run `apt-get update` * [optional] subscribe to $NEW_RELEASE-changes at https://lists.ubuntu.com/mailman/listinfo/$NEW_RELEASE-changes === QA (devel) === For projects where the security team is the upstream maintainer (eg, !AppArmor, ufw, ecryptfs): * Update the daily build PPA to build for the development release * As needed, update the daily build PPA packaging (eg, merge in any changes since the last release) == Debian Release/EOL Checklist == === Infrastructure (Release/EOL) === * Update [[https://launchpad.net/ubuntu-security-tools|lp:ubuntu-security-tools]] for: * README needs the proper release_extras list * build-tools/build-sources-list has a hard-coded "supported releases" list * Update [[SecurityTeam/BuildEnvironment]] to mk-sbuild the current releases and document the proper release_extras list * Update d2u.py in [[https://git.launchpad.net/debian2ubuntu/ | lp:debian2ubuntu]] with new debian release. Will need to pull the git tree on people.c.c as well. * '''IMPORTANT:''' only update the list for new Debian releases since d2u may show pending merges against EOL Debian releases === Individuals (Release/EOL) === * pull infrastructure changes (from above): * ubuntu-security-tools * update `~/.ubuntu-security-tools.conf` settings for: * "release_extras" list gains/drops the release name * [optional] create/delete VMs and schroots from the release * update your sources.list to add/remove the deb-src lines for the release (eg use `$UST/build-tools/build-sources-list` output in `/etc/apt/sources.list.d/ubuntu-security.list`) * Then run `apt-get update` ---- CategorySecurityTeam