I thought this was a fairly well known way to pass arbitrary strings to commands and ensure they aren't interpreted as options (for commands which honor "--", like ssh does).
Or is that really unnecessary?
Someone needs to teach the next generation about ABI compatibility...
(And by the way, neither is a leading dot, which I use to my advantage to define hostname aliases in ~/.ssh/config which I can be sure will never clash with anything.)
By the RFCs, that's true; but if you think it's true in practice, then 4chan.org would like a word with you.
...Oh, fuck me. I just found https://archive.fo/T0WcV ... (archive.is link because Firefox won't open it directly)
Chrome: 61.0.3163.31 (Official Build) beta (64-bit)
Windows: Microsoft Windows 10 Pro 10.0.15063 Build 15063
My DNS is pointed at my router which is forwarding requests to Google's 18.104.22.168 DNS servers.
gethostbyname() cant resolve names starting/ending with "-"
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
I have a strange feeling '3com.com' would have been a consideration when this change was proposed.
I was very happy when I found http://scoop.sh. It's simpler and slightly less powerful, and most notably it just runs official installers in the background instead of copying binaries over from the source and packing them up in a special way.
(It's also at the latest got already)
I haven't released it yet, but Napkin solves this very issue.
Part of my workflow involves using ncat.exe to use git over a socks/ssh proxy. A real pain. I noticed scoop has nc but not ncat.
(Actually I used to run all devtools, eg git and webpack I etc etc on WSL entirely but it still has too many quirks. Moved back to plain Windows recently and I'm happier)
For stuff that needs to run everywhere and I don't feel like writing two versions of scripts, I just use Python.
I don't really get it. I did a fresh install of it a few minutes ago, gave the command to install 7zip. Then it downloaded the file, said it was installing, and it just sat there for 10-15 minutes before I got fed up and hit CTRL+C to cancel it. Then it kicked back into gear and magically finished the install somehow?
Edit: it seems to have one.
They have a switch to configure it once and have their tool figure out the right argument for each installer by itself, but it's only for paid users (~$96/year)
The update this morning for Ubuntu 17.04 installs git 2.11.0
.. NOT the patched 2.11.3 NOR the latest 2.14.1
Why isn't Ubuntu fully up to date?
If you are maintaining or developing any kind of server and services where you need an uptime guarantee above 0%, you will appreciate this. Otherwise you will need staff on standby 24/7 being ready to develop fixes for breaking backwards compatibility changes. Imagine if you had to deal with funky errors like these every minute of the day - https://gitlab.com/gitlab-org/gitlab-ce/issues/36028
For Ubuntu, you should follow their "usn" security notices and you would stay informed: https://usn.ubuntu.com/usn/
For Debian, likewise there is a "debian-security-announce" mailing list https://lists.debian.org/debian-security-announce/
Also for Debian, you can check up on the status for known vulnerabilities on their security tracker. For example, for this particular git exploit, you could look up https://security-tracker.debian.org/tracker/CVE-2017-8386
PHP has gotten better about "no BC breaks in patch versions" over the years, but the Debian/Ubuntu teams still insist on making people effectively run e.g. 7.1.8 while the version indicator says 7.1.1.
It makes feature detection a nightmare.
For example, the current package for Ubuntu 16.04 LTS is 7.0.22-0ubuntu0.16.04.1. How does this mismatch 7.0.22 from the PHP upstream project?
This used to be a huge problem. I've since convinced [most PHP devs I talk to] to stop using distro-provided packages, in favor of deb.sury.org.
> I've since convinced [most PHP devs I talk to] to stop using distro-provided packages, in favor of deb.sury.org.
You do realise that Ondřej Surý (of sury.org) is the primary Debian PHP maintainer? The point of his repositories (AIUI) is to allow users to mix and match PHP versions. The downside is that he's one person with (AFAIK) a bus factor of 1 when it comes to security updates. That's irresponsible to use in production.
In contrast, Debian and Ubuntu's PHP packages, essentially provided by the same person, has in addition teams (both in Debian and Ubuntu) who can pitch in when required.
It's somewhat confusing if you run `git --version` and it reports back 2.11.0, despite being fully patched against this vulnerability.
I've added the git-core PPA now which installs 2.14.1 .
I just don't understand this screwing with version numbers and not being on the latest code.
Edit: The package is actually 2.11.0-2 which contains the security patch.
Point in case: 16.04 TLS is still on 2.7.4 but it is fully patched and secure.
Indeed if I check with "apt-get show git", the package is on version 2.11.0-2, and then I have to browse to the package web page at https://packages.ubuntu.com/zesty/git and click on the changelog and finally I get to the update information, which clearly contains the text, "SECURITY UPDATE: Arbitrary code execution on clients through malicious ssh URLs."
So it was patched as expected, it just wasn't easy for me to see that without going through a few extra steps.
It means that one group of developers is busy improving and fixing packages, and another different group is cherry-picking commits in order to maintain the illusion of stability (as mentioned above).
That second group has to duplicate all the testing work done by the first group, and additionally ensure that there are no new problems introduced.
It's very vulnerable to human error and adds a lot of unnecessary work.
The example you gave is specifically about a client application of git that wasn't updated to work with the current version of git - probably because of some twisted logic that they didn't have to worry about it until some future date.
Imagine you had a daily backup script that uses git to commit and push to a remote server perhaps managed by someone else. You then upgrade to the latest and greatest version of git to try to patch this vulnerability, and surprise, your backup script fails! Hope you weren't planning on spending the rest of the day getting the guys running the git server to implement a workaround, who might have already left for the weekend, leaving you with no backups or having to manually try to fix your git to work with that server again.
I see it differently. Where do new bugs and vulnerabilities come from? When the main developers add features or make changes to existing features that go beyond fixing bugs.
From the point of view of many server administrators, using the latest versions of everything is inherently risky. What they want to use is a stable, solid version that has all the latest security fixes.
It's unlikely that these opposing viewpoints will ever be reconciled.
Some cases will slip through sometimes, but over a couple of releases these should be gone.
>> Where do new bugs and vulnerabilities come from? When the main developers add features or make changes to existing features that go beyond fixing bugs.
Do you have stats for that?
Semantic versioning was supposed to be the fix for that, but as Rich Hickey has pointed out, that is also broken.
Everyone is their own server admin these days. We all want "a stable, solid version that has all the latest security fixes" but it's difficult accept that that might be impossible.
it is a duplicate of
which is fixed by https://cgit.kde.org/konversation.git/commit/?id=783dc0f595e...
but upstream for some reason does not think this is important enough to tag and bag into a release.
as much hate as Fedora gets, rdieter has taken the time to backport the changes that we need in Fedora.
Ideally, we'd rather see upstream release this fix but we've all read https://news.ycombinator.com/item?id=14051106 and I don't want to be too impatient with software that upstream has graciously provided for free (in both senses of the word!)
I guess my point is backporting might make sense if there are small changes we can make to enhance release. However, I agree that there is too much duplication of effort going on.
And, I'm not too surprised, KDE has a broken development and maintenance process.
I'm sure they think they're doing a great job - but that's because they don't even see or receive most bug reports.
KDE actually fixed the bug but it hasn't gone to a tagged release after two months. Maybe they think this small change doesn't warrant a release? I asked if KDE neon can pick it up but they (understandably) seem to see this as feature creep. KDE applications means something different for the neon folks (only the things they ship with neon from what I understand).
I agree. I have no doubt we are all trying to do our best. =)
It's a shame, because the Git dispatching code ought to be able to invoke the ssh command via
ssh -p 22 -etc -etc -- <hostname>
Indeed, from a comment above:
> We discussed that, but it wasn't clear that doing so was portable. It works for OpenSSH. It doesn't for PuTTY. We don't know what other implementations people might have as `ssh` on their systems.
Seems to me like git shouldn't be using the shell in order to invoke ssh at all.
The issue isn't one of shell quoting, but one of ssh treating the argument list ["ssh", "-oProxyCommand=something", "remote-cmd"] not as ["ssh", hostname, command] but as ["ssh", option, hostname].
Seems to me the the use of "=" notation for CLI args would be rife with situations like this.
[also, still going through the code, but it looks like they are setting up for a call to exec*()]
I found CVE-2015-7545 a few years ago, a malicious URL using the ext:: scheme could cause code execution. It was only easily exploitable because you can ask the client to fetch any URL you want via git submodules. (This vulneriblity was fixed, and since then the entire ext url scheme was disabled by default.)
I tried to install a new version and found I could not as there was another version that was present. Git did not appear anywhere as a program to uninstall. I tried to delete it (from an admin account) and it failed with an access denied - and no other information.
The solution was to use LockHunter (https://lockhunter.com/) which informed me that malwarebytes was the program preventing me from deleting it. Using LockHunter, I removed the lock and successfully removed the old version of git.
brew update && brew upgrade
brew update && brew install git
Their release note for this release just says "This release forward-ports the fix for 'ssh://...' URL from Git v2.7.6".
Nodejs has a page where they outline their procedure (https://nodejs.org/en/security/), with a list you can subscribe to. Does Git have something like that and I'm just missing it?
This will negatively affect https://github.com/nasser/---
It's actually quite easy to reproduce (the RCE aspect comes from the ProxyCommand and LocalCommand SSH options that you can set from the SSH command-line).
use this PPA
My hands are a little full at this moment but feel free to shoot me an email if you're interested in doing something I like this. Seems like a good case for automation.
Not just for git, but for any tools you use honestly. MacOS very rarely patches this kind of thing, and in situations like this you need to be able to move fast.
I think it's more accurate to say that Apple often takes their time patching these vulnerabilities. CVE‑2016‑2324 and CVE‑2016‑2315 were announced in March 2016 but Apple didn't release a patched version with Xcode until May 2016. Are there any major security vulnerabilities in git Apple hasn't yet released a patch for, other than this one?
But yeah, Homebrew gets the patches out much faster. It's probably the right move to prefer using Homebrew's git to system git.