12.3 Kali Repositories

The Repository Lineup

Kali is a rolling release: instead of frozen versioned releases with big-bang upgrades, packages flow continuously from Debian and from Kali's own build infrastructure into repositories that users track. The exam expects you to know the four distribution names and what each is for:

kali-rolling

kali-rolling is what the default sources.list points at. It is built from Debian Testing with Kali's hundreds of security tools layered on top, and it is updated continuously. The practical consequence: there is no 'Kali 2024.1 to 2024.2 upgrade procedure' on an installed system — you just keep running updates and you are always current. The point-in-time installer images (2025.1, 2025.2, and so on) are snapshots of kali-rolling at a moment, not separate distributions.

kali-dev and kali-bleeding-edge

kali-dev is the integration branch: packages modified by Kali developers land here first so the team can shake out build and dependency problems before promoting them to kali-rolling. kali-bleeding-edge is more aggressive — its packages are generated automatically from the latest upstream source (git snapshots, fresh tarballs) with essentially no testing. The Kali documentation is blunt that bleeding-edge is expected to break, sometimes badly enough to leave dpkg unable to complete a transaction. On the exam, 'enable kali-bleeding-edge to get the newest tools' is always the wrong answer; the right move for a newer tool is to wait for kali-rolling or install the tool separately (from source, pip, or a vendor repo) in a controlled way.

kali-experimental

kali-experimental hosts changes too disruptive even for kali-dev — a glibc or Python transition, a major Xfce or GNOME bump. It is enabled temporarily, by testers, for a specific purpose, and disabled afterward. Like bleeding-edge, it is not a source of 'better' packages for daily work.

kali-last-snapshot and checking what you track

One more name appears in real deployments: kali-last-snapshot, a main branch served from the same archive that stays frozen at the last quarterly point release instead of moving daily like kali-rolling — Kali's stated equivalent of Debian Stable. Freeze-sensitive environments — training labs, prebuilt VM images, CI pipelines — use it so that every machine built between two point releases receives identical package versions, trading freshness for reproducibility. If you inherit a Kali box whose updates seem mysteriously frozen in time, check whether its sources point at a snapshot instead of kali-rolling.

To see which repository would actually supply a package, run apt-cache policy nmap: it lists the installed version, the candidate, and every available version alongside the URI and distribution providing it. This is the fastest way to confirm that a system really tracks kali-rolling and nothing else.

archive.kali.org vs http.kali.org

Two hostnames appear constantly, and the exam distinguishes them:

• archive.kali.org — the master archive: the canonical server the Kali team uploads packages to. Directing your sources.list at it works, but every user hammering one machine would be slow and fragile.
• http.kali.org — a redirector in front of a worldwide mirror network (including CDN endpoints and community mirrors). When APT requests a file, http.kali.org redirects the request to a mirror that is geographically or topologically near you. This is why the default line uses http.kali.org: fast downloads with no manual mirror selection.

One related hostname is worth recognizing: cdimage.kali.org, a second MirrorBrain redirector that fronts the released installer and live ISO images while http.kali.org fronts the package archive (append .mirrorlist to a URL on either redirector to see the mirror list). The old Kali 1.x security.kali.org host no longer exists — and unlike Debian, Kali does not maintain a separate security-updates repository that users must add; security fixes flow into kali-rolling like everything else. That is a favorite exam trap: adding a kali-security line copied from old Debian habits is wrong.

Why Mixing Debian Repositories Breaks Kali

Kali is based on Debian Testing, which tempts people into adding Debian's own repositories — debian testing, debian stable, or debian security — to sources.list 'for more packages'. Do not do this, and expect a question about it. The reasons:

1. Divergent versions. Kali snapshots Debian Testing at its own pace and then patches, rebuilds, or forks many packages (the kernel, Python, desktop stacks). A Debian repository will offer versions of shared libraries — libc6, openssl, python3 — that differ from the versions Kali's tools were compiled against.
2. APT has no idea a conflict exists until it computes a transaction. It will happily propose upgrading half your system to Debian's builds, after which Kali-specific packages fail their Depends and tools stop launching.
3. The damage is hard to reverse. Once core libraries are replaced, you cannot simply remove the line and downgrade — dpkg strongly resists downgrades, and dependency pinning makes a rollback a manual, package-by-package fight.

The supported pattern for third-party software is a separate .list file in /etc/apt/sources.list.d/ scoped to that vendor's own repository, or APT pinning to control which source may provide which package — never wholesale mixing of two distributions' main archives. Keep Kali on kali-rolling alone, and it will stay coherent because every package in that single repository is built and tested to work with every other.