Just an update, we are working with the metasploit team, to hammer out some of the issues with the current package, etc.
Please see the below email for communication between myself and the team-lead. Thanks, Justin M. Wray ---------- Forwarded message ---------- From: Justin Wray <[EMAIL PROTECTED]> Date: Aug 30, 2007 10:01 AM Subject: Re: Fwd: [Bug 102212] Re: [needs-packaging] Metasploit Framework 3.0 (multiverse) To: H D Moore <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Moore: With your permission, I would like to post your comments (as well as mine) to our "bug" (https://bugs.launchpad.net/ubuntu/+bug/102212 ) so others outside of this thread (including the package approvers) can keep track of our status. On 8/29/07, H D Moore < [EMAIL PROTECTED]> wrote: > > Hi Justin, > > We can likely help with some of these in the future, but there are some > things that we should clarify: I appriciate your willingness to help, and look forward to working with you and the rest of the metasploit team. 1) We will continue to use Subversion as a system for performing online > updates. This means any distribution will always contain .svn > directories. One solution, for a packager, is to give each user their own > Metasploit 3 installation and provide a script which extracts this > package and configures PATH/symlinks during the first use. This is how > Metasploit 3.1 will work on Windows and a simple way to avoid having > Subversion modify system-wide directories. I like the idea of each user having their own installation. Not only does it alleviate any issues implied by SVN and system-wide directories, but it also allows each user to keep their own patch level, and more importantly their own exploits. This then allows them to download third-party exploits (milw0rm and the like) and even write their own, without the fear of interfering with other users on the system. As such I will see what we can do about packaging metasploit in such a way, and at the same time keep the SVN update ability. 2) The license may change in the future, but we have no timeline set and > no requirements to be compatible with debian-legal. For what its worth, > our license was written by a lawyer and then reviewed again by a second > legal team as a sanity check. The license stipulations are standard for > EULAs and are not in line with what most folks consider open source. We > understand that this doesn't make packaging easy, but allowing other > people to distribute our software has not been a priority. This makes perfect sence, as does the motive behind such a restrictive license. However, this will cause the license to fall under the non-free category. Which requires a bit more user interaction and fore-thought in order to install. Thus it may scare some users away from trying metasploit, then again, if they do not know what metasploit is, they will most likely not be using it in the first place. Which I do not see as a bad thing. The major license issues we are having: * Limited ability to redistribute * The inability to redistribute changes (patches, etc) I understand that redistribution has not been a priority, and this honestly is a bunch of bureaucracy that hinders productivity, all licenses are. But allowing distributions (Ubuntu, Fedora, Suse, Backtrack) the ability to package should be something that is looked at, when the next license review comes along. The majority of users (even those who use metasploit) are far more comfortable installing packages from the distributions repositories. Some will go as far as requesting an application to be packaged and added to the distribution before they will install. It allows the user to keep a clean system and easily update all the applications. Dependencies are handled, updates are provided, and configuration complete, it makes installation painless. I also understand the wish to protect metasploit from re-branded and re-packaging. But there is ways to allow distribution of changes, while still retaining original copyright, name/branding, and maintainers etc. Thus protecting metasploit from thief but still allowing Ubuntu and others to make needed changes in order to have metasploit integrate cleanly into the distribution. 3) Splitting the package in a way that core, gui, web, and data is > separate will not happen. Exploit modules often depend on updates to the > libraries and APIs. At some point, we may freeze the API or enforce a > versioning system, but at this team the code is inter-dependent. Our intentions on this were two fold. First users may or may not want the web interface, or the gui. Others may just run the web interface, and some may only use the gui. It truly depends on the user, and each has different motives, experience, and opinions. Spiliting the package up allowed the user to control which part of metasploit was on the systems, those who never use the gui can easily leave it and the (then) un-needed dependencies off of their system. If they wish to have the gui and cli only, without the web, they can keep the system clear of the dependencies needed by the web portion of metasploit. This allows the user to be in control, and the reduction of un-needed dependencies. Our second motive for breaking the package up, is as follows; Debian and/or Ubuntu has this mentality against so-called "crack" also known as bleeding edge. Updates are throughly tested before release, etc. Spliting the package would allow us to "freeze" the core, web, and gui packages, and only allow updates to the -data package (which would contain exploits, modules, etc). This keep the "crack" updates to a minimal and to a specific package and location only. However as you explain the API is normally updated along with the exploits/modules. I really appreciate the work that Kristian, yourself, and the other Debian > folks have put into this, but we have been extremely short on time for > the last couple months and tearing up the code base to appease a > distributor is just not feasible. We have made note of the issues raised > and would like to streamline this in the future, but there just isn't > much we can do for you right now. Thanks! > > -HD Not only do I apprciate and respect the work you have done and provided for the Information Security community, but I also want to thank you for your willingness to collaborate with the Ubuntu community. I would also like to thank you for taking time out of your busy schedule and respond to emails like this one. Thanks, Justin M. Wray -- [needs-packaging] Metasploit Framework 3.0 (multiverse) https://bugs.launchpad.net/bugs/102212 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs