Junio C Hamano:
We have a set of urgent maintenance releases. Please update your Git if you are on Windows or Mac OS X.
Git maintains various meta-information for its repository in files in .git/ directory located at the root of the working tree. The system does not allow a file in that directory (e.g. .git/config) to be committed in the history of the project, or checked out to the working tree from the project. 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).
Unfortunately, this protection has been found to be inadequate on certain file systems:
- You can commit and checkout to .Git/<anything> (or any permutations of cases .[gG][iI][tT], except .git all in lowercase). But this will overwrite the corresponding .git/<anything> on case-insensitive file systems (e.g. Windows and Mac OS X).
- In addition, because HFS+ file system (Mac OS X) considers certain Unicode codepoints as ignorable; committing e.g. .g\u200cit/config, where U+200C is such an ignorable codepoint, and checking it out on HFS+ would overwrite .git/config because of this.
GitHub:
Repositories hosted on github.com cannot contain any of the malicious trees that trigger the vulnerability because we now verify and block these trees on push. 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. This work is an extension of the data-quality checks we have always performed on repositories pushed to our servers to protect our users against malformed or malicious Git data.
Update (2014-12-21): Apple has fixed this in Xcode 6.2 beta 3. It is unfortunate that there is no security update for a stable release of Xcode.
Bug File System Git GitHub HFS+ Mac Programming Security Unicode Version Control Windows
Glenn Reid:
I was editing an important file, but left it open (commonplace, and usually not destructive). Meanwhile, I edited the same file on another computer, with different changes, and saved it to my shared (Dropbox) location, so it sync’ed out from under TextEdit.
This has happened countless times in the past, and TextEdit was smart enough to notice it, and tell me not to save over the other file. This dialog box purports to do the same thing, BUT WITH A CRITICAL DIFFERENCE. It does not allow me to Save As… to preserve my changes (because Save As… is not a feature any more!).
My two choices are [LOSE CHANGES] and [LOSE OTHER CHANGES]. How is that a good choice?
I still find the new document model confusing. If I open a file in TextEdit and start typing, the indicator in the window’s close box shows that there are changes. This used to mean unsaved changes, but now it means something like changes since opening the document. Viewing the file with Quick Look or BBEdit shows that TextEdit has already saved the changes to disk. The file on disk does not match my last explicit save point, which is the way Macs worked for nearly 30 years. Instead, if I close the TextEdit window and elect not to save changes, TextEdit then fetches the last explicitly saved version of the file and writes it on top of the newer version on disk.
In short, the contents on disk always match the contents in the window, but you have the opportunity to revert if you want. This is inconsistent with history and with applications that don’t or can’t use the new document model. And it causes confusion in situations like the one Reid describes.
I’m glad to see Reid blogging again. His new post about Safari is also good.
Update (2014-12-21): Michel Fortin:
A problem I see with the new model is that version management isn’t that well done. Currently you have to open the document and navigate through a Time Machine-like UI to revert to an older version. If you just want to make a copy of the old version of a document somewhere, the way to accomplish that is terrible. It’d be much better if the Finder could let you browse previous save points for a document (perhaps in the Get Info window?). It should also let you open those previous versions, copy them elsewhere, and delete the ones you no longer want. The side-by-side view within the app can be convenient at times but is also is a terrible at other times (such as when the app crashes when reading your corrupted document!).
Perhaps another thing that is confusing is that there is actually three modes right now: the old model (save/don’t save/cancel), the autosaving model one with no prompt, and the new autosaving model with a prompt (save/revert changes/cancel).
Update (2014-12-27): Brian Webster:
This is the point where the aforementioned confusing language and UI comes in. If we take a closer look at this message, there is a key phrase that’s easy to miss:
Click Save Anyway to keep your changes and save the changes made by the other application as a version, or click Revert to keep the changes from the other application and save your changes as a version.
This is the “Versions” part of Versions & Autosave kicking in. No matter which button we choose, both versions of the document will be saved: our version from TextEdit, and the version written behind our backs by Dropbox/nano. The only difference between the two choices is which version we will see in the TextEdit window immediately afterwards.
After clicking “Save Anyway”, if we go to File > Revert > Browse All Versions…, we can see that both versions of the document are still available.
Document Model Dropbox Mac Mac OS X 10.10 Yosemite Safari TextEdit
