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.

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

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