OK, sounds good. Like I said, I don't have much time to deal with it right now as I am moving so San Francisco. keep me posted if you guys make any significant progress (ie, they fix it on their end or rework the license). metasploit is a tool by them, for them, and we have the benefit of seeing the code and using it for free. they have no obligation to change anything to suit a distro's needs. just keep that in mind ;-P
On 8/30/07, Justin M. Wray <[EMAIL PROTECTED]> wrote: > 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 direct subscriber > of the bug. > -- Kristian Erik Hermansen -- [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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
