Security1 publisher2 min readPublished Updated
Canonical puts Ubuntu's one-week kernel fix in the -proposed pocket, ahead of certification testing
Canonical is merging two update cycles so that an Ubuntu kernel ships every week. Getting a CVE fix faster than that means running release candidates its certification testing has not yet cleared.
The Watch · Security desk
What happened
- Canonical is folding its four-week cycle for stable release updates and its two-week security cycle into one two-week cycle, staggered so each starts a week after the last and a kernel ships every week.
- Admins who need a kernel CVE fix inside a week now have a sanctioned route: pull release candidates from the -proposed pocket before Canonical has run certification testing on them.
- Canonical ties the change to CVE volume, citing AI-automated bug hunting and the upstream kernel community, now its own CVE Numbering Authority, assigning identifiers to thousands of bugs.
- Where a safe workaround exists, Canonical aims to publish it within 24 to 48 hours of public disclosure, and to point users to general hardening steps where none does.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- decision Fleet owners now sort machines into two groups: those that wait two weeks for a certified kernel, and those that take an uncertified one seven days earlier.
- cost Skipping the certification week moves integration and regression testing onto the adopting team, which needs an acceptance suite and hardware to run it on.
- exposure Because the dropped stage is certification on Ubuntu Certified hardware, the fast lane bites hardest on boxes with vendor drivers and firmware quirks rather than on generic virtual machines.
- constraint At roughly 52 kernels a year, a monthly patch window accumulates about four releases at a time, so teams that batch updates fall further behind between windows.
The week that gets skipped is the certification week. Fixes accumulate until a cutoff date, the kernel tree is snapshotted, and Canonical spends the first week building kernels and smoke testing that they boot and run [3]. Those builds land in -proposed, the part of the Ubuntu archive that holds release candidates [4]. The second week goes to certification, integration and regression testing on hardware in the Ubuntu Certified program, and the kernels are released at the end of it [5]. Pulling from -proposed buys about seven days [1].
"Expedited releases aren't possible while thoroughly testing every release candidate," Canonical wrote [7]. The company says it is keeping full testing on every release [8]. Teams that cannot wait are pointed at the -proposed builds, which update weekly, and at running their own acceptance tests on them [9].
Under the old split, security kernels arrived on a two-week cycle, about 26 a year. Weekly releases put that near 52 [2]. A fleet on a monthly change window now has roughly four kernels queued at each window instead of two [3].
The stage the fast lane drops is hardware certification, so the exposure concentrates on machines whose drivers and firmware are what that testing exercises [5]. Canonical's own pre-release check confirms the kernel boots and runs [3]. Help Net Security's assessment is that the fastest kernel Canonical offers is the one it has not finished testing, and that any regression it carries becomes the adopting team's problem [13].
Help Net Security's advice to fleet owners is to plan for weekly kernel releases and decide which machines, if any, can take uncertified builds [14]. The report does not give a date for the first weekly kernel [15].
What to watch
- Whether Canonical publishes a start date and says which LTS kernels and flavours the weekly cadence covers.
- Whether a regression from a -proposed kernel reaches production, and who reports it first.
- Whether the 24 to 48 hour workaround target holds for the first widely exploited kernel CVE after the switch.