12.2 The sources.list File

Anatomy of a sources.list Line

APT learns where to find packages from /etc/apt/sources.list (and, since Kali 2026.2, the deb822 file /etc/apt/sources.list.d/kali.sources) and from any .list files placed in /etc/apt/sources.list.d/. Each active (uncommented) line describes one repository source and follows this format:

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

Reading left to right, the fields are:

1. Archive type — deb for precompiled binary packages, or deb-src for source packages
2. URI — the base address of the repository; http and https are standard, but file:/, cdrom:, and even ssh are supported
3. Distribution — the release or suite name within that repository, for example kali-rolling; the path appended to the URI is built from this (.../dists/kali-rolling/)
4. Components — one or more whitespace-separated component names, such as main contrib non-free non-free-firmware

Lines starting with # are comments. A common hardening habit during exams and on real assessments: when someone asks you to 'check what repositories a box uses', look at both /etc/apt/sources.list and every file in /etc/apt/sources.list.d/ — packages like VPN clients and monitoring agents routinely drop their own .list files there, and the main file alone can look deceptively clean.

deb vs deb-src

A deb line tells APT where to download ready-to-install binary packages. A deb-src line tells it where to download source packages — the upstream tarball plus Debian packaging files — which you would fetch with apt source packagename and rebuild with dpkg-buildpackage. Source lines matter to developers modifying a tool, but they are useless for ordinary installs, and every enabled deb-src line makes apt update download extra indexes. The stock Kali image ships only a deb line; the KLCP exam treats 'you need deb-src to install packages' as a classic wrong answer.

The Four Components

The component list on each line selects which licensing categories you want from the repository:

• main — packages that fully comply with the Debian Free Software Guidelines (DFSG)
• contrib — packages that are themselves free software but depend on non-free software to build or run
• non-free — packages with licenses that do not meet the DFSG (certain drivers, tools with redistribution restrictions)
• non-free-firmware — binary firmware blobs (Wi-Fi and GPU firmware, for example), split out of non-free starting with Debian 12 (Bookworm) and adopted by Kali

Kali enables all four by default, because a penetration-testing distribution needs the broadest possible hardware and tool support.

Kali's Default Entry

A Kali system installed before the 2026.2 release contains a single active line in /etc/apt/sources.list. Learn this form first — it is the one the exam is written around, and it is what Kali's documentation still shows for pre-2026.2 systems; older printings of the book predate the non-free-firmware split and list only main contrib non-free:

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

Memorize it for the exam, field by field: binary packages, from Kali's mirror redirector at http.kali.org, tracking the kali-rolling distribution, with all four components enabled. If you ever find a Kali machine whose sources.list was clobbered, restoring exactly this line followed by apt update returns package management to a known-good state.

Note the plain http:// scheme — this surprises people. Security does not come from TLS here; it comes from APT's GPG signature verification of the repository's Release file and the checksum chain down to each individual .deb. A malicious mirror cannot inject packages without Kali's signing key. HTTPS mirrors exist but are optional defense-in-depth, not the root of trust.

What apt update Actually Does

apt update is the most misunderstood command in the ecosystem, and the exam exploits that. When you run it, APT:

1. Reads every deb and deb-src line from sources.list and sources.list.d/
2. Contacts each repository and downloads its InRelease (or Release + Release.gpg) file — the signed index of indexes — and verifies the GPG signature against keys in /etc/apt/trusted.gpg.d/ and the keyring package
3. Downloads the per-component, per-architecture Packages indexes (and translation/hash metadata) that list every available package, version, dependency set, and checksum
4. Stores all of this in /var/lib/apt/lists/

That is all. apt update installs nothing and upgrades nothing — it refreshes APT's local view of what the repositories offer. Two consequences follow:

• You must run apt update before apt install or apt upgrade, or APT works from stale indexes and may try to fetch .deb files the mirror has already deleted, producing 404 errors.
• Editing sources.list has no effect until the next apt update. Adding a repository and immediately running apt install is the classic way to get 'Unable to locate package'.

A failed signature check during update ('The following signatures couldn't be verified', 'NO_PUBKEY') means the repository's key is missing from APT's keyring — on Kali this is usually fixed by reinstalling the kali-archive-keyring package, not by disabling verification. Treat any tutorial telling you to add [trusted=yes] to a line as a red flag: it turns off the signature check that is your only real protection against a poisoned mirror.

Modern variants you may encounter

Since Kali 2026.2 the deb822 format is the default: instead of one-line entries, /etc/apt/sources.list.d/kali.sources uses labeled stanzas (Types:, URIs:, Suites:, Components:, and Signed-By:) to describe the same repository in a machine-parseable way. The semantics are identical to the one-line format — deb822 is a syntax change, not a new kind of repository — so do not be thrown if a fresh image shows .sources files where you expected .list files.

Two deprecated practices still surface in old tutorials and on exam distractors. First, apt-key add for repository keys: it is deprecated because it trusted the imported key for every configured repository; the modern approach is a per-repository keyring file referenced with Signed-By, so a compromised third-party key cannot vouch for Kali's packages. Second, PPAs (Personal Package Archives): they are an Ubuntu Launchpad concept, are not designed for Debian-based systems, and adding them to Kali routinely produces the same dependency breakage as mixing Debian's own repositories.