Gentoo Linux Release History: Portage, Profiles, Stages and GLSAs

Gentoo Linux has no version numbers to support. It is a source based rolling release: one ebuild repository that every system tracks, signed stage 3 tarballs rebuilt every week, and a "profile version" (currently 23.0) that sets the toolchain defaults. Security fixes arrive as updated ebuilds and are announced as GLSAs, which glsa-check tests against your installed packages.

Since December 2023 Gentoo has also published signed binary packages, so the old choice between "compile everything" and "use another distribution" is gone. This post covers where Gentoo came from, how Portage, ebuilds, USE flags and profiles decide what a system is, what the stage 3 variants are and how their signatures work, what the binary package host changed, how the security team decides what gets an advisory and how fast, which architectures came and went, and a step by step routine to verify a stage, set a profile, turn on signed binary packages and audit a running system.

Key takeaways

• There is no "Gentoo 2026". The project ships weekly, dated, OpenPGP signed stage 3 tarballs. On 24 October 2026 the signed amd64 index listed 21 stage 3 variants, all built on 18 October 2026. A system is defined by its profile and its last emerge --sync, not by the date of the stage it started from.
• Profiles are the closest thing to a release. Profile versions such as 13.0, 17.0, 17.1 and 23.0 change toolchain defaults. The 23.0 upgrade was announced on 22 March 2024; the timeline page sets the old profiles' deprecation at 6 June 2024, removal from profiles.desc at 6 June 2025 and deletion of the directories on 1 January 2028.
• 23.0 hardened the defaults. The news item says the profiles "enable some toolchain hardening features" by default; the transition page plans GCC -fstack-clash-protection, linker -z relro -z now, DT_RELR relocations and merged /usr for all architectures, with architecture specific changes on top. Upgrading requires glibc 2.36 or musl 1.2.4 or newer.
• Binary packages are signed, but only GPKG. The 29 December 2023 announcement says official binary packages are GPKG files signed with the release engineering key that also signs the stages. Old XPAK packages carry no signature, and Portage still accepts them unless you set FEATURES="binpkg-request-signature".
• Advisories have deadlines. The vulnerability treatment policy maps package reach and impact to a severity level with a target delay from upstream fix to stable ebuild and GLSA: 1 day for Blocker, 3 for Critical, 5 for Major, 10 for Normal, 20 for Minor and 40 for Trivial.
• Some things never get a GLSA. Kernels are outside the GLSA process, as are vulnerabilities that only affect testing (~arch) versions. A clean glsa-check run does not mean a patched kernel or a patched testing package.
• Primary architectures are amd64, arm64 and ppc64. A GLSA waits for a stable fix on those; secondary architectures may be fixed later. IA-64 (Itanium) profiles and keywords were removed in September 2024.

This post sits next to our release histories for other distributions. For a branch based distribution with fixed support windows, see Alpine Linux release history, and for how a corporate pipeline differs, see Fedora, CentOS Stream and RHEL.

Where Gentoo came from

Gentoo began as a one person project. According to the Wikipedia article on Gentoo Linux, Daniel Robbins first built a distribution called Enoch Linux, with at least one public version (0.75, December 1999). The aim was software tuned to the hardware it ran on and nothing more than the user needed. While experimenting with EGCS, a fork of GCC whose work later merged back into GCC 2.95, the project was renamed Gentoo, after the fastest swimming penguin. Robbins later described taking ideas from FreeBSD's ports collection to turn the build scripts into Portage. Gentoo Linux 1.0 was released on 31 March 2002.

In 2004 Robbins created the non profit Gentoo Foundation, transferred the copyrights and trademarks to it and stepped back from the project. Technical governance moved to an elected council. The About Gentoo page still describes a seven member council elected every year to decide global issues and policy, and puts the developer community at around 250 developers.

The legal side changed again in 2024. On 10 April 2024 the project announced that, as of March, Gentoo had become an associated project of Software in the Public Interest (SPI), a US 501(c)(3) fiscal sponsor that also hosts Arch and Debian. The announcement explains why: the Gentoo Foundation was a recognised non profit only in New Mexico and "a for-profit entity at the US federal level". The 2024 year in review adds that the plan is to "gradually wind down operations of the Gentoo Foundation" and move its assets to SPI.

From numbered releases to weekly stages

Gentoo has always been a rolling release underneath, but for a while its install media looked like versioned releases. According to the Wikipedia article's version history, Gentoo began naming its live media by year in 2004 (2004.0, 2004.1 and so on) instead of numerically. That continued until 2008, when the planned 2008.1 live CD was cancelled "in favour of weekly automated builds" of stage 3 tarballs and minimal CDs, and the first weekly builds were published on 20 December 2008. A special live DVD marked the project's tenth anniversary in 2009. Even /etc/gentoo-release gives the game away: it holds the version of the installed sys-apps/baselayout package, not a distribution version.

Those media numbers never described the installed system. Because Portage pulls the current ebuild repository on the first sync, a machine installed from 2008.0 media was, a day later, running whatever the tree contained that day. The number only described the installer. Profiles, which had tracked the media numbering, switched to two digit year names after 2008.0 and became the real markers of change.

The early years also had a precursor to today's binary packages. The Gentoo Reference Platform (GRP) shipped prebuilt packages such as KDE, GNOME, X and Mozilla so a new install could get to a desktop quickly, with the expectation that users would later rebuild them locally. Wikipedia records that the last reference to GRP was in the 2008.0 handbook and that it was discontinued by 2011.

The project eventually stopped pretending otherwise. Release engineering now builds installation stages automatically, signs them and publishes them under dated directories, with a signed latest-stage3.txt index per architecture. The 2025 year in review says Gentoo now builds 154 distinct installation stages every week across its architectures and system configurations. The repository itself is a continuous stream of commits: that same review counts 112,927 commits to the main ::gentoo repository in 2025, and says the tree holds 31,663 ebuilds for 19,174 packages.

Two infrastructure moves shaped how that stream reaches users. On 12 August 2015 the project announced that the main package repository had moved from CVS to Git, after work that began with a proof of concept in 2006. The announcement links the move to signing: it "will allow end-to-end signature tracking from the developer to the final repository". In February 2026 Gentoo added a Codeberg mirror for contributions as part of a gradual move of its mirrors away from GitHub, while stating that it continues "to host our own repositories".

Portage, ebuilds, USE flags and profiles

Portage and the ebuild repository

The About page calls Portage "the heart of Gentoo". It does three jobs. It syncs the ebuild repository (emerge --sync). It installs packages (emerge package), compiling each one to the settings you chose. It keeps the system current (emerge -uD @world). The Portage wiki article adds that it can install from source or from binary packages, drawing on the Gentoo repository, from additional ebuild repositories or from a binary host.

An ebuild is a bash based recipe for one version of one package: where to fetch the source, which dependencies it needs, which optional features it supports, and how to configure, compile and install it. The format is versioned as an EAPI. The 2025 review notes that EAPI 9 was finalised and Portage support completed in 2025, adding pipestatus, an edo helper and a cleaner build environment.

Portage itself has a version history worth knowing. Portage 3.0 was stabilised in September 2020; it removed Python 2.7 support and, thanks to a user patch, sped up dependency calculation by "around 50-60%".

USE flags

USE flags are how Gentoo exposes optional features. A package that can be built with or without, say, LDAP or Qt support declares those as flags, and the system's settings decide which are on. Flags come from three layers: the profile sets defaults, /etc/portage/make.conf sets global choices, and /etc/portage/package.use overrides them per package. Changing a flag changes what gets compiled and therefore which libraries end up on disk. Two machines with the same package list can have different dependency trees, which matters when you ask "is this library installed anywhere?".

This is also why binary packages cannot cover every system. The binary package announcement says it plainly: if your USE flag combination deviates from the profile default, the prebuilt package will not be used. Portage will mix binary and locally built packages, using a binary where the flags match and compiling where they do not.

Profiles

A profile is a named, versioned bundle of defaults: architecture, C library, init system, CHOST, compiler flags, default USE flags and package masks. Profile paths look like default/linux/amd64/23.0/systemd or default/linux/amd64/23.0/desktop/plasma. You select one with eselect profile, and it is stored as the /etc/portage/make.profile symlink.

Profiles are versioned because some defaults cannot change in place. Moving to a new profile version can change the CHOST (the target triplet the toolchain is built for), the directory layout or the ABI, and that requires a careful rebuild. In practice, profile versions are Gentoo's major releases.

What the 23.0 profile changed

The 23.0 news item says the new profiles turn on toolchain hardening and performance features by default and standardise settings across architectures. The transition tracking page lists the work by bug number under "planned specific issues". The items planned for all architectures are:

• GCC's -fstack-clash-protection on by default (bug 675050).
• The SHT_RELR / DT_RELR relative relocation format adopted (bug 818376).
• -z relro -z now in the linker by default (bug 876923); the page notes -z relro was already default since 2017.
• Merged /usr as the default layout (bug 876881).
• clang renamed to llvm in profile names (bug 878119).
• New systemd/hardened profiles, with systemd/selinux inheriting them (bug 878157).
• The -gentoo- part removed from the musl CHOST (bug 917396).

Architecture specific items include an i686 CHOST fix for x86, ABI specific CHOSTs on MIPS, the 128 bit IEEE long double ABI on ppc64le and, on amd64, Intel CET enabled by default (bug 927298). A separate "deferred / postponed" section holds items such as time64 for 32 bit architectures and -mbranch-protection=standard on arm64, so do not assume those are in 23.0.

The upgrade itself is a 16 step procedure in the news item. It requires a current system and backups, glibc 2.36 or musl 1.2.4 or newer, and a rule that trips people up: old profiles defaulted to split /usr and 23.0 defaults to merged /usr, so you must pick the 23.0 profile with the same layout you already have (for example default/linux/amd64/17.1 becomes default/linux/amd64/23.0/split-usr). After switching, you rebuild binutils, GCC and the C library, fix any changed CHOST, rebuild libtool and then rebuild @world with --emptytree.

How old profiles are retired

Gentoo does not keep old profiles alive indefinitely, but it gives a long runway. The 23.0 profile timeline tracks each architecture through the same stages: profiles available, binary packages available, stages tested, news item published, stages uploaded, ISO switched, old profiles deprecated, then two removal steps. For every architecture on the table:

So in October 2026 a machine still on 17.1 is on a profile that has been deprecated for more than two years and is no longer listed as a selectable profile, while its directory still exists until the start of 2028. Portage will warn about the deprecated profile on every run. Binary packages are another hard edge: the binary package FAQ says packages cannot be used with older or newer profile versions, which is why the binary host path contains the profile number. On 24 October 2026 the amd64 binary package directory contained only a 23.0/ subdirectory.

Stage 3 tarballs and install media

What a stage 3 is

A stage 3 is a compressed tarball containing a minimal, already compiled Gentoo userland for one architecture and one profile: toolchain, C library, Portage and the base system. The Handbook's stage chapter has you unpack it onto the target root, configure make.conf, chroot in and build up from there. The names "stage 1" and "stage 2" survive from the early years, when an install could start from a far smaller bootstrap and build the toolchain locally; the Handbook today starts from stage 3.

The variants

The signed amd64 latest-stage3.txt on 24 October 2026 listed these variants, all from the build stamped 20261018T124555Z (sizes rounded from the byte counts in the file):

The Handbook explains the main choices. OpenRC is Gentoo's native and original init system, and systemd is fully supported. Multilib uses 64 bit libraries wherever possible and falls back to 32 bit ones only for compatibility. The Handbook warns beginners away from no multilib, because moving from it back to multilib needs deep knowledge of Gentoo and its low level toolchain. It recommends the desktop stages for graphical systems because they include LLVM, a Rust binary and USE flag tuning that "will greatly improve install time".

The choice of stage is the choice of profile family. The Handbook says switching profiles after installation is possible but takes substantial effort, and that switching init systems is difficult. Pick the stage that matches where the machine needs to end up.

Gentoo also ships ready made images built from the same pipeline. Official Docker images built from the stage 3 have been on Docker Hub since at least July 2020, and bootable QCOW2 disk images for amd64 and arm64, updated weekly, arrived on 20 February 2025 in a "no root password" console flavour and a cloud-init flavour with all accounts locked.

How install media and stages are signed

Every stage, ISO and index is signed with OpenPGP. The release media signatures page lists the keys:

Weekly stages are signed by the automated weekly release key or one of its subkeys. The page gives four ways to get the keys: the keys.gentoo.org keyserver, Web Key Directory, a bundle at qa-reports.gentoo.org, or the sec-keys/openpgp-keys-gentoo-release package, which installs /usr/share/openpgp-keys/gentoo-release.asc on an existing Gentoo system.

The signature format was simplified on 17 February 2022. The announcement says each stage and ISO now has "a detached GnuPG signature where the file itself is signed", with the signing key unchanged. Before that, you verified a signed DIGESTS file and then compared hashes. Today the Handbook lists both: the .asc detached signature over the tarball, plus .DIGESTS (hashes in several algorithms, itself signed), .sha256 and .CONTENTS.gz, a list of every file in the tarball.

Notice also that the per architecture latest-stage3.txt index is itself a clearsigned message. A script that fetches "the latest stage" should verify that index first and only then trust the filename it contains.

The binary package host

What changed on 29 December 2023

Portage has supported binary packages for many years, mostly for people building on one machine and installing on others. What changed in late 2023 is that Gentoo started publishing official binary packages for everyone. The announcement, "Gentoo goes Binary!", dated 29 December 2023, says:

• For amd64 and arm64 there were more than 20 GB of packages, from LibreOffice and desktop environments to Docker, built from the stable tree and updated daily.
• For other architectures, coverage is limited to the stage contents, including the toolchain, with weekly updates.
• amd64 packages were built with CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe" and USE settings matching three stable profiles (the OpenRC no multilib profile and the Plasma and GNOME systemd desktop profiles). arm64 used -O2 -pipe.
• New stages already contain /etc/portage/binrepos.conf/gentoobinhost.conf, so a fresh install can use them immediately.
• There are no testing (~amd64) binaries; the advice is to stay on stable and add testing packages locally.

Five weeks later, on 4 February 2024, the project added a separate x86-64-v3 package set for machines whose CPUs support that microarchitecture level, selected by changing x86-64 to x86-64-v3 in the binary host URI. The announcement suggests ld.so --help to check which levels a machine supports. By the end of 2025 the amd64 binary set had grown to 89 GB, according to the 2025 review.

How binary packages are signed and verified

The announcement answers the signing question directly: yes, binary packages are signed, "with the same key as the stages". There is one caveat that matters for security. Portage knows two binary package formats. XPAK is the old one and cannot carry a signature. GPKG is the new one and can. All official packages are GPKG, and a GPKG whose signature fails is refused. But to avoid breaking existing setups, Portage by default still installs unsigned XPAK packages from any configured source.

The fix is one line, and the announcement strongly recommends it:

# /etc/portage/make.conf
FEATURES="${FEATURES} getbinpkg binpkg-request-signature"

With binpkg-request-signature set, only signed GPKG packages are accepted, and Portage runs the Gentoo Trust Tool, getuto, before every binary download, so key updates and revocations are always imported first. getuto builds a keyring under /etc/portage/gnupg anchored on the release engineering keys. The side effect: binary packages you build yourself will be refused until you sign them with a key trusted by that anchor.

The binary host quickstart shows the current repository configuration, now pointing at the 23.0 path:

# /etc/portage/binrepos.conf/gentoo.conf
[gentoo]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64/
verify-signature = true
location = /var/cache/binhost/gentoo

Because packages are signed, the announcement notes that pointing sync-uri at a local mirror is safe. The signature, not the transport, is what you trust.

How Gentoo handles security

The vulnerability treatment policy

The Gentoo vulnerability treatment policy is one of the more precise documents of its kind in the Linux world. Every vulnerability starts as a Bugzilla entry in the Gentoo Security product, assigned to the security team. Confidential reports are handled in restricted tools, with encrypted email to named team members; the policy discourages IRC and other unencrypted channels.

A bug wrangler then assigns a severity from two axes. The first is how widespread the package is:

The second is the vulnerability type, from 0 (remote root code execution) through 1 (remote code execution with reduced rights, or local privilege escalation), 2 (code execution by enticing a user to malicious data), 3 (denial of service, credential or database leaks, data loss) to 4 (cross site scripting, information leaks and similar). Combining them gives the Bugzilla severity and a target delay. The policy defines that delay as the longest it wants to take from the upstream fix to a stable ebuild plus its GLSA:

Two worked examples make the table concrete. A remote root code execution in a system package with a default configuration is A0, a Blocker: one day from upstream fix to stable ebuild and advisory. A cross site scripting bug in a web application that is not a system package, triggered only by an unusual setting, is D4, Trivial: a 40 day target and no GLSA at all. The initial triage itself has a target of 12 hours.

Primary and secondary architectures

The policy splits architectures into two groups. For primary architectures, a stable fix must be committed before the GLSA is released. For secondary ones, the team copies the architecture on the bug but may publish the GLSA without waiting for their stable fix. The primary list is amd64, arm64 and ppc64, with discretion to block only on amd64 depending on the package and severity. A secondary architecture can become primary by naming an architecture security liaison and agreeing to the stabilisation timelines.

What never gets a GLSA

Two exclusions are easy to miss. Kernels: "Kernels are not covered by the GLSA release process." Kernel bugs are fixed, but no advisory is issued. Non stable packages: if a vulnerability only affects a testing (~arch) version, or a package that has never been stable, it is fixed without a GLSA. A system that runs a mix of stable and testing packages, which the binary package FAQ itself recommends, has a blind spot here that only emerge -uDN @world closes.

The kernel exclusion matters more since the Distribution Kernel project arrived in September 2020 with sys-kernel/gentoo-kernel, gentoo-kernel-bin and vanilla-kernel, which install kernels through the package manager like any other package. They update with @world, but they still do not get GLSAs. Gentoo sometimes uses a news post instead. In May 2026 it published one on two kernel vulnerabilities that says only gentoo-kernel, gentoo-kernel-bin and gentoo-sources are security supported, that the vanilla kernel packages were still vulnerable when it was written, and recommends running the latest kernel because upstream "does not reliably backport security fixes to older versions".

From bug to GLSA

The policy describes the path from bug to advisory:

1. The GLSA coordinator finds the upstream fix, or reports the bug upstream if none exists.
2. The package maintainer commits a fixed ebuild. The policy asks for a new version or revision bump so the fix arrives through a normal system upgrade, with a higher version than any vulnerable one.
3. A stabilisation request goes to the architecture teams, flagged for all architectures if the severity warrants it.
4. A draft GLSA is written in GLSAMaker in parallel.
5. At least one security team member other than the author must approve the draft before it gets a number.
6. Once the fix is in the stable tree, the GLSA XML is committed to the glsa.git repository, which publishes it to the GLSA index and RSS feed.
7. A text version is mailed to gentoo-announce, signed with the coordinator's OpenPGP key. Since 2 February 2012, third party lists are no longer copied.

GLSA IDs encode the year and month followed by a sequence number. On 24 October 2026 the newest were 202610-02 (PHP: Multiple Vulnerabilities) and 202610-01 (ca-certificates: Compromised Intermediate Certificate Authority). The index also shows how uneven publishing is: it lists 33 advisories numbered 202608 (August 2026) alone, against eight for January to July. The policy covers mistakes too: a wrong title gets a replacement erratum GLSA, while a wrong description is corrected in the XML without republishing.

Keywords and stabilisation

Every ebuild carries keywords that say on which architectures it is known to work and at what level. The devmanual's keywording concepts page defines the states: arch (for example amd64) is stable, ~arch is testing, -arch means known not to work, and a missing keyword means nobody knows yet. The special -* marks versions that only work on the architectures listed explicitly. A version must not be marked stable while a dependency it needs is still testing on that architecture. A system's ACCEPT_KEYWORDS (set by the profile) decides which it will install; package.accept_keywords lets you accept testing for a single package.

Stabilisation is the gate between testing and stable, and it is where security and stability pull against each other. Normally a version sits in testing first: the stable request guide asks whether the ebuild is "older than 30 days (sooner for security issues or serious regressions)" before an architecture team marks it stable. The security policy lets the coordinator file a stable request immediately and flag all architectures when the severity warrants it, which is how a Blocker can reach stable in a day.

Architectures over time

The downloads page lists 13 architecture families on 24 October 2026: amd64, arm64, alpha, arm, hppa, loong (LoongArch), mips, m68k, ppc, riscv, s390, sparc and x86, with ppc and arm each covering several ABIs. Support has moved over the years:

• arm64 profiles were declared stable on 11 August 2019, helped by donated bare metal hardware. arm64 is now a primary architecture for GLSAs and has full binary package coverage.
• riscv and loong joined later, starting on the 20.0 and 22.0 profile numbers respectively, before moving to 23.0 with everyone else.
• IA-64 (Itanium) was dropped in August 2024 after the Linux kernel and glibc removed it and the Gentoo Council voted. The plan was to remove all ia64 profiles and keywords and close all IA-64 bugs in the first half of September 2024.
• MIPS and Alpha went the other way: in September 2024 the project announced improved support for both.
• 32 bit platforms face the 2038 problem. The 2024 review describes experimental 64 bit time_t profiles and a migration tool, noting that the switch breaks the ABI between programs and libraries, which a source based distribution must approach carefully.

The retirement pattern for an architecture mirrors the one for profiles: a news item, a period of notice, then removal of profiles and keywords. Once keywords are gone, no new fixes reach that architecture through the tree.

Gentoo milestones timeline

The 2018 GitHub incident is worth one sentence of lesson. Gentoo's development happens on its own hardware, so the project could say that users on the default mirrors "should not be affected" and point people to repository verification. Signed repository snapshots turned an alarming headline into a contained mirror problem.

Gentoo, Arch, NixOS and Alpine compared

Facts for the other three distributions come from their own documentation: the Arch master signing keys page and security tracker, the nix.conf reference, whose require-sigs setting is true by default, the NixOS 26.05 announcement with its seven month support statement, the NixOS security team page and the Alpine releases page. The table compares approaches, not quality. The practical difference for Gentoo is that the "what is installed" question depends on USE flags and keywords as well as versions, so a list of package names and versions is necessary but not always enough.

Walkthrough: verify a stage, set a profile, enable signed binaries, audit with glsa-check

This walkthrough assumes an amd64 machine booted from Gentoo or other live media, with the target root mounted at /mnt/gentoo, as in the Handbook.

Warning before step 1: unpacking a stage 3 writes a full root filesystem into the target directory. Check the mount first so you do not unpack over the live system or the wrong disk:

findmnt /mnt/gentoo        # must show the partition you intend to install to
lsblk -f                   # confirm device, filesystem and size match your plan

Step 1: fetch the signed index and verify it

cd /mnt/gentoo
gpg --import /usr/share/openpgp-keys/gentoo-release.asc 2>/dev/null \
  || gpg --keyserver hkps://keys.gentoo.org --recv-keys 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
wget https://distfiles.gentoo.org/releases/amd64/autobuilds/latest-stage3.txt
gpg --verify latest-stage3.txt

Look for "Good signature" from the Gentoo Linux Release Engineering automated weekly release key, and check that the primary key fingerprint ends in 0E2D182910. Then read the filename for the variant you want:

grep 'stage3-amd64-systemd-' latest-stage3.txt

Step 2: download the stage and its signature, then verify

B=https://distfiles.gentoo.org/releases/amd64/autobuilds
F=20261018T124555Z/stage3-amd64-systemd-20261018T124555Z.tar.xz
wget "$B/$F" "$B/$F.asc" "$B/$F.DIGESTS" "$B/$F.sha256"
gpg --verify "$(basename $F).asc" "$(basename $F)"
gpg --output "$(basename $F).DIGESTS.verified" --verify "$(basename $F).DIGESTS"
openssl dgst -r -sha512 "$(basename $F)"

The detached signature check is the one that matters. The SHA512 comparison against the verified DIGESTS file is a second check that catches corruption. Do not continue on "BAD signature" or on a signature from a key you did not expect.

Step 3: unpack

Recheck the target, then unpack with the flags the Handbook uses to preserve permissions, extended attributes and numeric ownership:

findmnt /mnt/gentoo
tar xpvf stage3-amd64-systemd-*.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/gentoo

Step 4: select a profile

After chrooting in and syncing the tree (emerge-webrsync or emerge --sync), list and set the profile:

eselect profile list | grep 23.0
eselect profile set default/linux/amd64/23.0/systemd
eselect profile show
ls -l /etc/portage/make.profile

Pick the profile that matches the stage you unpacked: a systemd stage with a systemd profile, a musl stage with a musl profile, split-usr only if you chose the split usr stage. On an existing system, eselect profile show is also the fastest way to find machines still on a deprecated 17.x profile.

Step 5: enable signed binary packages

New stages already ship /etc/portage/binrepos.conf/gentoobinhost.conf. Check it points at the 23.0 path, then require signatures:

cat /etc/portage/binrepos.conf/*.conf
grep -E '^FEATURES' /etc/portage/make.conf
echo 'FEATURES="${FEATURES} getbinpkg binpkg-request-signature"' >> /etc/portage/make.conf
getuto
emerge --ask --verbose --update --deep --changed-use @world

getuto sets up the trust anchor in /etc/portage/gnupg. In the emerge output, packages shown with a binary marker come from the binhost; everything else is compiled locally because your USE flags or keywords differ from the binary build. If you set custom CFLAGS with -march=native, expect most packages to compile, which is the intended trade.

To confirm the signature requirement is active, run:

portageq envvar FEATURES | tr ' ' '\n' | grep -E 'binpkg-request-signature|getbinpkg'

Step 6: audit the installed system with glsa-check

glsa-check ships with current Portage. The Portage wiki article lists its modes. A routine audit looks like this:

emerge --sync                     # refresh the tree, including the GLSA metadata
glsa-check --list affected        # GLSAs that affect this system, with titles
glsa-check --test all             # print only the IDs of GLSAs this system is affected by
glsa-check --list --cve affected  # same list, with CVE IDs
glsa-check --dump 202610-02       # full text of one advisory
glsa-check --pretend affected     # show the steps needed to remediate

--test all returns only IDs, which makes it easy to use in monitoring: an empty result means no known GLSA applies. --fix exists but is marked experimental and only upgrades or removes packages. The usual remediation is to update the package the GLSA names, at the version it gives, then update @world:

emerge --ask --oneshot --verbose ">=dev-lang/php-8.3.0"   # example form only; use the version in the GLSA
emerge --ask --update --deep --newuse @world
emerge --ask --depclean

Then cover the gaps the GLSA process leaves on purpose:

uname -r                                       # running kernel; compare against the installed kernel package
equery list 'sys-kernel/*'                     # installed kernel packages (needs app-portage/gentoolkit)
portageq envvar ACCEPT_KEYWORDS                # are you on stable or testing globally?
cat /etc/portage/package.accept_keywords 2>/dev/null   # per package testing exceptions, which GLSAs do not cover

Rebooting into the newest installed kernel, and keeping testing exceptions on a short list you update often, closes most of what glsa-check cannot see.

Common mistakes

• Treating the stage date as the system version. The stage only starts the install. After the first sync the system reflects the tree; what matters is the last sync date and the profile.
• Staying on a 17.x profile. Those profiles were deprecated on 6 June 2024 and removed from profiles.desc on 6 June 2025. Binary packages for them are gone, and Portage warns on every run.
• Changing the /usr layout during the 23.0 upgrade. The news item says not to; pick the 23.0 profile that matches your current layout, then migrate the layout separately.
• Leaving unsigned binary packages allowed. Without binpkg-request-signature, Portage still installs XPAK packages that carry no signature, from any binhost you configure.
• Verifying only the SHA512. A hash from the same mirror as the file proves nothing about tampering. Verify the detached signature and the key fingerprint.
• Reading a clean glsa-check as "fully patched". Kernels and testing only packages never get GLSAs, and glsa-check is only as current as your last sync.
• Assuming every architecture is fixed when a GLSA ships. Only amd64, arm64 and ppc64 block GLSA release. On a secondary architecture, check the keywords on the fixed version.
• Copying package.accept_keywords lines and forgetting them. Each testing exception is a package outside the GLSA process.
• Running -march=native and expecting binaries. Binary packages match the profile defaults. If your flags differ, Portage compiles, which is correct but slower.

FAQ

Is Gentoo a rolling release?

Yes. There is one ebuild repository, and every system updates against it. Install stages are rebuilt weekly and signed, but they are only starting points. The nearest thing to a major release is a profile version such as 23.0, which changes toolchain defaults and has a published deprecation and removal schedule.

When was Gentoo Linux 1.0 released?

On 31 March 2002, according to the Wikipedia article on Gentoo. It grew out of Daniel Robbins's earlier Enoch Linux, whose 0.75 version appeared in December 1999.

What is the current Gentoo profile version?

23.0, announced on 22 March 2024. The 17.0, 17.1, 20.0 and 22.0 profiles were deprecated on 6 June 2024, removed from the selectable list on 6 June 2025, and their directories are due to be deleted on 1 January 2028.

Does Gentoo have binary packages now?

Yes, since 29 December 2023. amd64 and arm64 get a large set built from stable, updated daily, with an extra x86-64-v3 set on amd64. Other architectures get binaries for the stage contents. They are used only when your USE flags and keywords match the build, and Portage compiles the rest.

Are Gentoo binary packages signed?

Official ones are GPKG files signed with the same key as the stages, and a failed signature blocks installation. Portage still accepts unsigned XPAK packages by default, so set FEATURES="binpkg-request-signature" to require signatures. getuto then manages the trusted keyring.

How do I verify a Gentoo stage 3 download?

Import the release keys (from keys.gentoo.org, WKD or the gentoo-release.asc file), then run gpg --verify on the .asc file against the tarball. Optionally verify the signed DIGESTS file and compare a SHA512 hash. The release signatures page lists the fingerprints.

What is a GLSA?

A Gentoo Linux Security Advisory. Each has an ID made of year, month and a sequence number, such as 202610-02. It names affected and fixed package versions and the upgrade command, is published to security.gentoo.org and the gentoo-announce list, and can be tested against a system with glsa-check.

How fast does Gentoo fix security vulnerabilities?

The policy sets target delays from upstream fix to stable ebuild and GLSA, by severity: 1 day for Blocker, 3 for Critical, 5 for Major, 10 for Normal, 20 for Minor and 40 for Trivial. These are targets, not guarantees, and they apply to primary architectures first.

Why did my kernel vulnerability not get a GLSA?

Because the policy excludes kernels from the GLSA process. Kernel fixes still land, and Gentoo's May 2026 kernel news names gentoo-kernel, gentoo-kernel-bin and gentoo-sources as the security supported packages, but you have to track them yourself by updating and rebooting.

Which architectures does Gentoo support?

amd64, arm64, alpha, arm, hppa, LoongArch, MIPS, m68k, PowerPC, RISC-V, s390, SPARC and x86 are on the downloads page. For security advisories, only amd64, arm64 and ppc64 are primary. IA-64 was dropped in 2024.

Gentoo's own packages get their fixes from Gentoo maintainers through the ebuild repository and GLSAs, and nothing below changes that or replaces emerge -uDN @world. But the services you run on a Gentoo host pull in their own dependency trees from npm, PyPI, Maven or Go modules, which no GLSA covers, and rebuilding the host with --emptytree does not touch a vulnerable library pinned in your application's lockfile.

Fix it without waiting for upstream

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

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On a Gentoo workstation or build host, that is how you would scan the application repositories and container images you build there. Gentoo's own packages stay with Portage and glsa-check.

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

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant 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. The same approve each step flow fits a Node.js service you develop on Gentoo, where the vulnerable dependency lives in your lockfile rather than in an ebuild.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your projects are in Safeguard, you can ask which of them contain a given component and version, the same question a GLSA answers for the operating system, asked of the software you ship.

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

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• About Gentoo
• Gentoo goes Binary! (29 December 2023)
• Gentoo x86-64-v3 binary packages available (4 February 2024)
• Release media signatures
• Format of download file signatures has changed (17 February 2022)
• Gentoo vulnerability treatment policy
• Gentoo Linux Security Advisories index
• Gentoo downloads
• amd64 latest-stage3.txt
• amd64 binary packages directory
• Gentoo AMD64 Handbook: choosing and verifying the stage file
• Gentoo AMD64 Handbook: installation media
• Gentoo AMD64 Handbook: installing the base system
• Gentoo Binary Host Quickstart
• Portage (Gentoo wiki), including glsa-check
• Profile upgrade to version 23.0 available (news item, 22 March 2024)
• 23.0 profile transition
• 23.0 profile timeline
• amd64 17.1 profiles are now stable (news item, 5 June 2019)
• Gentoo Package Repository now using Git (12 August 2015)
• Hardened Linux kernel sources removal (19 August 2017)
• GitHub Gentoo organization hacked, resolved (28 June 2018)
• AArch64 (arm64) profiles are now stable (11 August 2019)
• Official Gentoo Docker images (4 July 2020)
• Portage 3.0 stabilized (5 September 2020)
• Distribution kernel for Gentoo (15 September 2020)
• 2023 in retrospect (22 January 2024)
• Gentoo becomes an SPI associated project (10 April 2024)
• Gentoo drops IA-64 support (14 August 2024)
• Improved MIPS and Alpha support (11 September 2024)
• 2024 in retrospect (5 January 2025)
• Bootable Gentoo QCOW2 disk images (20 February 2025)
• 2025 in retrospect (5 January 2026)
• Gentoo on Codeberg (16 February 2026)
• Gentoo news on two kernel vulnerabilities (19 May 2026)
• Gentoo Linux (Wikipedia), for early history and release media versions
• Stable request (Gentoo wiki)
• Gentoo devmanual: keywording concepts
• Arch Linux master signing keys
• Arch Linux security tracker
• nix.conf reference
• NixOS 26.05 release announcement
• NixOS security team
• Alpine Linux releases

Last reviewed: 24 October 2026. Gentoo is a rolling distribution, so stage dates, binary package paths, profile schedules and the GLSA list change weekly; check the linked Gentoo pages before acting on any date or path in this post.