9.3 Filing Good Bug Reports

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

9.3 Filing Good Bug Reports

Key Takeaways Explain This Topic AI

File Kali packaging bugs at bugs.kali.org, tool-functionality bugs with the upstream project's issue tracker, and bugs in packages inherited unmodified from Debian in the Debian Bug Tracking System (BTS)

A version suffix like 0kali1 marks a Kali-modified package; kali.org/tools shows whether Kali packages a tool at all, and pkg.kali.org (the Kali Package Tracker, linked from every tool page) shows how the packaged version compares with upstream

reportbug is Debian's command-line bug-reporting tool: it checks the BTS for existing reports, collects system and package version information, and emails the report to the BTS

A good bug report contains minimal numbered reproduction steps, exact OS and package versions, complete verbatim error output and logs, and a clear statement of expected versus actual behavior

The bug tracker is not a support channel — one bug per report, search for duplicates first, and answer developer follow-up questions promptly

Last updated: July 2026

9.3 Filing Good Bug Reports

Kali is built by a small team, and high-quality bug reports are one of the most valuable contributions a user can make. But a report only helps if it lands in the right tracker and contains enough detail to reproduce the problem. The KLCP exam tests both halves: choosing the venue and writing the report.

Three Venues: Kali, Upstream, Debian

Because Kali is based on Debian Testing , every package on your system has one of three origins, and each origin has its own tracker:

Kali-specific packages and modifications — the kali-menu, metapackages like kali-linux-default, Kali's custom kernel patches, installer issues, and Kali-applied patches to tools. These go to bugs.kali.org , the Kali bug tracker.

The tool's own functionality — when the defect is in the software itself (a scanner crashes on valid input, a feature behaves wrongly) and would affect any distribution, report it to the upstream project , usually its GitHub or GitLab issue tracker. kali.org/tools links to each tool's upstream source.

Packages inherited unmodified from Debian — much of the base system (coreutils, openssh, most libraries) flows straight from Debian. Bugs in these belong in the Debian Bug Tracking System (BTS) at bugs.debian.org.

Telling Them Apart

Misrouting is the most common beginner failure, so learn the forensic steps:

Check the version string with apt policy <package> or apt show <package> . A suffix like 0kali1 (for example 2.3-0kali1 ) means Kali modified or rebuilt the package — report to Kali. A plain Debian revision (like 2.3-1 ) with no kali marker usually means the package came through unmodified.

Check the maintainer field in apt show <package> : Kali-maintained packages list the Kali team; Debian-maintained ones list a Debian maintainer.

Check kali.org/tools to see whether Kali packages the tool, then follow its Package Tracker link to pkg.kali.org, which shows how the packaged version compares with upstream.

Test whether the bug is in the software or the packaging. If the tool fails because a file is missing from the .deb, a dependency is wrong, or a Kali patch broke something, that is packaging (Kali's tracker). If the upstream source itself is defective — verifiable by testing the same version from the developer's own repository — report upstream.

Why does the exam care? Because filing in the wrong place hurts everyone: a Debian bug posted on bugs.kali.org will be closed by Kali's team (they cannot fix Debian's package), an upstream bug posted to Kali sits until the developer who never sees it fixes it, and the reporter waits weeks for nothing. Fifteen minutes of provenance checking gets the report in front of someone who can actually act on it.

Using bugs.kali.org

The Kali bug tracker runs MantisBT , a web-based tracker. The workflow:

Create an account and — before anything else — search existing reports . Duplicates dilute maintainer attention; if your bug exists, add your details as a note instead.

Choose the right category — the tracker's fixed set is General Bug, Kali Package Bug, Kali Package Improvement, Feature Requests, Tool Upgrade Request, New Tool Requests, Kali Websites & Docs, and Queued Tool Addition (the last is reserved for the Kali tool team). Anything attributable to a package belongs under Kali Package Bug or Kali Package Improvement.

Fill the fields honestly : a summary that names the tool and the failure ('aircrack-ng 1.7-0kali1 segfaults on WPA handshake capture'), the reproducibility (always, sometimes, random), and an accurate product version value — but leave severity , priority , assign to , target version and tags unmodified, because the book states those fields are for the developers.

Attach evidence : log files, screenshots, core dumps where relevant.

Monitor the issue and respond when a developer asks for more information; reports whose reporters vanish get closed as unactionable.

The reportbug Tool

For bugs that belong to Debian, the standard client is reportbug , available as a package and run from the command line: sudo apt install reportbug

reportbug openssh-server

reportbug walks you through the process: it queries the BTS for existing reports on the package (so you can spot duplicates), prompts for a subject and description, automatically attaches system information such as package versions and configuration status, and submits the report by email to the BTS. The exam expects you to recognize reportbug as Debian's dedicated reporting tool — not apt , not dpkg , which have no bug-reporting function.

Anatomy of a Good Bug Report

Whatever the tracker, an actionable report contains the same elements. Think of it as giving a stranger everything needed to see the failure on their own machine:

Environment : Kali version ( cat /etc/os-release ), kernel ( uname -a ), and the exact package version ( apt policy <package> ).

Minimal, numbered reproduction steps starting from a clean state: '1. Install X. 2. Run this exact command. 3. Observe the crash.' Remove every step that is not required to trigger the bug.

Expected versus actual behavior , stated explicitly: 'Expected: a pcap file is written. Actual: segmentation fault after banner.'

Complete, verbatim error output — full messages, not paraphrases — plus relevant logs from journalctl , dmesg , or the tool's own log files.

One bug per report. Bundling three issues into one ticket makes it impossible to close and easy to ignore.

Proof the bug still exists in the current version. Run sudo apt update && sudo apt full-upgrade and retry before filing — developers run the latest version and will close reports for bugs they have already fixed. If Kali does not yet ship the newest upstream release, test it in a throw-away VM or check the upstream changelog, and say so in the report.

What you already tried , including workarounds, so developers can skip dead ends.

Bug Tracker Etiquette

Close the loop on the chapter's theme: the tracker is a work queue, not a help desk. Do not file questions ('how do I install...'), do not bump tickets with 'any update?' comments days after filing, and be courteous — the person reading your report is the person who will fix it. A precise, reproducible, correctly routed report is often fixed within days; a vague 'it's broken, please investigate' note — a real pattern on bugs.kali.org — is closed with a pointer to the forums and the submission guidelines at kali.org/docs/community.