Re: Git Privacy

[Junio C Hamano <gitster@pobox.com>]

René Scharfe <l.s.r@web.de> writes:

> But Git is not a legal entity, it's just a command line program that you,
> the data subject, control.  You can use the  option --date or the
> environment variable GIT_AUTHOR_DATE to set the author timestamp and the
> variable GIT_COMMITTER_DATE to set the committer timestamp on commit.
> Not sure why there is no command line option for the latter, hmm.

For two reasons.

 * While using the GIT_AUTHOR_DATE environment variable is perfectly
   adequate (after all, we did not have the option before Git 1.7.0,
   released in Feb 2010), overriding the author time with "--date"
   had a good reason to exist, unlike the committer timestamp.

   Imagine you were relayed somebody else's changes, not via a
   format that is kosher and acceptable by "git am", but somehow
   managed to reproduce in your working tree.  If you also have
   learned when and in which timezone the original author made that
   change, you'd want to have a way to record it.

 * Having a system clock that can randomly go backwards and using
   such a system clock to record the committer timestamp, has broken
   "git log" in mergy-bushy histories.  This issue has been somewhat
   mitigated by introduction of generation numbers, but traversing
   the commits in the newer part of the history that are not yet
   covered by commit-graph would be affected if you let your commit
   timestamps go back and force deliberately.

> So I see this more as a usability issue.  Git allows its users to tailor
> commits to suit their needs in many ways.  You can edit file contents,
> history and metadata.  For timestamp and timezone this isn't as
> convenient as it could be.

I think the existing two environment variables are very good place
to draw the line.  When we start talking about "privacy", just like
"security", the exact details of the design and the implementation
would affect the resulting quality of the "privacy enhancing
features", but our primary mission is source code control and we are
not equipped to even measure how good our implementation would be.

Just like we do not pretend to be security engineers and do not
invent our own implementations of the hash functions and secure
network transports (instead we let third-parties to implement them
and just use them), we should NOT be adding a "--privacy" option
that picks rand(24)*60 as UTC offset and pretends that it the
timezone of the author, and picks some random timestamp between the
timestamp of the latest commit in the repository and the actual
wallclock timestamp and pretends that is the author time.  After
all, our project is not about coming up with a quality time
obfusucation.

But the good thing is that privacy-minded folks can write a quality
implementation of a much better design to lie about the timezone and
the current time, preferrably (but not absolutely necessary) within
the constraints that the time should not go backwards, which would
help Git.  Once such an external program is written, the users can
arrange that the program is called every time the shell gives the
control back to the user to set its output to GIT_AUTHOR_DATE.  Zsh
has precmd mechansim that you can use to invoke such a mechanism
before each prompt; bash has PROMPT_COMMAND that can used in a
similar way.

Needless to say, such a "privacy enhancing `date` command" can be
used outside the context of Git, too.  My point is that it is not
within the scope of this project to add an internal implementation
of such a command and drive that from a command line option or a
configuration variable.

Thanks.