Re: Git Privacy

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 17, 2023, 02:36 UTC
Message-ID: <xmqqsf9njmc9.fsf@gitster.g>
In-Reply-To: <1d36d5ce-f452-fc31-6e30-b4ba819de7e4@web.de>

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

Show 5 quoted lines

> 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.