[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/15/07, Justin M. Wray <email address hidden> wrote:
> 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.

You have a good point. If it is not against policy, and since this
package with be in multiverse anyways, and having updates is a good
thing obviously, let's leave them in! Thanks for making a valid point
to convince me. You are right. If it is not a hard rule for Debian,
it really does amkes sense to leave them in if we won't be penalized
for it -- due to the nature of security products and how quickly they
are updated. 6 months would be a long time to wait for a new release
:-)

> Seems in this case we just ignore the SVN issue.

Yup. Let's do it. Btw, the cutoff date for multiverse is August
30th. So, if we get the package in before that time, it will be in
Gutsy. I checked with #ubuntu-motu. Also, I asked them about the
license issues, and the only requirement for multiverse is that the
package is allowed to be redistributed. So, we will have metasploit
in Gutsy if we hurry up and get this done :-)

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

Just take my script, and comment out the clean_svn function at the
bottom. Run the other two cleanup routines, and let me know how
linda/lintian handles the result. Can you do that today?

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

The only files that need to be "modified" are the invalid Ruby script
paths (/usr/local/bin/ruby). In my script, I fix them to be
(/usr/bin/env ruby). I highly doubt that this constitutes a breach of
the Metasploit license agreement, as this portion of the code is not
the intellectual property. If we started to modify the logic, that
would be a problem, and that's what the license is trying to prevent.
All the other changes my script does are dealing with executable
permissions and trying to determine which files should or should not
be set. I think it worked fairly well.

So, get back to me when you have a moment. Maybe we can check in our
package into Gutsy before the weekend :-)
--
Kristian Erik Hermansen

Okay, I am away from my desk at the moment, I'll run the scrip as soon as I get back, creat the patch, and repackage. Then we can take a look at the linda/lintian output.

Thanks,
Justin M. Wray
Sent via BlackBerry by AT&T

-----Original Message-----
From: Kristian Hermansen <email address hidden>

Date: Wed, 15 Aug 2007 13:33:04
To:<email address hidden>
Subject: Re: [Bug 102212] Re: [needs-packaging] Metasploit Framework 3.0

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> 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.

You have a good point. If it is not against policy, and since this
package with be in multiverse anyways, and having updates is a good
thing obviously, let's leave them in! Thanks for making a valid point
to convince me. You are right. If it is not a hard rule for Debian,
it really does amkes sense to leave them in if we won't be penalized
for it -- due to the nature of security products and how quickly they
are updated. 6 months would be a long time to wait for a new release
:-)

> Seems in this case we just ignore the SVN issue.

Yup. Let's do it. Btw, the cutoff date for multiverse is August
30th. So, if we get the package in before that time, it will be in
Gutsy. I checked with #ubuntu-motu. Also, I asked them about the
license issues, and the only requirement for multiverse is that the
package is allowed to be redistributed. So, we will have metasploit
in Gutsy if we hurry up and get this done :-)

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

Just take my script, and comment out the clean_svn function at the
bottom. Run the other two cleanup routines, and let me know how
linda/lintian handles the result. Can you do that today?

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

The only files that need to be "modified" are the invalid Ruby script
paths (/usr/local/bin/ruby). In my script, I fix them to be
(/usr/bin/env ruby). I highly doubt that this constitutes a breach of
the Metasploit license agreement, as this portion of the code is not
the intellectual property. If we started to modify the logic, that
would be a problem, and that's what the license is trying to prevent.
All the other changes my script does are dealing with executable
permissions and trying to determine which files should or should not
be set. I think it worked fairly well.
...

Okay, ran the script, which did fix the permissions. I repackaged, and linda/lintian are now happy.

Thanks,
Justin M. Wray

> E: metasploit: wrong-path-for-ruby ./usr/share/metasploit/external/ruby-pcapx/examples/tcpdump.rb #!/usr/local/bin/ruby

Your script does _NOT_ seem to fix this error. However, I do not get that output with or without your patch.

Thanks,
Justin M. Wray

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> > E: metasploit: wrong-path-for-ruby ./usr/share/metasploit/external
> /ruby-pcapx/examples/tcpdump.rb #!/usr/local/bin/ruby
>
> Your script does _NOT_ seem to fix this error. However, I do not get
> that output with or without your patch.

It should! The clean_ruby_paths function should change three files
which have this issue. Does it not? I basically just do a sed on the
files and replace with (/usr/bin/env ruby). You could fix my script,
if it is broken, but don't think it is! Or you could write another
script/patch which does this. Or manually. Then we can get it
packaged and uploaded for Gutsy. We only have two weeks though. So,
let's hustle :-)
--
Kristian Erik Hermansen

Yeah I looked over the script, should have worked. I just wanted to let you know.

I will fix this, correct the rules, and repackage.

Thanks,
Justin M. Wray

Sent via BlackBerry by AT&T

-----Original Message-----
From: Kristian Hermansen <email address hidden>

Date: Wed, 15 Aug 2007 15:31:45
To:<email address hidden>
Subject: Re: [Bug 102212] Re: [needs-packaging] Metasploit Framework 3.0

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> > E: metasploit: wrong-path-for-ruby ./usr/share/metasploit/external
> /ruby-pcapx/examples/tcpdump.rb #!/usr/local/bin/ruby
>
> Your script does_NOT_ seem to fix this error. However, I do not get
> that output with or without your patch.

It should! The clean_ruby_paths function should change three files
which have this issue. Does it not? I basically just do a sed on the
files and replace with (/usr/bin/env ruby). You could fix my script,
if it is broken, but don't think it is! Or you could write another
script/patch which does this. Or manually. Then we can get it
packaged and uploaded for Gutsy. We only have two weeks though. So,
let's hustle :-)
--
Kristian Erik Hermansen

--
[needs-packaging] Metasploit Framework 3.0
https://bugs.launchpad.net/bugs/102212
You received this bug notification because you are a direct subscriber
of the bug.

Here is the diff patch to correct Ruby paths...

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> Here is the diff patch to correct Ruby paths...
>
> ** Attachment added: "Ruby Path Correction (diff/patch)"
> http://launchpadlibrarian.net/8841542/ruby.patch

Great! So is it ready to be uploaded for Gutsy??? :-)
--
Kristian Erik Hermansen

>Great! So is it ready to be uploaded for Gutsy??? :-)

Well, not quite yet, but close.

The Ruby issue has been resolved, but the scripts method for determining the correct permissions only partial worked. We still have plenty of permissions issues. So we need to decide how we will proceed with those.

In addition, I have setup a symlink to /usr/bin/ for all of the executables (msfcli, msfgui, etc). And created a menu link with the MSF (#) logo. This is all working great, with no issue. The question however, were should we install the metasploit files?

I was thinking /usr/local/metasploit/framework-3.0

Any incite?

Thanks,
Justin M. Wray

Assigned to myself, as I will be packaging.

Thanks,
Justin M. Wray

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> The Ruby issue has been resolved, but the scripts method for determining
> the correct permissions only partial worked. We still have plenty of
> permissions issues. So we need to decide how we will proceed with
> those.

Can you post the warning messages?

> In addition, I have setup a symlink to /usr/bin/ for all of the
> executables (msfcli, msfgui, etc). And created a menu link with the MSF
> (#) logo. This is all working great, with no issue. The question
> however, were should we install the metasploit files?
>
> I was thinking /usr/local/metasploit/framework-3.0

I think /usr/share/<package name> is better...
--
Kristian Erik Hermansen

>Can you post the warning messages?

W: metasploit; Executable /usr/local/metasploit/framework-3.0/external/source/meterpreter/source/extensions/stdapi/server/net/net.h with perms 0755 is not an ELF file or script.

Seems this should have been covered by the script?

Thanks,
Justin M. Wray

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> >Can you post the warning messages?
>
> W: metasploit; Executable
> /usr/local/metasploit/framework-3.0/external/source/meterpreter/source/extensions/stdapi/server/net/net.h
> with perms 0755 is not an ELF file or script.
>
> Seems this should have been covered by the script?

Should have! Did you first drop the script into the root directory of
metasploit?
--
Kristian Erik Hermansen

When packaging you cannot modify the source package at all, other then through patches.

As such I added the patch to the debian/rules. Let me check something.

Thanks,
Justin M. Wray
Sent via BlackBerry by AT&T

-----Original Message-----
From: Kristian Hermansen <email address hidden>

Date: Wed, 15 Aug 2007 19:09:13
To:<email address hidden>
Subject: Re: [Bug 102212] Re: [needs-packaging] Metasploit Framework 3.0

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> >Can you post the warning messages?
>
> W: metasploit; Executable
> /usr/local/metasploit/framework-3.0/external/source/meterpreter/source/extensions/stdapi/server/net/net.h
> with perms 0755 is not an ELF file or script.
>
> Seems this should have been covered by the script?

Should have! Did you first drop the script into the root directory of
metasploit?
--
Kristian Erik Hermansen

--
[needs-packaging] Metasploit Framework 3.0
https://bugs.launchpad.net/bugs/102212
You received this bug notification because you are a direct subscriber
of the bug.

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> When packaging you cannot modify the source package at all, other then
> through patches.
>
> As such I added the patch to the debian/rules. Let me check something.

My file is a shell script, not a patch made with diff. And I made the
script require to be run from the root directory. You can change that
to suit the Debian rules if you like. I am not familiar with
everything they enforce...
--
Kristian Erik Hermansen

>My file is a shell script, not a patch made with diff. And I made the
script require to be run from the root directory. You can change that
to suit the Debian rules if you like. I am not familiar with
everything they enforce...

Right, I made a diff, after running your script, thats the RUBY patch above.

However, 'diff' doesn't catch the change in file permissions etc.

Therefore, within the debian/rules I used part of your script, but that doesn't seem to be working.

Thanks,
Justin M. Wray

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> Right, I made a diff, after running your script, thats the RUBY patch
> above.

Of course :-) I saw that...

> However, 'diff' doesn't catch the change in file permissions etc.

Yup!

> Therefore, within the debian/rules I used part of your script, but that
> doesn't seem to be working.

What I am saying is that if you put the other parts of my script into
another directory (debian/rules) and run it, it will fail to catch all
the files I believe. It starts searching from the current directory
and recursively downward...
--
Kristian Erik Hermansen

Oh okay, didn't catch what you mean't. Sorry.

Yes, I changed the directory, to back to the root.

I think there is a build function to do this, I just need to find it

I am on the road, will be back on the PC in 45.

Thanks,
Justin M. Wray

Sent via BlackBerry by AT&T

-----Original Message-----
From: Kristian Hermansen <email address hidden>

Date: Wed, 15 Aug 2007 20:31:10
To:<email address hidden>
Subject: Re: [Bug 102212] Re: [needs-packaging] Metasploit Framework 3.0

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> Right, I made a diff, after running your script, thats the RUBY patch
> above.

Of course :-) I saw that...

> However, 'diff' doesn't catch the change in file permissions etc.

Yup!

> Therefore, within the debian/rules I used part of your script, but that
> doesn't seem to be working.

What I am saying is that if you put the other parts of my script into
another directory (debian/rules) and run it, it will fail to catch all
the files I believe. It starts searching from the current directory
and recursively downward...
--
Kristian Erik Hermansen

--
[needs-packaging] Metasploit Framework 3.0
https://bugs.launchpad.net/bugs/102212
You received this bug notification because you are a direct subscriber
of the bug.

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> I think there is a build function to do this, I just need to find it

Let me know if you find it...

> I am on the road, will be back on the PC in 45.

No problem. I just got back from the BeanSec security meetup in
Boston. Fun times...
--
Kristian Erik Hermansen

Okay, so I got it working, sort of.

I am now getting an error from you function, looking into this.

Thanks,
Justin M. Wray

On 8/15/07, Justin M. Wray <email address hidden> wrote:
> Okay, so I got it working, sort of.
>
> I am now getting an error from you function, looking into this.

Post the output?
--
Kristian Erik Hermansen

Okay, well, we should be good to go, I was able to integrate the needed permission changes into the build. The Ruby patch applies as well.

Any other needed changes?

I'll post linda/lintian without SVN errors, so we can review.

Thanks,
Justin M. Wray

On 8/16/07, Justin M. Wray <email address hidden> wrote:
> Okay, well, we should be good to go, I was able to integrate the needed
> permission changes into the build. The Ruby patch applies as well.

Excellent.

> Any other needed changes?

Not that I can think of!

> I'll post linda/lintian without SVN errors, so we can review.

Anything major?
--
Kristian Erik Hermansen

hello guys,
i was away this days for the CCCamp.
I see that you done a good work, but remember that tha msf sources can't modified.
So you can't apply any sort of patches.

On 8/16/07, Alessandro Tanasi <email address hidden> wrote:
> hello guys,
> i was away this days for the CCCamp.

I heard it was a good time from my hackers on a plane friends :-)

> I see that you done a good work, but remember that tha msf sources can't modified.
> So you can't apply any sort of patches.

The only file we "modified" was the ruby paths from
'/usr/local/bin/ruby' to '/usr/bin/env ruby'. This is not
intellectual property...
--
Kristian Erik Hermansen

Welcome back Alessandro, I noticed you did package MSF as well, so I hope that I haven't stepped on your toes.

I have been reviewing the licenes as well. Have a look at: http://framework-mirrors.metasploit.com/documents/RELEASE-3.0.txt

The part that stands out -

 * Metasploit is now released under the Metasploit Framework License.
 This license allows anyone to use the framework for almost anything,
 but prevents commercial abuse and outright code theft. The Metasploit
 Framework License helps keep the platform stable and still allows
 module developers to choose their own licensing terms for their code
 (commercial or open source). For more information, please see the
 license document included in the distribution.

It is clear that Metasploit LLC is attempting to protect the work from being used to re-create a "metasploit clone" and more importantly be altered and sold. But I do not really think the idea is to keep anyone from packaging the application, as long as the license stays intact and the "core" code isn't altered. We are not changing any code or functions in anyway. Only correcting the Ruby path (thats the patch that is mentioned). I would honestly like clarification from the Metasploit developer's as to what is "legal" and not.

Now lets just say the end result is the code cannot be altered in any way, including our patches to the Ruby path, and file permissions. How will Debian (or Ubuntu) handle the resulting package? Obviously it will build, and work, but will have a hefty linda/lintian output, and break a few policies. Then again this is going to multivers anyway...

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

     "multiverse" component

     The "multiverse" component contains software that is "not free", which means the licensing requirements of this software do not meet the Ubuntu "main"
     Component Licence Policy.

     The onus is on you to verify your rights to use this software and comply with the licensing terms of the copyright holder.

      This software is not supported and usually cannot be fixed or updated. Use it at your own risk.

So it is clear that Ubuntu is far more lenient with multiverse packages. The package still functions without the "Ruby" patch or the permission correction. It would just be a rather bad package.

The best chance we have is to make the minor changes to the source from the patches mentioned. This will also give us the best package possible.

Thanks,
Justin M. Wray

Let's break down the License, and see where we fall.

...

Definitions

...

c. "Enhancement" means any bug fix, error correction, patch, or other
addition to the Software that are independent of the Software and do not
require modification of the Software of the Software itself.

...

3. The license granted in Section 2 is expressly made subject to and
limited by the following restrictions:

a. You may only distribute, publicly display, and publicly perform
unmodified Software. Without limiting the foregoing, You agree to
maintain (and not supplement, remove, or modify) the same copyright,
trademark notices and disclaimers in the exact wording as released by
Developer.

...

4. You may develop Enhancements to the Software and distribute Your
Enhancements, provided that You agree to each of the following
restrictions on this distribution:

a. Enhancements may not modify, supplement, or obscure the user interface
or output of the Software such that the title of the Software, the
copyrights and trademark notices in the Software, or the licensing terms
of the Software are removed, hidden, or made less likely to be discovered
or read.

b. If you release any Enhancement to the Software, You agree to
distribute the Enhancement under the terms of this License (or any other
later-issued license(s) of Developer for the Software). Upon such
release, You hereby grant and agree to grant a non-exclusive royalty-free
right, to both (i) Developer and (ii) any of Developer's later licensees,
owners, contributors, agents or business partners, to distribute Your
Enhancement(s) with future versions of the Software provided that such
versions remain available under the terms of this License (or any other
later-adopted license(s) of Developer).

...

Online Updates

The Software includes the ability to download updates (i.e., additional
code) from Developer's server(s). These updates may contain bug fixes,
new functionality, updated Documentation, and/or Extensions. When
retrieving these updates, the Software may transmit the Software version
and operating system information from Your computer to the update server.
The server may record (store) this information, in conjunction with the
IP (global Internet Protocol) address of the user, in order to attempt to
maintain accurate end user and version statistics. By using the online
update feature, You hereby agree to allow this information to be
transmitted, recorded, and stored in any nation by or for Developer.

I pulled out only the parts that are important to the matter at hand. An unedited version of the license can be found, attached above or from the metasploit website. I have not modified any content of the license and have only "copied&pasted" the parted needed for discussion.

-----

 1) Definitions, entry "c" - Indicates that bug fixes are considered an "Enhancement" (this includes patches).
 2) Section 3 - a indicates that only unmodified versions of the software can be distributed.
 3) Section 4 grants the right to create "Enhancements" (or patches)
 4) Section 4 - a enforces that the patches do not alter, the user-interface, license, or output etc.
 5) Section 4 - b ...

On 8/16/07, Justin M. Wray <email address hidden> wrote:
> Let's break down the License, and see where we fall.

OK. So let's do this. Will msf3 work unmodified? And will Ubuntu
allow msf3 to slip in unmodified into multiverse? If so, I say we
just add it to Gutsy ASAP and then worry about cleaning it up for the
next release. We could easily get into many days of interpretation of
the license. If we can just place it in multiverse now, we can worry
about all that stuff later and get more feedback from hdm when he is
not so busy...
--
Kristian Erik Hermansen

>OK. So let's do this. Will msf3 work unmodified? And will Ubuntu
allow msf3 to slip in unmodified into multiverse? If so, I say we
just add it to Gutsy ASAP and then worry about cleaning it up for the
next release. We could easily get into many days of interpretation of
the license. If we can just place it in multiverse now, we can worry
about all that stuff later and get more feedback from hdm when he is
not so busy...

You are right, and none of us (as far as I know) are lawyers, nor Dev's for MSF. But it is clear to me that modifications are allowed, and they would result in a cleaner package. Just throwing everything together, without fixing the current linda/lintian issue, will most likely get the package rejected, meaning it may not make it in Gutsy at all.

But to answer the question at hand, Yes. Metasploit runs fine, exactly the way it is packaged, even with the Ruby path issues, and the permissions etc. We would still have a .desktop (Menu Entry) and everything else, so it works.

Thanks,
Justin M. Wray

On 8/16/07, Justin M. Wray <email address hidden> wrote:
> You are right, and none of us (as far as I know) are lawyers, nor Dev's
> for MSF. But it is clear to me that modifications are allowed, and they
> would result in a cleaner package. Just throwing everything together,
> without fixing the current linda/lintian issue, will most likely get the
> package rejected, meaning it may not make it in Gutsy at all.

Agreed. But if the Metasploit license requires that any changes must
NOT be distributed, then we may have an issue. I think we know the
license's intention, but we are not allowed to take a risk on behalf
of Ubuntu regarding this. The guidelines are there to protect them.
So, if we want to default to the least amount of risk, let's go with
unmodified. Your only issue with adding it unmodified is that it may
be rejected. When we submit it, we could let them know that the
issues are only warnings at that they will be resolved in Gutsy+1. If
they reject it then, we can send the modified version...

> But to answer the question at hand, Yes. Metasploit runs fine, exactly
> the way it is packaged, even with the Ruby path issues, and the
> permissions etc. We would still have a .desktop (Menu Entry) and
> everything else, so it works.

Excellent...
--
Kristian Erik Hermansen

I think that we need a law expert, and as i say in the first posts of this bug the only easy way is that the msf dev team start to distribute good archive.

On 8/16/07, Alessandro Tanasi <email address hidden> wrote:
> I think that we need a law expert, and as i say in the first posts of
> this bug the only easy way is that the msf dev team start to distribute
> good archive.

Yes ok, but that law does not come into play unless the package is
modified, right? So we can worry about fixing the package later. We
only have 12 more days to get msf3 in for Gutsy...
--
Kristian Erik Hermansen

Kristian, I know you have been "attempting" to speak with the MSF Dev's. Any chance they will apply the patches upstream? Alessandro is right, it would make things a lot easier, because then we would have no need to edit the source.

Thanks,
Justin M. Wray

On 8/17/07, Justin M. Wray <email address hidden> wrote:
> Kristian, I know you have been "attempting" to speak with the MSF Dev's.
> Any chance they will apply the patches upstream? Alessandro is right,
> it would make things a lot easier, because then we would have no need to
> edit the source.

hdm is back it seems. Why don't you send an email to
<email address hidden>, let them know what we are trying to do, and
about the issues we encountered. He hasn't gotten back yet about
applying my script to the source. So, they may not want to do it.
But let's make the list as short as possible. Maybe we can just ask
him to change the Ruby paths instead, and do it manually? I think he
might have been weary of using my script on the source blindly...
--
Kristian Erik Hermansen

>I think he might have been weary of using my script on the source blindly...

Agreed, plus the original script removed SVN, which is used to update MSF, so he would not have done that anyway.

I'll send him an email and see if we can get the Ruby paths updated, as well as the permissions corrected.

Thanks,
Justin M. Wray

The metasploit developers have made the requested changes to the current SVN update.

I'll be packaging tonight, and will place the package online for testing etc.

Let me know if you are interested in testing.

I also wanted to take a moment to thank the metasploit team for working with us, to get this packaged and added to Ubuntu. And I also want to thank Kristian for taking the time out of his own schedule to communicate with the metasploit team. Thanks everyone.

Thanks,
Justin M. Wray

On 8/20/07, Justin M. Wray <email address hidden> wrote:
> I'll be packaging tonight, and will place the package online for testing
> etc.
>
> Let me know if you are interested in testing.

Great! Sure, I will test it. I think we should make the 'subversion'
package a RECOMMENDS. What do you think?
--
Kristian Erik Hermansen

The first metaspoilt 3 package that i do when i open this bug have the following:

Depends: ruby, libruby, rdoc, libyaml-ruby, libzlib-ruby, libopenssl-ruby, libdl-ruby, libreadline-ruby, libiconv-ruby, libgtk2-ruby, libglade2-ruby

and recommends svn.

On 8/20/07, Alessandro Tanasi <email address hidden> wrote:
> The first metaspoilt 3 package that i do when i open this bug have the
> following:
>
> Depends: ruby, libruby, rdoc, libyaml-ruby, libzlib-ruby, libopenssl-
> ruby, libdl-ruby, libreadline-ruby, libiconv-ruby, libgtk2-ruby,
> libglade2-ruby

What about gems/rails?

> and recommends svn.

Correct package name is 'subversion'...
--
Kristian Erik Hermansen

I consider to deploy a separate package with web interface, in my packages.
Are you a kind of pedantic guy? svn stay for nickname of subversion ;)

On 8/20/07, Alessandro Tanasi <email address hidden> wrote:
> I consider to deploy a separate package with web interface, in my packages.

So, if we can't modify the package, does that mean that you want the
same package in repositories twice, one with the web interface
dependencies, and on without? I think the web interface is a huge
part of msf3, especially for people who will be using it on Ubuntu.
If we left that out, it would be a major detriment. Otherwise, we
would need th same package in the repos twice (metasploit3 and
metasploit3-web)...

> Are you a kind of pedantic guy? svn stay for nickname of subversion ;)

I just wanted to make sure the package name was termed correctly. If
you make the package RECOMMEND 'svn' apt will not resolve this
package, as it is not valid. svn is the command name and not the
package name. Yes, pedantics are my specialty :-p
--
Kristian Erik Hermansen

Okay, so in general, I would agree that an application that doesn,t normall have a web feature, should seperated.

I would also apply this rule to a GUI interface.

But where do we draw the line?

Just because MSF2 didn't have a GUI or a webinterface, doesn't mean that people using version 3 won't want it. Then again, are really the ones who should make that decision? I do not believe so.

But do we really want a metaspolit-core, metasploit-gui, and metasploit-web. I do see a benifit, as dependencies would be diffrent etc. And I for one rearly use the web interface, and the GUI is far from mature.

But then enters the legality issue. Can we really split the package up? That would require upstream approval, or for them to alter the way they distribute the package, and I see no benifit for them to do either. Do you?

Last but I am sure not least, updates. Metasploit is updated with SVN, which would replace the missing files, so the first time the user updates his metaspolit installation (core) he ends up with the same thing he would have gotten with -web and -gui. Where is the point in that?

Of course we could modifiy the package further, and make it only update part of the package, based on what they install. But all of that would come far after Gutst, and be more likely after Metasploit LLC releases a license change, which is in the works.

So, I do agree, that split packages could be benifitial, however, I do not this that should be the focus of this release. Instead, I think a solid package from SVN with all compoents is in order.

Thanks,
Justin M. Wray

Sent via BlackBerry by AT&T

-----Original Message-----
From: Kristian Hermansen <email address hidden>

Date: Mon, 20 Aug 2007 19:57:22
To:<email address hidden>
Subject: Re: [Bug 102212] Re: [needs-packaging] Metasploit Framework 3.0

On 8/20/07, Alessandro Tanasi <email address hidden> wrote:
> I consider to deploy a separate package with web interface, in my packages.

So, if we can't modify the package, does that mean that you want the
same package in repositories twice, one with the web interface
dependencies, and on without? I think the web interface is a huge
part of msf3, especially for people who will be using it on Ubuntu.
If we left that out, it would be a major detriment. Otherwise, we
would need th same package in the repos twice (metasploit3 and
metasploit3-web)...

> Are you a kind of pedantic guy? svn stay for nickname of subversion ;)

I just wanted to make sure the package name was termed correctly. If
you make the package RECOMMEND 'svn' apt will not resolve this
package, as it is not valid. svn is the command name and not the
package name. Yes, pedantics are my specialty :-p
--
Kristian Erik Hermansen

--
[needs-packaging] Metasploit Framework 3.0
https://bugs.launchpad.net/bugs/102212
You received this bug notification because you are a direct subscriber
of the bug.

Kristian Hermansen wrote:
> So, if we can't modify the package, does that mean that you want the
> same package in repositories twice, one with the web interface
> dependencies, and on without? I think the web interface is a huge
> part of msf3, especially for people who will be using it on Ubuntu.
> If we left that out, it would be a major detriment. Otherwise, we
> would need th same package in the repos twice (metasploit3 and
> metasploit3-web)...

Sure, but the control file that i paste is from my package for personal
use only, and i need to split ;)

> I just wanted to make sure the package name was termed correctly. If
> you make the package RECOMMEND 'svn' apt will not resolve this
> package, as it is not valid. svn is the command name and not the
> package name. Yes, pedantics are my specialty :-p

Yes, and i am pedantic. So i say, that line is a comment, no a control
file line, so i think i can use a friendly alias.
And now, like pedantic guys, i think we need a huge beer.

On 8/20/07, Justin M. Wray <email address hidden> wrote:
> Okay, so in general, I would agree that an application that doesn,t
> normall have a web feature, should seperated.
>
> I would also apply this rule to a GUI interface.
>
> But where do we draw the line?

Yes, I also agree that under ideal circumstances this would be the
case. However, we are working with a restrictive license so this
become a larger issue. Suggest deferring until license is changed...

> Just because MSF2 didn't have a GUI or a webinterface, doesn't mean that
> people using version 3 won't want it. Then again, are really the ones
> who should make that decision? I do not believe so.

msf2 did has a GUI as well :-) It just wasn't as easy to use as it is
today. I use both the cli and gui, depending on how lazy I am and if
I am screening the session, etc. Sometimes for n00bs, a GUI helps
them learn enough that they can feel comfortable with the cli at a
later point...

> But do we really want a metaspolit-core, metasploit-gui, and metasploit-
> web. I do see a benifit, as dependencies would be diffrent etc. And I
> for one rearly use the web interface, and the GUI is far from mature.
>
> But then enters the legality issue. Can we really split the package up?
> That would require upstream approval, or for them to alter the way they
> distribute the package, and I see no benifit for them to do either. Do
> you?

Yes, there is a benefit, but not at the cost of delaying the package
inclusion and/or dealing with license issues...

> Last but I am sure not least, updates. Metasploit is updated with SVN,
> which would replace the missing files, so the first time the user
> updates his metaspolit installation (core) he ends up with the same
> thing he would have gotten with -web and -gui. Where is the point in
> that?

This is the best point to have been made. It makes no sense to break
it up if you will pull the files right back in :-)

> Of course we could modifiy the package further, and make it only update
> part of the package, based on what they install. But all of that would
> come far after Gutst, and be more likely after Metasploit LLC releases a
> license change, which is in the works.
>
> So, I do agree, that split packages could be benifitial, however, I do
> not this that should be the focus of this release. Instead, I think a
> solid package from SVN with all compoents is in order.

Agreed, so please include the dependencies for the web interface as
well as I have listed. This will be great. 10 days left to cut off
:-)
--
Kristian Erik Hermansen

On 8/20/07, Alessandro Tanasi <email address hidden> wrote:
> Yes, and i am pedantic. So i say, that line is a comment, no a control
> file line, so i think i can use a friendly alias.
> And now, like pedantic guys, i think we need a huge beer.

Let's all hang out and grab some beers at the next security-con. Here
is a Google Calendar list of many events ongoing...

http://www.google.com/calendar/embed?src=pe2ikdbe6b841od6e26ato0asc%40group.calendar.google.com
--
Kristian Erik Hermansen

I never noticed that msf2 had a GUI, then again I am much more of a CLI guy.

Anyhow, I agree, we will add all depends, submit to Gutsy, and deal with the ideal situations down the road when they are possible.

Thanks,
Justin M. Wray

Sent via BlackBerry by AT&T

-----Original Message-----
From: Kristian Hermansen <email address hidden>

Date: Mon, 20 Aug 2007 21:38:54
To:<email address hidden>
Subject: Re: [Bug 102212] Re: [needs-packaging] Metasploit Framework 3.0

On 8/20/07, Justin M. Wray <email address hidden> wrote:
> Okay, so in general, I would agree that an application that doesn,t
> normall have a web feature, should seperated.
>
> I would also apply this rule to a GUI interface.
>
> But where do we draw the line?

Yes, I also agree that under ideal circumstances this would be the
case. However, we are working with a restrictive license so this
become a larger issue. Suggest deferring until license is changed...

> Just because MSF2 didn't have a GUI or a webinterface, doesn't mean that
> people using version 3 won't want it. Then again, are really the ones
> who should make that decision? I do not believe so.

msf2 did has a GUI as well :-) It just wasn't as easy to use as it is
today. I use both the cli and gui, depending on how lazy I am and if
I am screening the session, etc. Sometimes for n00bs, a GUI helps
them learn enough that they can feel comfortable with the cli at a
later point...

> But do we really want a metaspolit-core, metasploit-gui, and metasploit-
> web. I do see a benifit, as dependencies would be diffrent etc. And I
> for one rearly use the web interface, and the GUI is far from mature.
>
> But then enters the legality issue. Can we really split the package up?
> That would require upstream approval, or for them to alter the way they
> distribute the package, and I see no benifit for them to do either. Do
> you?

Yes, there is a benefit, but not at the cost of delaying the package
inclusion and/or dealing with license issues...

> Last but I am sure not least, updates. Metasploit is updated with SVN,
> which would replace the missing files, so the first time the user
> updates his metaspolit installation (core) he ends up with the same
> thing he would have gotten with -web and -gui. Where is the point in
> that?

This is the best point to have been made. It makes no sense to break
it up if you will pull the files right back in :-)

> Of course we could modifiy the package further, and make it only update
> part of the package, based on what they install. But all of that would
> come far after Gutst, and be more likely after Metasploit LLC releases a
> license change, which is in the works.
>
> So, I do agree, that split packages could be benifitial, however, I do
> not this that should be the focus of this release. Instead, I think a
> solid package from SVN with all compoents is in order.

Agreed, so please include the dependencies for the web interface as
well as I have listed. This will be great. 10 days left to cut off
:-)
--
Kristian Erik Hermansen

--
[needs-packaging] Metasploit Framewo...

Pulled the latest snapshot from (Rev:5080), however all of the permission issues are still present.

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