- 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.
Tuesday, December 23, 2014