First time Kali Linux unveils a roadmap that highlights the changes and the new features coming to Kali Linux in the following year.

The Kali Linux team is “trying to balance our efforts between changes that are user facing and those that apply 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.

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. 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 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. 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 on 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.

For this infrastructure to be as useful as it can be, we will need to have runtime test 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 request 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 tools.kali.org.

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 and FISH 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 docs.kali.org and tools.kali.org, 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

Updates for NetHunter to support with the latest version of Android, and various bug fixes. Starting from Kali NetHunter 2019.2 the support enhanced for more than 50 devices running KitKat through to Pie.

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 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.


By admin

Leave a Reply

Your email address will not be published. Required fields are marked *