How Kali Linux Is Built: live-build, Metapackages and Image Signing

Kali Linux is built in three layers. Packages flow from Debian testing, plus Kali's own and forked packages, into a development branch and then into kali-rolling once they pass an installability check. Public build scripts then assemble images: live-build for the Live ISO, simple-cdd for the Installer ISO, and separate scripts for VM, ARM, cloud, container, WSL and NetHunter images. Metapackages decide which tools go in, and one OpenPGP key signs both the APT archive and the SHA256SUMS file for every image.

This guide goes one level deeper than our history of Kali's quarterly releases from 2020 to 2026 and our comparison of Ubuntu, Kali and Debian. If you only want to run Kali, start with installing Kali in a virtual machine safely and writing and verifying an ISO on USB. If you are here for the APT signing details, our post on signed APT repositories with Signed-By explains the keyring mechanics this post relies on.

Key takeaways

• Kali is based on Debian testing. Most packages are imported as they are; Kali forks a small number and adds many security tools of its own.
• Packages move through kali-dev into kali-rolling only after a tool confirms they are installable. That check does not include functional testing, so a broken tool can still land.
• Each quarterly release freezes kali-rolling into kali-last-snapshot, and that branch can be used to rebuild the latest released image.
• The old single live-build-config repository has been split. kali-live builds Live ISOs with Debian's live-build, and kali-installer builds Installer ISOs with simple-cdd and debian-cd. The old URL now redirects to kali-live.
• Metapackages are layered: kali-linux-core sits under kali-linux-headless, which sits under kali-linux-default, which sits under kali-linux-large, and kali-linux-everything pulls in all of them.
• The archive's InRelease file and every image's SHA256SUMS file are signed by the Kali Linux Archive Automatic Signing Key (2025), fingerprint 827C 8569 F251 8CC6 77FE CA1A ED65 462E C8D5 E4C5.
• The archive key changed in April 2025, not 2023. Kali lost access to the old signing key, froze the archive, rolled a new key and asked every user to install a new keyring by hand.
• Bit for bit reproducibility has been shown for Debian's own live images. Kali publishes the scripts it uses, which makes an audited rebuild possible, but we found no Kali statement that its ISOs are reproducible bit for bit.

How does Kali relate to Debian testing?

Kali's policy page states it plainly: the distribution "is based on Debian Testing", and most Kali packages are imported as they are from Debian's archive. Newer packages are sometimes taken from Debian unstable or experimental, either for a better user experience or to pick up a needed bug fix.

Two kinds of package are different from Debian:

• Forked packages. Some Kali features need changes to Debian packages. Kali tries to keep that list short by pushing changes upstream or adding hooks upstream so its features can be switched on without a fork. Each forked package lives in a Git repository with a debian branch, so a Debian update is merged with git merge debian on the main branch. live-build itself is one of these forks; the Kali build docs point non-Kali hosts at a live-build_...+kali... package from Kali's pool.
• Additional packages. The security and forensics tools Kali adds. Kali says most of them meet the Debian Free Software Guidelines, follow Debian Policy, and are intended to go back into Debian over time.

Kali has used Debian testing as the starting point for kali-rolling since January 2016, according to its branch documentation. The first Kali Rolling release, 2016.1, shipped on 21 January 2016.

How packages flow from Debian into kali-rolling

Kali's branch documentation draws the pipeline like this. Arrows show the direction packages move.

debian-experimental -> debian-unstable -> debian-testing -> kali-dev -> kali-rolling -> kali-last-snapshot
        |                     |                                ^  ^           ^              |
        +---------------------+-----> kali-debian-picks -------+  |           |              +--> kali-bleeding-edge
                                                                  |           |                       ^
kali-experimental -> kali-dev-only -------------------------------+           |                    upstream
                                                                              |
kali-rolling-only ------------------------------------------------------------+

In words:

1. debian-testing is a mirror of Debian's testing distribution.
2. kali-debian-picks holds packages cherry picked from Debian experimental and unstable. It is merged into kali-dev automatically.
3. kali-dev-only holds Kali specific packages, and is also merged into kali-dev automatically.
4. kali-dev is Debian testing with Kali's packages force injected. Kali packages take precedence. Kali warns that kali-dev will "regularly break", because when testing moves, Kali's packages sometimes need updates that do not happen at once.
5. A tool picks updated packages from kali-dev and copies them into kali-rolling only when they are verified to be installable. Packages that must reach users quickly can go through kali-rolling-only.
6. At every release, Kali freezes kali-rolling and merges it into kali-last-snapshot. Users on that branch get the jump from one versioned release to the next and nothing in between.

That installability gate is the main quality control between Debian testing and a Kali user. Kali is open about its limit: the checks "do not include any functional testing", so software that installs cleanly can still be broken.

Which Kali branch should you use?

Since Kali 2026.2, a fresh kali-rolling system keeps its APT source in deb822 format at /etc/apt/sources.list.d/kali.sources. Systems installed earlier may still use the one line form in /etc/apt/sources.list. Both are shown in the branch documentation:

# /etc/apt/sources.list.d/kali.sources (Kali 2026.2 and later)
Types: deb
URIs: http://http.kali.org/kali/
Suites: kali-rolling
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg

# /etc/apt/sources.list (older installs)
deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

Note the Signed-By line. It binds this repository to one keyring file, which matters for the key rotation story later in this post.

The build scripts: one repository per image type

All official Kali images come from repositories under gitlab.com/kalilinux/build-scripts. Each README says these are "the same build-scripts" the Kali team uses for the official images. That is the single most important fact for anyone who wants to audit or rebuild Kali: the recipe is public.

GitLab's project records give a rough history. kali-live and kali-docker date from April 2019, kali-vm from March 2022, and kali-installer from January 2025. All of them showed commits within the last few weeks when we checked on 23 October 2026.

Why live-build-config became kali-live and kali-installer

Kali was traditionally a Live image only. The Installer image arrived with Kali 2020.1, released on 28 January 2020. For years both were produced from one repository, live-build-config, with an --installer switch. Kali's current documentation says the project "has since been split into two parallel repositories", one per image type, and that the old URL now redirects to kali-live. We confirmed the redirect: requesting gitlab.com/kalilinux/build-scripts/live-build-config lands on kali-live.

The split matters because older blog posts and forum answers still tell you to clone live-build-config and run ./build.sh --installer. That flag no longer exists in kali-live.

There is a second wrinkle. Kali's docs page for custom ISOs still shows the older wrapper flags (--distribution, --verbose, --subdir), while the kali-live and kali-installer READMEs, updated more recently, document -b/--branch, -v/--variant, -o/--output, -k/--keep, -P/--packages and -x/--version. When the two disagree, trust ./build.sh --help in the checkout you actually have.

What is live-build?

live-build is the Debian Live project's tool for building live system images. The Debian Live Manual describes it as a set of scripts that read their configuration from a single config/ directory, much as debhelper reads debian/.

Three commands do most of the work:

• lb config creates or refreshes the config/ tree, plus auto/ and local/ skeletons.
• lb build reads config/ and runs the lower level commands that build the image. It is run as root.
• lb clean removes build stages so the next build starts clean. By default it cleans the chroot, binary and source stages and keeps the package cache.

The four live-build stages

The manual splits every build into stages, applied in order:

Within the chroot stage the order is deliberate: preseeds are applied before packages are installed, packages before locally included files, and hooks last, after everything else is in place. If a hook seems to run "too early", it usually is not; the file it expects was placed in the wrong directory.

Why auto/config exists

lb config stores the options you pass into files under config/, but running it again does not reset options it defaulted from your earlier choices. The manual's answer is the auto/ directory: auto/config holds your lb config command with every option, so running lb config always rebuilds the same configuration. The noauto argument inside it stops the script calling itself in a loop. Kali's kali-live repository ships its own auto/config and auto/clean, which is how its build.sh wrapper produces the same configuration every time.

How kali-live turns live-build into a Kali ISO

The kali-live README describes a short structure:

• build.sh, the entry point, which calls live-build's lb config and lb build.
• build-in-container.sh, which runs build.sh inside a helper container defined by the repository's Dockerfile.
• auto/, live-build's own config and clean hook scripts.
• kali-config/, the live-build configuration tree: common/ for shared settings and one variant-* directory per desktop or edition.

The supported Live variants in the README are default, e17, everything, gnome, i3, kde, large, light, lxde, mate, minimal, xfce, xfce-everything, xfce-large and xfce-light. Architectures are amd64, arm64 and armhf. Branches are kali-rolling, kali-dev and kali-last-snapshot.

Customisation follows live-build's directory conventions:

The default package lists include kali-linux-default and a few other metapackages. Kali's docs suggest commenting those lines out and listing packages by hand when you want precise control. That is the hook for everything in the next section.

How the Installer ISO is built with simple-cdd and debian-cd

The Installer image is built a different way. kali-installer drives simple-cdd, which is a wrapper around debian-cd, the tool Debian uses for its own installer media. The README calls this "a wrapper, for a wrapper": build.sh calls simple-cdd, which calls debian-cd.

Its structure mirrors kali-live:

• kali-config/ holds the debian-cd tree, with common/ and one installer-* directory per variant: default, everything, netinst and purple.
• simple-cdd/ holds the simple-cdd profile: profiles/, local_packages, disc-end-hook and simple-cdd.conf.

The two images make different promises. The Live ISO lets you boot Kali without touching the disk and offers a basic install. The Installer ISO lets you choose desktops and metapackages during installation. Kali's docs explain that kali-config/installer-default/packages controls what goes into the installer's package pool, while a separate simple-cdd profile file controls what the installer actually installs. Edit only the first and the packages sit on the disc unused.

For unattended installs the Installer ISO accepts Debian installer preseeding. Kali keeps examples in a kali-preseed-examples repository, linked from the kali-live README.

What are Kali metapackages, and how is the default set chosen?

A metapackage is an empty Debian package whose only job is to depend on other packages. Install it and APT pulls in everything it lists. Kali uses metapackages to let users pick how much of the archive they want, and its own image builds use the same metapackages to decide what each image contains.

All of them are defined in one file: debian/control in the kali-meta package repository on GitLab. Reading that file is the most direct way to see what "default Kali" means on a given day.

How the main metapackages stack

The layering is the design decision to understand. kali-linux-default does not list its command line tools directly. It inherits them from kali-linux-headless, and the comment in debian/control says only GUI tools should be added to kali-linux-default itself. So a change to the headless list changes every desktop image too.

The other metapackage families

Kali's metapackage documentation groups the rest into four families:

• Desktop environments and window managers: kali-desktop-core plus kali-desktop-xfce, -gnome, -kde, -mate, -lxde, -i3 and -e17. kali-desktop-live is used only in a live session.
• Tools by hardware or protocol: kali-tools-gpu, -hardware, -crypto-stego, -fuzzing, -802-11, -bluetooth, -rfid, -sdr, -voip and -windows-resources.
• Menu categories: one metapackage per Kali menu section, such as kali-tools-information-gathering, -vulnerability, -web, -passwords, -wireless, -reverse-engineering, -forensics and -reporting.
• Systems: kali-linux-arm for tools suitable for ARM devices, kali-linux-nethunter for NetHunter, and kali-linux-labs for practice environments.

How to inspect what a metapackage brings in

You do not have to read debian/control by hand. On any Kali system:

# What does the default metapackage depend on directly?
apt-cache depends kali-linux-default

# Which metapackages pull in a given package?
apt-cache rdepends --installed nmap

# How many packages would kali-linux-large add to this system?
apt-get install --simulate kali-linux-large | grep -c '^Inst'

# Which kali-* metapackages are installed right now?
dpkg-query -W -f='${Package}\t${Version}\n' 'kali-linux-*' 'kali-tools-*' 2>/dev/null

To change the set interactively, Kali documents kali-tweaks, which has a Metapackages tab. On the command line, update first and then install the metapackage you want:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y kali-linux-default

Some entries in debian/control are limited to particular architectures, written as [amd64 arm64] after the package name. That is why an ARM image and an amd64 image built from the same metapackage can contain slightly different tools.

How are the Kali archive and images signed?

Kali uses one signing key for two jobs: signing the APT archive metadata, and signing the checksum files published next to every image. Individual .deb files are not signed one by one. Trust flows down through hashes instead.

The APT chain of trust

The Debian apt-secure manual describes the chain that Kali inherits:

1. When a package is uploaded and accepted, its checksum is computed and written into the archive's Packages file.
2. Checksums of every Packages file are written into the Release file.
3. The Release file is signed by the archive key. InRelease is the same file with the signature inline.
4. APT on your machine checks that signature against the keyring named by Signed-By, then checks each Packages file against Release, then each downloaded .deb against Packages.

Break any link and APT refuses the update. That is exactly what users saw in April 2025.

We fetched https://http.kali.org/kali/dists/kali-rolling/InRelease on 23 October 2026. Its header listed origin Kali, suite kali-rolling, architectures i386 amd64 armhf arm64 and components main contrib non-free non-free-firmware, with a SHA512 armour hash. GnuPG reported a good signature from RSA key 827C8569F2518CC677FECA1AED65462EC8D5E4C5. The file had no Valid-Until field, which means APT applies no built in expiry to the index itself; freshness comes from the mirror and the date in the file.

The keys

Kali's April 2025 announcement listed both keys in the new keyring:

Both are RSA 4096 keys. The full fingerprint of the current key is 827C 8569 F251 8CC6 77FE CA1A ED65 462E C8D5 E4C5.

The image checksum files

Every image directory on cdimage.kali.org carries four files: SHA256SUMS, SHA256SUMS.gpg, SHA1SUMS and SHA1SUMS.gpg. The .gpg files are detached signatures. On 23 October 2026 the /current/ directory listed checksums for the 2026.3 Hyper V, QEMU, VirtualBox and VMware archives, the Installer ISOs for amd64 and arm64, netinst, everything and purple variants, the Live ISOs for amd64 and arm64, and the Live everything ISO. Most image files there were dated 9 October 2026 and the checksum files 20 October 2026. Kali's release history page still listed 2026.2 as its latest announced release at that time, so treat any 2026.3 dates as provisional until the release announcement appears.

The /kali-weekly/ directory follows the same pattern with ISO week names such as kali-linux-2026-W42-installer-amd64.iso, and its own signed SHA256SUMS.

How to verify SHA256SUMS and the GPG signature, step by step

Kali's documentation describes three levels of assurance. Comparing a hash you compute with one shown on the website is quick, but it trusts the website. Using the .txt.sha256sum file that ships with a torrent is easier, but that file is not signed. The strongest method checks the signed SHA256SUMS against a key you obtained independently. Kali's docs say this method fails only if the private key is both subverted and not revoked afterwards.

Here is the full method on Linux or macOS. Replace the file name with the image you downloaded.

Step 1: import the Kali key.

wget -q -O - https://archive.kali.org/archive-key.asc | gpg --import
# or, from a keyserver
gpg --keyserver hkps://keys.openpgp.org --recv-key 827C8569F2518CC677FECA1AED65462EC8D5E4C5

Step 2: check the fingerprint against more than one source.

gpg --fingerprint 827C8569F2518CC677FECA1AED65462EC8D5E4C5
# pub   rsa4096 2025-04-17 [SC] [expires: 2028-04-17]
#       827C 8569 F251 8CC6 77FE  CA1A ED65 462E C8D5 E4C5
# uid   Kali Linux Archive Automatic Signing Key (2025) <devel@kali.org>

Compare it with the fingerprint printed in Kali's documentation, in the April 2025 announcement and on the Ubuntu keyserver, where Kali says developer signatures on the new key are published. Fetching the key and the fingerprint from the same web page proves little; three independent sources agreeing proves more.

Step 3: download the image and both checksum files from the same directory.

BASE=https://cdimage.kali.org/current
curl -fLO "$BASE/SHA256SUMS"
curl -fLO "$BASE/SHA256SUMS.gpg"
# then download your image from the same directory or a mirror

Step 4: verify the signature on SHA256SUMS.

gpg --verify SHA256SUMS.gpg SHA256SUMS

When we ran this on 23 October 2026 against /current/, GnuPG printed "Good signature from Kali Linux Archive Automatic Signing Key (2025)" using RSA key 827C8569F2518CC677FECA1AED65462EC8D5E4C5. It also printed a warning that the key "is not certified with a trusted signature". That warning is normal: it means you have not signed the key yourself in your own web of trust. What matters is the "Good signature" line and the matching fingerprint.

Step 5: check the image against the signed list.

grep ' kali-linux-2026.3-installer-amd64.iso$' SHA256SUMS | shasum -a 256 -c
# kali-linux-2026.3-installer-amd64.iso: OK

On Windows, Kali documents certutil -hashfile with the file name and sha256 for the hash and Gpg4win for the signature. PowerShell may print the hash in upper case, which Kali notes can cause a false mismatch when comparing by eye.

If either check fails, stop. Kali's own instruction is not to use the image, and to download again from an official mirror.

Verifying the archive keyring itself

The keyring APT uses is /usr/share/keyrings/kali-archive-keyring.gpg, shipped by the kali-archive-keyring package. To see what it contains:

gpg --no-default-keyring --keyring /usr/share/keyrings/kali-archive-keyring.gpg --list-keys --with-fingerprint

On a current system you should see both keys from the table above.

The 2025 archive key rotation: what happened and what broke

Our research plan expected a 2023 key rotation. Kali's own record says otherwise: the archive signing key changed in April 2025, and the announcement is dated Monday 28 April 2025.

What Kali said happened

According to the announcement, Kali "lost access to the signing key of the repository". It created a new key, dated 17 April 2025, and froze the archive so that no user was affected while it prepared the change; the post notes there had been no update since Friday 18 April. When the archive was unfrozen and signed with the new key, every system that only trusted the old key would fail to update.

The failure looked like this on a current APT, which now verifies signatures with the sqv helper:

Err:1 https://http.kali.org/kali kali-rolling InRelease
  Sub-process /usr/bin/sqv returned an error code (1), error message is:
  Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5, which is needed to verify signature.
Warning: An error occurred during the signature verification. The repository is not updated
and the previous index files will be used.

The second line is the dangerous one. APT does not stop the machine working; it keeps using the old index files. A system can sit for weeks with apt update printing a warning, apt upgrade reporting nothing new, and its owner believing it is current.

The fix Kali published

Kali asked users to replace the keyring file by hand:

sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg
sha1sum /usr/share/keyrings/kali-archive-keyring.gpg
# Kali published: 603374c107a90a69d983dbcb4d31e0d6eedfc325

The new keyring contained both the old and the new key. Kali's question and answer section addressed the obvious worry directly: the key was not compromised, and the proof offered was that the old key was kept rather than removed with a revocation certificate.

What else changed

Kali 2025.1c is described in the release history as the same as 2025.1, "but with a new version of kali-archive-keyring". If you reinstall from an older ISO, such as 2025.1 or earlier, you will hit the missing key error on first update and need the manual fix.

The 2018 precedent and the lesson

The same announcement recalls that in 2018 the Kali key was allowed to expire by accident. Two signing incidents seven years apart point at the same lesson for anyone running their own repository: a signing key is an operational dependency with a calendar. Track its expiry date, keep the private key recoverable under more than one person's control, ship the next key in the keyring package before you need it, and decide in advance how users will learn about a rotation.

For Kali users the lesson is simpler. Treat "An error occurred during the signature verification" as a failed update, not a warning, and alert on it in any automation.

Timeline: how Kali's build and signing evolved

How to build a custom Kali ISO yourself, step by step

This walkthrough builds a Live ISO with kali-live, adds your own packages and a file, tests it in QEMU, and then signs and records what you built. It assumes a Kali host, which Kali recommends because fewer things go wrong. Plan for several gigabytes of downloads and a long first build.

Step 1: prepare the host and clone the scripts

sudo apt update
sudo apt install -y --no-install-recommends git ca-certificates live-build apt-utils
# only needed for cross-architecture builds, for example arm64 on an amd64 host
sudo apt install -y --no-install-recommends qemu-user-binfmt

git clone https://gitlab.com/kalilinux/build-scripts/kali-live.git
cd kali-live
git log -1 --format='%H %cd'   # record the exact commit you build from
./build.sh --help

Record that commit hash. It is the first line of your build's audit trail.

Step 2: build the stock image once

sudo ./build.sh
# Output: output/kali-linux-rolling-default-amd64.iso

Building the unmodified image first proves the host works before you change anything.

Step 3: choose a branch, variant and extra packages

The README's own example builds from the last release snapshot, with GNOME, a custom hostname and extra packages:

sudo ./build.sh -b kali-last-snapshot -v gnome -H kali-gnome -P nmap,wireshark

For a small headless image with no default toolset, a custom version name, kept intermediate files and a specific mirror:

sudo DEBUG=1 ./build.sh --variant minimal --version custom --keep --mirror http://kali.download/kali

Use kali-last-snapshot when you want two builds a week apart to start from the same package versions. Use kali-rolling when you want the newest packages.

Step 4: edit the package list

For finer control than -P, edit the variant's list. For the default variant:

$EDITOR kali-config/variant-default/package-lists/kali.list.chroot

You can comment out kali-linux-default and list exactly the tools you need. Smaller lists build faster and leave fewer packages to patch later; Kali's own docs suggest swapping the default toolset for the top 10 tools to speed up builds.

Step 5: overlay files and add a hook

Anything under includes.chroot appears at the same path inside the live system:

mkdir -p kali-config/common/includes.chroot/etc/profile.d
cat > kali-config/common/includes.chroot/etc/profile.d/lab-banner.sh <<'EOF'
echo "Lab image built from kali-live; do not use on production networks."
EOF

A chroot hook runs inside the image during the build, after packages and included files are in place. The repository keeps its hooks in kali-config/common/hooks/live/, where Kali's own kali-hacks.chroot lives; follow that naming:

ls kali-config/common/hooks/
cat > kali-config/common/hooks/live/9990-record-packages.chroot <<'EOF'
#!/bin/sh
set -e
dpkg-query -W -f='${Package}\t${Version}\t${Architecture}\n' > /usr/share/doc/image-packages.tsv
EOF
chmod +x kali-config/common/hooks/live/9990-record-packages.chroot

That hook writes a package manifest into the image itself, which you will want later for vulnerability matching.

Step 6: build and test in a virtual machine

sudo ./build.sh
sudo apt install -y --no-install-recommends qemu-system-x86 ovmf
qemu-system-x86_64 -enable-kvm -cpu host -m 4096 -smp cores=4 \
  -cdrom output/kali-linux-rolling-default-amd64.iso

For a UEFI boot test, Kali's docs add two read only pflash drives for the OVMF firmware files. Test both BIOS and UEFI boot if you will hand the image to others.

Step 7: checksum, sign and record what you built

Treat your ISO as a release artifact, the same way Kali does:

cd output
sha256sum *.iso > SHA256SUMS
gpg --local-user YOUR_KEY_ID --armor --detach-sign --output SHA256SUMS.asc SHA256SUMS
gpg --verify SHA256SUMS.asc SHA256SUMS

Keep, next to the ISO: the kali-live commit hash, the branch, the mirror URL, the exact build.sh command line, SHA256SUMS with its signature, and the package manifest from the hook.

Step 8: write it to USB, carefully

Warning: the next command erases the target device completely. Writing to the wrong device path destroys that disk's data, and there is no undo. Check the device path first, every time.

# 1. Identify the USB drive by size, model and transport. Unplug and replug to be sure.
lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
# 2. Confirm the path you chose is the USB stick and nothing on it is mounted.
DEV=/dev/sdX            # replace with the device you just confirmed
lsblk "$DEV"
# 3. Only then write the image.
sudo dd if=output/kali-linux-rolling-default-amd64.iso of="$DEV" bs=4M status=progress oflag=sync

The resulting Live ISO is a hybrid image, so the same file works on USB, optical media or a VM. Our ISO to USB guide covers verifying what was written.

Building the Installer ISO instead

The flow is the same with a different repository:

git clone https://gitlab.com/kalilinux/build-scripts/kali-installer.git
cd kali-installer
sudo ./build.sh -v netinst          # variants: default, everything, netinst, purple
sudo ./build.sh -b kali-last-snapshot -x 2026.2

Remember the two package files: the pool list under kali-config/installer-*/ and the simple-cdd profile that decides what the installer installs.

Building on Debian or Ubuntu instead of Kali

Kali's docs and the kali-live README describe building on another Debian based host. You need Kali's keyring and Kali's fork of live-build, both from Kali's package pool, because Debian's live-build does not know about Kali's branches:

sudo apt install -y --no-install-recommends debootstrap cpio apt-utils wget ca-certificates
# Check the pool for current file names first:
#   https://http.kali.org/pool/main/k/kali-archive-keyring/
#   https://http.kali.org/kali/pool/main/l/live-build/
wget https://http.kali.org/pool/main/k/kali-archive-keyring/kali-archive-keyring_<VERSION>_all.deb
sudo apt install ./kali-archive-keyring_*_all.deb
wget https://http.kali.org/kali/pool/main/l/live-build/<LIVE_BUILD_KALI_FILE>_all.deb
sudo apt install ./live-build_*_all.deb

The older docs page also shows creating a kali-rolling debootstrap script from Debian's sid script and, on some hosts, commenting out a debootstrap version check in build.sh. The container route avoids most of this: ./build-in-container.sh builds a helper image from the repository's Dockerfile and runs the build inside it. For kali-live, the container must be rootful; rootless Podman makes the script try to elevate with sudo.

Download the keyring package from an HTTPS URL and compare its fingerprint with the one in this post before you install it. That .deb decides which signatures your build host trusts.

How cloud, WSL, ARM, VM, container and NetHunter images are built differently

The Live and Installer ISOs are the familiar outputs, but most Kali installs in practice come from other images. Each uses a different tool, which changes what you can audit and how you rebuild.

VM images with debos

kali-vm uses debos, a Debian OS image builder that runs YAML recipes. debos runs the build inside a throwaway virtual machine created by fakemachine, which is why kali-vm needs KVM and membership of the kvm group but not root. The README's options cover:

• Variants: generic, hyperv, qemu, rootfs, virtualbox and vmware, each with the right guest tools preinstalled.
• Formats: hyperv (VHDX), ova, ovf, qemu (QCOW2), raw, vagrant, virtualbox (VDI) and vmware (VMDK).
• Toolsets: default, everything, headless, large and none, mapping onto the metapackages above.
• Defaults worth changing: user and password kali:kali, an 86 GB disk and the America/New_York time zone.

./build.sh -b kali-last-snapshot -v qemu -T headless -U analyst:'choose-a-strong-password'
./build.sh -v virtualbox -- --memory 8G --scratchsize 60G

A rootfs variant produces a root filesystem tarball, and -r lets you build several VM formats from one rootfs. That is useful for auditing: one rootfs, one package set, several wrappers.

ARM images with per device scripts

kali-arm holds one shell script per board, for example raspberry-pi.sh, plus common.d/build_deps.sh to install dependencies. The README asks for at least 8 GB of RAM or a swap file, tests the scripts on Kali arm64, x64 and x86 hosts, and recommends x64. Its worked example notes about 100 minutes per script on a four core VM with 8 GB RAM using a local mirror. Options include architecture (arm64, armel, armhf), desktop, --minimal (no desktop) and --slim (no desktop and no command line tools). The scripts cover more boards than Kali publishes images for, so some devices are build it yourself only.

Cloud images with FAI

kali-cloud is a fork of Debian's cloud image builder, debian-cloud-images, and uses FAI (Fully Automatic Installation). The repository keeps Debian's README as README.debian.md. Building needs root but not KVM, and the dependency list includes fai-server, fai-setup-storage and Python libraries for cloud provider APIs.

Containers built in CI

kali-docker produces a minimal kali-rolling base image with no tools added. The README says images are rebuilt weekly and pushed to Docker Hub under kalilinux, and that the easiest way to build your own is to fork the repository and let GitLab CI build it, with every push producing a new image in your fork's registry. A local build.sh exists too.

docker run --rm -it kalilinux/kali-rolling
# then add only what you need
apt update && apt install -y kali-linux-headless

Because the base image has no tools, a container image's contents are decided entirely by your Dockerfile. Pin the base image by digest and record which metapackages you install.

WSL through the Microsoft Store app

kali-wsl-app is the Microsoft Store app for Kali on Windows Subsystem for Linux, forked from Microsoft's WSL distro launcher sample. Once you run apt update inside it, the same archive and signing key apply.

NetHunter with build.py

NetHunter, Kali's Android platform, is built with Python scripts in kali-nethunter-installer. You run ./bootstrap.sh to fetch a kernels repository with device definitions, then python3 build.py with a device kernel, an Android version flag and a rootfs size (full, minimal or nano). The output is a recovery flashable zip that contains a Kali root filesystem archive such as kali-nethunter-rootfs-full-arm64.tar.xz. The kali-linux-nethunter metapackage defines the tool set.

Which build path fits which need?

Weekly images, quarterly releases and last snapshot

Quarterly releases, such as 2026.2, are frozen into kali-last-snapshot and go through Kali's release testing. Weekly images, named by ISO week such as 2026-W43, are built from kali-rolling and published in /kali-weekly/ with signed checksums; they are newer but untested beyond the build. Your own build reflects whatever the branch and mirror held when you ran it. A quarterly ISO followed by apt full-upgrade ends up close to a weekly image; the difference is only where any breakage lands.

What does a reproducible or audited build of Kali look like today?

The Reproducible Builds project defines a build as reproducible when, given the same source code, build environment and build instructions, any party can recreate bit by bit identical copies of the specified artifacts. The SOURCE_DATE_EPOCH environment variable is the project's standard way to stop build timestamps from making every output unique.

Debian has done this work for its own live images. In its June 2023 report, the Reproducible Builds project relayed Roland Clobus's status update that "all major desktops build reproducibly with bullseye, bookworm, trixie and sid", and that the live images were being generated officially by Debian. Kali builds on the same live-build machinery, so many of the same fixes apply.

We did not find a Kali statement that its official ISOs are reproducible bit for bit, and we did not test it. Kali does document something weaker but useful: with kali-last-snapshot, the build scripts let you "re-create the latest distributed image". In practice that means the same package versions and configuration, not necessarily identical bytes.

An audit you can run today

You can get most of the value of reproducibility without bit for bit equality:

1. Pin the recipe. Record the commit hash of kali-live, kali-installer or kali-vm, and the exact command line.
2. Pin the inputs. Build from kali-last-snapshot, or from your own mirror snapshot, rather than kali-rolling.
3. Record the outputs. Generate a package manifest inside the image, as in step 5 above, and keep it with the ISO and its signed checksum.
4. Compare with the official image. Boot the official ISO of the same release, run the same dpkg-query command, and compare the two manifests. Differences in package versions mean your inputs were not the same.
5. Investigate byte differences. If you want to go further, the Reproducible Builds project's diffoscope tool shows where two ISOs or two packages differ, down to individual files.
6. Verify every upstream signature. The InRelease signature for your build mirror, and the SHA256SUMS signature for any image you compare against.
7. Keep build hosts boring. Use the container builders or a clean VM per build so host packages do not leak into results.

That gives you an answer to the question auditors actually ask: which exact packages, at which versions, are on this image, and where did they come from.

Common mistakes

• Following an old guide that clones live-build-config and uses --installer. The repository redirects to kali-live, and Installer images now come from kali-installer.
• Trusting the hash on the same page you downloaded from. That only proves the download matched the page. Verify the signed SHA256SUMS with a fingerprint you checked elsewhere.
• Treating the "not certified with a trusted signature" warning as a failure. It only means you have not certified the key yourself. The failure to watch for is a missing "Good signature" or a fingerprint mismatch.
• Ignoring APT's signature warning. After the 2025 rotation, unfixed systems kept running on old index files while printing a warning. Automation should treat it as a failed update.
• Running apt-key add to fix a key problem. Kali's fix replaced the file referenced by Signed-By. Adding keys to a global trust store lets that key sign for every repository.
• Reinstalling from a pre 2025.1c ISO and wondering why updates fail. Older media carry only the old key. Fix the keyring first, or download a current image.
• Editing the installer's package pool and expecting the packages to be installed. The pool list and the simple-cdd profile are separate files.
• Building from kali-rolling and calling it a rebuild of the release. Only kali-last-snapshot matches the last release.
• Leaving the default kali:kali credentials in custom VM images. kali-vm lets you set -U at build time; use it.
• Running dd without checking the device path. Confirm with lsblk immediately before writing, every time.

FAQ

Is Kali Linux based on Debian stable or Debian testing?

Debian testing. Kali's policy page says most Kali packages are imported as they are from Debian testing, with occasional newer packages from unstable or experimental. Kali has used testing as the starting point for kali-rolling since January 2016.

How often is kali-rolling updated?

Continuously. Packages move from kali-dev into kali-rolling whenever an automated tool confirms they are installable. Kali also publishes weekly images built from kali-rolling and quarterly releases frozen into kali-last-snapshot.

What is the difference between the Kali Live and Installer ISO?

The Live ISO is built with live-build in kali-live and boots Kali without changing the disk, with a basic install option. The Installer ISO is built with simple-cdd and debian-cd in kali-installer and lets you choose desktops and metapackages during installation.

What tools are in kali-linux-default?

Everything in kali-linux-headless, which includes kali-linux-core, plus kali-system-gui, the ten tools in kali-tools-top10, and a short list of GUI only tools. The authoritative list is debian/control in the kali-meta repository, and apt-cache depends kali-linux-default shows it on any Kali system.

How do I verify a Kali ISO download?

Import Kali's key, confirm its fingerprint is 827C 8569 F251 8CC6 77FE CA1A ED65 462E C8D5 E4C5, run gpg --verify SHA256SUMS.gpg SHA256SUMS, then check your file with shasum -a 256 -c against the matching line in SHA256SUMS.

How do I fix "Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5" on Kali?

Install the current keyring, as Kali's April 2025 announcement describes: download https://archive.kali.org/archive-keyring.gpg to /usr/share/keyrings/kali-archive-keyring.gpg, check its SHA1 against the value Kali published, then run sudo apt update again.

Was the Kali signing key compromised in 2025?

Kali says no. It said it lost access to the old signing key, kept the old key in the new keyring, and pointed out that a compromised key would have been removed and revoked instead.

Can I build Kali on Ubuntu or Debian?

Yes. Install Kali's archive keyring and Kali's fork of live-build from Kali's package pool, or use build-in-container.sh, which builds a helper container and runs the build inside it.

Are Kali ISOs reproducible?

We found no Kali statement that its ISOs are reproducible bit for bit. Kali publishes the exact build scripts it uses and supports rebuilding the latest release from kali-last-snapshot. Debian has shown reproducible live images with the same live-build tooling.

How are Kali VM images built?

With kali-vm, which uses debos inside a fakemachine VM. It needs KVM but not root, and outputs raw, QCOW2, VDI, VMDK, VHDX, OVA or Vagrant images with the right guest tools for each hypervisor.

Where Safeguard fits, and where it does not

Safeguard does not build Kali images, sign anything, manage the machines Kali runs on or check APT signatures. Everything in this post is done with Kali's build scripts, live-build, simple-cdd, debos, GnuPG and APT. The honest link is the software inside the image. A custom Kali ISO or VM is a bundle of thousands of open source packages at specific versions, and a rolling distribution means those versions change every week. If you keep the package manifest from step 5, or build container images from a Dockerfile in a repository, Safeguard can scan that repository, the container image or an SBOM of it, show which of your projects carry a given component version, and match those versions against vulnerability data. It cannot tell you whether a given laptop ran apt full-upgrade this morning.

A rebuilt Kali image pulls its tools and libraries again from the archive, and many of the tools on it pull further dependencies from language registries when you run them. Image signing proves where the bits came from; it says nothing about whether those versions carry known vulnerabilities, so dependency hygiene still matters even though the fit with an operating system image 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 build or sign a Kali image. They show the software side: the projects and images you build on top of a distribution like Kali.

This is a real Safeguard CLI session: install, open the interactive terminal with safeguard, ask it to fix a lodash CVE, and approve each command as it edits package.json to lodash 4.17.21 and runs npm install and npm test, with nothing pushed. On a freshly built Kali analyst VM, the same flow is how you would fix a vulnerable dependency in the scripts and tools your team keeps in a repository, approving every command yourself.

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

This demo sets up the Safeguard runner on your own machine, approves it with a device code, and runs a scan from the terminal. If you keep your Kali build configuration, Dockerfiles or an exported SBOM in a repository, the same runner can scan that repository or SBOM on your own hardware, so the package versions you ship in a custom image are checked against vulnerability data.

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

Here Claude connects to the Safeguard MCP server with OAuth, and you choose which Safeguard tools Claude may use. That helps when you want to ask in plain language which of your projects or images carry a particular package version after a distribution update, while keeping the assistant's access limited to the tools you picked.

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

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Kali's Relationship With Debian, Kali Linux documentation
• Kali Branches, Kali Linux documentation
• Creating A Custom Kali ISO, Kali Linux documentation
• Generate an Updated Kali ISO, Kali Linux documentation
• Kali Linux Metapackages, Kali Linux documentation
• Download Official Kali Linux Images and verification, Kali Linux documentation
• A New Kali Linux Archive Signing Key, Kali Linux blog, 28 April 2025
• Kali Linux Release History
• kali-live build scripts README, GitLab
• kali-installer build scripts README, GitLab
• kali-vm build scripts README, GitLab
• kali-arm build scripts README, GitLab
• kali-cloud build scripts README, GitLab
• kali-docker README, GitLab
• kali-wsl-app, GitLab
• kali-meta debian/control, GitLab
• Building NetHunter, Kali Linux documentation
• Kali current images directory with SHA256SUMS, cdimage.kali.org
• Kali weekly images directory, cdimage.kali.org
• kali-rolling InRelease file, http.kali.org
• Debian Live Manual, Debian Live Project
• apt-secure(8), Debian manpages
• debos README, go-debos on GitHub
• Definitions, Reproducible Builds
• SOURCE_DATE_EPOCH, Reproducible Builds
• Reproducible Builds in June 2023, Reproducible Builds

Last reviewed: 23 October 2026. Kali's build scripts change often; check ./build.sh --help in your checkout and the Kali documentation for the current options.