[needs-packaging] Metasploit Framework

What is it?
The Metasploit Framework is a development platform for creating security tools and exploits. The framework is used by network security professionals to perform penetration tests, system administrators to verify patch installations, product vendors to perform regression testing, and security researchers world-wide. The framework is written in the Ruby programming language and includes components written in C and assembler.

What does it do?
The Metasploit Framework consists of tools, libraries, modules, and user interfaces. The basic function of the framework is a module launcher, allowing the user to configure an exploit module and launch it at a target system. If the exploit succeeds, the payload is executed on the target and the user is provided with a shell to interact with the payload.

http://framework-mirrors.metasploit.com/msf/download.html
--
Kristian Hermansen

The required packages:

# aptitude install ruby libruby rdoc libyaml-ruby libzlib-ruby libopenssl-ruby libdl-ruby libreadline-ruby libiconv-ruby rubygems libgtk2-ruby libglade2-ruby
# gem install -v=1.2.2 rails

http://metasploit.com/dev/trac/wiki/Metasploit3/InstallUbuntu
--
Kristian Hermansen

The license of this package dont permit the packaging.

Please read the license *before* ask to package a software.

Isn't it released under the GPL2 ? :
http://www.metasploit.com/projects/Framework/docs/userguide/node68.html

NO!
It's released under Metasploit Framework license. The OLD Metasploit 2.0 was GPL.
Your simply must, download, unpack, and read the copyright.

On 7/14/07, Alessandro Tanasi <email address hidden> wrote:
> NO!
> It's released under Metasploit Framework license. The OLD Metasploit 2.0 was GPL.
> Your simply must, download, unpack, and read the copyright.

I just emailed the developers to see if there is some way we can work
this out. They are cool guys, and are not trying to prevent
distribution. They are trying to prevent people reselling the
product. How can we distribute Metasploit for Ubuntu, to ease
installation and user accessibility, but give the developers what they
want as well? If Sun can distribute their packages on Ubuntu, then
Metasploit should be able to as well with some sort of license
agreement screen, etc, on installation as the 'sun-java6-bin' package
does (among others).

This is not a technical issue. It is merely a legal and political
hindrance that can be overcome by working together to satisfy all
parties involved. Let's make it work.
--
Kristian Hermansen

I make my work, and i have metasploit already packaged ready to upload on ubuntu repos.
But i can't.

And... Canonical *sell* ubuntu.
And... i am not sure that Metasploit, due to his license, can be modified for packaging.

On 7/14/07, H D Moore <email address hidden> wrote:
> The license does allow for packaging, provided that the software is not
> modified and is not sold for a value above the cost of distribution. A
> number of free software distributions include Metasploit 3 in
> the "non-free" trees.

Thanks for clarifying dude. OK, so if we can all agree that the
package will not be modified or sold, and Alessandro has a package
ready to go, let's get it into Ubuntu. Do you think that metasploit
would fit into universe or multiverse? I would think that it is free
enough for universe according to

http://www.ubuntu.com/community/ubuntustory/components

but if there are any doubts it probably should be placed into
multiverse. The major factor here would be how "free" metasploit is
considered to be if the sources cannot be modified for distribution.
That might make it ripe for the multiverse category...
--
Kristian Hermansen

Ok, great!
But before write my first comment here i talk with a couple of motu in #ubuntu-motu, they thinks that metasploit cant be in ubuntu, but if the author write this, he know sure the license better :)
The problem is that the software must be modified to be a good debian package, for example i have removed the .svn directory that is crap in a package, and so on..

On 7/14/07, Alessandro Tanasi <email address hidden> wrote:
> Ok, great!
> But before write my first comment here i talk with a couple of motu in #ubuntu-motu, they thinks that metasploit cant be in ubuntu, but if the author write this, he know sure the license better :)
> The problem is that the software must be modified to be a good debian package, for example i have removed the .svn directory that is crap in a package, and so on..

Great! Let's put together a list of items that need to be modified in
the package, and we will present them to H D and see if he will OK
them or show us a clause that allows such simple modifications. How
does that sound?
--
Kristian Hermansen

Sounds great!

The todo list is:
- remove all .svn directory, that are crap in a deb package
- if its possible rename the tar.gz and the directory inside to metasploit
- if its possible fix ruby path from #!/usr/local/bin/ruby to debian compliant in :
E: metasploit: wrong-path-for-ruby ./usr/share/metasploit/external/ruby-pcapx/examples/tcpdump.rb #!/usr/local/bin/ruby
E: metasploit: wrong-path-for-ruby ./usr/share/metasploit/external/ruby-pcapx/examples/test.rb #!/usr/local/bin/ruby
E: metasploit: wrong-path-for-ruby ./usr/share/metasploit/external/ruby-pcapx/examples/httpdump.rb #!/usr/local/bin/ruby
- fix the following permissions:
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/common/crypto.h
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/extensions/stdapi/server/sys/process/process.c
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/output/extensions/ext_client_net.dll
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/client/module.c
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/extensions/stdapi/stdapi.h
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/data/msfweb/public/stylesheets/window-themes/metasploit/titlebar-mid-shaded-focused.png
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/data/vncdll.dll
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/data/msfweb/public/stylesheets/window-themes/metasploit/frame-bottom-left-focused.png
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/workspace/metsrv/metsrv.dsp
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/common/remote.c
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/extensions/stdapi/server/net/config/route.c
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/client/metcli.def
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/data/msfweb/public/stylesheets/window-themes/metasploit/titlebar-left-shaded-focused.png
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/vncdll/winvnc/vncdll/vncdll.dsw
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/extensions/stdapi/server/ui/keyboard.c
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/extensions/stdapi/server/net/net.h
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/extensions/stdapi/server/sys/config/config.h
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/meterpreter/source/extensions/boiler/client/boiler.c
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/external/source/passivex/PassiveX.bin
W: metasploit: executable-not-elf-or-script ./usr/share/metasploit/data/msf...

On 7/18/07, Alessandro Tanasi <email address hidden> wrote:
> Sounds great!
>
> The todo list is:

These seem relatively easy. How are we building the package after the
changes are made. If you give me the steps, I can make one on my
amd64 box, but it shouldn't really matter in this case, since this is
all interpreted code. Just let me know what your method was for
building the completed DEB...
--
Kristian Hermansen

When the author release the new tar.gz i upload the deb that i have ready.
I think that the first thing is that the author make a new tar.gz

On 7/19/07, Alessandro Tanasi <email address hidden> wrote:
> When the author release the new tar.gz i upload the deb that i have ready.
> I think that the first thing is that the author make a new tar.gz

So you want the metasploit dev team to release a new tar.gz with the
changes you requested previously so that your DEB is legal to the
license agreement (unchanged package)? Do I understand you correctly?
--
Kristian Hermansen

The only 2 options that i see to get metasploit in ubuntu are:
1) that we have a special agreement to package it, modifing metasploit license (hard to do)
2) that dev team release a new version debianization friendly (i think easy to do)

On 7/20/07, Alessandro Tanasi <email address hidden> wrote:
> The only 2 options that i see to get metasploit in ubuntu are:
> 1) that we have a special agreement to package it, modifing metasploit license (hard to do)
> 2) that dev team release a new version debianization friendly (i think easy to do)

OK, let's go for option two. How about you whip up a script to make
the changes you propose, so that all the MSF devs need to do is run
it, and then we have the package just as we want. How does that
sound? Do you want to write it or have me do it? I don't care,
either way...
--
Kristian Hermansen

On 7/22/07, Kristian Hermansen <email address hidden> wrote:
> OK, let's go for option two. How about you whip up a script to make
> the changes you propose, so that all the MSF devs need to do is run
> it, and then we have the package just as we want. How does that
> sound? Do you want to write it or have me do it? I don't care,
> either way...

I took the liberty of cleaning up metasploit3 and wrote a script to
help. Surely there are bugs, but let me know if it makes lintian
complain less. If you have any questions let me know. Let's get
metasploit3 into ubuntu asap! I think hdm will like it if we can just
put everything into this one script and he can check out svn and run
it, then make a tar.gz.

Let me know if you need any help with the next step. I want to get
this going quickly. Thanks dude!
--
Kristian Erik Hermansen

Kristian Hermansen, thanks again for marking the other bug as a duplicate. I missed this one when I added.

I too have a packaged version, from the unmodified metasploit release, it is more then possible to build the deb with the SVN, as SVN is used to update the exploits, and other framework modules. May not be the ideal build, but can work.

Either way, if you want to modify the "original package" we can simply write a patch, and place it in the debian/ directory. But again, doesn't seem modifications are necessary, everything builds fine. And that is when we start to interfere with the license.

The real issue here isn't the "ease" of packaging metasploit, but the license itself.

So do we have the license issue resolved? In what other ways can I assist? Alessandro Tanasi we should trade .changes to see where we can improve the package, before upload to REVU.

I am really looking forward to getting metasploit in the Ubuntu repositories.

Thanks,
Justin M. Wray

On 8/14/07, Justin M. Wray <email address hidden> wrote:
> I too have a packaged version, from the unmodified metasploit release,
> it is more then possible to build the deb with the SVN, as SVN is used
> to update the exploits, and other framework modules. May not be the
> ideal build, but can work.

Someone has claimed that leaving .svn around is against debian policy,
which would be understandable...

> Either way, if you want to modify the "original package" we can simply
> write a patch, and place it in the debian/ directory. But again,
> doesn't seem modifications are necessary, everything builds fine. And
> that is when we start to interfere with the license.

Yes, the problem is modification and distribution...

> The real issue here isn't the "ease" of packaging metasploit, but the
> license itself.

Yup :-) msf2 is GPL, but not msf3...

> So do we have the license issue resolved? In what other ways can I
> assist? Alessandro Tanasi we should trade .changes to see where we can
> improve the package, before upload to REVU.

hdm is busy at the moment, so we will hear from the msf devs when they
get some free time. msf3 won't make it into Gutsy anyways, right?
Unless there is some way we can get it into gutsy there is no reason
to rush. If you know a cut off date for gutsy, let me know, but I
thought the cutoff for universe/multiverse was when they did the pull
from debian unstable, which is relatively early in the cycle...

> I am really looking forward to getting metasploit in the Ubuntu
> repositories.

Me too :-)
--
Kristian Erik Hermansen

Here is the script I whipped up...let me know if you find any issues with it...

Here is the script I whipped up...let me know if you find any issues with it...

Change name to [needs-packaging] Metasploit Framework 3.0.

Thanks,
Justin M. Wray

> Someone has claimed that leaving .svn around is against debian policy,
> which would be understandable...
We need to check into this a bit more, as I asked about the policy (when I started working on MSF), and was told, it is not against policy, just frowned upon. The problem, without the SVN updates, the user would be unable to pull the new exploits and modules. And its almost pointless to repackage and distribute the entire binary deb every time one exploit is released, which may only be 15 lines of Ruby. If we do decide to scrap the SVN update capability, we will need to come up with a update path for exploits/modules.

Seems in this case we just ignore the SVN issue.

Also, some of the errors linda/lintian is producing are due to the windows files packaged within MSF and the fact that some of the ruby modules aren't set as executable. This can easily be fixed by a patch (if not safely ignored).

> Here is the script I whipped up...let me know if you find any issues with it...
Can you create a diff patch of the end result of your script. That it what we would use in the Package, as well as what the MSF devs would want to see.

Thanks,
Justin M. Wray

Sorry -- Seems Launchpad added some of my responses as "quotes," thus I reposted.

> Someone has claimed that leaving .svn around is against debian policy,
> which would be understandable...

We need to check into this a bit more, as I asked about the policy (when I started working on MSF), and was told, it is not against policy, just frowned upon. The problem, without the SVN updates, the user would be unable to pull the new exploits and modules. And its almost pointless to repackage and distribute the entire binary deb every time one exploit is released, which may only be 15 lines of Ruby. If we do decide to scrap the SVN update capability, we will need to come up with a update path for exploits/modules.

Seems in this case we just ignore the SVN issue.

Also, some of the errors linda/lintian is producing are due to the windows files packaged within MSF and the fact that some of the ruby modules aren't set as executable. This can easily be fixed by a patch (if not safely ignored).

> Here is the script I whipped up...let me know if you find any issues with it...

Can you create a diff patch of the end result of your script. That it what we would use in the Package, as well as what the MSF devs would want to see.

Thanks,
Justin M. Wray

On 8/21/07, Justin M. Wray <email address hidden> wrote:
> Pulled the latest snapshot from (Rev:5080), however all of the
> permission issues are still present.

The permissions issues are able to be modified, and do not fall under
the relevant source code changes policy. They did fix the ruby files
though, right? So, let me know if you need help modifying the
permissions. We can do it manually for this first build, and talk to
the msf boys again later. Do you want me to take over the package
upload from here, or do you want to finish up with the permission
issues and submit it?
--
Kristian Erik Hermansen

Kristian:

     I already have a patch to correct the permission errors, so I can easily apply that to the Rev:5080 build. However, after looking through the linda/lintian output, the Ruby paths are not corrected either. I do not think the changes have been released upstream. We should speak to the upstream developers again.

     As soon as we have a clean build I'll put this up for testing, and then submission, as long as there are no issues. We have eight more days, if by the 24th, the changes are not applied upstream, I'll submit the package as is, and see what we can do. Hopefully worst case scenario we just upload a fix down the road.

Thanks,
Justin M. Wray

So is it officially in Gutsy now? Can I "sudo aptitude update && sudo
aptitude install metasploit3" ??
--
Kristian Erik Hermansen

Not yet, I have uploaded to my PPA, (not sure the status of that system yet). I will upload to REVU now...time to face the fire.

Thanks for all of the assistance.

Thanks,
Justin M. Wray

On 8/27/07, Justin M. Wray <email address hidden> wrote:
> Not yet, I have uploaded to my PPA, (not sure the status of that system
> yet). I will upload to REVU now...time to face the fire.

I know some of the packaging people at Canonical/Ubuntu. If they give
you a hard time, mention Kristian Erik Hermansen from Cisco aka "The
Clonezilla Dude" :-)
--
Kristian Erik Hermansen

On 8/27/07, Justin M. Wray <email address hidden> wrote:
> ** Changed in: ubuntu
> Status: In Progress => Fix Committed

I just updated my Gutsy install, but I don't see it. Has it made it
into multiverse yet? This is the last day. Do you want me to get on
#ubuntu-motu and coordinate this with you?
--
Kristian Erik Hermansen

* Now talking on #ubuntu-motu
* Topic for #ubuntu-motu is: Ubuntu Masters of the Universe:
https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs?
https://wiki.ubuntu.com/MOTU/Contributing | http://ubuntu.joejaxx.org/
- TOP 10 Uploaders/Packages | REVU is back up on a new box at the same
url. | Gutsy new package freeze is 30 August
* Topic for #ubuntu-motu set by ScottK at Mon Aug 27 01:40:02 2007
* #ubuntu-motu :[freenode-info] if you need to send private messages,
please register: http://freenode.net/faq.shtml#privmsg
<khermans_> got a new packages, metasploit3
<khermans_> has justin wray come by to try adding it yet?
<khermans_> bug marked as FIX COMMITED
<khermans_> if anyone has this info, please contact me
<khermans_> <email address hidden>
<khermans_> looking to get metasploit into multiverse for Gutsy,
package was made earlier
<khermans_> thanks...
* jml has quit (Read error: 110 (Connection timed out))
* jml (<email address hidden>) has joined
#ubuntu-motu
* jdong has quit (Read error: 110 (Connection timed out))
* mayday_jay has quit ("Leaving")
* TheMuso has quit (Read error: 110 (Connection timed out))
* elkbuntu has quit (Read error: 110 (Connection timed out))
* blackskad (<email address hidden>) has joined #ubuntu-motu
* elkbuntu_ is now known as elkbuntu
* vil has quit ("Leaving.")
* jml has quit ("Ex-Chat")
* jml (<email address hidden>) has joined
#ubuntu-motu
* Paddy_EIRE has quit (""so shave your face with some mace in the dark"")
<RAOF> khermans_: Didn't that have crazy licencing problems?
<khermans_> RAOF, yeah but its all worked out
<RAOF> Ah, cool.
<khermans_> RAOF, we found that basiclaly anything can be placed in
multiverse if it allows redistribution
<RAOF> What bug is marked as fix committed, incidentally.
<khermans_> https://bugs.launchpad.net/ubuntu/+bug/102212
<ubotu> Launchpad bug 102212 in ubuntu "[needs-packaging] Metasploit
Framework 3.0 (multiverse)" [Wishlist,Fix committed]
<khermans_> so i am wondering when the package will be installable form apt
<khermans_> i updated to latest Gutsy, apt update, but dont see it
* gusguus has quit ()
<khermans_> if you find out, please let me know
<khermans_> i am damn tired, moving from boston to san francisco, got
tons to do tonight and tomorrow
<khermans_> but i wanted to make sure this was all set since cutoff
date is tomorrow
<RAOF> khermans_: Aaah, so it's actually on REVU now, presumably.
<khermans_> the 30th... for multiverse new package
<khermans_> REVU ?
<RAOF> khermans_: http://revu.tauware.de/details.py?upid=121
<khermans_> i am reading the second hit
<khermans_> https://wiki.ubuntu.com/MOTU/Packages/REVU
<khermans_> hrmm i dont see it in there...
* ScottK2 (n=kitterma@72-254-80-101.client.stsn.net) has joined #ubuntu-motu
<khermans_> oh ok nm
<khermans_> it is in there
<khermans_> http://revu.tauware.de/details.py?upid=121
<RAOF> khermans_: It looks like it needs some work.
<khermans_> RAOF, a few things, but not much
* ceros_ has quit (Remote closed the connection)
<khermans_> the errors from linda are warnings, intentionally we left them in
<khermans_> lintian warnings...

Set to incomplete as further packaging/license issues are worked out.

Thanks,
Justin M. Wray

Kristian:

     Thank you for following-up in #ubuntu-motu as I have been busy the past few evenings. As I assumed would happen, the package has been rejected. This is obviously due to the multiple errors and issues that we were having (and unable to resolve due to the license).

     Unless we have these issues resolved today/tomorrow metasploit will not make it into the Gutsy release. We need to speak with the MSF Dev team a bit further and see what we can do.

Thanks,
Justin M. Wray

I said that .svn dirs must be removed ;)
A package for being accepted must be lintian *clean*, so i think, as i prev said:
1) we get a good package from dev team
2) we get an execption from ubuntu-dev

>I said that .svn dirs must be removed ;)
A package for being accepted must be lintian *clean*, so i think, as i prev said:
1) we get a good package from dev team
2) we get an execption from ubuntu-dev

Completely agree, we were just trying to see if we could get past this for the time being.

I think the best solution is as follows:

1) We split metasploit into the following packages -
     * metasploit-core (Containing all the core components, including CLI)
     * metasploit-web (Containing all of the msfweb files)
     * metasploit-gui (Containing all of the msfgui and needed files)
     * metasploit-data (Containing all exploits, modules, etc.)

2) Offer a way to automatically update the exploits and modules only (leaving core, web, and gui to be updated in future releases or with security concerns). Although we need to discuss how this should be approached, specific SVN, repackaging to the archive, a download script, etc.

The problem again, is how to we gain the ability to do such. The options are MSF distributes the upstream package as we have outlined above, or they allow an exception to the license that grants Ubuntu the right to modify the package and distribute in the way stated above.

But it is a long shot that they would repackage just to please one distro (even though other distros could benefit from such a release).
Worse it is unlikely any license exception or change will be seen until the next major release which should be accompanied by a new license.

Which leaves us hanging without a metasploit release again...feedback?

I wonder if the MSF team would be willing to create a separate SVN trunk for Ubuntu specifically, in which they release under the layout above?

Thanks,
Justin M. Wray

I agree with everything you mentioned here, especially braking up the
packages. I am actually glad that Ubuntu is rejecting it :-) it
shows me that people care about what packages make it into the
repositories and results in a high quality system for the users. I am
a long time user since Warty :-) So, looks like we need to puch this
back to the MSF team so they can clean up their act. They may not
even want to, and for that, we can do nothing. So, for myself, I will
just continue pulling down sources manually until they work out a new
license and/or ways to deal with these issues. They may not care,
since it is their tool for their use, and we have the fringe benefit
of being able to use it. Oh well...we tried. I won't work on this
any more. I'll let you guys take over if you like. The MSF guys
don't seen to have time or want to fix these things, at least as far
as I can tell. Maybe they do, but they don't care if it makes it into
a distro or not...

On 8/29/07, Justin M. Wray <email address hidden> wrote:
> >I said that .svn dirs must be removed ;)
> A package for being accepted must be lintian *clean*, so i think, as i prev said:
> 1) we get a good package from dev team
> 2) we get an execption from ubuntu-dev
>
> Completely agree, we were just trying to see if we could get past this
> for the time being.
>
> I think the best solution is as follows:
>
> 1) We split metasploit into the following packages -
> * metasploit-core (Containing all the core components, including CLI)
> * metasploit-web (Containing all of the msfweb files)
> * metasploit-gui (Containing all of the msfgui and needed files)
> * metasploit-data (Containing all exploits, modules, etc.)
>
> 2) Offer a way to automatically update the exploits and modules only
> (leaving core, web, and gui to be updated in future releases or with
> security concerns). Although we need to discuss how this should be
> approached, specific SVN, repackaging to the archive, a download script,
> etc.
>
> The problem again, is how to we gain the ability to do such. The
> options are MSF distributes the upstream package as we have outlined
> above, or they allow an exception to the license that grants Ubuntu the
> right to modify the package and distribute in the way stated above.
>
> But it is a long shot that they would repackage just to please one distro (even though other distros could benefit from such a release).
> Worse it is unlikely any license exception or change will be seen until the next major release which should be accompanied by a new license.
>
> Which leaves us hanging without a metasploit release again...feedback?
>
> I wonder if the MSF team would be willing to create a separate SVN trunk
> for Ubuntu specifically, in which they release under the layout above?
>
> 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

>I won't work on this any more.

I would strongly encourage you not to abandon this effort. As the only way to resolve this issue is to work harder, and obviously closer to the MSF Dev team. And I would like to think they do want to see their product released within the Ubuntu repositories.

>shows me that people care about what packages make it into the repositories and results in a high quality system for the users

I think that has been a selling point for Debian/Ubuntu for years...

I'll forward my comments to the metasploit team, and see what we can do...

Thanks,
Justin M. Wray

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 r...

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.
>
>
> ...

Nobody followed up on the lintian/linda errors on: http://revu.tauware.de/details.py?package=metasploit

Hi Daniel,

On Nov 25, 2007 11:04 PM, Daniel Holbach <email address hidden> wrote:
> Nobody followed up on the lintian/linda errors on:
> http://revu.tauware.de/details.py?package=metasploit

I submitted patches to H.D. Moore and the Metasploit team to fix many
of the errors. However, they decided that they were too busy to
modify metasploit for inclusion in Debian/Ubuntu. The Metasploit
license non-standard and does not allow modification of the source by
anyone other than the msf developers, but does allow redistribution in
an unaltered form. With this in mind, H.D. said they would sort it
out when they draw up a new license for a future release of msf,
possibly version 4.0. As it stands now, we are tied by that license
and cannot proceed. H.D. Moore did integrate some of my patches, but
not all of them that were required to fix this package for inclusion
in Ubuntu :-(
--
Kristian Erik Hermansen

What about uploading the proposed-for-gutsy deb package to getdeb.net?

Hi all, just wanted to point out that Metasploit has changed to a 3-clause BSD license. Just wondering if packaging can take place now, it's a shame such a good tool isn't already in the Ubuntu repos.

quoting from http://trac.metasploit.com/browser/framework3/trunk/README

"
31 The Metasploit Framework is provided under the BSD license above.
32
33 The copyright on this package is held by Metasploit LLC.
34
35 This copyright does not apply to the following components:
36 - The vncdll.dll binary or its associated source code (modified RealVNC)
37 - The icons used by msfweb that were not created by the Metasploit Project
38 - The Ole::Storage library located under lib/ole
39 - The Scruby library located under lib/scruby
40 - The PcapRub library located under external/pcaprub
41 - The Ruby-Lorcon library located under external/ruby-lorcon
42 - The Byakugan plugin located under external/source/byakugan
"

I have been gathering license information on the extra code in Metasploit and it seems like most are under the GPL. Here's what I have:
LICENSES:
Metasploit framewok = BSD
pcaprub = gpl
ratproxy = Apache License 2.0
lorcon = ?
byakugan = ?
dllinject = ?
ipwn = GPLv2 / Perl Artistic License
meterpreter = ?
passivex = ?
unixasm = gplv2
vncdll = gplv2
msf = Metasploit Framework License
Still looking into it though, if anyone has any info I would love some help

You have some errors between LGPL and GPLv2. I've tried to look into
source code and README and LICENSE files.

This is what I could come up with:
Metasploit framework: 3-clause BSD

I have looked into:
1) lib directory
2) external directory

"N/A" means "No license found", I suppose those follow the 3-clause
BSD metasploit framework has.

lib/msf: Metasploit Framework License (3-clause BSD?)
http://trac.metasploit.com/browser/framework3/trunk/lib/msf
(hasn't been updated for 2 years)

lib/metasm: GNU Lesser General Public License (LGPL)
http://trac.metasploit.com/browser/framework3/trunk/lib/metasm/LICENCE

lib/bindata: GNU General Public License (GPL) version 2
http://trac.metasploit.com/browser/framework3/trunk/lib/bindata/LICENSE

lib/net: Ruby license (GNU General Public License - GPL):
http://trac.metasploit.com/browser/framework3/trunk/lib/net/dns/README
http://www.ruby-lang.org/en/about/license.txt

lib/packetfu: 3-clause BSD
http://trac.metasploit.com/browser/framework3/trunk/lib/packetfu/LICENSE

lib/rabal: N/A
http://trac.metasploit.com/browser/framework3/trunk/lib/rabal/tree.rb

lib/rex: 3-clause BSD
http://trac.metasploit.com/browser/framework3/trunk/lib/rex/LICENSE

lib/scruby: GNU General Public License (GPL) version 2
http://trac.metasploit.com/browser/framework3/trunk/lib/scruby/LICENSE

lib/zip: Ruby license (GNU General Public License - GPL)
http://trac.metasploit.com/browser/framework3/trunk/lib/zip/README

lib/telephony: N/A
http://trac.metasploit.com/browser/framework3/trunk/lib/telephony/modem.rb

pcaprub: GNU Lesser General Public License (LGPL)
http://rubyforge.org/projects/pcaprub/
http://trac.metasploit.com/browser/framework3/trunk/external/pcaprub/LICENSE

ratproxy: Apache License 2.0
( http://code.google.com/p/ratproxy/ )

ruby-lorcon: GNU General Public License (GPL) version 2
http://802.11ninja.net/lorcon/browser/trunk
http://rubyforge.org/projects/ruby-lorcon/

byakugan plugin: N/A
http://trac.metasploit.com/browser/framework3/trunk/external/source/byakugan

vncdll: GNU General Public License (GPL) version 2
http://trac.metasploit.com/browser/framework3/trunk/external/source/vncdll/LICENCE.txt

Ole::Storage: GNU General Public License (GPL) version 2
http://trac.metasploit.com/browser/framework3/trunk/lib/ole/LICENSE

unixasm: GNU Lesser General Public License (LGPL)
http://trac.metasploit.com/browser/framework3/trunk/external/source/unixasm/COPYING

passivex: Same as Metasploit Framework (3-clause BSD)
http://trac.metasploit.com/browser/framework3/trunk/external/source/passivex/HttpTunnel.cpp

dllinject: N/A
http://trac.metasploit.com/browser/framework3/trunk/external/source/dllinject/README

meterpeter: N/A
http://trac.metasploit.com/browser/framework3/trunk/external/source/meterpreter

shellcode: Same as Metasploit Framework (3-clause BSD)
http://trac.metasploit.com/browser/framework3/trunk/external/source/shellcode/linux/ia32/generic.asm

Removing assignment, as the package in http://revu.ubuntuwire.net wasn't updated for a while