Ubuntu 8.04 LTS Hardy Heron: Release Facts, Kernel 2.6.24, Security

Ubuntu 8.04 LTS "Hardy Heron" was released on 24 April 2008 with Linux kernel 2.6.24 and the GNOME 2.22 desktop, and its support ended on 12 May 2011 for the desktop and 9 May 2013 for the server. Canonical's current Expanded Security Maintenance and release cycle pages list no extended coverage for it, so every 8.04 system still running today has gone more than thirteen years without an official security update.

Hardy was Ubuntu's second long term support release, two years after 6.06 LTS "Dapper Drake." It was the first LTS to ship AppArmor with enforcing profiles, the first release of any kind to include ufw, the Uncomplicated Firewall, and the first LTS with a run of kernel and userspace memory protections that later releases built on. It also shipped the Debian OpenSSL random number generator flaw, CVE-2008-0166, which was fixed three weeks after release and is still the best lesson in why patching a package does not always fix the problem. Below are the release facts with a citation for each, what changed since 6.06 and the interim releases between them, and how to recognise an 8.04 system or image in an inventory. Where an official page does not state a fact, we say so.

Key takeaways

• Released 24 April 2008, codename Hardy Heron. The date comes from the archived Ubuntu wiki Releases page; the current release notes page on documentation.ubuntu.com does not state it.
• Kernel 2.6.24, specifically the 2.6.24-16.30 build based on upstream 2.6.24.3, according to Canonical's archived 8.04 technical overview.
• GNOME 2.22.1 desktop, with Xorg 7.3 and Firefox 3 Beta 5 as the default browser. Canonical chose a beta browser on purpose because of the long support window.
• Support: desktop support ended 12 May 2011 and server support ended 9 May 2013. No ESM, Legacy add-on or Ubuntu Pro coverage is listed for 8.04 on Canonical's current pages.
• AppArmor arrived in 7.10 and 8.04 was the first LTS with it. Four profiles shipped enforcing by default in 8.04: CUPS, OpenLDAP, MySQL and BIND.
• ufw debuted in 8.04 as a new host based firewall. Canonical's security pages describe it as installed but disabled until an administrator enables it.
• Memory protections landed: restricted /dev/mem and /dev/kmem, no mapping of the lowest 64K of memory, exec, VDSO and brk related ASLR, glibc pointer obfuscation and the GCC stack protector.
• Not yet there: Fortify Source, RELRO, archive wide PIE builds, SHA-512 password hashes and encrypted private directories all came later, mostly in 8.10.
• CVE-2008-0166, the Debian OpenSSL predictable random number flaw, affected 8.04 and was fixed in USN-612-1 on 13 May 2008. Keys generated before the fix stayed weak until replaced.

What are the Ubuntu 8.04 LTS release facts?

A note on sources. The 8.04 page on documentation.ubuntu.com is a list of known issues, covering Ubuntu 8.04 LTS and version 8.04 of Kubuntu and Xubuntu. It does not give the release date, kernel version or support length. The feature descriptions came from Canonical's technical overview page at www.ubuntu.com/getubuntu/releasenotes/804overview, which no longer resolves, and from the HardyHeron wiki pages, which return 404 since the wiki migration. We read those through the Internet Archive's Wayback Machine and cite the original URL with a note that it is an archived copy. The archived release notes page from May 2008 also carries a Firefox paragraph that the current documentation copy does not.

What happened when: the 8.04 timeline

The day the 8.04 ISO files were built shows on the archive itself: the 8.04 desktop images on old-releases.ubuntu.com carry timestamps of 23 April 2008, the alternate images 22 April and the server images 23 April. The 8.04.4 images are dated 21 January 2010, a week before the published point release date.

How long was Ubuntu 8.04 LTS supported?

Hardy followed the support model that Dapper introduced. The 6.06 release notes state that 6.06 LTS "will be supported with security updates for 5 years on the server and 3 years on the desktop." The 8.04 pages we fetched do not restate that rule for Hardy, but the end of life dates on the archived Releases page match it exactly: 12 May 2011 for the desktop, a little over three years after release, and 9 May 2013 for the server, a little over five.

The flavours did not share the server's five years. The archived Releases page lists only Ubuntu desktop and server rows, and the 8.04 pages we fetched do not state a separate support period for Kubuntu, Xubuntu, Edubuntu, Ubuntu Studio or Mythbuntu. Treat any flavour support claim for 8.04 as not stated in the official sources.

Why there is no ESM for 8.04

Canonical's ESM page today offers "up to 15 years" of security maintenance, and explains that LTS releases became popular because of a five year security maintenance commitment for the main repository. Neither that page nor the release cycle page, whose LTS rows start at 14.04, lists any extended maintenance for 8.04. The ESM product arrived later, and our Ubuntu Pro and ESM history post walks through which release got it first. For Hardy the practical answer is simple: after 9 May 2013 there was no official channel for new security fixes, paid or free.

What "end of life since 2013" means in practice

A Hardy server patched on its last day of support has missed every Ubuntu security notice published since. That gap covers well known classes of bugs in OpenSSL, the kernel, glibc, bash, sudo and OpenSSH that later releases fixed. None of the packages on that system will receive those fixes, and Hardy's package archive moved to old-releases.ubuntu.com, so even the original updates are no longer on the main mirrors. Our explainer on end of life software: upgrade, extend, isolate or retire covers the options when you find one.

What kernel does Ubuntu 8.04 LTS use?

The archived technical overview says: "This release includes the 2.6.24-16.30 kernel based on 2.6.24.3." It names two upstream features as the highlights: dynamic ticks on amd64, which brought the power savings 32-bit systems already had to 64-bit laptops and desktops, and the Completely Fair Scheduler introduced in Linux 2.6.23.

There was no hardware enablement kernel series for 8.04 in the form later LTS releases use. The kernel lifecycle page starts its HWE tables much later, and the 8.04 pages we fetched do not describe newer kernels shipping in the 8.04.x point releases. Whether any 8.04.x point release changed the default kernel version is not stated in the official sources we fetched.

The kernel also changed the virtualization story. The overview says KVM became "a fully maintained option for virtualization," with libvirt and virt-manager integrated, and the kernel included virtio for guest I/O. iSCSI initiator support was fully integrated in the kernel and exposed in the server installer through an iscsi=true boot option.

For comparison, the 6.06 release notes list Linux 2.6.15.6, and the 8.10 release notes refer to Linux 2.6.27 throughout, so Hardy sat almost exactly halfway between them.

What desktop does Ubuntu 8.04 LTS ship?

GNOME 2.22.1. The overview credits it with a new Nautilus file manager on the GVFS backend, a clock applet that shows time and weather for several locations, the Seahorse keyring manager and Google Calendar support in Evolution. The Hardy Beta wiki page adds that GVFS made it possible to restore files from the trash, pause and undo file operations, and would let Nautilus raise privileges through PolicyKit for some operations.

Other default applications changed too, per the overview:

• Firefox 3 Beta 5 replaced Firefox 2 as the default browser.
• Brasero became the default CD and DVD burner, replacing Serpentine for audio CDs.
• Transmission replaced the GNOME BitTorrent downloader.
• Vinagre replaced xvnc4viewer as the VNC client and could find servers through Avahi.
• Totem gained a YouTube plugin, local search through Tracker and DVB support.
• PulseAudio came preinstalled as the sound server.
• Xorg 7.3 brought better autoconfiguration and a new Screen Resolution tool for second monitors.

Why ship a beta browser on an LTS?

The archived May 2008 release notes give Canonical's reason in plain terms. Ubuntu 8.04 included Firefox 3.0 Beta 5, which "was felt to be the best option despite its pre-release status, in light of the extended support lifetime of Ubuntu 8.04 and the importance and complexity of Firefox security updates." The same paragraph said release candidates and the final release might come as post-release updates. The logic is the one that still drives LTS browser decisions: shipping a browser branch that upstream would stop patching early leaves a long tail of unpatched desktops.

Flavours

The current release notes cover Ubuntu, Kubuntu and Xubuntu 8.04. The Hardy Beta announcement listed downloads for Ubuntu, the Edubuntu add-on, Kubuntu, Kubuntu with KDE 4, Ubuntu JeOS, Xubuntu, Ubuntu Studio and Mythbuntu. The 8.04 notes warn that dual screen support in Kubuntu 8.04 was more limited than in Ubuntu, because the Xinerama extension had largely been replaced by Xrandr and updated KDE 3 tools were not available. The 8.10 notes later refer to the "Kubuntu 8.04 KDE 4 Remix" when describing upgrade issues.

When did AppArmor arrive, and which profiles did 8.04 enforce?

AppArmor first shipped in Ubuntu 7.10. The archived Gutsy release notes say "Ubuntu 7.10 introduces an additional security layer called App Armor," and warn that its CUPS printing support was not yet complete. The workaround they gave was to switch the CUPS profile to complain mode with aa-complain cupsd, and back with aa-enforce cupsd.

Hardy was therefore the first LTS with AppArmor. The Ubuntu Security Features wiki, in its archived 2011 version, lists AppArmor 2.1 for 8.04 and nothing for 6.06. Its table of profiles shipped in enforcing mode by default shows four for 8.04:

The same page notes that example profiles lived in the apparmor-profiles package in universe, and that enforcing profiles "are being built up" release by release. So an 8.04 server running MySQL, BIND, OpenLDAP or CUPS had a mandatory access control profile around that daemon out of the box. Everything else ran unconfined.

The 8.04 overview also added SELinux as an option: "In addition to supporting AppArmor, Ubuntu 8.04 LTS now includes support for security enhanced Linux," available from universe through the selinux package. AppArmor stayed the default. Our comparison of SELinux or AppArmor for a server explains the difference between path based and label based confinement.

On a current Ubuntu system, the Ubuntu Server AppArmor guide shows how to see which profiles are loaded and in which mode:

sudo aa-status

The same guide documents aa-complain and aa-enforce for moving a profile between modes. Our post on AppArmor complain or enforce mode covers when each is appropriate.

When did ufw first ship, and was it enabled by default?

ufw first shipped in 8.04. The archived overview says: "The Ubuntu 8.04 LTS release includes ufw (Uncomplicated Firewall), a new host-based firewall application configurable from the command line which is designed to make administering a firewall easier for end users while not getting in the way of network administrators." The Hardy Beta page used almost the same words. The 2011 Security Features matrix shows "iptables" for 6.06 and "ufw" for 8.04 under configurable firewall.

The 8.04 pages do not say in so many words whether ufw was active after installation. The Security Features wiki describes ufw as "installed by default in Ubuntu (users must explicitly enable it)," and the current Ubuntu Server firewall guide says "ufw by default is initially disabled." Neither statement is specific to 8.04, so the precise answer is: ufw shipped in 8.04, Canonical's security documentation describes it as off until enabled, and the 8.04 release pages do not state its default state.

That design matched Ubuntu's long standing "no open ports" policy, which the Security Features matrix lists for both 6.06 and 8.04: a default install should not listen on the network, so a firewall is a second layer rather than the first. On a server where you install services, the firewall matters. The current guide shows the commands to check and turn it on:

sudo ufw status verbose
sudo ufw enable

Our ufw first steps post covers the rules most teams start with.

Which compiler hardening and memory protections were on by default?

This is where 8.04 moved the most, and also where it is easiest to over credit it. The archived overview lists three memory protection changes:

1. Additional access checks so that /dev/mem and /dev/kmem "can only be used to access device memory," to help defend against rootkits.
2. "The lower 64K of system memory is no longer addressable by default," to make kernel NULL pointer bugs harder to turn into vulnerabilities.
3. Programs compiled as Position Independent Executables "are now placed into memory in unpredictable locations."

The Security Features matrix adds detail. Here is what it lists for 8.04 against 6.06 and 10.04:

Source: Ubuntu wiki: Security Features, archived May 2011 copy. The matrix color codes cells as on by default, available or unimplemented; the colors did not survive in the archived text, so the table above records what each release had, not whether every item was switched on.

The feature notes on the same page, in their archived 2011 and 2015 versions, fill in the history:

• Stack protector. GCC's -fstack-protector adds a random canary that guards return addresses. Ubuntu patched GCC to enable it by default, so packages built for 8.04 got it unless they opted out. The current compiler flags page still describes GCC as "patched to enable linking against those routines by default."
• Exec ASLR. Randomising the load address of PIE programs was in mainline from Linux 2.6.25 and "was backported to Ubuntu 8.04 LTS." Only programs actually built as PIE benefit, and 8.04 did not build its archive as PIE.
• VDSO ASLR. Earlier releases kept COMPAT_VDSO enabled, which blocked VDSO randomisation; it "was removed in Ubuntu 8.04 LTS," and glibc 2.7 in 8.04 supported VDSO ASLR on x86_64.
• brk ASLR. True brk randomisation came with Linux 2.6.26 in 8.10, though PIE programs on 8.04 saw some of the effect because the heap sits right after the randomised executable.
• ASLR default value. Before 8.10, /proc/sys/kernel/randomize_va_space defaulted to 1; later releases with brk ASLR default to 2. The current ASLR page explains both values.
• /dev/kmem. The device node still existed in 8.04 through 9.04, but "it is not actually attached to anything in the kernel."
• Module loading. In 8.04 and earlier, removing CAP_SYS_MODULES from the bounding set stopped new kernel modules loading; Linux 2.6.25 changed bounding sets and the option disappeared until 9.10 added modules_disabled.
• 0-address protection. Done through the mmap_min_addr sysctl from 2.6.22 kernels, and built into the kernel from 9.04.
• Password hashes. 8.04 still stored salted MD5 hashes. "Ubuntu 8.10 and later" moved to salted SHA-512.

What 8.04 did not have matters as much for anyone assessing an old binary. Fortify Source, RELRO and BIND_NOW were not set by default, archive wide PIE builds came much later (the current compiler flags page dates PIE by default on amd64 to 16.10 and on all architectures to 17.10), and the kernel itself was not built with its own stack protector. A binary compiled on Hardy has a stack canary and little else.

TPM and disk encryption

The Security Features wiki says "TPM 1.2 support was added in Ubuntu 7.10," with tpm-tools in universe, so 8.04 had kernel TPM support but nothing used it for disk encryption. Full disk encryption meant encrypted LVM, available from the alternate installer only. The 8.04 release notes add that Wubi did not support software RAID or encrypted disks. Encrypted private directories arrived in 8.10, and encrypted home directories in 9.04.

PolicyKit

PolicyKit was the other privilege change. The overview describes it as letting administrative tools run as a normal user and "gain extra privileges dynamically only for privileged operations instead of requiring the whole application to run as root." 8.04 used it in the Network, Users and Groups, Services and Time and Date tools, the panel clock, gnome-mount and HAL, configured through a new System, Administration, Authorizations tool.

What else was new: Wubi, PulseAudio, Firefox 3 beta and PolicyKit

The topic brief asked us to confirm each of these. All four are confirmed in the archived 8.04 technical overview:

Smaller changes from the same pages: file systems mounted with relatime by default, a quick LTSP terminal server option on the alternate CD, umenu replacing the Windows open source software launcher on the CD, and Likewise Open in universe for Active Directory logins.

A CVE example: the Debian OpenSSL flaw on 8.04

Three weeks after Hardy shipped, Ubuntu published USN-612-1 on 13 May 2008. It reported "a weakness has been discovered in the random number generator used by OpenSSL on Debian and Ubuntu systems," which made certain keys "much more common than they should be." It particularly affected keys used by OpenSSH, OpenVPN and SSL certificates. The affected releases were 7.04, 7.10 and 8.04 LTS. The Ubuntu CVE tracker entry for CVE-2008-0166 rates it Critical in Ubuntu priority and 7.5 High under CVSS 3, and describes the affected range as OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian based systems.

The tracker lists these fixed versions for 8.04:

USN-612-1 itself names the library update for 8.04 as libssl0.9.8 version 0.9.8g-4ubuntu3.1, and the tracker links follow up notices USN-612-2, 612-3, 612-4 and 612-7.

The lesson for anyone running old systems is in the shape of the fix. Updating the OpenSSL package changes how new keys are made. It cannot change keys that already exist. A Hardy server that generated its SSH host keys or a certificate key between April and May 2008, then installed the update, still holds those keys until someone replaces them. That is why the tracker lists the blacklist packages alongside the library fix. When you assess an old system, "the package is at the fixed version" is the start of the check, not the end.

This post does not describe how the weakness can be abused. To confirm you have the fix on a system of that age, compare the installed openssl and libssl versions to the fixed versions above, and check when long lived keys on the host were generated.

What changed from Ubuntu 6.06 LTS to 8.04 LTS?

Many sites went straight from Dapper to Hardy, LTS to LTS, which the 8.04 release notes support directly: "Users of Ubuntu 7.10 or Ubuntu 6.06 LTS can upgrade to Ubuntu 8.04 by a convenient automated process." Users of 6.10 or 7.04 had to go step by step.

The release notes list several upgrade traps that matter for anyone reading an old configuration management repository:

• Networking. network-manager in 8.04 only managed interfaces marked for roaming, so the upgrade removed plain DHCP auto stanzas from /etc/network/interfaces. ifupdown also set a default route metric of 100 instead of 0.
• NFS. Mounting NFS needed the nfs-common package installed.
• Shell scripts. Scripts written for bash but run as /bin/sh could break on dash.
• EVMS. Dropped upstream and moved to universe from 7.10, so Dapper systems using it needed attention before upgrading.
• Repositories. The commercial repository on archive.canonical.com became "partner," and PowerPC and SPARC users had to repoint their sources at ports.ubuntu.com.

The interim steps: 6.10, 7.04 and 7.10

Official release notes for 6.10 and 7.04 are not on documentation.ubuntu.com; those pages return 404. The 7.10 page there is a stub that redirects to the old GutsyGibbon wiki page, which we read through the Wayback Machine. What we could confirm:

Kernel and desktop versions for 6.10, 7.04 and 7.10 are not stated in the official pages we fetched, so we leave them out rather than fill them from memory.

What came next: 8.10 and 10.04 LTS

Ubuntu 8.10 "Intrepid Ibex" followed on 30 October 2008 with Linux 2.6.27. Its release notes say 8.04 LTS users could upgrade directly and users of older releases had to go to 8.04 LTS first. Several of the protections Hardy lacked arrived here: SHA-512 password hashes, true brk ASLR with randomize_va_space set to 2, and encrypted private directories through eCryptfs. 8.10 also started installing packages listed in Recommends by default.

The 10.04 release notes say users of 9.10 and 8.04 LTS can upgrade to 10.04, and users of other releases must first go to one of those two. That LTS to LTS path is the only official way off Hardy, and 10.04 has itself been out of support for years.

Why 8.04 still turns up, and how to recognise it

Nobody chooses Hardy for new work. It turns up because something was built on it and never rebuilt: an appliance image, a virtual machine template, a lab server, a build host for a legacy product, or a filesystem copied into a container. Recognising it in an inventory comes down to a few clues:

1. The release name. On a running system, the Ubuntu Desktop docs use lsb_release --description, which on Hardy reports Ubuntu 8.04 or one of its point releases.
2. The codename in package sources. Hardy's sources use the suite names hardy and hardy-security, as the 8.04 release notes show in their ports.ubuntu.com example.
3. The kernel. A 2.6.24 kernel string is a strong pointer to 8.04.
4. Version baselines in an SBOM. Package versions carry the release. OpenSSL at 0.9.8g with an ubuntu suffix, OpenSSH 4.7p1 or GNOME 2.22 components point to Hardy, as the version strings on the CVE-2008-0166 tracker page show.
5. Hashes in /etc/shadow. An 8.04 install created MD5 password hashes; a modern Ubuntu does not.

For container images and appliances, the SBOM is the faster route. Our guides to checking whether a base image's operating system is end of life and to Docker Ubuntu image tags cover the general method, and how to check a distro's backported security fix explains why an Ubuntu version string can carry a fix that the upstream version number does not show. On Hardy, though, the backports stopped in 2013.

How do you check and move off an Ubuntu 8.04 system?

These steps use commands from Canonical's current documentation. The documentation is written for supported releases, and Hardy's own tools predate some of them, so treat the read only checks as the safe part and plan the move as a rebuild.

Step 1: Confirm the release

From the Ubuntu Desktop docs:

lsb_release --description

Step 2: Check which AppArmor profiles are enforcing

The Ubuntu Server AppArmor guide lists the profile status command. On Hardy you expect at most the four default profiles plus any you added:

sudo aa-status

Step 3: Check the firewall state

From the Ubuntu Server firewall guide:

sudo ufw status verbose

An inactive firewall on an end of life host that offers network services is the first thing to change while you plan its replacement.

Step 4: Check the ASLR setting

Read the value of /proc/sys/kernel/randomize_va_space. The ASLR page explains the values; per the archived Security Features wiki, Hardy's default was 1.

Step 5: Decide between upgrade and rebuild

The official upgrade path is 8.04 to 10.04 LTS, then onward one LTS at a time. The current Ubuntu Server upgrade guide says "you cannot skip releases" and recommends do-release-upgrade, after bringing the system up to date, taking a backup and checking /run/reboot-required:

sudo apt update
sudo apt dist-upgrade
sudo do-release-upgrade

Those commands are written for current releases; they are the shape of each hop, not a promise that a Hardy system can still reach its next release's archive without changes. Getting from 8.04 to a supported LTS today means 10.04, 12.04, 14.04, 16.04, 18.04, 20.04, 22.04 and then 24.04 or 26.04, every hop on a release that is itself end of life until the last ones. For almost every real system, rebuilding the service on a current LTS and moving the data is faster and far safer than eight in place upgrades.

Where to get official 8.04 ISOs, and why not to run them on a network

Hardy's images live on old-releases.ubuntu.com/releases/hardy, the only official location. The directory holds the 8.04.4 images (desktop, alternate and server for i386 and amd64) alongside earlier 8.04 point releases, together with MD5SUMS, SHA1SUMS and SHA256SUMS files and their .gpg signatures. The checksum files were refreshed on 28 May 2013, shortly after the server end of life. Verify any download against the signed SHA256SUMS before use, and do not download Hardy from third party mirrors. Our post on Linux distribution package signing explains why the signature check matters.

Use these images only to reproduce a legacy environment in an isolated lab: no route to the internet, no shared credentials, no production data. A fresh Hardy install from the 8.04.4 images lacks every fix published after those images were built in January 2010, and has no official fix at all for anything found after May 2013.

Common mistakes

• Treating 8.04 as "LTS, so still supported." LTS meant three years on the desktop and five on the server. Hardy server support ended on 9 May 2013.
• Assuming ESM covers it. Canonical's ESM and release cycle pages list no extended coverage for 8.04. There is no subscription that brings it back into support.
• Assuming ufw was protecting the host. ufw shipped in 8.04, but Canonical's documentation describes it as disabled until enabled. Check ufw status.
• Over crediting the hardening. 8.04 had the stack protector and better ASLR, but not Fortify Source, RELRO or archive wide PIE. Old binaries are easier targets than modern ones.
• Assuming AppArmor confined everything. Only cupsd, slapd, mysqld and named had enforcing profiles by default.
• Stopping at "the package is patched." CVE-2008-0166 shows that a fixed library does not repair keys created before the fix.
• Planning a single upgrade jump. You cannot skip releases with do-release-upgrade, and Hardy is eight LTS steps from a supported release.
• Downloading old ISOs from unofficial mirrors. Only old-releases.ubuntu.com is official, and the checksums are signed.
• Forgetting the application layer. Even a carefully isolated Hardy host runs application code with its own dependencies, which no Ubuntu update ever covered.

FAQ

Is Ubuntu 8.04 still supported?

No. Desktop support ended on 12 May 2011 and server support on 9 May 2013, per the archived Ubuntu Releases page. Canonical's current ESM and release cycle pages list no extended coverage for 8.04.

When was Ubuntu 8.04 released?

On 24 April 2008, according to the archived Ubuntu wiki Releases page. The current 8.04 release notes on documentation.ubuntu.com do not state the date.

What kernel does Ubuntu 8.04 use?

Linux 2.6.24. The archived technical overview gives the exact build as 2.6.24-16.30, based on upstream 2.6.24.3.

What desktop does Ubuntu 8.04 use?

GNOME 2.22.1 on Xorg 7.3. Kubuntu 8.04 shipped KDE 3, with a separate KDE 4 edition.

Did Ubuntu 8.04 have AppArmor?

Yes. AppArmor arrived in 7.10, and 8.04 was the first LTS with it, at version 2.1. Profiles for CUPS, OpenLDAP, MySQL and BIND were enforcing by default.

Was ufw enabled by default in Ubuntu 8.04?

ufw first shipped in 8.04. The 8.04 release pages do not state its default state; Canonical's security documentation describes ufw as installed but disabled until an administrator enables it.

Was Ubuntu 8.04 affected by the Debian OpenSSL bug?

Yes. USN-612-1, published 13 May 2008, fixed CVE-2008-0166 on 7.04, 7.10 and 8.04, with OpenSSL 0.9.8g-4ubuntu3.1 for Hardy. Keys generated before the fix had to be replaced.

Can I upgrade Ubuntu 8.04 to 10.04 directly?

Yes. The 10.04 release notes say 8.04 LTS and 9.10 users can upgrade to 10.04. From there each LTS must be taken in turn, because releases cannot be skipped.

Where can I download Ubuntu 8.04?

From old-releases.ubuntu.com/releases/hardy, which has the 8.04.4 images and signed checksum files. Use them only in an isolated lab.

What does Hardy Heron mean in Ubuntu?

It is the codename of Ubuntu 8.04 LTS. Hardy's package suites are named hardy, hardy-security and so on, which is the easiest way to recognise it in a sources list or SBOM.

Fix it without waiting for upstream

On Hardy, upstream is gone: no Ubuntu security notice has covered 8.04 since 2013, and no ESM channel exists for it. The operating system has to be replaced. What can be fixed without waiting is everything you build on top of it, the application dependencies that a legacy service carries in its lockfiles and vendored libraries, which keep their own vulnerabilities after the service moves to a new base.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard scans repositories, container images and SBOM files and matches the components it finds against vulnerability databases, so an image built from an old Ubuntu filesystem shows its OS packages and versions next to its application dependencies:

safeguard scan --dir .
safeguard scan --image your-image:tag
safeguard scan --sbom sbom.json

Results are written as JSON under ./output, and the platform shows every project that contains a given component and version, which is how you find every image still carrying a Hardy era OpenSSL. Safeguard does not patch an end of life host kernel or deliver Ubuntu updates; for 8.04 the answer to the operating system is replacement.

In this Safeguard CLI session you install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. Rebuilding a legacy service off 8.04 is the right moment to bring its own dependencies up to fixed versions, and this is that flow.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. For teams auditing old images or appliance exports, it means the scan runs on a machine you control. Our guide to how the local runner and offline mode work covers the details.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask Claude which of your projects still carry a component version you are tracking, for example an OpenSSL 0.9.8 build, while you decide which legacy services to rebuild first.

Click through it at your own pace, or open it full screen.

To try it yourself, download Safeguard from safeguard.sh/download and follow the CLI docs.

For every Ubuntu version with its kernel and support dates, see our Ubuntu release history hub. For how LTS, interim, ESM and Legacy windows fit together, see the Ubuntu support lifecycle explained, and for a later LTS in the same format, Ubuntu 16.04 LTS Xenial Xerus. To keep up with notices for releases you do still run, see how to subscribe to Ubuntu and Debian security advisories.

Quick check

Sources

• Ubuntu release notes: Ubuntu 8.04 LTS
• Ubuntu release notes: Ubuntu 7.10 (redirect stub to the wiki page)
• Ubuntu release notes: Ubuntu 8.10
• Ubuntu release notes: Ubuntu 10.04 LTS
• Ubuntu release notes: Ubuntu 6.06 LTS
• Ubuntu release notes index
• Ubuntu 8.04 technical overview, www.ubuntu.com/getubuntu/releasenotes/804overview, read via the Wayback Machine copy of 13 May 2008
• Ubuntu 8.04 release notes, www.ubuntu.com/getubuntu/releasenotes/804, read via the Wayback Machine copy of 11 May 2008
• Ubuntu wiki: HardyHeron/Beta, read via the Wayback Machine copy of 13 August 2011
• Ubuntu wiki: GutsyGibbon/ReleaseNotes, read via the Wayback Machine copy of 23 December 2010
• Ubuntu wiki: Security/Features, read via the Wayback Machine copies of 20 May 2011 and 27 December 2015
• Ubuntu wiki: Releases, read via the Wayback Machine copy of 12 February 2014
• Old Ubuntu releases: Hardy Heron
• Ubuntu: Release cycle
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu: Expanded Security Maintenance
• Ubuntu security notice USN-612-1
• Ubuntu CVE tracker: CVE-2008-0166
• Ubuntu Security documentation: AppArmor
• Ubuntu Security documentation: Firewall
• Ubuntu Security documentation: Default compiler and linker flags
• Ubuntu Security documentation: ASLR
• Ubuntu Server documentation: AppArmor
• Ubuntu Server documentation: Firewalls
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Desktop documentation: Switch between an LTS and interim release

Last reviewed: 23 October 2026.