Kali linux package repository

The topic of repositories is always a large one, and comes up frequently. It is an item which people often get wrong and confused with. Please take the time to read the information below and any references which is linked to before acting on anything.

Default Network Repository Value

On a standard, clean install of Kali Linux, with network access, you should have the following entry present in /etc/apt/sources.list :

If the output doesn’t exactly match up to the above output, you may not be able to install any new additional packages or receive updates. This may happen for any number of reasons, such as:

You have switched your branch.
Using a different hardcoded mirror.

You will probably want to read the “switching branches” section to alter this.

Since Kali 2020.3, after Kali’s setup is complete, network repositories will be enabled by default, even if there was no network access during installation.

Switching Branches/Regular Repositories

Kali has various different branches to choose from (please take the time to read which one would be the best option for your setup), and you may be able to switch or include additional repositories.

kali-rolling (Default & frequently updated):

kali-last-snapshot (Point release so more “stable” & the “safest”):

kali-experimental (Packages which are under testing — often used with the rolling repository):

Sources.list Format

Archive is going to be deb (Regular Binary) or deb-src (Source), depending if you want a package or the source of the package.
Mirror should be http.kali.org/kali as this is our load balancer, which will direct you to best mirror.
Branch is what version of Kali you wish to use.
Component is what packages you wish to use, based on the Debian Free Software Guidelines (DFSG). Kali defaults to everything.

Default Offline Install Values

During the Kali setup process, if you don’t have access to a network connection to reach a repository, you will perform an offline installation of Kali Linux. You will be limited to the packages & the version which is on the medium you installed Kali from. This will then configure Kali to continue to use this medium to install packages from, even after Kali has been installed.

This means you will not get any updates to packages, or any new additional tools, which can be frustrating. You can see if you the offline media enabled if your values match up with whats below (or if you want to enable this option):

If your output matches whats above, please see the switching branch section, if you wish to receive updates.

However, if you do have network connection, which has access to network repositories, it will be enabled for you. You don’t need to do anything.

Non-Kali Repositories

If you want to install additional tools and software (such as signal) outside of what Kali has to offer, you may need to include an extra repository for this to happen. Please do not alter /etc/apt/sources.list , as this is used for the Kali Linux Operating System. Any extra tools and software needs to be placed into their own file in the directory /etc/apt/sources.list.d/ (such as /etc/apt/sources.list.d/repo-name.list , replacing repo-name with the mirror name). It is highly recommended that each mirror should be in its own file.

By adding Kali’s repository to a non-Kali OS (such as trying to add Kali to Ubuntu), this will highly increase the chance of your system not working. It may not happen straight away, but without any warning, it may break. We will not be able to offer support (and based on what we have seen over the years, most other OS will not help too).

Likewise, adding other operating system’s repositories into Kali (such as trying to put Ubuntu on Kali), will break your installation. This is the single most common reason why Kali Linux systems break.

If any guides are telling you to do anything else than the above, this is unofficial advice, and completely not supported by Kali Linux. More often than not, users in this case end up doing a reinstall after learning this lesson.

Mirrors

We have a list of official Kali Linux mirrors, as well as a guide on how to setup your own. This may be kept as a local repository which is only accessible on a LAN, or a remote private one, or if you have the ability to, you may wish to share back to the community and make it public allowing for anyone else in your geographical area to benefit from it.

Source Repositories

By using a deb in the repositories, it will allow for binary packages to be downloaded. However, should you require the source to a package (so you can compile the package yourself if you so wish, or look into debugging a problem with a package), you can add deb-src as a extra line in the repositories.

We used kali-rolling for the branch above, but you can select any value you wish.

Updated on: 2021-Sep-27
Author: g0tmi1k

Источник

Finding Packages for Kali Linux

In an earlier post, we covered Package Management in Kali Linux. With the ease of installation that APT provides, we have the choice amongst tens of thousands of packages but the downside is, we have tens of thousands of packages. Finding out what packages are available and finding the one(s) we want can be a daunting task, particularly for newcomers to Linux. In this post, we will cover three utilities that can be used to search through the haystack and help you take advantage of the vast Open-source ecosystem.

apt-cache

Of the various interfaces available to search for packages, apt-cache is the most basic and rudimentary of them all. However, it is also the interface we tend to use most often because it is fast, easy, and efficient. By default, apt-cache searches for a given term in package names as well as their descriptions. For example, knowing that all Kali Linux metapackages include ‘kali-linux’ in their names, we can easily search for all of them.

In many cases, apt-cache returns far too many results because it searches in package descriptions. The searches can be limited to the package names themselves by using the —names-only option.

Since apt-cache has such wonderfully greppable output, we can keep filtering results until they’re at a manageable number.

You can further filter down the search results but once you start chaining together a few commands, that’s generally a good indication that it’s time to reach for a different tool.

aptitude

The aptitude application is a very close cousin of apt and apt-get except it also includes a very useful ncurses interface. It is not included in Kali by default but it can quickly be installed as follows.

After installation, running aptitude without any options will launch the ncurses interface. One of the first things you will notice is that you can quickly and easily browse through packages by category, which greatly helps with sorting through the thousands of available packages.

To search for a package, either press the / character or select ‘Find’ under the ‘Search’ menu. As you enter your query, the package results will be updated dynamically.

Once you’ve located a package of interest, you can mark it for installation with the + character or to remove/deselect it, the — character.

At this point, you can keep searching for other packages to mark for installation or removal. When you’re ready to install, press the g key to view the summary of the actions to be taken.

If you’re satisfied with the proposed changes, press g again and aptitude will complete the package installations as usual.

The Internet

If you want to restrict your searches to tools that are packaged by the Kali team, the easiest way to do so is probably by using the Google site search operator.

Learn More

Hopefully, this post will help you answer whether or not a certain tool is available in Kali (or Debian). For a much more detailed treatment of package management, we encourage you to check out the Kali Training site.

Источник

Advanced Package Management in Kali Linux

The Advanced Package Tool (APT) is how programs, libraries, documentation, and even the kernel itself are installed and managed on Kali and other Debian-based derivatives. APT often works so well that many users don’t pay any particular attention to it other than to perhaps search for and install programs and (hopefully) update their system regularly.

For most standard users, making use of APT this way is perfectly normal but we like to think that people who use Kali Linux are not standard users (in a good way) and so we are devoting this post to telling how you to get better use of APT and how to take advantage of the wide ecosystem of packages that are available, while keeping your Kali system stable and happy.

Many people will tell you that you should not rely on a package manager at all and instead, you should compile everything from scratch because you will learn more that way. While it’s certainly true that you will learn a lot, especially as you start out, building everything by hand will quickly devolve into tedium when you could be spending your time hacking or learning something new, preferably both.

In this post, we’ll show you how you can safely add additional package repositories to your Kali installation, how to upgrade and downgrade them, and how to ensure all of these repositories live in harmony. APT is very powerful and will evaluate the available packages from all sources as a whole when it formulates its solutions.

Adding Package Sources to Kali Linux

If you want to make your future self happy, you should not directly edit /etc/apt/sources.list directly. For each new package repository you add to your system, create a new file with a descriptive name (like debian-unstable.list) under /etc/apt/sources.list.d/. By leaving the original sources.list file untouched, if Kali needs to update it, it won’t interrupt you during the update, asking you which version of the file to keep.

In this post, we are going to add the Kali Bleeding-Edge repository and the Debian Unstable and Experimental repositories.

The kali-bleeding-edge Repository

The kali-bleeding-edge repository contains a number of tools that are very popular and change very frequently (even daily). It would be impractical and time-consuming to manually create and test updated packages so the packages in this repository are generated automatically whenever the upstream source changes. On the positive side, it means you are never more than 24 hours behind the upstream project but on the downside, these packages are not tested so you need to be aware that the packages in this repository may break from time to time.

You can add the repo and update the list of available packages as follows.

To install a package from kali-bleeding-edge, you need to append the repository name to the package name:

Fortunately, APT makes it an easy to downgrade back to the kali-rolling version of a particular package at any time, so there is no need to fear the packages in the kali-bleeding-edge repository. If you find that a package is broken in kali-bleeding-edge, you can revert back to the kali-rolling version in the same manner:

The Debian Unstable and Experimental Repositories

Kali Linux is a derivative of Debian Testing, which has more up-to-date software than Debian Stable. For even more recent software, there is the Debian Unstable distribution, which is a rolling development version of Debian, containing the most recent packages. When you encounter a bug in a Debian package, there might be a fixed version in the Debian Unstable repository so it is a good idea to add it to your Kali system. As with kali-bleeding-edge, the packages in Unstable may break from time to time.

Debian Experimental is yet another repository that contains packages that are under development. The packages in this repository are very current but can also be very buggy, more so than kali-bleeding-edge or Debian Unstable. APT will only install packages from this repository if you explicitly request them and you can always downgrade if things don’t work out.

As with the kali-bleeding-edge packages, if you want to install packages from unstable or experimental, append the repository name to the end of the package name as shown below.

Determining Package Priorities

In order to determine what packages get installed, APT has priorities assigned for all package sources, with the highest priority number taking precedence. A package with a priority of 0 will never be installed and a package with a priority over 1000 will always be installed, even if it means downgrading the package.

This is all well and good for APT but how can you, the user, see what the priority is of a given package? Enter the little-known ‘apt-cache’ command and its ‘policy’ option, which displays all of your configured repositories and their priorities.

You will note that kali-rolling, as the default distribution, has the highest priority at 990, meaning its packages take precedence over all others (which is what you want as a Kali user), followed by Debian unstable at 500, kali-bleeding-edge at 100, and lastly, experimental, with a lowly priority of 1. To see how these priorities apply to a given package, take a look at sqlmap.

Even though the version of sqlmap in kali-bleeding-edge is newer, it will not be installed because it only has a priority of 100, versus the installed version, which has a priority of 990. It is for this reason that when you want to install a package from a different package repository, it needs to be requested explicitly.

APT Configuration

Setting the Default Distribution

Now that you have some extra repositories added to your system, you will want to begin exploring and installing new packages, but before you do, it’s a good idea to tell APT what your default distribution is, which for Kali Linux users, is “kali-rolling”. This way your system won’t upgrade to some other distribution without your consent. Configure your default distribution by adding “APT::Default-Release “kali-rolling”;” to /etc/apt/apt.conf.d/local.

With your default distribution configured, any time you run ‘apt full-upgrade’, it will apply the upgrade to kali-rolling, helping keep your system stable.

Reducing Upgrade Prompts

If you use any Debian derivative for a significant amount of time, you will come across a prompt while running ‘apt upgrade’ asking you about a configuration file and whether you want to keep the local version, use the new version, or compare them. More often than not, you will find yourself accepting the default, making these interruptions wasteful.

You can avoid these prompts by updating your /etc/apt/apt.conf.d/local file with ‘DPkg::options < “–force-confdef”; “–force-confold”; >’ as shown below. This line tells APT to try to choose by itself if the files have not changed (–force-confdef) and if the files are different, keep the existing version (–force-confold).

Pinning Package Versions

Occasionally, you will find some application that needs a specific version of a particular package and will not work with any other. Other times, an update to one package might adversely affect other tools. This happened to us recently with an update to the devscripts package, which was preventing us from building Kali packages.

Fortunately, APT allows you to pin a package to a particular version by setting its priority to 1001 in /etc/apt/preferences. For example, to tell APT to hold the devscripts package at version 2.16.x, you would add the following.

Additional Resources

In this post, we have only been able to scratch the surface of how you can extend APT far beyond the default Kali or Debian ecosystem. The solver algorithms are very effective and running into issues is rare, so you need not fear exploring other repositories. To learn more about APT and how to bend it to your will, we encourage you to refer to Kali Linux Revealed and The Debian Administrator’s Handbook, both of which contain a wealth of information, tips, and tricks.

Источник