Kali Linux Roadmap (2019/2020)
Published: 2023-08-21 21:15:17

---
title: Kali Linux Roadmap (2019/2020)
published: true
date: 2019-06-19 00:00:00 UTC
tags: 
canonical_url: https://www.kali.org/blog/kali-linux-roadmap-2019-2020/
---

Now that our 2019.2 release is out, we thought we would take this opportunity to cover some of the changes and new features we have coming to Kali Linux in the following year. Normally, we only really announce things when they are ready to go public, but a number of these changes are going to impact users pretty extensively so we wanted to share them early.

As you read through this post, what you will see is that we are really trying to balance our efforts between changes that are user facing and those that are applicable to the backend. The backend changes don’t seem as exciting at first, but the fact is that the easier it is for us to work on Kali, the easier it is for us to get to user facing features. Plus, some of these changes are focused on tweaking the development process to make it easier for others to get involved in the project.

We are not ready to announce dates on any of these changes just yet. When they are ready, they will drop.

### GitLab - The New Home for Kali Packages

One of the biggest changes, which you may have already noticed, is our move of the Official Kali git repository to [GitLab](https://gitlab.com/kalilinux). With this change, it’s easier than ever for the community to submit improvements to Kali packages and for us to apply them! We expect to make an heavy use of the GitLab Continous Integration features to streamline our work on packages and to provide automated feedback to all the contributors submitting merge requests.

Documentation is coming soon on how to contribute packages. Expect a full guide to be published in [our docs](https://www.kali.org/docs/) later.

### Runtime Tests - Finding Bugs Before Users

Speaking of packages, the detection of bugs and problems with the packages is always something to improve. Until now, we have relied on manual testing on our part and [user-provided bug reports](https://bugs.kali.org/). This works ok, as popular packages would never stay broken for long but some edge packages could break for months at a time before anyone would notice and actually report it to us. (Let’s be honest, most of the time when you find something broken in Kali, you don’t create a bug report do you?)

To improve this situation, we have recently deployed [debci](https://salsa.debian.org/ci-team/debci) on [autopkgtest.kali.org](https://autopkgtest.kali.org/). This allows us to have our own continuous integration system, allowing for automated testing of Kali packages on a regular basis. We have integrated the result of those tests in the [Kali Package Tracker](https://pkg.kali.org/teams/kali-developers/).

For this infrastructure to be as useful as it can be, we will need to have [runtime tests](https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst) on all our packages, which is still a long way off. Hopefully, this will be a place where we **get community help to speed up the process** , so feel free to submit [merge requests](https://gitlab.com/kalilinux/packages) adding tests!

### Metapackages - What is Installed by Default

One of the biggest challenges with running a project like Kali Linux is balance. We now have so many users that there’s no longer “one right size”. Traditionally, what people have asked for is “all the tools, all the time”. But as time has gone by, this has led to one of the largest (pun fully intended) issues with Kali: Bloat. Too many packages making too big of a distribution, large ISO sizes, etc. etc.

To address this, we are giving our metapackages a refresh. This change includes the default Kali metapackage, “kali-linux-full”, the metapackage that controls what packages are installed on Kali by default. Needless to say, this is a big user-facing change that will impact everyone. Tools that we decide to drop are most often older tools that don’t have a lot of modern utility, have not been updated in years, or have been supplanted by newer better tools.

What this means is that by default, some of the tools you may have relied upon may no longer be included by default. These tools will still exist in the repo, so you can install them manually or use a metapackage that contains them. You can see full documentation of the metapackages and what they contain at [kali.org/docs/general-use/metapackages/](https://www.kali.org/docs/general-use/metapackages/)

Before these changes go live, we will do another blog post detailing them. Expect that these metapackages will be in flux for a bit as we continue to optimize.

### Default Shell - Your Primary Kali Interface

The shell in Kali is likely the most used utility in the entire distribution for the majority of users. This creates a bit of a schizophrenic challenge in that it’s used so much we want to improve it, but at the same time we have to make sure it does not break.

To address this, we will be adding default installations of [ZSH](https://en.wikipedia.org/wiki/Z_shell) and [FISH](https://en.wikipedia.org/wiki/Friendly_interactive_shell) to Kali. Each of these shells are optimized for penetration testers, which is sort of fun. Most of the time when you look at shell optimization, all the text is focused on developers, which is not where Kali sits. Our goal here is to have the best, most optimized, shell environment for penetration testers.

At the same time, good old Bash won’t go away and we are going to leave it as the default for now. Those of you that want to be adventurous and try the new shells will find easy ways to switch. Those of you that just want to stick with Bash will still be able to. Expect in-shell instructions (and a blog post) when this change is rolled out.

### Documentation - Read The Fine Manual

Expect some changes to [**kali.org/docs/**](https://www.kali.org/docs/) and [**kali.org/tools/**](https://www.kali.org/tools/), along with an integration of the Kali manual into git via markdown. This will allow for user submitted documentation to help us keep instructions up to date and accurate. This is another great way for you to contribute to the Kali Linux project.

### NetHunter - New Blood

As you may have noticed on Twitter and git commits, we have got another developer on board, “[@Re4son](https://twitter.com/Re4sonKernel)”, and he has put the [NetHunter](https://www.kali.org/get-kali/#kali-mobile) project into overdrive. He is working on supporting new hardware, working with the latest version of Android, and various bug fixes.

There is also “ **Project Redback** ”, but that is all we are going to say about that for the time being…more about this in a blog post very soon.

### What Else can we Expect?

This is just the portion of the roadmap that makes sense to talk about now. There is a lot more in development that we are just not ready to talk about yet.

We also would like to welcome [@g0tmi1k](https://twitter.com/g0tmi1k) who has switched over from [OffSec](https://www.offsec.com/) as a full time core [Kali developer](https://www.kali.org/about-us/).

We are at a really exciting stage of the Kali development process, where a lot of the behind the scenes items we have been working on are getting ready to go public. Expect a fair amount of improvements in Kali Linux over the next half of the year. If you want to discuss this post with us or have ideas on things that we might consider, please get in touch via [the forum](https://forums.kali.org/showthread.php?44470-Kali-Linux-Roadmap-(2019-2020)&p=86334#post86334).