Re: git version statistics

[Jeff King <peff@peff.net>]

On Thu, May 31, 2012 at 12:35:20PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
> > index 149db88..f3b8422 100644
> > --- a/builtin/fetch-pack.c
> > +++ b/builtin/fetch-pack.c
> > @@ -327,6 +327,7 @@ static int find_common(int fd[2], unsigned char *result_sha1,
> >  			if (args.no_progress)   strbuf_addstr(&c, " no-progress");
> >  			if (args.include_tag)   strbuf_addstr(&c, " include-tag");
> >  			if (prefer_ofs_delta)   strbuf_addstr(&c, " ofs-delta");
> > +			strbuf_addf(&c, " agent=git/%s", git_version_string);
> >  			packet_buf_write(&req_buf, "want %s%s\n", remote_hex, c.buf);
> >  			strbuf_release(&c);
> 
> Even though the version string GIT-VERSION-GEN script deduces from
> the repository version is designed to be safe, in general "version"
> file can contain a string with whitespaces.  You may want to be
> careful about that in the above.

Yeah, I agree. I should have been more clear that this patch was an RFC
about the idea, not the implementation.

We could also strip off junk like ".dirty" which is unlikely to be
interesting for statistical reporting. On the other hand, it could be
useful for somebody debugging, and it can always be stripped later.

I don't know if anybody cares about the security or privacy implications
of advertising your client version. Maybe it should be configurable?

> Do we want a similar identifier string on the other side of the
> connection?

We could. I don't see much point, unless you were going to conduct a
similar survey by hitting random IPs looking for git ports (but even
then, you're not likely to turn up much, because you have to know a repo
name before you can convince git to show a capability string). I suppose
it could also help with debugging if your client is having trouble
talking to a server that is not under your control.

Some traditional security advice I have heard is that servers should not
advertise their versions, as it makes it more obvious what holes they
have. Personally, I find that argument to be mostly security through
obscurity. If I have an exploit for version X, it's generally just as
easy to try it as it is to check the version (unless the exploit
requires a lot of effort, like guessing a value that might take
thousands of tries).

-Peff