Julian Brost <julian@xxxxxxxxxx> writes: > On 07.03.2014 22:04, Jeff King wrote: >> >> If you want to work on it, I think it's an interesting area. But >> any development would need to think about the transition plan for >> existing sites that will be broken. > > I can understand the problem with backward compatibility but in my > opinion the default behavior should definitely be to ignore untrusted > config files and hooks as it would otherwise only protect users that > are already aware of the issue anyways and manually enable this option. > > Are there any plans for some major release in the future that would > allow introducing backward incompatible changes? Git 2.0 has been in the planning for quite some months, and I am inclined to merge these topics prepared for that release to 'master' during this cycle. Anything new like this one is way too late for it, but that does not mean we can never do 3.0 in the future. Perhaps going this way might be possible: * Introduce a configuration that is read only from $HOME/.gitconfig (or its xdg equivalent) to enable or disable the "unsafe" behaviour. By default (i.e. when the above configuration is not set), allow "unsafe" read; when instructed by the above configuration to forbid "unsafe" read, ignore configuration files that are not owned by the owner of the process. People can toggle the "unsafe" read to experiment with the above (~gitdaemon/.gitconfig can perhaps be used to restrict the daemon access) Keep it that way for a few releases. * After a few releases, start warning people who do not have the "unsafe" option in their $HOME/.gitconfig about a future default change, to force them to explicitly set it. Keep it that way for a few releases. * Flip the default, perhaps still keeping the warning on the flipped default to help people who have not been following along. Keep it that way for a few releases. * Then finally remove the warning. A release cycle usually last 10-12 weeks on average. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html