Comment 102 for bug 102212

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 address hidden>
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 address hidden>
Cc: <email address hidden>, <email address hidden>

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 address hidden>> 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