Kali is a large project made up of many different parts. Some of these parts are more obvious, like the tools making up Kali or the theme and wallpapers that are used. Other parts may be a bit less obvious, like the community that supports us and the mirrors that host the packages so people can download and update their installation. There is one thing in common with all of these areas, and that is community contribution. Without mirrors to host our data, Kali could take much longer to update than it may now. We always welcome contributions, and detailed below are some of the ways you may be able to contribute as well.

Our documentation is made up of two parts. The first is typically referred to as the “Kali Docs,” which includes information about how to install Kali and things to do after. The other part is referred to as “Kali Tools,” which includes information about how to use tools and learn where the tools originate from.

Contributing to our documentation pages is a huge help. This helps other Kali users better understand and be more familiar with different parts of Kali and things related. Most likely, you are reading this on our docs right now. These pages need to be understandable, accurate, and easy to read. This means things like typos, grammatical mistakes, information that is missing or could be expanded on, and new ideas that could be added are important to either correct or create a ticket to track it. Because we host our documentation off of GitLab, and write it using markdown, anyone is able to view and edit the source material and, if they wish, create a merge request to correct the issue. More information on how to create a merge request can be found here.

Penetration testing makes up the bulk of Kali use cases. Being a penetration testing distribution, knowing how to use the tools included is pretty important. To help users who may not be familiar with a certain tool understand basic functionality and use cases, we have kali.org/tools/. Located here is information that helps users to know how to use a tool and where to go for more information if needed. In an ideal world, each one of these pages would be detailed with all sorts of use cases and show the tools in action. If there is a page you feel should have more information, submitting a ticket or merge request would be very helpful.

The Kali community is spread out through many different platforms and apps, however there are only three official platforms we are on. The first is on Discord, the second our very own forums, and finally is our bug tracker. Helping in any of these communities is very much appreciated.

Discord is a real time chat app that encourages live discussion. The Kali Linux & Friends Discord server is one of the main places for people to chat with others regarding Kali and share ideas or interesting information. While not a support server, it is common to see others willing to help people who want to learn and grow. If you want to help others out, share things related to Kali, or just talk with people that have similar interests, check out our server.

The Kali Linux Forums are a place where people can request support, share tools, give feedback, and much more. Anyone is able to go to our forums and help point others in the right direction or maybe even share a fix to an issue they’ve encountered themselves. The forums are a great place to help out as they are permanent. As long as the website is up, the information on it will always be able to be found. This is different to Discord, where information can be lost pretty easily.

The Bug Tracker is a great place to help out Kali, whether reporting a bug or helping to fix one. When reporting a bug, we ask that you follow our documentation on how to. When helping others with their bug reports, we ask that you use information you know is trust worthy. Helping out on a bug tracker ticket can be as simple as just being able to reproduce the problem or as complex as submitting a merge request to fix the issue yourself. Everything is appreciated.

Packaging is the core of Kali. Packages are what helps tools to be so easy to install, and insures they are up-to-date with no bugs. Debian packaging is a complicated thing that takes a while to learn, but if you are willing to do so can help quite a bit to know.

When there is a new update from upstream (in most cases, this is the tool creator) it is important we get that update verified and out as soon as we can. To do this we must first package up the new update, test the resulting .deb file to ensure it works as expected and includes anything new, then sign it and release it. For most people, this process is not something they would be able to do without first learning Debian packaging. If you were to discover that a tool is outdated, and don’t know packaging, you could instead create a bug report about the outdated tool.

With the number of tools out there that users want to see in Kali, there is no way we can get them all on our own. A perk of us being on GitLab is that we can easily accept packages submitted by users, to learn more check out our Public Packaging page. If you would like to help but don’t know of a package that should be done, we have a list that can be chosen from. A great example of a user-contributed package is kali-desktop-i3 which is help maintained by Arszilla.

When dealing with packages we may encounter updates that may break functionality. Something that helps to catch these problems are autopkgtests. These tests are defined by the packager, and can range from a simple help output test to a full package functionality test. While extremely helpful, they also take time to develop and in most cases require intimate knowledge of the tool being tested. For more information on the actual process of creating them, please refer to the following page. It would be very helpful to have contributions to this effort of creating more advanced autopkgtests for all of the tools in Kali.

Mirrors are what helps get Kali to users all around the world. Mirrors host our files for things like installation isos or tool packages. The more mirrors we have in different parts of the world, the better the experience is for users. If the closest mirror is a few countries away, it will likely take a lot longer to perform an update than if there is a mirror in the same country as the update is being done. If you are in a position where you can help to host a Kali mirror, please refer to our Mirror Policy Page to learn more.