Re: Enhancements to git-protocoll

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sun, Jul 29, 2012 at 7:38 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>
>> We sort of want this in Gerrit Code Review to pass reviewer names on
>> the command line of git push, making it easier for users to upload a
>> code review. The idea is similar to what happens with gcc accepting
>> linker flags that are just passed onto the linker.
>
> For reviewer names, authentication cookies and things of that nature
> where the extra pieces of information affect the outcome in a way
> that does not have to change how the underlying protocol exchange
> works, such an additional one-way channel from the pusher to pushee
> to carry auxiliary information would be sufficient.

Yes, that is what I was trying to argue. :-)

I agree that authentication information is outside of the Git protocol
itself. We rely on SSH authentication for SSH and HTTP native
authentication methods for HTTP transport. But at least in the HTTP
case, the Git client has learned how to set up the authentication data
for the user to make it easier to use HTTP authentication. We don't
yet support native OAuth 2.0 (ick!) or HTTP cookies as well as we do
client side SSL certificates or basic username/password pair.

If we want to support additional information from pusher to pushee,
this is a "native feature" of Git and should be supported on all
native push type transports, with roughly the same semantics
everywhere. I don't want to add additional data into X-Git-Foo HTTP
headers in HTTP, and as environment variables in SSH, for example.
Additional HTTP headers will *probably* transit an HTTP proxy
correctly (but there are a lot of broken proxy servers so I don't put
it past someone to strip an X-* header they don't think is "safe").
SSH environment variables are icky to set from the client, and server
side Git would need to know how it was invoked to decode the correct
data and make it available uniformly to repository owner authored
hooks.

>  The server may
> decide to accept otherwise forbidden, or reject otherwise permitted,
> push based on the extra information given, for example, and that is
> an example of an enhancement that does not have to change how the
> underlying protocol exchange works.

Yes.

> The way to expose the extra information parsed by Git to the server
> side could be made into calling out to hooks, and at that point,
> gitolite would not even have to know about the pack protocol.

Good point. The case that spawned this thread however still has a
problem with this approach. gitolite would need to create a repository
to invoke the receive-pack process within, and install that new hook
script into... when the hook was trying to prevent the creation of
that repository in the first place.

Maybe I am jaded by the way JGit handles the protocol, it is easy for
application code to glue into and see things going on in the protocol
in ways that are hard to do from git-core.

> Perhaps the interface to such a hook may be "hook can tell Git to
> abort the communication by exiting non-zero, after giving a message
> to its standard output".

Perhaps this new channel data is simply passed as arguments to
receive-pack on the remote side?

An ancient Git would abort hard if passed this flag. An updated Git
could set environment variables before calling hooks, making the
arguments visible that way. And gitolite can still scrape what it
needs from the command line without having to muck about inside of the
protocol, but only if it needs to observe this new data from pusher to
pushee?

`git push -Rfoo=baz host:dest.git master` on the client would turn
into `git-receive-pack -Rfoo=baz dest.git` in the SSH and git://
command line, and cause GIT_PUSH_ARG_FOO=baz to appear in the
environment of hooks. Over smart HTTP requests would get an additional
query parameter of foo=baz.


The other hacky idea I had was to use a fake reference and have the
client push a structured blob to that ref. The server would decode the
blob, and deny the creation of the fake reference, but be able to get
additional data from that blob. Its hacky, and I don't like making a
new blob on the server just to transport a few small bits of data from
the client.
--
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


[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google