Michal Novotny [off-list ref] writes:
Hi,
this is the patch to introduce the ACL module architecture into git
versioning system.
No, it doesn't. It adds something only to "git daemon", but does
not affect any other uses of Git.
Side note: I am not saying other uses of Git must be ACL
controlled by MySQL database. They shouldn't be. I am only
saying that the proposed commit log message must match what the
change does.
Please familiarize yourself with Documentation/SubmittingPatches
first, and then imitate the style in existing commits in the history
and posted patches by the "good" developers (you can tell who they
are by observing the list traffic for a few weeks), by the way.
As "git daemon" already has a mechanism to specify what repositories
are served with whitelist or blacklist, I am not sure if this patch
adds enough value to the system to make us want to add further
complexity only to carry more code to be audited for security.
Opinions?
On Tue, Aug 14, 2012 at 9:12 AM, Junio C Hamano [off-list ref] wrote:
Michal Novotny [off-list ref] writes:
quoted
Hi,
this is the patch to introduce the ACL module architecture into git
versioning system.
No, it doesn't. It adds something only to "git daemon", but does
not affect any other uses of Git.
Yes, this part of the commit message also confused me until I read
through the patch further. :-(
Side note: I am not saying other uses of Git must be ACL
controlled by MySQL database. They shouldn't be. I am only
saying that the proposed commit log message must match what the
change does.
Please familiarize yourself with Documentation/SubmittingPatches
first, and then imitate the style in existing commits in the history
and posted patches by the "good" developers (you can tell who they
are by observing the list traffic for a few weeks), by the way.
As "git daemon" already has a mechanism to specify what repositories
are served with whitelist or blacklist, I am not sure if this patch
adds enough value to the system to make us want to add further
complexity only to carry more code to be audited for security.
Opinions?
Traditionally Git has been about providing the plumbing to handle the
protocol and storage, and other tools that wrap git manage access
controls, e.g. UNIX filesystem or gitolite. I would strongly prefer to
keep that arrangement.
Parsing the request line of git-daemon is easy. But we could make it
easier. An alternative arrangement would be to add a new command line
flag to git daemon like --command-filter that names an executable
git-daemon will invoke after parsing the request line. It can pass
along the client IP address, command request, repository name, and
resolved repository path, and tie stdin/stdout to the client. This
binary can decide to exec the proper git binary for the named command,
or just exit to disconnect the client and refuse service. This makes
it simple for a tool like gitolite to plug into the git-daemon
authorization path, without needing to be the network daemon itself,
worry about number of active connection slots, etc.