Arch Linux Release History: Rolling Release, ISOs, Keyring, Archinstall

Arch Linux does not have releases in the Debian or Fedora sense. It is a rolling release: there is one current set of repositories, every installed system is expected to track it with pacman -Syu, and no older version is supported. The monthly "release" you download, currently 2026.10.01 with Linux 7.2.7, is only a dated, signed snapshot of the installer, not a version that receives fixes.

That one design decision explains most of what follows. Arch has published a dated installation image almost every month since 2013, signs every official package with OpenPGP keys chained to five master keys, keeps every old package and daily repository snapshots in the Arch Linux Archive for rollback, and has shipped a guided installer, archinstall, on the ISO since April 2021. This post covers the history from Judd Vinet's 0.1 in 2002, the signing model and why old installs throw keyring errors, security tracking, AUR trust, and a step by step routine to verify, install, check the keyring and roll back.

Key takeaways

• There is only one supported version: current. The ArchWiki describes Arch as "a rolling-release system, which allows a one-time installation with continuous upgrades". A system months behind is simply out of date.
• The monthly ISO is a snapshot. The release list has 195 images from 0.1 (March 2002) to 2026.10.01, twelve or thirteen a year since 2013.
• Every official package is signed. pacman 4 brought PGP signing on 16 January 2012. The default SigLevel = Required DatabaseOptional refuses unsigned packages but not unsigned databases.
• Trust flows from five master keys. Per the Master Signing Keys page, each is held by one developer with its revocation certificate held by another, and a packager key needs three master key signatures.
• Keyring errors on old installs are expected. New packages may be signed by keys an old keyring does not know. The documented fix is pacman -Sy --needed archlinux-keyring && pacman -Su, plus a correct system clock.
• The Arch Linux Archive is the rollback plan. archive.archlinux.org keeps every package version with its signature, every ISO and daily repository snapshots.
• The AUR is not part of the distribution. The ArchWiki warns that AUR PKGBUILDs "are completely unofficial and have not been thoroughly vetted". Arch announced an active malicious packages incident in the AUR on 12 June 2026.
• Security tracking exists but is thin. The Arch security tracker publishes AVG groups and ASA advisories. Its advisory list jumps from June 2025 to October 2026, so treat it as one input, not a complete feed.

For signing across Linux in general, see Linux distribution package signing. Sibling histories: every Debian release and its security support dates, how the Fedora, CentOS Stream and RHEL pipeline works, Alpine Linux branches, musl and apk and Kali's move to a rolling release.

When and why Arch Linux started

The ArchWiki says Canadian programmer Judd Vinet "began developing Arch Linux in early 2001". The first formal release, 0.1, came out in March 2002; the wiki gives 11 March, while the official release list records 12 March. Vinet was inspired, the wiki says, by Slackware, BSD, PLD Linux and CRUX, but disappointed that they lacked package management, so he also wrote pacman to handle dependency resolution, installation, removal and upgrades. pacman is still the center of the system 24 years later; on 15 October 2026 the [core] repository carried a pacman 7.1.0 build.

The leadership has changed hands twice. Vinet stepped back in late 2007 and handed the project to Aaron Griffin, which the news archive records in an "Arch Leadership" item dated 1 October 2007. At the start of 2020 the staff wrote a formal process for choosing a project leader, and on 24 February 2020 the news item The Future of the Arch Linux Project Leader made Levente Polyak's election official. The most recent leader election result was posted on 4 June 2026. Apart from select exceptions, the wiki says, Arch developers "remain unpaid, part-time volunteers".

The principles

The ArchWiki lists five principles, and each has a security consequence.

Because Arch avoids carrying its own patches, the version in pacman -Q openssl is the upstream version plus an Arch package release number. Matching against upstream advisories is simpler than on distributions that backport fixes into old version numbers.

How a rolling release works

A fixed release distribution such as Debian 13 freezes its package set and then takes only security and important fixes for years. Arch has no freeze: new upstream releases pass through testing repositories into the main ones, and every machine picks them up at its next full upgrade.

Repositories and the path a package takes

After the May 2023 Git migration the official repositories are [core] and [extra], plus [multilib] for 32 bit compatibility libraries on x86_64. The Git migration completed item of 21 May 2023 records that [community] was moved into [extra], and the wiki adds that testing and staging were each split into core and extra variants. The accepted RFC 0014, proposed on 1 September 2022, is where that merge was agreed. It also says new Package Maintainers are restricted to publishing into [testing] for their first two months.

In short, a packager updates a PKGBUILD in GitLab, builds and signs the package, publishes it to a testing repository, then moves it to [core] or [extra], and your next pacman -Syu installs it.

Why partial upgrades are unsupported

Because every package in the repositories is built against every other package in the repositories at that moment, Arch only supports a system where everything is upgraded together. The System maintenance page says partial upgrades are "not supported" and to "never run pacman -Sy; instead, always use pacman -Syu", because a newly installed package may expect a newer library than the one on disk.

There is one documented exception, and it matters for keyring errors. The package signing page says pacman -Sy --needed archlinux-keyring && pacman -Su "is not considered a partial upgrade" because it syncs the database, upgrades only the keyring package first, and then immediately performs the full upgrade.

Manual interventions and the news page

A rolling release cannot hide breaking changes behind a major version number, so Arch announces them on its news page. The 14 September 2024 item on pacman 7.0.0 explained that pacman now downloads "as a separate user with dropped privileges", so local repositories must be readable by the alpm group. On 22 September 2026 another item warned that mkinitcpio 42 needs manual intervention for TPM2 based LUKS unlocking. Reading the news before a large upgrade is part of operating Arch.

What the monthly ISO actually is

Arch builds an installation image with archiso, usually on the first of the month, and names it after the date. The release list JSON we fetched on 24 October 2026 has 195 entries:

• Ten early versioned releases, 0.1 to 0.8, from 2002 to 2007.
• Dated releases from 2007.05 (17 May 2007), at irregular intervals until 2012.
• Six in 2012, then twelve a year from 2013 onward, with an occasional thirteenth when a respin was needed.

The current image, 2026.10.01, carries kernel 7.2.7, is 1,640,497,152 bytes, and is signed with the key whose fingerprint ends in 9054449A5C, published through WKD under pierre@archlinux.org. Only the three most recent images are marked available; older ones live in the Arch Linux Archive.

The image is a live environment plus the install tools: pacstrap, arch-chroot, genfstab and archinstall. pacstrap downloads current packages from a mirror rather than copying what is frozen on the ISO, so a system installed from a three month old ISO is current after its first upgrade. The ISO date matters for booting your hardware and having a working keyring during installation, not for the software versions you end up running.

It matters in two edge cases. A very old ISO may carry a keyring too old to verify today's packages. And an ISO can be withdrawn. The xz backdoor news item of 29 March 2024 listed installation medium 2024.03.01, two virtual machine images and container images built between 24 February and 28 March 2024 as containing the compromised xz 5.6.0 or 5.6.1, and the release list now marks 2024.03.01 as removed. Arch's later update said that to its knowledge the malicious code never reached Arch binaries, because the build script only injected it in Debian and Fedora style build environments; the artifacts were pulled anyway.

A dated timeline of Arch Linux milestones

Every date below was checked against the Arch news archive, the release list or the ArchWiki on 24 October 2026.

Context for three of the milestones

i686. The January 2017 announcement cited "the decreasing popularity of i686 among the developers and the community" and made the February 2017 ISO (2017.02.01, kernel 4.9.6) the last 32 bit one. After a nine month deprecation period, support ended on 8 November 2017, with a pointer to the community fork Arch Linux 32. [multilib] was not affected.

systemd. The switch took four months of news items, from the 2012.10.06 install image to the final sysvinit warning on 4 February 2013. Existing installations had to migrate themselves, which is user centrality in practice.

zstd. The news item reported "a total ~0.8% increase in package size" and "a ~1300% speedup" in decompression. Systems with a libarchive older than 2018 could not read the new format, an early example of how a rolling system left alone too long becomes hard to update.

The GitLab and RFC era

Arch's governance now happens largely in public GitLab projects. RFC 0001, proposed on 3 February 2021, defines an RFC as "a way for Arch Linux contributors to propose, design and discuss new features and changes in project direction in a focused environment". The RFC index lists accepted RFCs from 0001 to 0070. Those that touch build hardening and signing:

RFC 0059 matters most for signing. Its summary says "Package maintainers will no longer sign packages using their individual OpenPGP private key", and that the number of OpenPGP certificates the main signing key holders need to manage "will be drastically reduced". It is a stepwise plan; today pacman still verifies the per packager model below.

How pacman package signing and the archlinux-keyring work

The web of trust

According to the package signing page, pacman uses OpenPGP keys in a web of trust. A small set of Master Signing Keys signs the keys of developers and Package Maintainers, at least three master keys per packager key. Packagers sign their packages with their own keys. On your machine, pacman-key --init generates a local key, pacman-key --populate imports the Arch keys and marks the master keys as trusted, and your local key signs the master keys.

The Master Signing Keys page adds custody: "Each key is held by a different developer, and a revocation certificate for the key is held by a different developer. Thus, no one developer has absolute hold on any sort of absolute, root trust." It listed five master keys on 24 October 2026, and explains the threshold: if a user marginally trusts all master keys, "three signatures from different master keys will consider a given developer's key as valid".

The archlinux-keyring package

The keys ship in the archlinux-keyring package, a dependency of base; the [core] repository carried version 20260909 on 24 October 2026. The archlinux-keyring repository holds the key material for main keys and packagers plus keyringctl, which builds the keyring, ownertrust and revoked files. Its README says releases "are exclusively created by keyring maintainers", with tags signed by one of seven listed keys and checkable with git verify-tag.

A new packager's key, once signed by the master key holders, reaches your machine only in a new archlinux-keyring release, and the same is true of the revoked file that keyringctl builds. An old keyring therefore lacks both new keys and recent revocations.

SigLevel: what pacman actually checks

The default /etc/pacman.conf contains:

[options]
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional

Required means every remote package must carry a valid signature; DatabaseOptional lets the repository database be unsigned. The wiki notes that "TrustedOnly is a default compiled-in pacman parameter", and LocalFileSigLevel = Optional lets you install packages you built yourself without signing them.

The package signature protects each package's content, but the repository database, which tells pacman which versions exist, need not be signed; the wiki says database signing was "a work in progress" as of November 2018. A mirror cannot feed you a forged package, but an unsigned database leaves room for a stale mirror to offer an older, still validly signed package set. Use mirrors you trust and watch their sync age.

The wiki warns that TrustAll "makes it very easy to trust keys that have not been verified", and that SigLevel = Never "was the behavior before pacman 4".

WKD and the weekly refresh

Since 29 July 2022, archlinux-keyring has shipped archlinux-keyring-wkd-sync.service with a timer enabled by default. The wiki says it fetches "new signatures of already trusted keys once a week" over the Web Key Directory, fixing marginal trust warnings with no user action. WKD looks up a key by email address over HTTPS from the owning domain, here archlinux.org, instead of public keyservers. The ISO signing key is published the same way.

Why keyring errors appear on old installs

The typical error looks like this:

error: PackageName: signature from "User <email@archlinux.org>" is invalid
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

The wiki covers four usual causes.

1. The keyring is older than the packages. A packager who joined after your last upgrade signed some new packages, and your keyring lacks their key. Update archlinux-keyring first.
2. The system clock is wrong. pacman-key "depends on system time", so a wrong clock makes keys look expired or not yet valid. Fix it with NTP.
3. A corrupt cached package. A partially downloaded file in /var/cache/pacman/pkg/ fails verification. Remove it and download again.
4. A broken local keyring. As a last resort, remove /etc/pacman.d/gnupg and rerun pacman-key --init and pacman-key --populate. Arch gave exactly that advice in its 8 December 2014 GnuPG 2.1 news item, after a format change "rendered the local master key unable to sign other keys".

Do not set SigLevel = Never to make the error go away; it turns off the one check that ties packages to the people who built them.

How Arch handles security

The Arch Security Team and the tracker

Arch's volunteer security team runs a public tracker at security.archlinux.org. It groups CVEs into Arch Linux Vulnerability Groups (AVG), each tied to a package, an affected version and, once known, a fixed version, and publishes Arch Linux Security Advisories (ASA) to the arch-security list. Identifiers look like AVG-2909 and ASA-202610-1. When we checked on 24 October 2026:

• The advisory list showed ten ASAs in June 2025, the latest dated 22 June 2025, and then two critical advisories on 21 October 2026 for php (ASA-202610-1) and php-legacy (ASA-202610-2). Nothing was published in between.
• The "vulnerable" issues page still listed groups opened in 2022 and early 2023, some with a fixed version already recorded but the status not closed.

The Arch Security Team wiki page is candid: an out of date banner says "The tracker is currently not updated" and that this "is not evident on the tracker page itself". When the process runs normally, ASAs "are scheduled in the tracker for peer-review, and need two acknowledgments from team members before being published".

None of this means Arch stopped shipping fixes. On a rolling distribution most fixes arrive as the next upstream release with no advisory at all. It does mean a scanner that relies only on the tracker will miss things and flag things already fixed.

Using the tracker from the command line

The arch-audit package in [extra], described as "a utility like pkg-audit based on Arch Security Team data", compares the tracker's data with your installed packages. Its man page documents -u, --upgradable for showing only packages that already have a fixed version available:

sudo pacman -S arch-audit
arch-audit        # installed packages with open AVGs
arch-audit -u     # only those where a fixed version is already in the repos

arch-audit inherits the tracker's gaps, so treat its output as a hint and compare pacman -Q versions with upstream advisories for anything that matters.

News items for critical issues

For the most serious cases Arch posts to the main news page. The 21 October 2026 items told users to update to php 8.5.12 or php-legacy 8.3.36 "to prevent remote code execution" and to update ca-certificates-mozilla to 3.131.1-1 "to prevent man-in-the-middle attacks". If you follow one Arch feed, make it the news feed, which also carries manual interventions.

The Arch Linux Archive and rollback

What the archive stores

The Arch Linux Archive wiki page describes three directories in the archive, formerly the Arch Linux Rollback Machine:

Old packages are periodically moved to the Arch Linux Historical Archive on the Internet Archive, with a redirect so old links keep working.

Why the archive is a supply chain tool, not only a rescue tool

The /repos/ snapshots give a rolling release a fixed point. Point a container or CI build at a dated snapshot and two builds a week apart produce the same package set; you move the date forward on purpose, in a reviewed change, rather than whenever a mirror syncs. The trade off is that a pinned snapshot gets no security fixes, so the date must move regularly. The wiki also warns: "It is not safe to mix the Arch Linux Archive and up-to-date mirrors". A failed archive download that falls back to a current mirror leaves you with packages from two points in time.

What trust can you place in the AUR?

The Arch User Repository holds user contributed build recipes (PKGBUILDs), not packages. You download a PKGBUILD, read it, build with makepkg and install the result with pacman. The AUR wiki page is direct: "AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk."

How AUR trust differs from official repositories

Why a PKGBUILD must be read before building

A PKGBUILD is a Bash script. makepkg runs its prepare(), build() and package() functions with your user's privileges, and an optional .install file runs as root during installation. The source array can point anywhere on the internet. Building an AUR package means running a stranger's shell script, and installing it runs part of it as root.

The wiki's instruction is to "carefully check the PKGBUILD, any .install files, and any other files in the package's git repository for malicious or dangerous commands", and it notes that "malicious code may be signed", so a valid validpgpkeys signature on the upstream tarball proves only who signed it. It also says scanning tools exist but "are not substitutes for careful manual verification".

The 12 June 2026 news item shows why. Arch reported "a high volume of malicious package adoptions and updates", warned that creating accounts, pushing updates and adopting packages might be affected while it worked on the problem, and asked users "to review all PKGBUILD and install script changes when updating". Two lessons follow. A package you trusted last year may have been adopted by someone else. And every update is a new script, so read the diff each time, not just at first install. The same applies to the GitHub mirror of AUR packages that Arch pointed to during the August 2025 outage: it is the same unvetted content.

Step by step: verify, install, check the keyring, pin and roll back

These steps assume an x86_64 machine and a Linux or Arch host for the download and verification.

Step 1: download the ISO and checksums

Download the image from a mirror on the download page, but take the .sig and checksum files from archlinux.org itself. The installation guide warns that a signature downloaded from a mirror "could be manipulated".

V=2026.10.01
curl -LO https://geo.mirror.pkgbuild.com/iso/$V/archlinux-$V-x86_64.iso
curl -LO https://archlinux.org/iso/$V/archlinux-$V-x86_64.iso.sig
curl -LO https://archlinux.org/iso/$V/b2sums.txt
b2sum -c b2sums.txt --ignore-missing

A checksum match proves the file is intact, not who made it. The signature does that.

Step 2: verify the ISO signature

Using Sequoia, as the download page shows:

sq network wkd search pierre@archlinux.org --output release-key.pgp
sq verify --signer-file release-key.pgp \
  --signature-file archlinux-$V-x86_64.iso.sig archlinux-$V-x86_64.iso

Or using GnuPG:

gpg --auto-key-locate clear,wkd -v --locate-external-key pierre@archlinux.org
gpg --verify archlinux-$V-x86_64.iso.sig archlinux-$V-x86_64.iso

Compare the printed fingerprint with the release list. On 24 October 2026 every recent release listed 3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C, and the August 2025 outage news item told users to confirm the ISO "is signed by 0x3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C (or other trusted keys that may be used in the future)". On an existing Arch system, pacman-key -v archlinux-$V-x86_64.iso.sig checks against the keyring you already trust.

Step 3: write the USB stick

Warning: the next command destroys everything on the target device. Run lsblk with the stick plugged in and again unplugged, and confirm the path is not your system disk.

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
# Identify the USB stick, for example /dev/sdX, by size, model and TRAN=usb.
# Make sure none of its partitions is mounted.
sudo dd bs=4M if=archlinux-$V-x86_64.iso of=/dev/sdX conv=fsync oflag=direct status=progress

Step 4: install with archinstall

Boot the stick and connect to the network (iwctl for wireless). The archinstall wiki page says updating just archinstall on the live ISO "is usually fine".

timedatectl                    # confirm the clock is synchronized
pacman -Sy archinstall         # optional: newer installer than the ISO's

Warning: archinstall repartitions and formats the disk you select. List the disks and note the target before starting.

lsblk -o NAME,SIZE,MODEL,TRAN,TYPE
archinstall

In the guided installer, pick that disk, choose layout and encryption, set a root password or sudo user, pick a profile and add packages. The wiki's warnings: archinstall uses "different defaults than the regular installation process", so mention it and provide /var/log/archinstall/install.log when asking for help. A blank root password disables the root account. Wireless configuration made with iwctl on the ISO, "including the network's password", is copied to the installed system. Profiles "are specific to archinstall and not supported by package maintainers".

Step 5: check keyring health after first boot

pacman -Q archlinux-keyring pacman
systemctl status archlinux-keyring-wkd-sync.timer
grep -E '^(SigLevel|LocalFileSigLevel|RemoteFileSigLevel)' /etc/pacman.conf
sudo pacman-key --list-sigs | head -40

archlinux-keyring should match the current repositories, the WKD sync timer should be active, and SigLevel should read Required DatabaseOptional with no TrustAll or Never anywhere, including per repository sections. To compare one master key with the master keys page:

sudo pacman-key --finger 3572FA2A1B067F22C58AF155F8B821B42A6FDCD7

If a machine has been offline for months, update the keyring first:

sudo pacman -Sy --needed archlinux-keyring && sudo pacman -Su

Step 6: pin a package that broke

If an upgrade broke something, downgrade from the local cache first, following Downgrading packages:

ls /var/cache/pacman/pkg/ | grep '^openssh-'
sudo pacman -U file:///var/cache/pacman/pkg/openssh-<old_version>-x86_64.pkg.tar.zst

Then hold it with IgnorePkg in /etc/pacman.conf:

[options]
IgnorePkg = openssh

Remove the line once a fixed version is out. An ignored package gets no security fixes while its dependencies keep moving, so a long lived entry is a partial upgrade in slow motion.

Step 7: roll back from the archive

If the old version is gone from the cache, pacman fetches it from the archive and verifies its detached signature:

sudo pacman -U https://archive.archlinux.org/packages/o/openssh/openssh-<old_version>-x86_64.pkg.tar.zst

To return the whole system to a date, make a single archive snapshot the only Server in the mirror list:

# /etc/pacman.d/mirrorlist
Server = https://archive.archlinux.org/repos/2026/10/01/$repo/os/$arch

sudo pacman -Syyuu

yy forces a fresh database download and uu allows downgrades. Before May 2023 you also need a [community] section. On signature errors, the archive wiki suggests updating archlinux-keyring and ca-certificates first. Afterwards, restore the normal mirror list and run pacman -Syu.

Step 8: pin a container build to a date

The official archlinux image is rebuilt weekly, according to its image documentation. A snapshot URL makes the package layer repeatable:

FROM archlinux:base
RUN echo 'Server = https://archive.archlinux.org/repos/2026/10/20/$repo/os/$arch' \
      > /etc/pacman.d/mirrorlist \
 && pacman -Syyuu --noconfirm \
 && pacman -S --noconfirm --needed base-devel git \
 && pacman -Scc --noconfirm

Move the date forward on a schedule in a reviewed change; a snapshot pinned for months is a known vulnerable base.

Arch, Debian, Fedora and Alpine compared

The biggest practical difference is where a fix lands. Debian backports a fix into the same upstream version with a +deb13u1 style suffix; Arch ships the next upstream release, which makes version matching simple but brings feature changes with every security update. For the other three, see the sibling posts on Debian, Fedora and Alpine.

Common mistakes

• Treating the ISO date as the system version. A machine installed from 2026.01.01 and upgraded yesterday is as current as one installed from 2026.10.01. One never upgraded since installation is nine months behind.
• Running pacman -Sy package. That is a partial upgrade. Use pacman -Syu package.
• Fixing signature errors with SigLevel = Never. Update archlinux-keyring and fix the clock instead.
• Using TrustAll for a third party repository. Import its key, check the fingerprint with pacman-key --finger, and locally sign only that key with pacman-key --lsign-key.
• Leaving IgnorePkg entries for months. Each one is a package that stops receiving fixes.
• Mixing archive snapshots with live mirrors. Use one or the other, never both.
• Building AUR packages without reading them, including on updates and after a maintainer change.
• Assuming the security tracker is complete. Its own team's wiki page says it is not currently updated.
• Skipping the news before a big upgrade. Manual interventions are announced there.

FAQ

Does Arch Linux have version numbers?

Not for the system. Arch is a rolling release with only one current state. Names such as 2026.10.01 belong to the monthly installation image, a snapshot of the installer that stops describing your system once you upgrade.

How often is a new Arch Linux ISO released?

About once a month, usually on the first. The release list shows twelve images a year from 2013, occasionally thirteen. The current image on 24 October 2026 is 2026.10.01 with Linux 7.2.7.

When was Arch Linux first released?

Arch Linux 0.1 came out in March 2002: 11 March according to the ArchWiki, 12 March according to the official release list. Judd Vinet began work in early 2001.

How do I fix "signature is invalid" errors in pacman?

Check the clock, then run sudo pacman -Sy --needed archlinux-keyring && sudo pacman -Su. Delete corrupt cached packages from /var/cache/pacman/pkg/. As a last resort, remove /etc/pacman.d/gnupg and rerun pacman-key --init and pacman-key --populate. Do not disable signature checking.

Is archinstall the official Arch Linux installer?

It is an official package and has shipped on the installation medium since 1 April 2021 as a guided alternative to the manual installation guide. It uses different defaults, and its profiles are not supported by package maintainers.

How do I verify an Arch Linux ISO?

Download the .sig from archlinux.org, fetch the release key over WKD (sq network wkd search pierre@archlinux.org or the GnuPG equivalent), verify with sq verify or gpg --verify, and check the fingerprint against the release list. A checksum alone does not prove authenticity.

How do I downgrade a package on Arch Linux?

Install the older file from /var/cache/pacman/pkg/ or from archive.archlinux.org/packages/ with pacman -U, then hold it with IgnorePkg until a fix arrives.

Are AUR packages safe?

They are not vetted. The ArchWiki says use is at your own risk, and Arch announced an active malicious packages incident in the AUR on 12 June 2026. Read the PKGBUILD and any install script before every build.

Does Arch Linux publish security advisories?

Yes, as ASAs on security.archlinux.org and the arch-security list, but none were published between June 2025 and October 2026, and the security team's wiki page says the tracker is not currently updated. Most fixes arrive as ordinary upgrades.

Is Arch Linux suitable for servers?

It can be if you accept frequent full upgrades, reading the news and no long term support branch. For Arch based build hosts or containers, pin to archive snapshots and move the date on a schedule.

Where Safeguard fits, honestly

Safeguard does not manage pacman, verify the archlinux-keyring, review AUR PKGBUILDs or replace the Arch security tracker; the steps above are the right tools for that. The fit is one layer up. An Arch workstation or build host is where developers build software that pulls in npm, PyPI, Maven, Go and container dependencies pacman never sees. Safeguard scans repositories, container images and SBOM files for those dependencies, matches them against vulnerability databases, ranks findings with reachability analysis and can open fix pull requests, which ship switched off by default.

A rolling distribution keeps the operating system current every week, but it does nothing for the lockfiles and images your projects carry, which age at their own pace. That is why software supply chain hygiene still matters on an Arch machine, even though the fit with the operating system itself is indirect.

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

None of these demos touches pacman or the Arch keyring; they show the dependency and image side of the work you do on an Arch machine.

The first demo sets up the Safeguard runner on your own machine: install it, approve it with a device code, then scan from the terminal. On an Arch workstation or build host, that is how you would scan the repositories and images you build there.

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

The second demo is a real CLI session. You ask the assistant to fix a lodash CVE; 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, and pushes nothing. The same flow applies to any project checked out on an Arch laptop: pacman keeps the OS current, and this keeps the project's dependencies current.

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 shows how you choose which Safeguard tools Claude can use, so an assistant can query your findings instead of guessing.

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

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Arch Linux (ArchWiki): principles and history
• Arch Linux release list
• Arch Linux release list, JSON
• Arch Linux download page and verification instructions
• Arch Linux news archive
• pacman 4 moves to core (16 January 2012)
• systemd is now the default on new installations (13 October 2012)
• GnuPG 2.1 and the pacman keyring (8 December 2014)
• Phasing out i686 support (25 January 2017)
• The end of i686 support (8 November 2017)
• Now using Zstandard instead of xz for package compression (4 January 2020)
• The future of the Arch Linux project leader (24 February 2020)
• Installation medium with installer (1 April 2021)
• Git migration completed (21 May 2023)
• The xz package has been backdoored (29 March 2024)
• Manual intervention for pacman 7.0.0 and local repositories required (14 September 2024)
• Recent service outages (21 August 2025)
• Active AUR malicious packages incident (12 June 2026)
• Arch Linux Master Signing Keys
• pacman/Package signing (ArchWiki)
• archlinux-keyring repository and README
• archinstall (ArchWiki)
• Installation guide (ArchWiki)
• System maintenance (ArchWiki)
• Arch Linux Archive (ArchWiki)
• Downgrading packages (ArchWiki)
• Arch Linux Archive
• Arch User Repository (ArchWiki)
• Arch Security Team (ArchWiki)
• Arch Linux security tracker
• Arch Linux security advisories
• arch-audit(1) man page
• Arch Linux RFC index
• RFC 0001: Using RFCs
• RFC 0002: x86-64-v3 microarchitecture port
• RFC 0011: Store source signing keys
• RFC 0014: Merge package repositories
• RFC 0017: Increase fortification level
• RFC 0059: Automated digital signing of OS artifacts
• Arch Linux container image documentation
• Debian security FAQ
• Debian releases
• snapshot.debian.org
• Fedora Linux release life cycle
• Fedora security and verification
• Alpine Linux release branches

Last reviewed: 24 October 2026. Arch is a rolling release, so ISO versions, package versions and keyring releases change every month; check the Arch news page and release list before acting on any version in this post.