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