Void Linux Release History: Rolling Release, runit, XBPS, musl

Void Linux has no version numbers. It is an independent rolling release distribution, written from scratch rather than forked, that ships packages continuously from its void-packages repository and publishes dated live images (the current set is 20250202) only as convenient starting points. It uses runit as init and service supervisor, its own XBPS package manager with RSA signed repositories, and offers every architecture except i686 in both glibc and musl editions.

That makes Void's "release history" different from Debian's or Ubuntu's. There is no list of releases with end of support dates, because there is only one release: the current state of the repository. What does have a history is the project itself (founded in 2008, through a leadership crisis in 2018 and a founder's departure in 2020), the toolchain and init choices it made and sometimes reversed, and the image sets it promotes to current every year or two. This post walks through all of it, with every date checked against the Void news archive or the Void Handbook, then shows how to verify an image, install, enable services, update safely and check what XBPS trusts.

Key takeaways

• One release, always moving. The Void Handbook calls Void "an independent, rolling release Linux distribution, developed from scratch rather than as a fork", focused on "stability over bleeding-edge". There are no point releases or support windows.
• Images are dated snapshots. The current set is 20250202, announced 2 February 2025. Older sets stay under /live/ on every mirror. The first xbps-install -Su brings any install to the current repository state.
• Void started on systemd. On 29 July 2014 runit replaced systemd as the default init. The Handbook says runit is what lets Void support musl, "which would not be possible with systemd".
• Both libcs everywhere except i686. musl builds arrived in January 2014 and the first musl images in June 2015. x86_64, aarch64, armv7l and armv6l have glibc and musl editions; i686 is glibc only.
• Two crypto reversals. LibreSSL became the default in August 2014; Void switched back to OpenSSL on 5 March 2021.
• 2018 was the governance turning point. The project leader became unreachable, taking control of the GitHub organisation, IRC and domains with him. The project moved to github.com/void-linux and voidlinux.org, and the old voidlinux.eu domain later fell to an unknown third party.
• Image signing changed twice. PGP gave way to signify with the 20191109 set and to minisign with the 20230628 set, each with a key valid for one image date. Repositories are signed separately with RSA keys.
• No advisory feed, no automatic restarts. Fixes arrive as new package versions. XBPS never restarts services by policy, so xcheckrestart belongs in every update routine.

This post extends our release history series for independent and rolling distributions. For the closest siblings, see Arch Linux release history, Alpine Linux release history, Gentoo release history and Slackware release history.

Where Void Linux came from, and why it is not a derivative

Void began in 2008. The project's own site still carries the line "Copyright 2008-2018 Juan RP and contributors" in the footer of every news post, alongside the current copyright for the Void Linux contributors. Juan RP, who used the handle xtraeme, wrote XBPS and led the project for its first decade.

The word "independent" is doing real work. Most Linux distributions start from another distribution's packages and change the defaults. Void did not. The project home page puts it bluntly under the heading "Not a fork!": Void "is not a modification of an existing distribution" and its "package manager and build system have been written from scratch." Three pieces are original to Void:

1. XBPS, the X Binary Package System, the package manager. The XBPS README describes it as "designed and implemented from scratch" and released under a two clause BSD license.
2. xbps-src, the build system that turns source templates into binary packages, also written from scratch under the same license.
3. void-packages, the single Git repository of templates from which every official binary package is built.

Everything else, from the kernel and C libraries to runit itself, is upstream software packaged by Void. The independence is in how the system is built, signed and updated. (The name, the Handbook says, "comes from the C literal void" and "is void of any meaning.")

What independence means for security work

An independent distribution has no upstream distribution to inherit fixes from. When a vulnerability is fixed in OpenSSL or in the kernel, the fix reaches Void users only when a Void maintainer updates the template in void-packages, the build servers build it, the packages are signed and the mirrors sync. No other distribution's security team stands behind it. The rolling model usually ships new upstream versions quickly, but it changes the question you ask. Not "is this release still supported", but "is my system current, and is what is running the same as what is installed".

The early years: systemd, runit, musl and LibreSSL (2012 to 2016)

The news archive goes back to October 2012, and its early entries show a distribution that looks quite different from today's Void.

Void ran systemd first. The 16 November 2012 post "Full switch to journald" says base-system 0.67 dropped its syslog daemon and logrotate dependencies because that functionality "is already provided by systemd's journald."

XBPS matured quickly. Through 2013 and 2014 the archive shows a new repository format in XBPS 0.25, then RSA signed remote repositories, which the XBPS README marks as "NEW in 0.27", then releases 0.28 to 0.41 in about a year.

musl arrived in January 2014. The 9 January 2014 post "xbps-src: building packages against the musl C library" announced that xbps 0.29 and xbps-src v96 could build for musl, natively or with a Void cross compiler, and asked users to "fix/report portability problems to their respective developers." That is still Void's musl policy.

runit replaced systemd in July 2014. The 29 July 2014 post "runit enabled by default" said runit "is small, portable and perfect for our needs" and that "All images have been switched to runit". systemd stayed optional for a while through base-system-systemd; current Void has no systemd base.

LibreSSL became the default a week later. The 6 August 2014 post "LibreSSL enabled by default" said the OpenBSD maintained fork would "help to not repeat the infamous heartbleed."

The first musl images shipped in June 2015, served from repo.voidlinux.eu, a domain that matters later (announcement). aarch64 became official on 17 September 2016, after a port that began with a cross compiled base system in March 2015, with packages "officially provided (both for glibc and musl)" (announcement).

The 2018 leadership transition and the move to new infrastructure

On 1 May 2018 the core team published "Serious Issues". It said the project leader "has disappeared", with no contact since the end of January and "no meaningful contact for well over a year". On its own that would not threaten the project. The problem was that three central resources had been managed exclusively by that one person:

• the Void Linux GitHub organisation,
• the IRC channels,
• the domains, including voidlinux.eu, the most used one.

The post said GitHub had "declined any help to regain access to the organisation", that the team had regained partial control of voidlinux.com but not voidlinux.eu, and that the plan was to move to a new GitHub organisation and a new domain. It ended with the lesson the team took from it: "In future no single person will have exclusive access to Void's resources."

What followed is all in the news archive. The IRC channels were recovered the next day with help from freenode support (2 May 2018). On 3 June the team announced that the GitHub organisation would move to github.com/void-linux on 15 June 2018 and that repositories would be repointed from voidlinux.eu to voidlinux.org (announcement). On 1 September 2018 all Void managed mirrors moved to new primary addresses, with the defaults updated in the xbps package (post). On 12 February 2019 the project warned that voidlinux.eu had lapsed and been bought by an unknown third party, and that anything involving it "should be considered potentially malicious" (post). Finally, on 24 April 2020, a maintainer wrote that Juan RP "has chosen to leave the Void Linux project" and that the project would "continue as it has" (Some Context for Recent Events).

That post also lists, among past breakages, "Pushing a musl update with no coordination", and explains that on musl, updating the C library can mean "recompiling almost everything" because, unlike glibc's usual ABI compatibility, "musl is different." It adds that users cannot update during large rebuilds "because that would install incompatible versions of some libraries", the partial upgrade problem covered below.

Why the domain story matters to you

This is a textbook case of a project losing a name users had hard coded. Any system still configured for repo.voidlinux.eu after the domain lapsed pointed at a host the project did not control. Two things limited the damage. XBPS requires remote repositories to be signed, so a stranger's index would fail verification unless the user accepted an unknown key at the import prompt. And the project told users, repeatedly and plainly, to change their mirrors.

The lesson for 2026: check xbps-query -L on long lived systems and images, and if anything still points at voidlinux.eu, change it. The mirrors page in the Handbook lists the current official mirrors, and repo-default.voidlinux.org is the default.

How a rolling release with dated images works

On a fixed release distribution, an ISO is a release. On Void, an ISO is a snapshot of the repository on the day it was built, with an installer added.

The download page and the installation chapter of the Handbook describe the layout:

• The newest images and root filesystem tarballs live at https://repo-default.voidlinux.org/live/current/.
• "Previous releases can be found under https://repo-default.voidlinux.org/live/, organized by date."
• Each image directory carries a sha256sum.txt file of checksums and a sha256sum.sig signature over that file.

Images come in several shapes:

• Live ISOs for x86_64 and i686, in a base flavour and an Xfce flavour. You can log in as anon or root with the password voidlinux and run void-installer. The installer offers a local install from packages on the ISO or a network install from a mirror. The download page warns that to get the Xfce desktop you must choose the local option, not "install from network".
• Live ISOs for UEFI arm64 devices, including Apple Silicon, where void-installer is not supported.
• Root filesystem tarballs for every architecture and both libcs, for chroot installs and containers.
• Platform images for Raspberry Pi boards, ready to write to an SD card.
• OCI container images, which since August 2023 live at ghcr.io/void-linux/void-glibc, void-musl, and the -full and -busybox variants.

An image set is "promoted to current" when the team is happy with it, and then never changes while the repository moves daily. A system installed from 20250202 in October 2026 starts twenty months behind, so its first full update is large.

When the gap causes trouble

Usually a full update from an old image just works. The exceptions are announced on the news page:

• Repository data compression. The Handbook's common issues page says that "In March 2020, the compression format used for the repository data (repodata) was changed from gzip to zstd." An XBPS older than 0.54, released in June 2019, cannot read the new index at all and gives no clear error. The fix is the static XBPS binary.
• XBPS updates itself first. The XBPS chapter says XBPS "must use a separate transaction to update itself. If your update includes the xbps package, you will need to run the above command a second time".
• glibc 2.38 and libxcrypt. The 4 January 2024 post "glibc 2.38 Update Issues and Solutions" explains that glibc 2.38 stopped providing libcrypt.so.1, and that "some kinds of partial upgrades can leave PAM unable to function", breaking sudo, doas, su and logins. Void fixed it by making glibc-2.38_3 depend on libxcrypt-compat.
• Firmware compression. The 10 March 2026 post "Changes to linux-firmware may require manual intervention" says firmware is now zstd compressed from linux-firmware-20260309_1, and lists the minimum kernel package for each series (for example linux6.6>=6.6.68_1 and linux6.12>=6.12.7_1, or linux6.18, linux6.19 and later). If you cannot run one of those, the post shows how to hold the firmware packages.

The image release history

The news archive records each image promotion. Not every set got its own post, and the early ones were not tied to a date stamped directory name in the announcement, so the table below lists what the posts themselves say.

Sources: 2015, 2018, 2020, 2021, 2022, 2023, 2024, 2025.

As of 25 October 2026 the download page still lists 2025-02-02 for every architecture. The distribution has not stalled; the packages behind those images keep moving.

The full timeline: project, toolchain and infrastructure

Sources for each row are linked in the sections above and listed under Sources.

XBPS, xbps-src and void-packages

XBPS: the package manager

The XBPS chapter of the Handbook lists the tools you use day to day:

The XBPS README lists the features that matter for integrity: SHA256 hashes "for package metadata, files and binary packages", package states "to mitigate broken package installs/updates", and the "Ability to check for incompatible shared libraries in reverse dependencies". That last one is the reason Void can run a rolling release without a separate testing branch. Every package records the shared library sonames it provides and needs, and XBPS refuses a transaction that would leave an installed package needing a soname nothing provides.

You see that check as an error. The common issues page gives the two forms. "broken, unresolvable shlib" usually means outdated or orphaned packages on your system. "Transaction aborted due to unresolved shlibs" means "the repositories are in the staged state, which can happen due to large builds. The solution is to wait for the builds to finish."

xbps-src and void-packages

Every official package starts life as a template in void-packages. Its README describes xbps-src as a script that will "fetch and compile the sources, and install its files into a fake destdir to generate XBPS binary packages". The Void home page adds that xbps-src "builds the software in containers through the use of Linux namespaces" with "No root required!", and can build natively or cross compile, for glibc and musl.

The README is explicit that xbps-src "does not allow building as root anymore", and that it needs a chroot method to bind mount directories into a masterdir, the clean build root. In January 2024 the project changed how masterdirs are created; the archive entry "Changes to xbps-src Masterdir Creation and Use" records it.

How packages get from a commit to your machine

The 11 February 2023 post "New Repo: Fastly CDN" is the best public description of Void's build and signing pipeline. In summary, as of that post:

1. A central build controller dispatches builds to servers that own specific architectures. At the time, one server built x86_64, i686, armv6l and armv7l; another built aarch64 and aarch64-musl; a third built x86_64-musl, armv6l-musl and armv7l-musl.
2. Each build server drives a standard Git checkout of void-packages and writes binary packages under /hostdir/binpkgs.
3. Packages are aggregated onto one host and then "they can be signed", a step handled by a Nomad managed batch task.
4. Signed packages go to a "shadow repo" that end users cannot reach. During large builds that would break user systems, the team disconnects downstream mirrors from the shadow repo so users can keep installing and updating existing packages.
5. Tier 1 mirrors operated by Void sync from the shadow repo; all other mirrors sync from tier 1.

The 24 October 2023 post "Changes to Repository Sync" simplified this: the shadow repo moved to the glibc builder, two rsync hops were removed, and sync switched from timers to lsyncd under Nomad. The 29 September 2024 post "Goodbye, Python 2! Hello, New Buildbot!" records the build controller moving from buildbot 0.8.12, "released on 21 April 2015 and using Python 2", to buildbot 4.0. You can watch builds at build.voidlinux.org.

How XBPS signs and verifies packages

Signing works at two levels.

Repository index. The Handbook's repositories page says a repository contains binary package files, "which may have signatures, and a data file named $ARCH-repodata (e.g. x86_64-repodata), which may also be signed", and states the rule: "while local repositories do not require signatures, remote repositories must be signed."

Keys and trust on first use. The signing page says the signing key "needs to be a PEM-encoded RSA key", added once to the repository metadata with xbps-rindex --sign, after which each package is signed with xbps-rindex --sign-pkg. On the client side, the common issues page shows what happens when XBPS sees a repository key it does not know: it prints that the repository "has been RSA signed by" a named signer, shows the fingerprint and asks "Do you want to import this public key?" The Handbook's instruction is to "ensure the fingerprint matches one of the fingerprints in both void-packages and void-mklive" before saying yes.

It is the SSH host key model. Official images already trust Void's key; the prompt appears when you add a repository, when Void rotates a key, or when someone serves you a repository signed with a key you have never seen. In the last case the answer is no.

Image verification is separate. Repository signatures protect packages. Image signatures protect the ISO you started from, which is the one piece of software you run before XBPS has any trust relationship. Void changed that mechanism twice:

Per release keys limit the blast radius of any single key. A key that signed the 20240314 images cannot vouch for a 20250202 image, and the trusted comment printed by minisign says so.

XBPS releases worth knowing

Three XBPS releases still matter, because old images and long untouched systems hit them:

• 0.54 (June 2019). The minimum version that can read zstd compressed repodata, per the Handbook.
• 0.58 (30 January 2020). A rewritten dependency resolver, ignorepkg to drop packages that other packages pull in, noextract to skip files such as translations, and a download only flag. (announcement)
• 0.60 (14 June 2025). The release notes say scripts now run before and after unpacking all packages, "to avoid running things in a half unpacked state", and that XBPS now exits with ENODEV (19) when a held dependency would break an install or update, instead of ignoring it and leaving an inconsistent package database.

runit: init and service supervision

runit, written by Gerrit Pape, describes itself as "a cross-platform Unix init scheme with service supervision". It runs as process 1 and boots, runs and shuts down the system in three stages:

1. Stage 1 runs /etc/runit/1 for one time initialisation and waits for it to finish.
2. Stage 2 runs /etc/runit/2, which "should not return until the system is going to halt or reboot". Normally that starts runsvdir, which supervises every enabled service.
3. Stage 3 runs /etc/runit/3 for shutdown tasks.

The runit site says it is "optimized for reliability and small size. The amount of code in process no 1 should be minimal."

How Void uses runit

The services chapter of the Handbook gives the reasons Void chose it: a small code base "easier to audit for bugs and security issues"; a clean process environment for every service "regardless of how the service was started or restarted"; and a log service that "stays up as long as the relevant service is running".

The moving parts are files and symlinks:

• Service directories live in /etc/sv/. Each needs one executable, run, which must exec the daemon in the foreground. Optional files are check (exit 0 means the service is available), finish (runs on stop), conf (environment variables sourced by run) and a log directory whose own run receives the service's output.
• runsvdirs live in /etc/runit/runsvdir/. Void ships default and single; /var/service is a symlink to whichever one is running.
• Enabling a service means symlinking it into /var/service/. Disabling means removing the symlink. A file named down in the service directory keeps an enabled service from starting at boot.
• Controlling a service uses sv up, sv down, sv restart, sv status and sv once.

One rule in the Handbook catches people: to change a service, copy its directory to a new name first, because otherwise "xbps-install(1) can overwrite the service directory". Configuration that only needs flags belongs in the conf file, which packages do not overwrite.

runit compared with systemd and OpenRC

This table compares approaches using each project's own documentation (the Void Handbook and runit site, the systemd.service manual and the OpenRC user guide). It is not a ranking.

The security relevant difference is not which is "better". It is that runit on Void deliberately does very little. There is no socket activation, no automatic restart on update and no central daemon reading unit files. That means fewer moving parts, and also more responsibility on you, which the update walkthrough below makes concrete.

musl and glibc: two editions of the same distribution

Which architectures get which libc

The installation chapter says Void "is available on x86_64, i686, aarch64, armv7l, and armv6l architectures. Both glibc and musl editions are available on all architectures except i686, where only glibc is available." It is not available for i386, i486 or i586.

Repository paths differ by libc and architecture. The repositories page gives them relative to a mirror: glibc at /current, musl at /current/musl, aarch64 and aarch64-musl at /current/aarch64. The optional sub repositories are nonfree, multilib (32 bit libraries, x86_64 glibc only), multilib/nonfree and debug. The musl page adds that musl has nonfree and debug sub repositories "but no multilib sub-repo".

Why Void offers musl at all

The musl project describes its library as "an implementation of the C standard library built on top of the Linux system call API" that is "lightweight, fast, simple, free, and strives to be correct in the sense of standards-conformance and safety." The Void Handbook's About page says musl "has first class support", which "allows us to build certain components for musl systems statically, which would not be practical on glibc systems."

The project's commitment goes further than shipping a second set of binaries. The home page says Void supports both libcs by "patching incompatible software when necessary and working with upstream developers to improve the correctness and portability of their projects."

What breaks on musl

The Void musl page is direct: "musl practices very strict standards compliance. Many commonly used platform-specific extensions are not present." It names proprietary software, which "usually supports only glibc systems", and specifically says the proprietary NVIDIA drivers "do not support musl". Its workaround for glibc only software is a glibc chroot, or a Flatpak where one exists.

The musl wiki's "Functional differences from glibc" explains the runtime differences that bite most often:

For supply chain work, two consequences matter. Prebuilt binaries from language package managers (Python wheels, Node native modules, release tarballs) are often glibc only, so on musl they fail or get built from source, which changes what you actually run. And a musl update can mean rebuilding most of the repository, so never mix a newer musl with older packages.

Security on a rolling distribution without advisories

We could find no numbered security advisory feed on the Void site or in the Handbook, whose security section covers hardening such as AppArmor. The news page posts only when an update needs manual action, such as the 20 February 2020 OpenSSH 8.2 notice: sshd had to be restarted "or it will not accept new ssh connections", and the project restated its policy of not restarting or enabling services during updates.

That leaves three practical sources of truth:

1. Upstream advisories. The musl home page, for example, lists advisories by affected release range at the top.
2. The void-packages history. Every version bump is a commit in void-packages, which shows when a fixed version landed.
3. Your installed versions. xbps-query -p pkgver shows what is installed; xcheckrestart shows whether the running process matches it.

So the plan is a cadence: update often, read the news before large updates, restart what changed, and keep an inventory of what your hosts and images contain so you can answer "where are we running this" in minutes.

Step by step: verify, install, enable services, update and check signatures

The commands below follow the Handbook. Replace dates and device names with your own.

1. Download and verify an image

Download the image, sha256sum.txt and sha256sum.sig from the same dated directory. Then verify the signature over the checksum file with the release key, and the image against the checksum file:

# On a Void system, the release keys come from a package you already trust
sudo xbps-install -S minisign void-release-keys

minisign -V -p /usr/share/void-release-keys/void-release-20250202.pub \
  -x sha256sum.sig -m sha256sum.txt
# Expect: Signature and comment signature verified
# Trusted comment: This key is only valid for images with date 20250202.

sha256sum -c sha256sum.txt --ignore-missing
# Expect: void-live-x86_64-20250202-base.iso: OK

On another operating system, get the .pub key from the void-release-keys files in Void's Git repository, as the Handbook describes, rather than from the same mirror as the image. The Handbook's instruction if either check fails: "do not use it!"

2. Write the image to a USB drive

Writing an image destroys everything on the target device. Check the device path first, every time.

# Identify the USB drive. Confirm size, model and that nothing on it is mounted.
lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS

# Only after confirming /dev/sdX is the USB drive and not a system disk:
sudo dd if=void-live-x86_64-20250202-base.iso of=/dev/sdX bs=4M status=progress conv=fsync

3. Install

Boot the live image, log in as root with password voidlinux, and run:

void-installer

Choose glibc or musl by choosing the image; the installer does not switch libc. If you want Xfce from the Xfce image, pick the local install source. Since the 20250202 images, the installer offers a post installation menu to enable services.

4. Confirm what you installed

xbps-uhelper arch          # for example x86_64 or x86_64-musl
xbps-query -L              # configured repositories and their signing status
ls /var/db/xbps/keys/      # repository public keys XBPS trusts

Check that every repository in xbps-query -L is on a current official mirror and none points at voidlinux.eu.

5. Update the system

sudo xbps-install -Su      # sync indexes and update everything
sudo xbps-install -Su      # run again if the first run updated xbps itself

Before a large update, read voidlinux.org/news. If XBPS reports "Transaction aborted due to unresolved shlibs", stop and wait for builds to finish. Do not force it.

To preview without changing anything:

xbps-install -Sun          # -n is a dry run: list what would be updated

6. Restart what changed

xcheckrestart              # from xtools; run as a normal user
sudo sv restart sshd       # restart each listed service
uname -r; xbps-query -p pkgver linux   # reboot if the running kernel is older than installed

7. Enable and test a service with runit

# Test once before enabling at boot
sudo touch /etc/sv/sshd/down
sudo ln -s /etc/sv/sshd /var/service/
sudo sv once sshd
sudo sv status sshd

# If it works, let it start at boot
sudo rm /etc/sv/sshd/down

To disable: sudo rm /var/service/sshd.

8. Check package integrity and signatures

sudo xbps-pkgdb -a         # check all installed packages against recorded hashes
xbps-query -RS openssl     # metadata of the repository version of a package

If XBPS ever prompts to import a new RSA key, compare the printed fingerprint against the fingerprints published in both void-packages and void-mklive before answering. If they do not match, answer no and find out why.

9. Hold or roll back a package when you must

sudo xbps-pkgdb -m hold linux-firmware   # stop a package from updating
sudo xbps-pkgdb -m unhold linux-firmware

The advanced usage page shows downgrades from /var/cache/xbps/ with xdowngrade or xbps-install -R /var/cache/xbps/ -f. A hold is a temporary measure, not a security policy; a held package receives no fixes.

10. Containers

Use the current image names, not the pre 2023 ones:

docker pull ghcr.io/void-linux/void-glibc
docker pull ghcr.io/void-linux/void-musl

The August 2023 post maps old names to new ones and notes that the old voidlinux/voidlinux image was two years out of date at the time. Rebuild derived images regularly and run xbps-install -Syu in the build so the container is not frozen at its base image date.

Common mistakes

• Treating the ISO date as the system's age. A system installed from 20250202 and updated weekly is current. A container built from an old base and never updated is not, whatever its tag says.
• Forcing through partial upgrade warnings. "Transaction aborted due to unresolved shlibs" means a large rebuild is in progress. Updating one package on its own, such as glibc, is how some systems lost PAM in January 2024. Wait, then run a full xbps-install -Su.
• Mixing musl and glibc binaries. Copying glibc built binaries onto a musl system, or pointing it at glibc repositories, fails in confusing ways; a repodata "Not Found" error usually means the wrong repository for your system. Use a glibc chroot instead.
• Forgetting to restart services. XBPS will not do it. After an OpenSSL or OpenSSH update, old code keeps serving traffic until you restart. Run xcheckrestart after every update.
• Editing service directories in place. An update can overwrite them. Use the conf file or a copy under a new name.
• Skipping the news page. Void posts only when manual action is needed, and the 2020 OpenSSH, 2024 glibc and 2026 firmware changes were all announced in advance.
• Accepting unknown repository keys without checking the fingerprint against void-packages and void-mklive.
• Leaving voidlinux.eu in configuration. It has belonged to someone else since 2019.
• No plan for advisories. Without a Void advisory feed you need your own inventory of what runs where and a habit of watching upstream advisories.
• Using pip against the system Python. Since October 2023 it is marked externally managed; use a virtual environment or pipx, as the Python post explains.

FAQ

What is the latest version of Void Linux?

There is no version. Void is a rolling release, so the latest Void is whatever is in the repository today. The newest installation image set is 20250202, announced on 2 February 2025, and the download page still lists it as current as of 25 October 2026.

Is Void Linux based on Arch or Debian?

No. The project says Void is "not a modification of an existing distribution" and that its package manager and build system "have been written from scratch." It is independent.

When was Void Linux created and by whom?

Void began in 2008. The site footer credits "Juan RP and contributors" for 2008 to 2018. Juan RP (xtraeme) wrote XBPS and led the project until 2018, when the core team lost contact with him; the project announced his departure in April 2020.

Does Void Linux use systemd?

No. Void used systemd components until July 2014, when runit replaced systemd as the default init and service supervisor. The Handbook says runit is what allows Void to support musl, which would not be possible with systemd.

Should I choose the musl or glibc version of Void?

Choose glibc if you need proprietary software, the proprietary NVIDIA driver, 32 bit multilib, or prebuilt binaries from language package managers. Choose musl if you want a smaller, stricter C library and can live with patching or chrooting the occasional glibc only program. i686 is glibc only.

How do I verify a Void Linux ISO?

Download sha256sum.txt and sha256sum.sig from the same dated directory, verify the signature with minisign -V and the release specific public key from the void-release-keys package or Void's Git repository, then check the image with sha256sum -c sha256sum.txt --ignore-missing.

How do I update Void Linux?

Run sudo xbps-install -Su. If the update includes XBPS itself, run it a second time. Then run xcheckrestart and restart any listed services, and reboot if the kernel changed.

Does Void Linux publish security advisories?

Not as a numbered advisory feed. Fixes arrive as updated packages in the rolling repository, and the news page covers updates that need manual action. Track upstream advisories for the components you depend on and check installed versions with xbps-query.

How are Void packages signed?

Remote repositories must be signed with a PEM encoded RSA key using xbps-rindex. XBPS verifies the repository data and package signatures, and asks you to confirm the fingerprint of any new repository key, which you should check against the fingerprints published in void-packages and void-mklive.

Where Safeguard fits, honestly

Safeguard does not replace Void's package signing or your xbps-install -Su routine, and we do not claim it reads the XBPS package database. Fixes for Void packages come from Void.

Where Safeguard helps is the software you put on top. A Void server or a void-glibc container usually runs an application with its own npm, PyPI, Maven or Go dependencies, pulled again on every rebuild, and those carry most of the vulnerabilities a team actually ships. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image, --sbom), shows which projects contain a given component and version, matches components against vulnerability databases with reachability analysis, and evaluates policies and gates. On a rolling distribution with no advisory feed, that inventory is the part of "where are we running this" you can answer from one place.

A Void system is rebuilt and updated constantly, and every rebuild of an application on top of it pulls its open source dependencies again, so the hygiene of those dependencies matters as much as the base system. Safeguard cannot speed up a Void package update, but it can close the gaps in the libraries and images you build and ship yourself.

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 Void build host, that is how you would scan the repositories and images you build there, such as an application image based on void-musl.

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 any command that changes something, 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 flow applies to a Node.js service running on Void, where the vulnerable dependency is in your repository rather than in an XBPS package, so the fix is a change you make and test yourself.

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 question that matters when an upstream advisory lands.

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

• Void Linux home page
• Void Linux downloads
• Void Linux news archive
• Void Handbook: About
• Void Handbook: Installation and verifying images
• Void Handbook: musl
• Void Handbook: XBPS Package Manager
• Void Handbook: Repositories
• Void Handbook: Signing Repositories
• Void Handbook: Mirrors
• Void Handbook: XBPS Common Issues
• Void Handbook: XBPS Advanced Usage
• Void Handbook: Services and Daemons, runit
• Void Handbook: Kernel
• Void Handbook: Security
• XBPS repository and README
• void-packages repository and README
• runit, by Gerrit Pape
• musl libc
• musl wiki: Functional differences from glibc
• systemd.service manual
• OpenRC user guide
• Void Handbook: Logging
• Void news: Full switch to journald
• Void news: xbps-src and the musl C library
• Void news: runit enabled by default
• Void news: LibreSSL enabled by default
• Void news: 31c3 talk
• Void news: New images, now with musl
• Void news: aarch64 support
• Void news: Serious Issues
• Void news: regained control of IRC
• Void news: GitHub Organisation is moving
• Void news: Default Repositories at new Address
• Void news: New images
• Void news: VoidLinux.eu Is Not Ours
• Void news: New images and new verification keys
• Void news: News about XBPS 0.58
• Void news: OpenSSH 8.2 requires restart of sshd
• Void news: Some Context for Recent Events
• Void news: Switching back to OpenSSL
• Void news: New Images
• Void news: Repository Signing Disruption
• Void news: New Images
• Void news: New Repo, Fastly CDN
• Void news: New Images
• Void news: Changes to Container Images
• Void news: Changes to Python 3 and pip
• Void news: Changes to Repository Sync
• Void news: glibc 2.38 Update Issues
• Void news: March 2024 Image Release
• Void news: Goodbye Python 2, New Buildbot
• Void news: February 2025 Image Release
• Void news: XBPS 0.60
• Void news: linux-firmware changes

Last reviewed: 25 October 2026. Void is a rolling release; check the Void news page and the Handbook before a large update or a new install.