On Tue, Dec 18 2018, Jonathan Nieder wrote: > Ævar Arnfjörð Bjarmason wrote: >> On Mon, Dec 17 2018, Jonathan Nieder wrote: > >>> This would make per-branch ACLs (as implemented both by Gerrit and >>> gitolite) an essentially useless feature, so please no. >> >> Doesn't Gerrit always use JGit? >> >> The discussion upthread is about what we should do about git.git's >> version of this feature since we document it doesn't do its job from a >> security / ACL standpoint, but that doesn't preclude other server >> implementations from having a working version of this. >> >> But if gitolite is relying on this to hide refs, and if our security >> docs are to be believed, then it's just providing security through >> obscurity. > > Yes, Gerrit uses JGit. JGit shares configuration with Git, so if we > make that configuration in Git warn "This is just a placebo", then > people will naturally assume that it's just a placebo in JGit, too. Aside from the merits of this change it sounds like a good idea to document the server options JGit shares with us somewhere, or have a test mode similar to what I added in (but didn't follow-up on integrating) in https://public-inbox.org/git/20170516203712.15921-1-avarab@xxxxxxxxx/ > More importantly, if Git upstream stops caring about this use case, > then the protocol and other features can evolve in directions that > make it even harder to support. I am willing to take on some of the > burden of keeping it working, even when I do not run any servers that > use plain Git (I do interact with many). > >> Like you I'm curious about a POC. The patch I submitted in >> <20181217221625.1523-1-avarab@xxxxxxxxx> takes the "SECURITY" docs at >> face value. > > One of the difficulties that security engineers have to deal with is > living without absolutes. In other words, their experience is > constant risk/benefit tradeoffs: if you want 0% risk, then don't use a > computer. ;-) > > If someone has thoughts on what would lead people to be comfortable > with removing the SECURITY notice, then I'm happy to listen. As > already mentioned, I am strongly against abandoning this use case. For me this would be docs backed up by tests (which can start as a ML reply) showing a case where this actually works to hide data. I.e. have a repo with "master" and a "root-password" branch, where the "root-password" branch has content that's irresistible to "git repack" for delta purposes, do we end up sending the "root-password" content over on a fetch even when that branch isn't advertised & forbidden? Or, if that fails are there ways to make it work? E.g. using hidden/* in combination with delta islands?
