Metasploit Bug Reporting

Metasploit Bug Reporting

As any open source software grows in popularity, there is a tendency to see an increase in bug report volume against that software coupled with a corresponding decrease in bug report quality. We are not against getting bug reports for Metasploit -- we need bug reports in order to know what's broken. So, rather than trying to stem the tide of bugs, this page will attempt to make sure that each bug report we get is written in a way that maximizes its chances of actually getting resolved.

That said, there are two situations where you generally oughtn't open a bug at all, and that's when you have a support contract, or when you've found a security issue with Metasploit itself.

Support Contracts

If you have a support contract for a Metasploit product, you ought to get in touch with your Rapid7 support representative, or write to [email protected]. The people who work Metasploit support full time are really pretty with-it are likely to have a fix or a workaround for you on the spot.

Security Issues

If you have a security issue with Metasploit itself, then we'd really appreciate it if you let us know at [email protected]. After all, we'd like to be treated as we treat other software projects. It's not because we'd like to bury your bug -- we'd just like to have a shot at fixing your bug before someone starts messing with our innocent users. We're happy to give you credit, keep you anonymous, inform you about progress, and explore related issues with you -- but if we see someone reporting security bugs out in public, then it gets a lot harder to keep all that attribution and communication straight as we try not to break our necks implementing a fix as fast as we can.

Also, if you could report your security bug in the form of a Metasploit module sent to [email protected], that would be both ideal and hilarious.

That should cover the cases where you shouldn't open a bug at all, so let's move on to our main issue tracking system, Redmine.

Redmine

The final destination for bug reports in Metasploit is our Redmine issue tracker. In order to file bug reports, you must first create an account. Sadly, we can't take anonymous bug reports at this time due to spam, but we are actively exploring ways to make the registration as painless as possible.

In casual conversation, when we ask, "is there a bug?" or refer to "the bug tracker" or simply "Redmine," we're nearly always talking about this system.

Avoiding Duplicates

You may not be the first person to notice the problem you're running into, so here are some strategies for ensuring that a previously reported bug gets attention.

If you're having a problem with a particular module, you might try searching that module's name to see if there's anything already reported. If your bug has a particular error message, look for that.

Another tactic is to simply glance at the most recent bugs, especially if you suspect this a new bug in a process you're sure used to work before.

If you happen to find the bug you're experiencing, updating that report with any new information is hugely helpful in coming to a resolution. You might also find resolved bugs that describe your problem, which indicates a regression (old bugs reintroduced) -- the fixes for those are usually fast, so noting likely regressions is quite useful.

Finally, you might find a bug that's been rejected or closed. In these cases, the problem is usually something external to Metasploit -- user error, configuration weirdness, known incompatibilities, etc. If you think that the original resolution was in error, though, open a new bug and point out what you think the problem is. After all, if people keep running into the same non-bug, then it's probably at least a documentation bug, and maybe something real.

Describing your bug

Submitting Patches

Following your bug