Skip to content

Commit 60d0667

Browse files
author
Tod Beardsley
committed
Land rapid7#3063, make CONTRIBUTING and HACKING useful
2 parents e638c3d + 9338b43 commit 60d0667

File tree

2 files changed

+87
-171
lines changed

2 files changed

+87
-171
lines changed

CONTRIBUTING.md

Lines changed: 66 additions & 42 deletions
Original file line numberDiff line numberDiff line change
@@ -1,44 +1,68 @@
11
# Contributing to Metasploit
22

3-
## Reporting Bugs
4-
5-
If you would like to report a bug, please take a look at [our Redmine
6-
issue
7-
tracker](https://dev.metasploit.com/redmine/projects/framework/issues?query_id=420)
8-
-- your bug may already have been reported there! Simply [searching](https://dev.metasploit.com/redmine/projects/framework/search) for some appropriate keywords may save everyone a lot of hassle.
9-
10-
If your bug is new and you'd like to report it you will need to
11-
[register
12-
first](https://dev.metasploit.com/redmine/account/register). Don't
13-
worry, it's easy and fun and takes about 30 seconds.
14-
15-
When you file a bug report, please include your **steps to reproduce**,
16-
full copy-pastes of Ruby stack traces, and any relevant details about
17-
your environment. Without repro steps, your bug will likely be closed.
18-
With repro steps, your bugs will likely be fixed.
19-
20-
## Contributing Metasploit Modules
21-
22-
If you have an exploit that you'd like to contribute to the Metasploit
23-
Framework, please familiarize yourself with the
24-
**[HACKING](https://github.com/rapid7/metasploit-framework/blob/master/HACKING)**
25-
document in the
26-
Metasploit-Framework repository. There are many mysteries revealed in
27-
HACKING concerning code style and content.
28-
29-
[Pull requests](https://github.com/rapid7/metasploit-framework/pulls)
30-
should corellate with modules at a 1:1 ratio
31-
-- there is rarely a good reason to have two, three, or ten modules on
32-
one pull request, as this dramatically increases the review time
33-
required to land (commit) any of those modules.
34-
35-
Pull requests tend to be very collaborative for Metasploit -- do not be
36-
surprised if your pull request to rapid7/metasploit-framework triggers a
37-
pull request back to your own fork. In this way, we can isolate working
38-
changes before landing your PR to the Metasploit master branch.
39-
40-
To save yourself the embarrassment of committing common errors, you will
41-
want to symlink the `msftidy.rb` utility to your pre-commit hooks by
42-
running `ln -s ../../tools/dev/pre-commit-hook.rb .git/hooks/pre-commit`
43-
from the top-level directory of your metasploit-framework clone. This
44-
will prevent you from committing modules that raise WARNINGS or ERRORS.
3+
Thanks for your interest in making Metasploit -- and therefore, the
4+
world -- a better place! What you see here in CONTRIBUTING.md is a
5+
bullet-point list of the do's and don'ts of how to make sure *your*
6+
valuable contributions actually make it into Metasploit's master branch.
7+
8+
If you care not to follow these rules, your contribution **will** be
9+
closed (*Road House* style). Sorry!
10+
11+
Incidentally, this is a **short** list. The
12+
[wiki](https://github.com/rapid7/metasploit-framework/wiki) is much more
13+
exhaustive and reveals many mysteries. If you read nothing else, take a
14+
look at the standard [development environment setup
15+
guide](https://github.com/rapid7/metasploit-framework/wiki/Setting-Up-a-Metasploit-Development-Environment)
16+
and Metasploit's [Common Coding Mistakes](https://github.com/rapid7/metasploit-framework/wiki/Common-Metasploit-Module-Coding-Mistakes).
17+
18+
## Code Contributions
19+
20+
* **Do** stick to the [Ruby style guide](https://github.com/bbatsov/ruby-style-guide).
21+
* **Do** follow the [50/72 rule](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) for Git commit messages.
22+
* **Do** create a [topic branch](http://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches) to work on instead of working directly on `master`.
23+
24+
### Pull Requests
25+
26+
* **Do** specify a descriptive title to make searching for your pull request easier.
27+
* **Do** include [console output](https://help.github.com/articles/github-flavored-markdown#fenced-code-blocks), especially for witnessable effects in `msfconsole`.
28+
* **Do** list [verification steps](https://help.github.com/articles/writing-on-github#task-lists) so your code is testable.
29+
* **Don't** leave your pull request description blank.
30+
* **Don't** abandon your pull request. Being responsive helps us land your code faster.
31+
32+
Pull requests [#2940](https://github.com/rapid7/metasploit-framework/pull/2940) and [#3043](https://github.com/rapid7/metasploit-framework/pull/3043) are a couple good examples to follow.
33+
34+
#### New Modules
35+
36+
* **Do** run `tools/msftidy.rb` against your module and fix any errors or warnings that come up. Even better would be to set up `msftidy.rb` as a [pre-commit hook](https://github.com/rapid7/metasploit-framework/blob/master/tools/dev/pre-commit-hook.rb).
37+
* **Do** use the [API](https://dev.metasploit.com/documents/api/). Wheel improvements are welcome; wheel reinventions, not so much.
38+
* **Don't** include more than one module per pull request.
39+
40+
#### Library Code
41+
42+
* **Do** write [RSpec](http://rspec.info/) tests - even the smallest change in library land can thoroughly screw things up.
43+
* **Do** follow [Better Specs](http://betterspecs.org/) - it's like the style guide for specs.
44+
* **Do** write [YARD](http://yardoc.org/) documentation - this makes it easier for people to use your code.
45+
46+
#### Bug Fixes
47+
48+
* **Do** include reproduction steps in the form of verification steps.
49+
* **Do** include a link to the corresponding [Redmine](https://dev.metasploit.com/redmine/projects/framework) issue in the format of `SeeRM #1234` in your commit description.
50+
51+
## Bug Reports
52+
53+
* **Do** report vulnerabilities in Rapid7 software to [email protected].
54+
* **Do** create a Redmine account and report your bug there.
55+
* **Do** write a detailed description of your bug and use a descriptive title.
56+
* **Do** include reproduction steps, stack traces, and anything else that might help us verify and fix your bug.
57+
* **Don't** file duplicate reports - search for your bug before filing a new report.
58+
* **Don't** report a bug on GitHub. Use [Redmine](https://dev.metasploit.com/redmine/projects/framework) instead.
59+
60+
Redmine issues [#8762](https://dev.metasploit.com/redmine/issues/8762) and [#8764](https://dev.metasploit.com/redmine/issues/8764) are a couple good examples to follow.
61+
62+
If you need some more guidance, talk to the main body of open
63+
source contributors over on the [Freenode IRC channel](http://webchat.freenode.net/?channels=%23metasploit&uio=d4)
64+
or e-mail us at [metasploit-hackers](https://lists.sourceforge.net/lists/listinfo/metasploit-hackers)
65+
mailing list.
66+
67+
Also, **thank you** for taking the few moments to read this far! You're
68+
already way ahead of the curve, so keep it up!

HACKING

Lines changed: 21 additions & 129 deletions
Original file line numberDiff line numberDiff line change
@@ -1,146 +1,38 @@
1-
# $Id$
1+
HACKING
2+
=======
23

3-
This file contains some brief instructions on contributing to the
4-
Metasploit Framework.
4+
(Last updated: 2014-03-04)
55

6-
Code Style
7-
==========
6+
This document almost entirely deprecated by:
87

9-
In order to maintain consistency and readability, we ask that you
10-
adhere to the following style guidelines:
8+
CONTRIBUTING.md
119

12-
- Standard Ruby two-space soft tabs, not hard tabs.
13-
- Try to keep your lines under 100 columns (assuming two-space tabs)
14-
- do; end instead of {} for a block
15-
- Always use str[0,1] instead of str[0]
16-
(This avoids a known ruby 1.8/1.9 incompatibility.)
17-
- Method names should always be lower_case and words separated by "_"
18-
- Variable names should be lower case with words separated by "_"
19-
- Don't depend on any external gems or libraries without talking to
20-
todb to resolve packaging and licensing issues
10+
in the same directory as this file, and to a lesser extent:
2111

22-
You can use the the "./tools/msftidy.rb" script to do some rudimentary
23-
checking for various violations.
24-
25-
26-
Code No-Nos
27-
===========
28-
29-
1. Don't print to standard output. Doing so means that users of
30-
interfaces other than msfconsole, such as msfrpc and msfgui, won't see
31-
your output. You can use print_line to accomplish the same thing as
32-
puts.
33-
34-
2. Don't read from standard input, doing so will make your code
35-
lock up the entire module when called from other interfaces. If you
36-
need user input, you can either register an option or expose an
37-
interactive session type specific for the type of exploit.
38-
39-
3. Always use Rex sockets, not ruby sockets. This includes
40-
third-party libraries such as Net::Http. There are several very good
41-
reasons for this rule. First, the framework doesn't get notified on
42-
the creation of ruby sockets and won't know how to clean them up in
43-
case your module raises an exception without cleaning up after itself.
44-
Secondly, non-Rex sockets do not know about routes and therefore can't
45-
be used through a meterpreter tunnel. Lastly, regular sockets miss
46-
out on msf's proxy and SSL features. Msf includes many protocols
47-
already implemented with Rex and if the protocol you need is missing,
48-
porting another library to use them is straight-forward. See our
49-
Net::SSH modifications in lib/net/ssh/ for an example.
50-
51-
4. When opening an IO stream, always force binary with "b" mode (or
52-
using IO#binmode). This not only helps keep Windows and non-Windows
53-
runtime environments consistent with each other, but also guarantees
54-
that files will be treated as ASCII-8BIT instead of UTF-8.
55-
56-
5. Don't use String#[] for a single character. This returns a Fixnum in
57-
ruby 1.8 and a String in 1.9, so it's safer to use the following idiom:
58-
str[idx,1]
59-
which always returns a String. If you need the ASCII byte, unpack it like
60-
so:
61-
tr[idx,1].unpack("C")[0]
62-
63-
6. Whenever possible, avoid using '+' or '+=' to concatenate strings.
64-
The '<<' operator is significantly faster. The difference will become
65-
even more apparent when doing string manipulation in a loop. The
66-
following table approximates the underlying implementation:
67-
68-
Ruby Pseudo-C
69-
----------- ----------------
70-
a = b + c a = malloc(b.len+c.len+1);
71-
strcpy(a, b);
72-
memcpy(a+b.len, c, c.len);
73-
a[b.len + c.len] = '\0';
74-
a = b a = b;
75-
a << c a = realloc(a, a.len+c.len+1);
76-
memcpy(a+a.len, c, c.len);
77-
a[a.len + c.len] = '\0';
78-
79-
Note that the original value of 'b' is lost in the second case. Care
80-
must be taken to duplicate strings that you do not want to modify.
81-
82-
7. For other Ruby 1.8.x/1.9.x compat issues, please see Sam Ruby's
83-
excellent slide show at <http://slideshow.rubyforge.org/ruby19.html>
84-
for an overview of common and not-so-common Ruby version related gotchas.
85-
86-
8. Never, ever use $global variables. This applies to modules, mixins,
87-
and libraries. If you need a "global" within a specific class, you can
88-
use @@class_variables, but most modules should use @instance variables
89-
to store information between methods.
90-
91-
9. Don't craft your XML document raw or by using Nokogiri, the current
92-
preferred way is REXML.
93-
94-
Creating New Modules
95-
====================
96-
97-
When creating a new module, the simplest way to start is to copy
98-
another module that uses the same protocol and modify it to your
99-
needs. If you're creating an exploit module, generally you'll want
100-
to edit the exploit() method. Auxiliary Scanner modules use one of
101-
run_host(), run_range(), or run_batch() instead of exploit().
102-
Non-scanner aux modules use run().
103-
104-
105-
Submitting Your Code
106-
====================
107-
108-
To get started with a Metasploit Framework source clone, simply:
109-
110-
- Fork rapid7/metasploit-framework to your GitHub account
111-
- git clone git://github.com/YourName/metasploit-framework.git
112-
- gem install bundler
113-
- bundle install
12+
The Metasploit Development Environment
13+
https://github.com/rapid7/metasploit-framework/wiki/Metasploit-Development-Environment
11414

115-
More detailed documentation regarding the process for submitting new
116-
modules via GitHub is documented here:
15+
Common Coding Mistakes
16+
https://github.com/rapid7/metasploit-framework/wiki/Common-Metasploit-Module-Coding-Mistakes
11717

118-
https://github.com/rapid7/metasploit-framework/wiki/Metasploit-Development-Environment
18+
The Ruby Style Guide
19+
https://github.com/bbatsov/ruby-style-guide
11920

120-
This describes the process of forking, editing, and generating a
121-
pull request, and is the preferred method for bringing new modules
122-
and framework enhancements to the attention of the core Metasploit
123-
development team. Note that this process requires a GitHub account.
21+
Ruby 1.9: What to Expect
22+
http://slideshow.rubyforge.org/ruby19.html
12423

125-
For Git commits, please adhere to 50/72 formatting: your commits should
126-
start with a line 50 characters or less, followed by a blank line,
127-
followed by one or more lines of explanatory text wrapped at at 72
128-
characters Pull requests with commits not formatted this way will
129-
be rejected without review.
24+
You can use the the "./tools/msftidy.rb" script against your new and
25+
changed modules to do some rudimentary checking for various style and
26+
syntax violations.
13027

131-
For modules, note that Author field is not automatic, and should be
132-
filled in in the format of 'Your Name <user[at]domain.tld>' so future
133-
developers can contact you with any questions.
28+
Licensing for Your New Content
29+
==============================
13430

135-
Licensing
136-
=========
13731
By submitting code contributions to the Metasploit Project it is
13832
assumed that you are offering your code under the Metasploit License
139-
or similar 3-clause BSD-compatible license. MIT and Ruby Licenses
33+
or similar 3-clause BSD-compatible license. MIT and Ruby Licenses
14034
are also fine. We specifically cannot include GPL code. LGPL code
141-
is accepted on a case by case basis for libraries only and is never
35+
is accepted on a case by case basis for libraries only and is never
14236
accepted for modules.
14337

144-
When possible, such as aux and exploit modules, be sure to include
145-
your license designation in the file in the appropriate place.
14638

0 commit comments

Comments
 (0)