-
Notifications
You must be signed in to change notification settings - Fork 14k
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
Comments
Please file an issue with the Kali Linux bug tracker. This is a packaging error. |
@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. |
You already take pro-active measures to not generate errors in your gemspec file here: 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) |
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 |
@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. |
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): 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. |
Upstream fix for dnsruby - alexdalitz/dnsruby#135 |
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:
But in the Kali metasploit package, it stays unexpanded. We have a few possible theories why:
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. |
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: Note that we have bundler 1.15.1, it's not the latest (1.15.3) but it's rather recent. |
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). |
FTR, you can see the build log of metasploit-framework here: I don't see any error message related to dnsruby. |
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. |
Steps to reproduce
How'd you do it?
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 tracesSystem stuff
Metasploit version
Get this with the
version
command in msfconsole (orgit log -1 --pretty=oneline
for a source install).I installed Metasploit with:
OS
What OS are you running Metasploit on?
kali linux rolling 2017
The text was updated successfully, but these errors were encountered: