On 8/15/07, Justin M. Wray <[EMAIL PROTECTED]> 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 member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
