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.
3.6.0
Features
- 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
Performance Improvements
- 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
The patches fixing CVE-2014-9390 released in JGit 3.4.2 and 3.5.3 are also included in 3.6.0.
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.
git-core
JGit
description
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.
- Log in to post comments