Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

not a git repository #8808

Closed
4 tasks
PandoraSec opened this issue Aug 8, 2017 · 12 comments
Closed
4 tasks

not a git repository #8808

PandoraSec opened this issue Aug 8, 2017 · 12 comments
Labels

Comments

@PandoraSec
Copy link

Steps to reproduce

How'd you do it?

  1. ...this happen every time i open msfconsole
  2. ...i have the correct repositories and the sistem is update

This section should also tell us any relevant information about the
environment; for example, if an exploit that used to work is failing,
tell us the victim operating system and service versions.

Expected behavior

What should happen?

Current behavior

What happens instead?

You might also want to check the last ~1k lines of
/opt/metasploit/apps/pro/engine/config/logs/framework.log or
~/.msf4/logs/framework.log for relevant stack traces

System stuff

Metasploit version

Get this with the version command in msfconsole (or git log -1 --pretty=oneline for a source install).

I installed Metasploit with:

OS

What OS are you running Metasploit on?
kali linux rolling 2017
20668497_10212069038174911_1580300156_n

@busterb
Copy link
Member

busterb commented Aug 8, 2017

Please file an issue with the Kali Linux bug tracker. This is a packaging error.

@busterb busterb closed this as completed Aug 8, 2017
@rhertzog
Copy link

rhertzog commented Aug 9, 2017

@busterb Kali packager here. Can you expand why this is packaging error? metasploit-framework has supported Kali packages so far and even offered a way to disable automatic update from the git repository inviting users to use apt.

IMO you should just ensure that it doesn't display this error message. The "git" call that prints this message is not fatal to the correct functioning of msfconsole and it should be easy to redirect stderr output away.

@rhertzog
Copy link

rhertzog commented Aug 9, 2017

You already take pro-active measures to not generate errors in your gemspec file here:
https://github.com/rapid7/metasploit-framework/blob/master/metasploit-framework.gemspec#L29

Maybe you could do the same in whatever code generates the current error message? (It's not yet clear to me what generates this message)

@busterb
Copy link
Member

busterb commented Aug 9, 2017

I replaced git with a shell script to see what is calling it. It looks like an issue with one of the upstream gems, because the invocation is 'ls-files -z', which framework doesn't do (and as you noted, we try to avoid spurious git invocations already.)

I'm not seeing this in the latest HEAD, or with any of the nightly packages we generate. A first thought would be to grep -R 'ls-files -z' /usr/share/metasploit-framework and see which gem is the culprit. It may be something that would be cured simply by updating to the latest (the last tagged release was 4.15.4), which is going to have slightly newer gems in the Gemfile.lock.

@rhertzog
Copy link

rhertzog commented Aug 9, 2017

@busterb In fact, if we update the Gemfile to use a released version of ruby-dns instead of a git snapshot then the message seems to go away. So it might be an issue that is present in the current git version of ruby-dns or a normal difference between the released version of ruby-dns and its git repository.

@busterb
Copy link
Member

busterb commented Aug 9, 2017

Sounds like one option, though I'm still not sure why other metasploit-framework packaging projects aren't running into this. Another option would be to locally patch the dnsruby gemspec file after bundling to not include the git command.

We're using the latest git version of dnsruby because it has a bad side-effect otherwise of crashing framework if any thread throws an exception (a lot of scanner modules do this as part of normal operations):
alexdalitz/dnsruby@09c3890

Will see about sending them a PR to add a similar git guard and a reminder to do a release soon so we can have a regular gemfile for it. Thanks.

@busterb
Copy link
Member

busterb commented Aug 9, 2017

Upstream fix for dnsruby - alexdalitz/dnsruby#135

@busterb
Copy link
Member

busterb commented Aug 10, 2017

After some sleuthing with @acammack-r7 we discovered the discrepancy with Kali linux's packaging. If I run 'bundle install' on almost any other system, the contents of the gemspec file for dnsruby shows that the git command was already expanded:

s.files = [".coveralls.yml".freeze, ".gitignore".freeze, ".travis.yml".freeze, "DNSSEC".freeze, "EVENTMACHINE".freeze, "EXAMPLES".freeze, "Gemfile".freeze, "LICENSE".freeze, "README.md".freeze, "RELEASE_NOTES.md".freeze, "Rakefile".freeze, "SIGNED_UPDATES".freeze, "demo/axfr.rb".freeze,....

But in the Kali metasploit package, it stays unexpanded. We have a few possible theories why:

  1. Maybe Kali's package builder has a really old or buggy version of bundler or the gem command and it's failing to install. If I copy the 'bundle install' command from http://git.kali.org/gitweb/?p=packages/metasploit-framework.git;a=blob;f=debian/rules;h=2753b7a11fc6615f5f5dac1a49e2d43abb37ef5a;hb=HEAD#l31 and simply run it from /usr/share/metasploit-framework, it fixes the problem.

  2. Maybe Kali's package builder builds in some sort of minimalistic chroot environment, that is missing the 'git' command in the path when it builds. It's possible this is preventing the expansion.

It's hard to say so far. I tried reproducing locally in various ways, just short of building a full Debian build environment so I could test the full Kali package build. Let me know what you find.

@rhertzog
Copy link

So we already have git available in the build environment (which is minimalistic but has all the build dependencies we need including git here), so that's not it. However we are currently not using the command that you linked. Due to the availability of conflicting system-wide gems and a failure to intsall the json gem via bundle we have this set of commands for our bundle calls:
http://git.kali.org/gitweb/?p=packages/metasploit-framework.git;a=blob;f=debian/rules;h=0068657114b533f7caad030f9fdb4d5e6f5944a5;hb=refs/heads/kali/master#l17

Note that we have bundler 1.15.1, it's not the latest (1.15.3) but it's rather recent.

@rhertzog
Copy link

Apparently the problem is introduced due to our use of the --force option on bundle install (which we use to install in the bundle the gems which are already available system-wide due to them being dependencies of some of the build dependencies that we need).

@rhertzog
Copy link

FTR, you can see the build log of metasploit-framework here:
http://buildd-amd64.kali.org/build-logs/metasploit-framework_4.15.5-0kali2-kali-dev-amd64-20170809-102416.3747.log

I don't see any error message related to dnsruby.

@acammack-r7
Copy link
Contributor

This was caused by a bug in bundler (introduced in 1.15.0) which is currently fixed in master but unreleased. Hopefully it will be out by the next time we have a git checkout of a gem in master.

@busterb busterb added the bug label Aug 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants