TL;DR: Please stop using SVN with

svn co https://www.metasploit.com/svn/framework3/trunk

and start using the GitHub repo with

git clone git://github.com/rapid7/metasploit-framework

As of today, a few of you may notice that an attempt to update Metasploit Framework over SVN (instead of git or msfupdate) results in an authentication request. If you try to SVN checkout on Windows, using TortoiseSVN, you will see a pop up much like this:

For command line people, if you try to ‘svn co‘ or ‘svn up‘ your checkout of Metasploit Framework you will read:

Please don‘t try any passwords you think you know. We‘ve locked up SVN and we‘re using the authentication realm to communicate the correct update path to humans in a way readable by human eyeballs. The password prompt is incidental. If you‘ve read this far, you might wonder why we‘re doing this.

On November 10, 2011, we moved our source control to GitHub, and we‘ve been bugging people to use git instead of SVN ever since. However, the Internet exists in an eternal present tense. There are thousands and thousands documents, blog posts, books, and articles on ‘Getting Started with Metasploit‘ in practically every human language spread all over the world, both on and offline, some of which we control, most of which we don‘t. If you don‘t believe me, just search for "svn co" metasploit.

Because of this, we‘re not ready to turn off SVN completely -- throwing a 404 error on an update will just generate more (than usual) complaints on Twitter, IRC, and mailing lists about ‘svn co‘ and ‘svn up‘ being broken. Those complaints are still happening today, so it‘s clear that some people are still stuck with way-out-of-date documentation. Hopefully, those folks will read the instruction in the HTTP authentication realm, since that‘s about the only way we can communicate with SVN-only clients.

If you are still on SVN, then converting to GitHub works like this:

1. Don‘t try to use a password; if by some miracle you happen to guess a correct one, your prize is that you get some messed up, out of date SVN-sourced code. (:
2. Delete your SVN checkout of Metasploit: rm -rf $HOME/metasploit (or the real path to your checkout).
3. Clone the latest from GitHub: git clone --depth=1 git://github.com/rapid7/metasploit-framework metasploit (or the path where you want the clone).
4. Go to your new Metasploit checkout, and run msfupdate: cd metasploit; ./msfupdate (this will get the bundle of Ruby gems together for you).

If you can‘t use the git:// URI handler, then use https:// instead. It‘s somewhat slower, but still a million times better than SVN. If bundler complains about gem dependencies, then check to make sure that you have a reasonable version of Ruby -- 1.9.3 is ideal. 1.8.x is out. 2.0.0 should be okay, but it‘s not vetted for prime time yet.

That‘s it. Everything will work as before -- your custom modules that you stashed in $HOME/.msf4/modules will be picked up, you will be gleefully tracking Metasploit‘s bleeding edge source branch, and now, your checkouts won‘t take hours and crash out on you.

If you use Metasploit Community, Metasploit Express, or Metasploit Pro, then basically none of this applies to you -- msfupdate was converted in Metasploit 4.5 to use use weekly updates, which means you‘re getting the benefit of both Rapid7 QA and community testing without bothering with git or SVN.

Below, you can find a smattering of documents and posts regarding msfupdate and tracking the Framework source, which will provide more detail on various aspects of the continuous state of Metasploit development. If your setup is not the simple case described here, you will probably find what you need in one of these documents:

Metasploit Development Environment · (metasploit-framework wiki)

Git while the gitting is good

Metasploit Moves from SVN to Git/GitHub

Update to the Metasploit Updates and msfupdate

Activating Metasploit to fix msfupdate: Start to Finish

[转至官方] https://community.rapid7.com/community/metasploit/blog/2013/05/20/git-clone-metasploit-dont-svn-checkout