Slackware Release History: 1993 to 15.0, pkgtools, GPG and Patches

Slackware is the oldest Linux distribution still maintained. Patrick Volkerding released version 1.00 in July 1993 as a cleaned up derivative of the Softlanding Linux System, and the current stable release, Slackware 15.0, shipped on 2 February 2022 and is still receiving security patches in October 2026. Fixes arrive as signed packages in each release's patches/ directory and are logged in ChangeLog.txt with a (* Security fix *) marker.

Slackware has no dependency resolver in its core package tools, on purpose, no fixed end of life calendar, a single 2003 era GPG key that signs everything, and a security process that lives in plain text files rather than a tracker. This post covers its history and version numbers, pkgtools, slackpkg and SlackBuilds.org, signing, patch delivery and support length, architectures, the 15.0 changes, and a step by step routine to verify media, apply patches and build an inventory you can audit.

Key takeaways

• July 1993 to today. Slackware 1.00 went out on 17 July 1993 (UTC) according to the original Usenet announcement; the project's own announcement page shows 16 July in US Pacific time. It grew out of fixes Volkerding made to SLS at Moorhead State University. No other distribution from 1993 is still shipping releases.
• Only one stable release is supported. A ChangeLog notice dated 3 January 2024 ended security patches for 14.0, 14.1 and 14.2 effective 1 January 2024. Slackware 15.0 is the only stable release still patched. As of 23 October 2026 the 15.0 ChangeLog carried 691 (* Security fix *) markers added since release day.
• Odd version numbers have reasons. The 1999 jump from 4.0 to 7.0 was a marketing move, and the gap between 14.2 (30 June 2016) and 15.0 (2 February 2022) was the longest in the project's history. Development happens in slackware-current, now heading toward 16.0.
• pkgtools do not resolve dependencies. installpkg, upgradepkg and removepkg handle compressed tar packages and record them in /var/lib/pkgtools/packages. slackpkg adds mirror sync and GPG checks; SlackBuilds.org adds build scripts with dependencies listed but not resolved.
• One key signs everything. The Slackware Linux Project key (ID 40102233, created 26 February 2003, expires 19 January 2038) is a 1024 bit DSA key. It signs every package, the CHECKSUMS.md5 file and the ISO images. installpkg does not verify signatures itself; slackpkg does, and you can by hand.
• Security fixes are plain text first. Each fix is a rebuilt package in patches/packages/, a ChangeLog entry naming the CVE records and a Slackware Security Advisory (SSA) mailed to the slackware-security list. There is no machine readable advisory feed.
• 15.0 modernised without changing character. PAM, elogind, Python 3, Rust, Wayland sessions and a 5.15 long term kernel arrived; the BSD style SysV init scripts stayed.

If you are comparing models, our Debian release history covers the opposite approach: published support dates, a security tracker and an LTS team. This post goes deep on the Slackware side.

Where Slackware came from

Slackware started as a fix list rather than a distribution. In 1993 Patrick Volkerding was a student at what was then Moorhead State University in Minnesota. According to the Wikipedia history of Slackware, he installed the Softlanding Linux System (SLS), the most complete Linux distribution of the day, because he needed a Lisp interpreter for a class. When a professor asked him to help install Linux on other machines, the pair applied Volkerding's notes on SLS problems to each install by hand. That took almost as long as installing SLS, so Volkerding changed the install disks to apply the fixes during installation. Those modified disks became Slackware.

Volkerding did not plan a public release. He held off expecting SLS to ship the same fixes, and when it did not he asked on Usenet whether anyone wanted "an SLS-like 0.99pl11A system". The response was strong, and with the university's permission he uploaded it. The Slackware 15.0 release notes add that his friend Brett Person, who died in 2020, urged him to put it on FTP in 1993, served as the original beta tester and was long considered a co-founder.

The date is slightly contested. Wikipedia records Slackware 1.00 as distributed on 17 July 1993 at 00:16:36 UTC, as twenty four 3.5 inch floppy images, and its editors note that the project's own announcement page shows 16 July 1993 in Pacific time. Both describe the same moment from two time zones. The mirror network still carries the very first trees: the Slackware mirror root lists a slackware-pre-1.0-beta directory last modified on 18 April 1993, and slackware-1.01, slackware-1.1.2 and onward.

Why Slackware is the oldest distribution still maintained

SLS itself stopped development within a couple of years, and other 1993 projects either became something else or stopped. Debian's own project history says it "was begun in August 1993 by Ian Murdock", a month after Slackware 1.00, so Slackware keeps the "oldest surviving" title by a few weeks. What kept it alive is personal rather than corporate: Volkerding has maintained it for more than three decades with a small core team. By 15.0 there were no discs or merchandise, and the 15.0 announcement asks for support through Patreon and PayPal.

The development model follows from that. There is no public bug tracker and no public source repository; decisions are made by Volkerding, contributions come through the core team and the LinuxQuestions.org Slackware forum, and the public record of what changed is the ChangeLog. For security work this matters: there is one place to look, and it is a text file.

Version numbers: 4.0 to 7.0, 13.37 and the long gap to 15.0

Slackware's version history has three oddities worth knowing because they confuse inventory tools and auditors alike.

The jump from 4.0 to 7.0. Slackware 4.0 shipped in May 1999 and the next release, in October 1999, was 7.0. According to the Wikipedia account, other distributions were at version 6 at the time and users read Slackware's lower number as a sign it was outdated, even though the bundled software was comparable. Volkerding bumped the number to 7 on the expectation that other distributions would soon reach it. There were never Slackware 5 or 6 releases. If an asset register shows "Slackware 5", the record is wrong.

13.37. The April 2011 release after 13.1 was numbered 13.37, a nod to "leet". It is a real release with its own trees on the mirrors.

The 14.2 to 15.0 gap. Slackware 14.2 shipped on 30 June 2016 according to its ChangeLog, and 15.0 shipped on 2 February 2022, a gap of about five years and seven months. The earlier record gap, between 14.1 (November 2013) and 14.2, was 31 months. The 15.0 release notes say the team built "over 400 different Linux kernel versions" before declaring it stable, against 34 for 14.2. The release day ChangeLog entry hoped a 15.1 incremental update would follow after a shorter cycle.

That 15.1 did not happen. The development tree now ships core packages versioned for the next major release: the slackware64-current ChangeLog records a/aaa_base-16.0 and a/pkgtools-16.0 packages, the first aaa_base-16.0 upgrade dated 29 September 2026, and the Slackware ARM project site describes a full AArch64 world rebuild with GCC 16 "in preparation for the next stable release of Slackware 16.0". There is no published release date. Slackware has always shipped "when it's ready".

What slackware-current is

slackware-current is the development branch: a single moving tree on the mirrors, slackware-current/ for 32 bit x86 and slackware64-current/ for x86_64, with its own ChangeLog. Volkerding uploads rebuilt and new packages to it as they are ready, and when the tree is declared stable it is copied to a numbered directory and a new current starts. Many users run current on desktops, but it is not a supported release in the security sense: it receives every fix because it receives every change, including library jumps that break third party builds. The 15.0 ChangeLog shows the lineage, holding current's history from the 14.2 release on 30 June 2016 to the 15.0 release entry, with stable patches stacked on top.

Slackware release timeline

Release dates below for 1.00 to 13.37 come from the Wikipedia release history table, which in turn cites the project's announcements; dates from 14.1 onward and all end of life dates for 12.0 and later were checked against the ChangeLogs on the official mirrors. Kernel versions are the release day kernels.

Releases 1.1.2, 1.2, 2.2, 2.3, 3.2, 3.3, 3.5, 3.9 and 10.1 are omitted for space; none has been patched in over a decade.

How pkgtools work

Slackware's package management is deliberately thin: a set of shell scripts called pkgtools, shipped as the a/pkgtools package, with scripts and man pages in the 15.0 source tree.

The package format

A Slackware package is a compressed tar archive of files laid out relative to /, plus an install/ directory holding two optional files: slack-desc, an 11 line description, and doinst.sh, a shell script run after the files are unpacked (most often to create symlinks or move new config files into place). The installpkg man page says it installs "*.txz (or .tbz, .tgz, .tlz)" packages, so xz, bzip2, gzip and lzma compression are all accepted.

The file name carries the metadata: name-version-arch-build.txz. In the 15.0 patches you see names like brotli-1.2.1-x86_64-1_slack15.0.txz, where 1_slack15.0 is the build number plus a tag identifying the release the patch is for. Packages from SlackBuilds.org conventionally carry an _SBo tag.

installpkg, upgradepkg, removepkg and friends

upgradepkg matters most for security work. Its man page says it installs the new package first and only then removes files that belonged solely to the old one, so libraries are replaced in place and a running system stays usable. By default it skips packages that are not installed and exact duplicates. It also warns that configuration files are not always preserved, so save anything in /etc you care about first.

The removepkg man page says it deletes only files unique to the package, after checking every other package's file list, and runs any uninstall script from /var/lib/pkgtools/douninst.sh/. The makepkg man page documents --acls and --xattrs (packages built that way need pkgtools 15.0 or later) and SOURCE_DATE_EPOCH support, which clamps timestamps for reproducible builds. The 15.0 announcement adds file locking so parallel installs cannot collide.

The package database

Every install writes a plain text record. Since 15.0 the canonical location is /var/lib/pkgtools/packages/, one file per installed package, named exactly like the package without the extension. Install scripts live in /var/lib/pkgtools/scripts/, and when a package is removed or replaced its file list and script move to /var/log/pkgtools/removed_packages/ and /var/log/pkgtools/removed_scripts/. Before 15.0 the database lived in /var/log/packages/, and the 15.0 UPGRADE.TXT points upgraders at the new path.

For supply chain purposes this database is the most useful thing on a Slackware host. Every package, official or not, appears there with its exact version and build tag, and listing the directory gives you a complete installed package inventory in one command. It is not signed and not tamper evident, so treat it as an administrator's record rather than an attestation.

No dependency resolution, by design

pkgtools will install a package whose libraries are missing, and remove a library that twenty other packages need, without a warning. That is intentional. The Slackware approach is that a full installation of every package in the release is the configuration everything is tested against, and that an administrator who removes packages is expected to know what they are removing. The Slackware-HOWTO shipped with 15.0 puts the full install at about 16 GB and says "we encourage you to do a full installation for best results", adding that the A series is the one set you must install.

The upside is fast operations, no solver to break and tools short enough to read in an afternoon. The cost is that a missing shared library only shows up at runtime, and third party software has to be tracked by a person.

slackpkg

slackpkg is the official network front end (ap/slackpkg, maintained by PiterPunk per the release notes). It syncs package lists from the one mirror you choose, compares them with your package database and, with CHECKGPG=on (the default in its config), checks each package's GPG signature. The slackpkg man page documents these commands:

slackpkg update gpg      # import the Slackware GPG key from the mirror
slackpkg update          # fetch the latest package lists and ChangeLog
slackpkg check-updates   # report whether the mirror's ChangeLog has changed
slackpkg upgrade-all     # upgrade every installed official package with a newer version
slackpkg install-new     # install packages that are new in the tree (matters on -current)
slackpkg clean-system    # offer to remove packages not in the official tree

slackpkg is still not a dependency resolver. It matches package names. clean-system in particular will offer to remove everything you built yourself, because those packages are not in the official tree, so a blacklist entry for your own tag (for example [0-9]+_SBo) in /etc/slackpkg/blacklist is the normal first step.

SlackBuilds.org

SlackBuilds.org (SBo) is a community repository of build scripts, not binaries, for software Slackware does not ship. Each entry is a directory with a .SlackBuild shell script, a slack-desc, a README and a .info file listing the upstream download URL, its MD5 sum and a REQUIRES line naming other SBo entries that must be built first. The SBo HOWTO describes the flow: download the script tarball and the source, check the source against the .info checksum, run the script as root, and install the resulting package from /tmp with installpkg.

The SBo FAQ says scripts target the latest stable release and that current is not supported, though they usually work there. It explains that automatic dependency resolution has "too many potential pitfalls", and that the project does not want to favour any third party package manager, so dependencies are noted in the .info and README files and left to you. SBo signs its script tarballs: each has a .asc file you check with gpg --verify against the project key published at slackbuilds.org/GPG-KEY. That signature covers the script, not the upstream source; the source is checked only against the MD5 sum in the .info file.

From a supply chain point of view, an SBo package is software you built from an upstream tarball on your own machine. Its security fixes come from you rebuilding it after the SBo maintainer updates the script, not from Slackware's patches/ directory.

How packages and ISOs are signed

The key

Slackware signs with a single OpenPGP key. The GPG-KEY file in every release tree identifies it as 1024D/40102233, user ID "Slackware Linux Project" with the address security@slackware.com, created 26 February 2003, with a 1024 bit ElGamal subkey and an expiry date of 19 January 2038. The issuer fingerprint recorded in the signature on the current 15.0 checksum list is EC56 49DA 401E 22AB FA67 36EF 6A44 63C0 4010 2233. It is the same key that signs the patches, the ISOs and the security advisories, so a single key compromise or a single expiry date affects everything at once.

What is signed

Three layers are signed with that key:

1. Every package. Each .txz in the release tree and in patches/ has a detached .txz.asc signature beside it.
2. The checksum list. CHECKSUMS.md5 at the top of each tree lists the MD5 sum of every file, and CHECKSUMS.md5.asc signs that list. On the 15.0 tree both were regenerated on 23 October 2026, the same day as the latest patch upload, so the signed checksum list moves with the patches.
3. ISO images. The 15.0 ISO directory carries slackware64-15.0-install-dvd.iso (3.5 GB) with an .iso.asc signature, an .iso.md5 sum and an .iso.txt file listing contents, all dated 3 February 2022.

What the signatures do and do not cover

The scheme is consistent and old fashioned, and it is worth being exact about its limits.

• installpkg and upgradepkg do not check signatures. They install whatever file you point them at. If you download patches by hand, verifying them is your job. slackpkg verifies each package's .asc before installing as long as its CHECKGPG setting is left on, which is the default.
• The checksum list uses MD5. MD5 is not collision resistant, so a signature over an MD5 list is weaker than a signature over the files. The per package .asc signatures do not rely on MD5, so verify those rather than relying on md5sum -c alone.
• The key is 1024 bit DSA, and its signatures use SHA-1. Inspecting the current CHECKSUMS.md5.asc packet shows public key algorithm 17 (DSA) and digest algorithm 2 (SHA-1). NIST SP 800-131A Rev. 2 (March 2019) lists DSA keys below 2048 bits as disallowed for signature generation, allowed only for "legacy use" when verifying, and says SHA-1 is disallowed for signature generation outside specific protocol guidance. That guidance binds US federal systems, not a volunteer project, and it does not make any individual Slackware signature forged. It does mean the assurance is lower than a modern key would give, and a compliance team will flag it. Some hardened GnuPG configurations also refuse SHA-1 signatures, so a verification failure on a locked down build host may be a policy setting rather than a tampered file. If your environment requires modern algorithms, mirror the tree internally and re-sign or re-hash with your own key after verifying the original.
• There is no signed repository metadata with freshness. A signature proves a file came from the project's key; it does not prove you are seeing the latest set of files. A mirror that stopped syncing serves valid signatures for old packages. Compare the top date of the mirror's ChangeLog with the primary mirror before trusting "no updates".

How security fixes are delivered

The patches directory

Once a release is stable, its main slackware64/ package directory is frozen and every later change goes into patches/packages/, with sources under patches/source/. The 15.0 tree listing shows slackware64/ last modified on 2 February 2022 and patches/ on 23 October 2026. The extra/, testing/ and pasture/ directories also receive updates; for example the 21 October 2026 ChangeLog entry rebuilt a PHP 8.0 package under extra/php80/.

Kernel updates go into their own subdirectory, such as patches/packages/linux-5.15.223/, and come with instructions in the ChangeLog: rebuild the initrd, make sure lilo.conf points at the right kernel and run lilo, or run eliloconfig to copy the kernel and initrd to the EFI System Partition. The 22 October 2026 entry is a typical example. As of that entry, 15.0 had moved from its release kernel 5.15.19 to 5.15.223, and still tracks the upstream 5.15 long term branch.

ChangeLog entries and the security marker

The ChangeLog is the security feed. Each entry starts with a UTC date line, lists every changed package with its path and an action (Upgraded, Rebuilt, Added, Removed), describes the fix in a few lines, lists https://www.cve.org/CVERecord?id= links for each CVE, and ends with (* Security fix *) when the change is security relevant. Entries are separated by a +--------------------------+ rule. A typical patch entry reads like this one from the top of the 15.0 ChangeLog, dated Fri 23 October 2026:

patches/packages/patch-2.8.1-x86_64-1_slack15.0.txz:  Upgraded.
  This update fixes a security issue:
  Prevent creation of out-of-tree files.
  For more information, see:
    https://www.cve.org/CVERecord?id=CVE-2026-115207
  (* Security fix *)

The format is stable across releases and easy to parse. Counting markers above the 15.0 release entry gives 691 between 2 February 2022 and 23 October 2026. The marker is the project's own judgement, so an unmarked bug fix may still be worth applying.

The slackware-security mailing list

For each security update, the Slackware Security Team mails a Slackware Security Advisory to the slackware-security mailing list. Advisories are numbered SSA:YYYY-DDD-NN: year, day of the year, and a sequence number for that day. The public archive of the list shows the pattern clearly. The kernel advisory SSA:2026-295-01, sent on 22 October 2026 (day 295), is a typical one. It is a PGP clear signed message (the header says Hash: SHA1) that:

1. names the release it applies to ("New kernel packages are available for Slackware 15.0");
2. quotes the ChangeLog entry word for word, including the CVE links, the (* Security fix *) marker and the initrd and bootloader instructions;
3. lists download paths for every package, separately for 32 bit x86 and x86_64;
4. lists the MD5 sum of every package;
5. ends with installation instructions using upgradepkg.

The archive listed 17 advisories for October 2026 by 24 October, and between 10 and 21 a month for the five months before. When an update affects several components on one day, each gets its own sequence number (for example SSA:2026-293-04 and SSA:2026-293-06). Subscription is managed from slackware.com's mailing list page.

One honest note: slackware.com returned HTTP 403 to our scripted client for its home page, the 15.0 announcement page, the security advisories page, the mailing list page and docs.slackware.com while researching this post, so the SSA details above come from the list archive and the ChangeLogs on the official mirrors rather than from slackware.com itself. The ChangeLog is also the better feed to automate against, since it arrives first and covers every change, not only those with an advisory.

How long a release gets patches

Slackware has never published a fixed support term. Instead, end of life arrives as a notice in the ChangeLog. Four waves are on record. The first three dates come from the Wikipedia support history, which says notices appeared in the ChangeLogs; the current ChangeLogs for those trees on the mirrors no longer carry a notice at the top, but their last patch dates fit (12.0's last entry is 27 July 2012, 12.2's is 18 October 2013 and 13.0's is 19 June 2018). The fourth notice is still at the top of the 14.x ChangeLogs.

The latest notice, at the top of the 14.0 and 14.2 ChangeLogs and dated 3 January 2024, says security patches "will no longer be provided" for 14.0, 14.1 and 14.2 from 1 January 2024, notes they would all be over seven years old, and advises migrating or handling your own patches. The last 14.2 patches, in December 2023, were a sudo bug fix, a glibc-zoneinfo update and fixes for the SSH "Terrapin" issue in proftpd and libssh.

So the pattern is that a release gets patches for roughly seven years or more, overlapping with its successor, and ends without a schedule announced years ahead. Slackware 15.0 turned four in February 2026 and was still being patched in October 2026. Expect, but do not assume, that it will be supported for some time after 16.0 ships.

Architectures

The 32 bit x86 release remains a first class edition, which is now rare among general purpose distributions. The 15.0 release notes still describe its SMP and non-SMP kernel choice in detail. The Slackware ARM site reports AArch64 work on Linux 6.18 LTS and later Linux 7.x, Raspberry Pi 5 support and refreshed installer images. There is no stable AArch64 release of 15.0; ARM users run current.

What changed in Slackware 15.0

The 15.0 announcement frames the goal as "Keep it familiar, but make it modern", and the CHANGES_AND_HINTS file lists the practical fallout.

Authentication: PAM, finally. CHANGES_AND_HINTS states simply that "User authentication is PAM-based now". The announcement explains why: upstream projects Slackware depended on were dropping support for plain shadow passwords. For administrators this means /etc/pam.d/ now matters, and any locally built software that authenticates users needs to be rebuilt against PAM.

Sessions: elogind replaces ConsoleKit2. elogind is the standalone logind from the systemd project, which gives desktop software the session API it expects without adopting systemd. CHANGES_AND_HINTS notes that elogind now manages cgroups, so cgmanager, pm-utils and ConsoleKit2 were removed.

Init: unchanged. Slackware 15.0 still boots with sysvinit and the BSD style /etc/rc.d/rc.* scripts. The announcement says elogind makes it easier to support software written for the other init system, which is exactly why Slackware does not need to adopt it.

Kernel and boot. 15.0 shipped Linux 5.15.19 in two flavours: huge, with enough drivers built in to boot without an initrd, and generic, which needs one. The release notes recommend the generic kernel and point out that the installer now builds the initrd, and a new geninitrd tool rebuilds it for the latest installed kernel. UEFI is supported on x86_64, through elilo or GRUB 2 and efibootmgr. Secure Boot is not supported out of the box; the release notes say a user could enrol their own Machine Owner Key, sign kernel, modules and bootloader, and boot through shim, and that official support would be looked at for the next release.

Userland. Python 3 and Rust arrived; Qt4 left in favour of Qt5; PipeWire became available as an alternative to PulseAudio; Wayland sessions joined X11; Xfce 4.16 and KDE Plasma 5.23.5 were the desktops. Postfix replaced Sendmail as the default mail server (Sendmail moved to extra/), and Dovecot replaced the old imapd and ipop3d. Wikipedia's release table adds that the default encoding moved from ASCII to UTF-8.

Packaging and reproducibility. 15.0 included a make_world.sh script that rebuilds the whole operating system from source, and the announcement says every source was tested to build. That is not a reproducible build guarantee, but it gives an organisation that wants to rebuild Slackware under its own controls a supported path.

Slackware, Debian, Arch and FreeBSD compared

The last row is the practical difference for a security team. The Debian security pages, the Arch Linux security tracker and the FreeBSD security information page all publish advisory data that tools can match against installed versions, and Arch documents its per package signing in the pacman package signing guide. Slackware publishes human readable text with consistent structure. The rest of this post is about doing the Slackware side well.

Walkthrough: verify, patch, read the ChangeLog, inventory

The commands below assume Slackware64 15.0, run as root, with gpg, curl and md5sum available (all are in a full install). Replace the mirror URL with your nearest official mirror.

Step 1: import and check the project key

# Download the key from the release tree on an official mirror
curl -fsSLO https://mirrors.slackware.com/slackware/slackware64-15.0/GPG-KEY
gpg --import GPG-KEY

# Confirm the key ID, user ID, creation date and expiry
gpg --list-keys --keyid-format long security@slackware.com

You should see the security@slackware.com user ID on a key ending in 40102233, created 2003-02-26, expiring 2038-01-19. Compare the fingerprint, EC56 49DA 401E 22AB FA67 36EF 6A44 63C0 4010 2233, with a copy obtained another way (for example the GPG-KEY file on install media you already trust, or the key already imported on an existing Slackware machine), not just with the same mirror you are about to download from.

Step 2: verify an ISO before writing it to a USB stick

ISO=slackware64-15.0-install-dvd.iso
BASE=https://mirrors.slackware.com/slackware/slackware-iso/slackware64-15.0-iso
curl -fSLO "$BASE/$ISO"
curl -fsSLO "$BASE/$ISO.asc"
curl -fsSLO "$BASE/$ISO.md5"

gpg --verify "$ISO.asc" "$ISO"   # must report a good signature from the Slackware key
md5sum -c "$ISO.md5"              # secondary check only

Only a good GPG signature counts. A "BAD signature" result means stop; a "good signature" with a warning that the key is not certified is expected unless you have signed the key yourself.

Warning before writing the image. Writing an ISO to a USB stick destroys everything on the target device. Check the device path first and make sure it is the stick, not a disk with data on it:

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINT
# Confirm the stick by size, model and TRAN=usb; make sure nothing on it is mounted

# Replace /dev/sdX with the device you confirmed above. This erases it.
dd if=slackware64-15.0-install-dvd.iso of=/dev/sdX bs=4M status=progress conv=fsync

Step 3: check the ChangeLog for new security entries

MIRROR=https://mirrors.slackware.com/slackware/slackware64-15.0
curl -fsSL "$MIRROR/ChangeLog.txt" -o /tmp/ChangeLog-15.0.txt

# The first line is the timestamp of the latest change
head -1 /tmp/ChangeLog-15.0.txt

# Show the last ten security relevant package lines with their dates
awk '/^[A-Z][a-z][a-z] [A-Z][a-z][a-z] /{date=$0}
     /^(patches|extra|testing)\/.*\.t.z:/{pkg=$1}
     /\(\* Security fix \*\)/{print date " | " pkg}' /tmp/ChangeLog-15.0.txt | head -10

Run the same against your mirror and against the primary mirror. If the first lines differ, your mirror is stale. Keep the date of the last entry you have applied in a file, and alert when the head of the ChangeLog moves past it.

Step 4: apply patches with slackpkg

Pick exactly one mirror in /etc/slackpkg/mirrors by uncommenting its line, then:

slackpkg update gpg
slackpkg update
slackpkg upgrade-all

slackpkg lists the packages it will upgrade and lets you deselect any. Leave CHECKGPG=on in /etc/slackpkg/slackpkg.conf. If a kernel package was upgraded, follow the ChangeLog instructions before rebooting: rebuild the initrd (geninitrd on 15.0), rerun lilo if you boot with LILO, or run eliloconfig if you boot with elilo on UEFI. Skipping that step is the most common way to turn a security update into an unbootable machine.

Step 5: or apply patches by hand, verifying each one

On a host without slackpkg, or for an air gapped mirror:

mkdir -p /root/patches && cd /root/patches
# Mirror the patches directory (packages and their .asc files) over HTTPS
wget -r -np -nH --cut-dirs=3 -R 'index.html*' \
  https://mirrors.slackware.com/slackware/slackware64-15.0/patches/packages/

# Verify every package signature; stop on the first failure
for p in packages/*.txz packages/*/*.txz; do
  [ -f "$p" ] || continue
  gpg --verify "$p.asc" "$p" 2>/dev/null || { echo "BAD SIGNATURE: $p"; exit 1; }
done

# Upgrade only packages that are already installed (preview first)
upgradepkg --dry-run packages/*.txz packages/*/*.txz
upgradepkg packages/*.txz packages/*/*.txz

upgradepkg without --install-new skips packages that are not installed, which is what you want for a server that runs a reduced package set. The kernel lives in a versioned subdirectory, which is why the glob includes packages/*/*.txz; on a machine that boots the huge kernel you may not want the generic one, so review the dry run before the real run. For an air gapped site, run the download and verification on a connected host and carry the verified directory across.

Step 6: inventory installed packages

# One line per installed package: name-version-arch-build
ls /var/lib/pkgtools/packages/ > /root/inventory-$(hostname)-$(date +%F).txt
wc -l /root/inventory-*.txt

# Split into fields; the name may itself contain hyphens, so split from the right
ls /var/lib/pkgtools/packages/ | awk -F- '{
  build=$NF; arch=$(NF-1); ver=$(NF-2);
  name=$1; for (i=2;i<=NF-3;i++) name=name"-"$i;
  print name"\t"ver"\t"arch"\t"build }' > /root/inventory.tsv

# Which packages are not from the official tree?
awk -F'\t' '$4 !~ /^[0-9]+$/ && $4 !~ /_slack15\.0$/' /root/inventory.tsv

Official 15.0 release packages have a plain numeric build such as 1; patches carry _slack15.0; SlackBuilds.org packages normally carry _SBo, and anything else is local. That third list is the one nobody patches automatically.

To compare against the current patch set, build the list of package names in patches/packages/ and check whether your installed version is older:

cd /root/patches
ls packages/*.txz packages/*/*.txz 2>/dev/null | xargs -n1 basename | sed 's/\.txz$//' | sort > /root/patch-set.txt
ls /var/lib/pkgtools/packages/ | sort > /root/installed.txt

# Patch set entries not installed in that exact name-version-arch-build
comm -13 /root/installed.txt /root/patch-set.txt > /root/not-applied.txt

# Of those, which package names ARE installed (in an older build)?
sed -E 's/-[^-]+-[^-]+-[^-]+$//' /root/installed.txt | sort -u > /root/installed-names.txt
sed -E 's/-[^-]+-[^-]+-[^-]+$//' /root/not-applied.txt | sort -u | comm -12 - /root/installed-names.txt

The final list is the set of installed packages that have a newer build in patches/, which is exactly what is waiting to be applied on that host. Keep the output with the date of the ChangeLog head you checked it against.

What a hand maintained distribution means for supply chain visibility

A Slackware server is easy to reason about: a full install is a known package list from one signer, every change is in one text file, and there is no third party repository layer unless you add one. The weak spots are just as predictable.

Advisory data is not machine readable. There is no OVAL feed, no CSAF documents and no project security tracker to query by package version. Scanners that match installed packages against distribution advisories generally have no Slackware data to match against. Your options are to parse the ChangeLog as above, or to match package names and versions against upstream CVE data yourself, which brings the usual name matching problems.

Package names are not package URLs. The Package URL type index listed 42 registered types when we checked, including deb, rpm, apk and alpm (Arch), but no Slackware type. Slackware packages therefore end up as pkg:generic entries in most SBOMs, and generic entries match vulnerability data poorly. Any SBOM you generate for a Slackware host needs a clear, documented mapping from Slackware package names to upstream project names.

Built from source means you own it. Every SBo or local package is a build you did. Its upstream version, its patches and its rebuild schedule are your records, not Slackware's. On many long lived Slackware servers, the third party set is where the old, unpatched software is.

Language ecosystems are invisible to pkgtools. A pip installed Python app, a Node.js service with its own node_modules or a Java fat JAR never appears in /var/lib/pkgtools/packages, and with few language libraries packaged by the distribution, more end up installed this way.

End of life arrives by notice. Because there is no published date, it is easy for a 14.2 host to keep running after 1 January 2024 with nobody noticing that patches stopped. The only signal was a ChangeLog entry. Put the support status of each release in your asset register and review it whenever the ChangeLog head changes.

The practical answer is to treat the package database as your inventory source, export it to an SBOM format on a schedule, keep a mapping table for names, track the ChangeLog with a simple watcher, and put SBo and local builds on their own tracked list with an owner.

Common mistakes

• Running installpkg on downloaded patches without verifying them. pkgtools never check signatures. Verify each .asc or use slackpkg with CHECKGPG=on.
• Trusting md5sum -c as proof of integrity. MD5 lists are a convenience check. The GPG signature on the package, or on the ISO, is the integrity check.
• Using a stale mirror. A mirror that stopped syncing still serves valid signatures. Compare its ChangeLog head with the primary mirror.
• Upgrading the kernel and rebooting without rebuilding the initrd or rerunning LILO or eliloconfig. The ChangeLog tells you every time; read it.
• Running slackpkg clean-system without a blacklist. It will offer to remove every SBo and local package.
• Assuming 14.2 is still supported. Security patches for 14.0, 14.1 and 14.2 ended on 1 January 2024.
• Treating slackware-current as a supported release. It gets fixes quickly, but it also gets breaking upgrades without notice.
• Installing a reduced package set without tracking dependencies. A missing library will not show up until the program that needs it runs.
• Forgetting SBo packages when patching. slackpkg upgrade-all does not touch them; you must rebuild them after the SBo maintainer updates the script.
• Recording "Slackware 5" or "Slackware 6" in an asset list. Those versions never existed; check the actual /etc/slackware-version.

FAQ

When was Slackware first released?

In July 1993. The original announcement is timestamped 17 July 1993 at 00:16:36 UTC, the evening of 16 July in US Pacific time, so you will see both dates.

Is Slackware still maintained in 2026?

Yes. Slackware 15.0 received security patches on 23 October 2026, and slackware-current is moving toward 16.0.

What is the latest version of Slackware?

The latest stable release is Slackware 15.0, released on 2 February 2022 for 32 bit x86 and x86_64. Development continues in slackware-current, where core packages are already versioned 16.0. No 16.0 release date has been announced.

Why did Slackware skip from version 4.0 to 7.0?

In 1999 other distributions were numbered around 6, and users read Slackware's lower number as a sign that it was out of date. Volkerding jumped to 7.0 so that the version would not mislead. There were never Slackware 5 or 6 releases.

Is Slackware 14.2 still supported?

No. A notice in the 14.x ChangeLogs ended security patches for 14.0, 14.1 and 14.2 effective 1 January 2024. Move to 15.0, or plan to patch the software yourself.

Does Slackware have dependency resolution?

Not in its core tools, by design; a full install is the tested setup. slackpkg handles mirrors and signatures but not dependencies, and SlackBuilds.org lists dependencies without resolving them.

How do I verify a Slackware ISO?

Import the key from the GPG-KEY file, download the ISO with its .asc file, and run gpg --verify on the pair. Expect a good signature from "Slackware Linux Project" (security@slackware.com) on key 40102233. The .md5 file is only a secondary check.

Where do Slackware security updates come from?

From the patches/packages/ directory of each supported release on the official mirrors. Each update is logged in that release's ChangeLog.txt, marked (* Security fix *) and announced as an SSA on the slackware-security mailing list.

Does Slackware use systemd?

No. Slackware 15.0 still uses sysvinit with BSD style rc scripts. It ships elogind, the standalone version of systemd's logind, to provide session management for desktop software.

Does Slackware support Secure Boot or ARM?

15.0 supports UEFI on x86_64 but not Secure Boot out of the box, though the release notes describe a manual route with your own Machine Owner Key and shim. Slackware AArch64 runs in the current development tree on boards such as the Raspberry Pi 4 and 5; there is no stable AArch64 15.0 release.

Fix it without waiting for upstream

Slackware itself is maintained by its own team, and only that team can ship fixes to the packages in its tree. But most Slackware servers also run applications with their own open source dependency trees, and those are where the steps below apply; fork and patch remains early access, so check coverage before you plan around it.

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

1. Autonomous remediation: pull requests, not tickets

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

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

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

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

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

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

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

See how Safeguard would help

Safeguard does not manage Slackware hosts, does not parse ChangeLogs and does not replace slackpkg. Where it does help is with the applications and container images you build to run on those hosts, and with the dependency inventory those carry.

The local runner demo shows the runner being set up on your own machine, approved with a device code, and then used to scan from the terminal. On a Slackware build box the same flow scans an application's source directory or an SBOM file you exported from the package database, so the services you deploy get the dependency checks the base system cannot give you.

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

The CLI demo is a real session: the assistant reads a finding and its advisory, asks before each command, edits package.json to a fixed lodash version, runs the install and tests with approval and pushes nothing. The same approval flow applies to a Node.js or Python service you deploy onto a Slackware server.

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

The Claude demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude may use. Once connected, you decide which Safeguard tools Claude may call, so a question such as which of your projects carry a given library version can be asked from a chat window and answered from your own scan results.

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

• Slackware64 15.0 ChangeLog.txt (official mirror)
• Slackware64 current ChangeLog.txt
• Slackware64 14.2 ChangeLog.txt with the EOL notice
• Slackware64 14.0 ChangeLog.txt
• Slackware 12.0 ChangeLog.txt
• Slackware 12.2 ChangeLog.txt
• Slackware64 13.0 ChangeLog.txt
• Slackware 15.0 RELEASE_NOTES
• Slackware 15.0 announcement, ANNOUNCE.15.0
• Slackware 15.0 CHANGES_AND_HINTS.TXT
• Slackware 15.0 UPGRADE.TXT
• Slackware 15.0 Slackware-HOWTO
• Slackware 15.0 README_UEFI.TXT
• Slackware GPG-KEY
• Slackware64 15.0 CHECKSUMS.md5.asc
• Slackware64 15.0 release tree listing
• Slackware64 15.0 ISO directory
• Slackware mirror root with all historical trees
• installpkg(8) man page source
• upgradepkg(8) man page source
• removepkg(8) man page source
• makepkg(8) man page source
• slackpkg(8) man page source
• slackpkg.conf default settings
• slackware-security mailing list archive
• SSA:2026-295-01 kernel advisory
• Slackware ARM / AArch64 project
• SlackBuilds.org
• SlackBuilds.org HOWTO
• SlackBuilds.org FAQ
• NIST SP 800-131A Rev. 2
• Package URL type index
• Debian project history
• Debian security information
• Arch Linux security tracker
• Arch Linux package signing
• FreeBSD security information
• Wikipedia: Slackware (history, release and support tables)

Not reachable from our scripted client (HTTP 403): slackware.com, its 15.0 announcement and security pages, and docs.slackware.com. The same release documents were read from the official mirrors instead.

Last reviewed: 24 October 2026. Slackware patches arrive without a schedule; check the release ChangeLog on an official mirror for the latest security entries and support notices.