End Date of the Review Period:
Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Wednesday, December 17, 2014
- Ignore rule parser was reimplemented to support ** wildcard patterns, negation rules and improve performance
- Add "aggressive" option to GC
- GarbageCollectCommand now supports DfsRepository
- Support for Submodule configuration submodule.<name>.ignore
Support for new submodule repository layout (.git/modules of the super project contains the submodule repositories)
InitCommand support for option "--separate-git-dir" to store .git meta data directory in a separate directory
CloneCommand support to store .git meta data directory in a separate directory
- Permission bits for "executable" attribute are now set according to the umask on Posix/Java7
- BundleWriter now supports including HEAD in bundle
- New config parameter core.trustfolderstat
Features in JGit Command Line
Add option --bare to clone command
Add options --heads and --tags to ls-remote command
- Reimplemented ignore rule parser to improve performance of ignore rule evaluation
- Enhance SubmoduleWalk with a fast check whether a repo contains submodules
Build and Release Engineering
- The java7 feature is now included in org.eclipse.jgit.feature
- Maven site generation for jgit
Fix for vulnerability CVE-2014-9390
We used to allow committing a path ".Git/config" with JGit & EGit that is running on a case sensitive filesystem, but an attempt to check out such a path with Git that runs on a case insensitive filesystem would have clobbered ".git/config", which is definitely not what the user would have expected. JGit now prevents you from tracking a path with ".Git" (in any case combination) as a path component.
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". Pathnames with these potential issues are rejected on the affected systems.
As described in Securing your Git server native git has been enhanced by configuration parameters allowing to configure a git server to check all objects it receives against problematic pathes. A server running e.g. on Linux can be configured to check also for pathes problematic on HFS+ or NTFS. This is also possible for JGit based Git servers. JGit understands the boolean config parameters receive.fsckobjects, fsck.safeForWindows and fsck.safeForMacOS. They match native git's receive.fsckobjects, core.protectNTFS, core.protectHFS.
|receive.fsckobjects||receive.fsckobjects||enable checks when receiving objects|
|core.protectNTFS||fsck.safeForWindows||check pathes problematic on NTFS|
|core.protectHFS||fsck.safeForMacOS||check pathes problematic on HFS+|
Enabling receive.fsckObjects makes JGit check the integrity of objects before a push is accepted, which is a pre-requisite for the other flags. The fsck.safeForMacOS and fsck.safeForWindows flags prevent the Mac OS X and Windows vulnerabilities described above, respectively. Both default to true on their respective systems but will need to be enabled specifically on other platforms. Since clients could be using a different operating system to your server you should enable both on JGit based servers.
A big "thanks!" for bringing this issue to us goes to our friends in the Mercurial land, namely, Matt Mackall and Augie Fackler.