Migrate docs from https://github.com/rapid7/metasploit-framework/wiki …

…to main repository

metasploit-framework.wiki/2017-Roadmap-Review.md

@@ -0,0 +1,27 @@
+# Metasploit's 2017 Roadmap Review
+
+In 2017, we published our first open roadmap for Metasploit development. How did we do? For achievements:
+
+ * The Metasploit data model backend: we did a lot of design work on this, and got a couple of initial Proof-of-Concept project built. You can see a video of it here: <https://www.youtube.com/watch?v=hvuy6A-ie1g>. In the mean time, we started merging parts of the main development branch
+
+ * The first pass of external session handling landed with the metasploit-proxy project. 
+
+ * Independent modules that run in isolation _did_ land, along with a hand full of new modules demonstrating the advantages of the design, including multi-language support.
+
+ * The ruby_smb project made a lot of progress, with support incorporated into several existing modules. Full client-side support is also available for testing now.
+
+ * Native iOS and macOS support landed, along with many new IoT and router exploits.
+
+ * Meterpreter shrank almost 4x thanks to the new cryptTLV packet obfuscation support, and the removal of OpenSSL.
+
+Things we didn't quite finish:
+
+ * Metasploit's RESTful interface was not complete in 2017, so we will continue it into 2018.
+
+ * Session handling as a separate process was implemented with the <https://github.com/rapid7/metasploit-aggregator> project, but more work needs to be done to improve scalability and usability.
+
+ * Asynchronous session support remains on the drawing board.
+
+ * SOCKS5 support did not land, but Metasploit did gain a lot more support for running modules externally as separate processes, and gained initial support for running modules in Python.
+
+ * Modernized payload generation with new tools continues to be researched.

metasploit-framework.wiki/2017-Roadmap.md

@@ -0,0 +1,30 @@
+# Metasploit's 2017 Roadmap
+
+Starting in 2017, we will provide an open roadmap for setting our goals for the year. The goals are based on many discussions we have had over the past year with users, developers, and customers. The intent is to provide focus for core developers and contributors alike, so that we can together work toward a common vision for how we want Metasploit to evolve.
+
+This year, the themes for Metasploit are modularity, reusability, and reliability.
+
+Metasploit has grown organically over the years into a very large project, combining thousands of modules, payloads, a database, session handling, user interaction and more into a single monolithic application. While the design has served us well, it has reached some limits for maintainability and agility. While we continue to refactor, improve, and reorganize Metasploit, large-scale improvements become increasingly difficult and highlight fragility in the overall system, due to its highly interdependent design.
+
+We want to allow users to effortlessly contribute to the portions of Metasploit they are interested in, and be able to reuse code, both from inside and and outside of the project. Language and licensing constraints have presented barriers to users, both real and imagined. Python, Go, C# and other languages are dominating influences on the infosec community. We would like to be able to welcome more developers, researchers, and tooling into the Metasploit ecosystem, taking advantage of the best-in-breed and avoiding not-invented-here syndrome wherever possible.
+
+In short, we want to develop reusable, modular, and reliable services to enable researchers, pen-testers, students, and red-teamers to work efficiently, have access to the latest technologies and techniques, and to continue to grow the Metasploit community.
+
+## The roadmap
+
+ * The Metasploit data model backend should be separated into its own project. Plans include a data service that provides a RESTful interface, both an event-oriented and classic workspace-oriented view of incoming data, improved performance, and easy direct interoperability with other tools.
+
+ * Session handling should be able to operate independently of framework, allowing users to share sessions and allowing servers to be as performant, reliable, and light-weight as possible. We have already begun a project called 'metasploit-aggregator' which is a first generation of this design. Once this is complete, direct integration into other frameworks should also be possible.
+
+ * Metasploit should support asynchronous sessions. Many testers today use asynchronous frameworks like Empire to maintain light-weight persistence or a footholds into a network, then have to pivot to Meterpreter for interactive sessions. We would like to be able seamlessly support both modes of operation, including the ability to run post exploitation modules and modules over pivots asynchronously as well.
+
+ * Metasploit should support running exploit and auxiliary modules in an isolated mode. Plans are underway to support supporting an RPC-style module API to Metasploit framework, providing core services like payload and session handling, network routing, reporting and logging. Modules are run as child processes to Metasploit, and are only loaded into memory as-needed. Networking from a module point-of-view will be handled via SOCKS5 proxy support, hooking the child environment, or remote API calls, largely removing the need for specially-crafted socket objects or changes to 3rd-party protocol libraries. Modules, when written for the Metasploit API, could even be tested and used independently from the full Metasploit framework.
+
+In addition to these primary goals, we'd also like to explore:
+
+ * *SMB 2.0* SMB 1.0 increasingly being disabled in many networks, making Metasploit modules using this protocol ineffective. We would like to implement at least server-side support for SMB 2.0, both for sharing files and for named pipe communications.
+ * *iOS and macOS support* The mettle and python meterpreter payloads will continue evolving to further support OS X and iOS, along with more post exploitation support.
+ * *Native Android support in Mettle* We began the work last year with mettle now supporting all of the basic operations for a Meterpreter implementation. We would like to continue adding Android post-exploitation capabilities to mettle as well.
+ * *Streamlining Windows Meterpreter* mettle soon will replace the original POSIX meterpreter, which will reduce the size of the Windows meterpreter. Switching from OpenSSL to native SChannel support will simplify and shrink Windows meterpreter, allowing to focus on what it supports best.
+ * *Router and IoT research* We would like to continue research and support for embedded device exploitation and first-class support for resource-constrained environments.
+ * *Modernizing payload generation* We are investigating being able to integrate with third-party toolchains for building assembly, C, .NET, Java, on the fly, making it easy for a user to acquire the and use the tools, while providing first-class support for many architectures and platforms.

metasploit-framework.wiki/API.md

@@ -0,0 +1,3 @@
+View the latest API docs at:
+
+[https://rapid7.github.io/metasploit-framework/api/](https://rapid7.github.io/metasploit-framework/api/)

metasploit-framework.wiki/Adding-Release-Notes-to-PRs.md

@@ -0,0 +1,69 @@
+Release notes inform our users about the stuff we're shipping in each release. By looking at our release notes, our users should be able to easily understand what's new, what's fixed, and what's changed in the release. Therefore, **all PRs, except for minor fixes and tweaks, must have release notes.**
+
+To add a release note to a pull request, you'll need to add it as a comment, like so:
+
+![Release Notes Example](https://i.imgur.com/dgzQxyD.png)
+
+You'll need to tag the comment for inclusion in the release notes by using the `# Release Notes` heading. After you apply the release notes heading, you can enter the release notes text you want to use. 
+
+That's it! After you add the release notes text, we'll be able to extract them from the pull requests when we run our release notes script and compile them into a single document. 
+
+## Writing Release Notes 
+
+Okay, so now that you know how to add a release note, you're wondering what you're supposed to write. 
+
+Basically, a release note summarizes the pull request and describes the value of the fix/feature to the user. Each release note has a title, a PR number, and a brief description. 
+
+Here's an example of what a release note looks likes:
+
+>The Beholder plugin automatically captures keystrokes, screenshots, and webcam snapshots from your active sessions. Run this plugin to collect data from your compromised targets every 30 seconds. 
+
+## Types of Release Notes
+
+There are three types of release notes:
+* [Enhancement](#release-notes-for-enhancements)
+* [Fix](#release-notes-for-fixes)
+* [Modules](#release-notes-for-modules)
+
+### Release Notes for Enhancements
+
+An enhancement indicates that an improvement or new feature has been added to the framework. Enhancements include things like auxiliary modules, post-exploitation modules, and new payloads. 
+
+When you write release notes for an enhancement, you should try to answer the following questions:
+
+* What is the enhancement?
+* Why is it valuable or important to users?
+* How can they use it?
+
+For example, the following is a release note for an enhancement:
+
+> The new  'resolve' command enables you to perform DNS lookups with Meterpreter, without leaving the session to run additional modules. To resolve host names on the target, you can run the 'resolve' command followed by the host name. For example, in the Meterpreter prompt, you can type something like 'resolve rapid7.com' to view the host resolutions for Rapid7.
+
+### Release Notes for Fixes
+
+A fix is for an issue that caused a particular feature or functionality to not work the way it's expected to work. Basically, a defect indicates that something was broken, and we've fixed it. 
+
+When you write release notes for a fix, you should try to answer the following questions:
+
+* What was broken?
+* How was it fixed?
+* Why is this important to users? 
+
+Here's an example for a fix: 
+
+> The email header contained duplicate date and subject headers, which caused email servers like AWS SES, to reject the emails. This fix removes the duplicate headers so that campaigns can send emails successfully. 
+
+### Release Notes for Modules
+
+An exploit is a module that takes advantage of a vulnerability and provides some type of access to the target. We call out exploits explicitly because they're the hotness.
+
+When you write release notes for an exploit, you should try to answer the following questions:
+
+* What vulnerability is the module exploiting?
+* What type of access can you achieve with the module?
+* Do you need credentials to exploit the vulnerability?
+
+And finally, here's an example for exploits:
+
+> This module allows you to exploit HP Data Protector, a backup and recovery system, to remotely upload files to the file share. Versions 6.10, 6.10, and 6.20 are vulnerable. You don't need to authenticate to exploit this vulnerability. 
+

metasploit-framework.wiki/Assigning-Labels.md

@@ -0,0 +1,52 @@
+Maintainers can assign labels to both issues and pull requests.
+
+### Docs
+
+Documentation changes, such as YARD markup, or README.md, or something along those lines.
+
+### External
+
+Touches something in /external, or the Gemfile, or something like that.
+
+### Heartbleed
+
+Has to do with heartbleed. This will go away soon, but there are three outstanding still...
+
+### Library
+
+Touches something in /lib.
+
+### Meterpreter
+
+Has to do with Meterpreter, or depends on a Meterpreter change to land to work.
+
+### Misc
+
+Plugins and scripts, anything that's not otherwise defined.
+
+### Module
+
+Touches something in /modules
+
+### Specs
+
+Has specs (an rspec test)
+
+### Newbie Friendly
+
+Something that's pretty easy to test or tackle.
+
+### attic
+
+When we move something to the attic it means that what you submitted is a thing that we want but the circumstances were not quite right for landing it. Sometimes this is on us, and sometimes the contribution needs more work. We recognize that contributors work on the PRs they submit at their own pace. Take a look at the comments and review suggestions on your PR, and feel free to re-open it if and when you have time to work on it again. Don't think you'll be able to get it across the finish line? Find a community champion to do it for you.
+
+### Needs unique branch
+
+Your submitted a PR from your `master` branch.
+
+Because of how GitHub tracks changes between branches and what got added in a particular PR, we don't accept contributions from the `master` branch of your fork. All branches are [required to be unique](https://github.com/rapid7/metasploit-framework/blob/master/CONTRIBUTING.md#code-contributions). If your PR is closed because of this, create a new branch with that code and we'll be happy to look at it again!
+```
+git checkout -b <BRANCH_NAME>
+git push <your_fork_remote> <BRANCH_NAME>
+```
+This helps protect the process, ensure users are aware of commits on the branch being considered for merge, allows for a location for more commits to be offered without mingling with other contributor changes and allows contributors to make progress while a PR is still being reviewed.