not a git repository

[PandoraSec]

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:

• Kali package via apt
• Omnibus installer (nightly)
• Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• Source install (please specify ruby version)

OS

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

[busterb]

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

[rhertzog]

@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]

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]

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]

@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]

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]

Upstream fix for dnsruby - alexdalitz/dnsruby#135

[busterb]

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]

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]

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]

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]

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.