{"thread":{"id":"59981","subject":"Git Privacy","startedAt":"2023-07-13T16:37:17Z","lastAt":"2023-07-18T21:59:36Z","messageCount":17,"participants":["nick","Junio C Hamano","René Scharfe","Jason Pyeron","Theodore Ts'o","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"479462","messageId":"CTZ9RD9RQ5UO.3OIJX50PKMIR0@anonymous","threadId":"59981","inReplyTo":null,"subject":"Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-13T16:27:46Z","receivedAt":"2023-07-13T16:37:17Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"A couple years ago, I created git-privacy[1]. In it, I explain how\nhaving exact commit times in a Git repo, over a long enough timespan,\ncan potentially be used to deduce private information about a\ndeveloper's life. Then I go on to explain the steps to prevent this\nprivate information leakage.\n\nI know this is low on the list of priorities when it comes to increasing\none's digital privacy, but I think it still matters. It's certainly\nrelevant to developers who need to remain anonymous while version\ncontrolling their public software.\n\nI was wondering if it would be appropriate to implement a feature which\nwould allow for automatic obfuscation of Git committer and author\ntimestamps without the need to assign environment variables or use Git\nhooks. Perhaps a config option to automatically set the date to a time\nbefore Git was invented?\n\nMight there a better way to implement these ideas than what I'm\nthinking? Please provide some feedback.\n\n\nReferences:\n1: https://git.nicholasjohnson.ch/git-privacy/\n"},{"id":"479464","messageId":"xmqqlefjpwif.fsf@gitster.g","threadId":"59981","inReplyTo":"CTZ9RD9RQ5UO.3OIJX50PKMIR0@anonymous","subject":"Re: Git Privacy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-13T17:11:04Z","receivedAt":"2023-07-13T17:11:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"nick\" writes:\n\n> hooks. Perhaps a config option to automatically set the date to a time\n> before Git was invented?\n\nFor some use cases that are outside of how Git was designed to be\nused, such configuration might be useful, but I am not yet convinced\nthat it is worth the engineering effort for this project to review,\naccept and maintain changes to implement it.\n\nJust my personal opinion, of course ;-)\n\nAfter all, if you leave series of commits that stress the fact that\nyou not just fail to keep, but do deliberately avoid to keep, a\nreliable record of when you made your changes, half the value of\nkeeping your work in source code management system vanishes. When\nsomebody comes to your project and says certain parts of your code\nwere stolen from their proprietary IP, wouldn't you rather be able\nto produce the record of who did what at which time to refute their\nclaim by showing that your project members invented the code long\nbefore they claim they were stolen from them?\n"},{"id":"479510","messageId":"CU1SAE4WGP3X.3R7TTIWFSHGDI@anonymous","threadId":"59981","inReplyTo":"xmqqlefjpwif.fsf@gitster.g","subject":"Re: Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-14T09:22:44Z","receivedAt":"2023-07-14T09:22:17Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"> \"nick\" writes:\n>\n> > hooks. Perhaps a config option to automatically set the date to a time\n> > before Git was invented?\n>\n> [...] I am not yet convinced that it is worth the engineering effort\n> for this project to review, accept and maintain changes to implement\n> it.\n\nUpon further thought, given that it's already pretty easy to accomplish\ntimestamp obfuscation, albeit clumsy, I concede that it may not be worth\nthe engineering effort to implement my original suggestion. So I'll drop\nit.\n\nHowever, I think it is worth the effort for the time zones. Is there any\nreason Git doesn't automatically convert local time to UTC in timestamps\nto prevent leaking the developer's time zone?\n\nIt seems like a simple change that would be good for the developer's\nprivacy without harming Git in any way. It would also be easy to\nimplement as backwards-compatible.\n\nI've been told this idea was already mentioned, but it has been ignored\nfor some time:\n\nhttps://git.issues.gerritcodereview.com/issues/40000039\n\nThe sooner it's addressed, the better since it means less personal\ninformation leakage.\n\n> After all, if you leave series of commits that stress the fact that\n> you not just fail to keep, but do deliberately avoid to keep, a\n> reliable record of when you made your changes, half the value of\n> keeping your work in source code management system vanishes. When\n> somebody comes to your project and says certain parts of your code\n> were stolen from their proprietary IP, wouldn't you rather be able\n> to produce the record of who did what at which time to refute their\n> claim by showing that your project members invented the code long\n> before they claim they were stolen from them?\n\nThank you for bringing this up. This was not an angle I considered when\nwriting my repo git-privacy, but now I'll definitely warn about it there.\n\nYour feedback above would not apply to the UTC time zone proposal I\nlinked to though. There is a good reason to implement it and, as far as\nI can think of, no reason not to.\n"},{"id":"479522","messageId":"xmqqbkgeqw6n.fsf@gitster.g","threadId":"59981","inReplyTo":"CU1SAE4WGP3X.3R7TTIWFSHGDI@anonymous","subject":"Re: Git Privacy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-14T16:45:04Z","receivedAt":"2023-07-14T16:45:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"nick\" writes:\n\n>> \"nick\" writes:\n>>\n>> > hooks. Perhaps a config option to automatically set the date to a time\n>> > before Git was invented?\n>>\n>> [...] I am not yet convinced that it is worth the engineering effort\n>> for this project to review, accept and maintain changes to implement\n>> it.\n>\n> Upon further thought, given that it's already pretty easy to accomplish\n> timestamp obfuscation, albeit clumsy, I concede that it may not be worth\n> the engineering effort to implement my original suggestion. So I'll drop\n> it.\n>\n> However, I think it is worth the effort for the time zones. Is there any\n> reason Git doesn't automatically convert local time to UTC in timestamps\n> to prevent leaking the developer's time zone?\n\nActually it is the other way around, if I understand correctly.\n\nGit could have been designed to discard that information like\nprevious version control systems, but it is another piece of\ninteresting information and made a conscious design decision to keep\nit. In other words, \"is there any reason why we do not discard the\ninformation?\" is a wrong question to ask in the context of VCS.\n\nI earlier said I am not yet convinced it is worth our time, and so\nfar I haven't heard anything new that may help me convince myself\nyet.\n\nThanks.\n"},{"id":"479541","messageId":"CU2GQHQV5GD3.CL67078EF4OO@anonymous","threadId":"59981","inReplyTo":"xmqqbkgeqw6n.fsf@gitster.g","subject":"Re: Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-15T04:32:13Z","receivedAt":"2023-07-15T04:31:40Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"Junio C Hamano wrote:\n> \"nick\" writes:\n>\n> > However, I think it is worth the effort for the time zones. Is there any\n> > reason Git doesn't automatically convert local time to UTC in timestamps\n> > to prevent leaking the developer's time zone?\n>\n> Actually it is the other way around, if I understand correctly.\n>\n> Git could have been designed to discard that information like\n> previous version control systems, but it is another piece of\n> interesting information and made a conscious design decision to keep\n> it. In other words, \"is there any reason why we do not discard the\n> information?\" is a wrong question to ask in the context of VCS.\n\nI'll make my best case one last time and if it doesn't convince you,\nthen I have nothing else to offer.\n\nGit leaks private information about developers publicly by design\nthrough its precise timestamps. You mentioned this makes it easier to\ndeny copyright claims, but one could get more or less the same benefit\nwithout sacrificing privacy by rounding commit times to the nearest day.\nI'm not advocating making this behavior the default, just that\ndevelopers be given the option to do it.\n\nThe time zones reveal private information about developers and they\ndon't even serve a use case, as far as I'm aware. A backwards-compatible\nway to solve this leak would be to convert timestamps to UTC by default\nand have a Git config option to revert back to the current behavior.\n"},{"id":"479559","messageId":"1d36d5ce-f452-fc31-6e30-b4ba819de7e4@web.de","threadId":"59981","inReplyTo":"CU2GQHQV5GD3.CL67078EF4OO@anonymous","subject":"Re: Git Privacy","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2023-07-16T11:47:29Z","receivedAt":"2023-07-16T11:47:42Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 15.07.23 um 06:32 schrieb nick:\n> Junio C Hamano wrote:\n>> \"nick\" writes:\n>>\n>>> However, I think it is worth the effort for the time zones. Is there any\n>>> reason Git doesn't automatically convert local time to UTC in timestamps\n>>> to prevent leaking the developer's time zone?\n>>\n>> Actually it is the other way around, if I understand correctly.\n>>\n>> Git could have been designed to discard that information like\n>> previous version control systems, but it is another piece of\n>> interesting information and made a conscious design decision to keep\n>> it. In other words, \"is there any reason why we do not discard the\n>> information?\" is a wrong question to ask in the context of VCS.\n>\n> I'll make my best case one last time and if it doesn't convince you,\n> then I have nothing else to offer.\n>\n> Git leaks private information about developers publicly by design\n> through its precise timestamps. You mentioned this makes it easier to\n> deny copyright claims, but one could get more or less the same benefit\n> without sacrificing privacy by rounding commit times to the nearest day.\n> I'm not advocating making this behavior the default, just that\n> developers be given the option to do it.\n>\n> The time zones reveal private information about developers and they\n> don't even serve a use case, as far as I'm aware. A backwards-compatible\n> way to solve this leak would be to convert timestamps to UTC by default\n> and have a Git config option to revert back to the current behavior.\n\nI get it to some extent: timezone and timestamps are personal data, which\nmay only be collected and processed for a lawful purpose according to the\nGDPR. Git works just as well with timestamps that omit time of day and\ntimezone, so is there a valid reason to collect that information? At\nleast that's how I understand it, and I'm certainly not a lawyer.\n\nBut Git is not a legal entity, it's just a command line program that you,\nthe data subject, control. You can use the option --date or the\nenvironment variable GIT_AUTHOR_DATE to set the author timestamp and the\nvariable GIT_COMMITTER_DATE to set the committer timestamp on commit.\nNot sure why there is no command line option for the latter, hmm.\n\nSo I see this more as a usability issue. Git allows its users to tailor\ncommits to suit their needs in many ways. You can edit file contents,\nhistory and metadata. For timestamp and timezone this isn't as\nconvenient as it could be. If git commit has a --signoff option that\ncan be enabled by default then adding config options for controlling\ntimestamp granularity is hard to say no to.\n\nRené\n\n"},{"id":"479561","messageId":"CU3SS0F0GOWY.1UEU7MOUEGUKZ@anonymous","threadId":"59981","inReplyTo":"1d36d5ce-f452-fc31-6e30-b4ba819de7e4@web.de","subject":"Re: Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-16T22:52:09Z","receivedAt":"2023-07-16T22:51:41Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"René Scharfe wrote:\n> schrieb nick:\n> > Git leaks private information about developers publicly by design\n> > through its precise timestamps. You mentioned this makes it easier to\n> > deny copyright claims, but one could get more or less the same benefit\n> > without sacrificing privacy by rounding commit times to the nearest day.\n> > I'm not advocating making this behavior the default, just that\n> > developers be given the option to do it.\n>\n> I get it to some extent: timezone and timestamps are personal data,\n> which may only be collected and processed for a lawful purpose according to\n> the GDPR.\n\n> But Git is not a legal entity, it's just a command line program that you,\n> the data subject, control.\n\nAs far as I know and I'm not a lawyer either, there are no legal issues\nrelated to this. To be clear, my argument is more a moral one, not a\nlegal one.\n\n> So I see this more as a usability issue. Git allows its users to tailor\n> commits to suit their needs in many ways. You can edit file contents,\n> history and metadata. For timestamp and timezone this isn't as\n> convenient as it could be. If git commit has a --signoff option that\n> can be enabled by default then adding config options for controlling\n> timestamp granularity is hard to say no to.\n\nYou're right that usability is not as good as it could be for those who\nwant more privacy.\n\nMany of the i2p devs are known only under pseudonyms. They definitely\ndon't want their timezones leaked while developing i2p. I imagine that\nthey have other repos that they develop non-anonymously. They could\ncreate a separate shell alias for Git with coarse-grained timestamps and\nno timezone, but it would still require a lot of mental bookkeeping to\nremember to use the alias every time. A single mistake would leak their\ntimezone.\n\nGit could solve this by offering a per-repo option that controls\ntimestamp granularity.\n"},{"id":"479562","messageId":"CU3Z2NYP6BGG.1PQ6S5AF60XX6@anonymous","threadId":"59981","inReplyTo":"CU2GQHQV5GD3.CL67078EF4OO@anonymous","subject":"Re: Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-16T23:07:06Z","receivedAt":"2023-07-16T23:11:17Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"nick wrote:\n> The time zones reveal private information about developers and they\n> don't even serve a use case, as far as I'm aware. A backwards-compatible\n> way to solve this leak would be to convert timestamps to UTC by default\n> and have a Git config option to revert back to the current behavior.\n\nCome to think of it, even if timezones were converted to UTC by default,\ntime of day would still leak information about a user's likely timezone.\n\nSo based on that and keeping in mind Git's desire for strong\nbackwards-compatibility, I'm amending my proposal to just a standalone\nGit option which would allow for forging timestamp and timezone\ninformation, with timestamp information being forgeable to varying\ndegrees of granularity.\n\nA new Git option is appropriate because Git doesn't already have\nfeatures which make this possible. So it would be necessary to implement\na new option anyways.\n"},{"id":"479564","messageId":"00b901d9b83d$249a2d20$6dce8760$@pdinc.us","threadId":"59981","inReplyTo":"CU3Z2NYP6BGG.1PQ6S5AF60XX6@anonymous","subject":"RE: Git Privacy","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2023-07-16T23:27:52Z","receivedAt":"2023-07-17T00:28:13Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> -----Original Message-----\n> From: nick \n> Sent: Sunday, July 16, 2023 7:07 PM\n> Subject: Re: Git Privacy\n> \n> nick wrote:\n> > The time zones reveal private information about developers and they\n> > don't even serve a use case, as far as I'm aware. A backwards-compatible\n> > way to solve this leak would be to convert timestamps to UTC by default\n> > and have a Git config option to revert back to the current behavior.\n> \n> Come to think of it, even if timezones were converted to UTC by default,\n> time of day would still leak information about a user's likely timezone.\n\nDiscussed this with our policy wonks...\n\nShort answer - no. There is no legal assumption that can be made - your work hours cannot be assumed to be 9-5. They also said that time zone is \"too broad at 1/24th of the world\", but understood the concern.\n\nThat being said the recommendation is to add --privacy\n\nWhere it assumes some defaults and those defaults can be controlled in your config or via --privacy=option1,option2 \n\nAnd then some of the options can be:\n\ndate-timezone=UTC\n\ndate-precision=8hour\n\netc...\n\nv/r,\n\nJason Pyeron\n\n--\nJason Pyeron | Architect\nContractor |\nPD Inc | Certified SBA 8(a)\n10 w 24th St | Certified SBA HUBZone\nBaltimore, MD | CAGE Code: 1WVR6\n\n.mil: jason.j.pyeron.ctr@mail.mil\n.com: jpyeron@pdinc.us\ntel : 202-741-9397\n\n\n"},{"id":"479565","messageId":"xmqqsf9njmc9.fsf@gitster.g","threadId":"59981","inReplyTo":"1d36d5ce-f452-fc31-6e30-b4ba819de7e4@web.de","subject":"Re: Git Privacy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-17T02:36:22Z","receivedAt":"2023-07-17T02:37:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> But Git is not a legal entity, it's just a command line program that you,\n> the data subject, control. You can use the option --date or the\n> environment variable GIT_AUTHOR_DATE to set the author timestamp and the\n> variable GIT_COMMITTER_DATE to set the committer timestamp on commit.\n> Not sure why there is no command line option for the latter, hmm.\n\nFor two reasons.\n\n * While using the GIT_AUTHOR_DATE environment variable is perfectly\n adequate (after all, we did not have the option before Git 1.7.0,\n released in Feb 2010), overriding the author time with \"--date\"\n had a good reason to exist, unlike the committer timestamp.\n\n Imagine you were relayed somebody else's changes, not via a\n format that is kosher and acceptable by \"git am\", but somehow\n managed to reproduce in your working tree. If you also have\n learned when and in which timezone the original author made that\n change, you'd want to have a way to record it.\n\n * Having a system clock that can randomly go backwards and using\n such a system clock to record the committer timestamp, has broken\n \"git log\" in mergy-bushy histories. This issue has been somewhat\n mitigated by introduction of generation numbers, but traversing\n the commits in the newer part of the history that are not yet\n covered by commit-graph would be affected if you let your commit\n timestamps go back and force deliberately.\n\n> So I see this more as a usability issue. Git allows its users to tailor\n> commits to suit their needs in many ways. You can edit file contents,\n> history and metadata. For timestamp and timezone this isn't as\n> convenient as it could be.\n\nI think the existing two environment variables are very good place\nto draw the line. When we start talking about \"privacy\", just like\n\"security\", the exact details of the design and the implementation\nwould affect the resulting quality of the \"privacy enhancing\nfeatures\", but our primary mission is source code control and we are\nnot equipped to even measure how good our implementation would be.\n\nJust like we do not pretend to be security engineers and do not\ninvent our own implementations of the hash functions and secure\nnetwork transports (instead we let third-parties to implement them\nand just use them), we should NOT be adding a \"--privacy\" option\nthat picks rand(24)*60 as UTC offset and pretends that it the\ntimezone of the author, and picks some random timestamp between the\ntimestamp of the latest commit in the repository and the actual\nwallclock timestamp and pretends that is the author time. After\nall, our project is not about coming up with a quality time\nobfusucation.\n\nBut the good thing is that privacy-minded folks can write a quality\nimplementation of a much better design to lie about the timezone and\nthe current time, preferrably (but not absolutely necessary) within\nthe constraints that the time should not go backwards, which would\nhelp Git. Once such an external program is written, the users can\narrange that the program is called every time the shell gives the\ncontrol back to the user to set its output to GIT_AUTHOR_DATE. Zsh\nhas precmd mechansim that you can use to invoke such a mechanism\nbefore each prompt; bash has PROMPT_COMMAND that can used in a\nsimilar way.\n\nNeedless to say, such a \"privacy enhancing `date` command\" can be\nused outside the context of Git, too. My point is that it is not\nwithin the scope of this project to add an internal implementation\nof such a command and drive that from a command line option or a\nconfiguration variable.\n\nThanks.\n"},{"id":"479567","messageId":"xmqq5y6jjlcs.fsf@gitster.g","threadId":"59981","inReplyTo":"xmqqsf9njmc9.fsf@gitster.g","subject":"Re: Git Privacy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-17T02:57:39Z","receivedAt":"2023-07-17T02:57:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> and just use them), we should NOT be adding a \"--privacy\" option\n> that picks rand(24)*60 as UTC offset and pretends that it the\n> timezone of the author, and picks some random timestamp between the\n> timestamp of the latest commit in the repository and the actual\n> wallclock timestamp and pretends that is the author time. After\n> all, our project is not about coming up with a quality time\n> obfusucation.\n\nWe could go to the extreme in the complete opposite, if we do not\ncare about the quality of the \"privacy\" feature, and you could\nprobably talk me into adopting below as long as the option or the\nconfiguration are not named with the word \"privacy\" in them (a\n\"--useless-time\" option, or a \"core.uselesstime\" configuration\nvariable, are OK).\n\nWhen the feature is in effect, all timestamps in commit and tag\nobjects pretend to be in UTC timezone, and\n\n (1) the commits record the Epoch as its timestamps if there is no\n parent;\n\n (2) the commits record one second after the largest of the\n timestamps as its timestamps of all its parents;\n\n (3) in any case, the same (phoney) timestamp is used for author and\n committer.\n\n (4) the tags record the Epoch as its timestamp if they point at\n trees or blobs.\n\n (5) the tags record one second after the largest timestamp of\n pointee as their timestamp, if they point at tags or commits.\n\n (6) as the reflog is a local matter, its timestamp may be local,\n but it is OK if it ends up being just a useless number if that\n is more convenient to implement.\n\nThe resulting history will be shouting that \"I am privacy conscious\nand hiding my activities behind a fake clock\" in capital letters,\nwhich I would not call a quality design of a privacy feature, but it\ndoes completely dissociate the wallclock time from the recorded\nhistory without breaking the monotonicity of timestamps in the\nrecorded history.\n\nWhen the useless-time feature is in use, you cannot expect features\nlike \"git log --since\" would work sensibly, but that is a given, I\nwould guess.\n"},{"id":"479568","messageId":"CU45QDSITT7K.1HLDIM21MXW7H@anonymous","threadId":"59981","inReplyTo":"00b901d9b83d$249a2d20$6dce8760$@pdinc.us","subject":"Re: Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-17T04:20:12Z","receivedAt":"2023-07-17T04:19:35Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"Jason Pyeron wrote:\n> > nick wrote:\n> > Come to think of it, even if timezones were converted to UTC by default,\n> > time of day would still leak information about a user's likely timezone.\n>\n> Discussed this with our policy wonks...\n>\n> Short answer - no. There is no legal assumption that can be made - your\n> work hours cannot be assumed to be 9-5. They also said that time zone is\n> \"too broad at 1/24th of the world\", but understood the concern.\n\nAn adversary may have other information which can be correlated with the\ntimestamps or timezone, making them less benign than in isolation.\n\n> That being said the recommendation is to add --privacy\n\nI'm not familiar with the processes here. Is it my responsibility to\nimplement it since I proposed it or who shall implement it?\n\n> Where it assumes some defaults and those defaults can be controlled in\n> your config or via --privacy=option1,option2\n>\n> And then some of the options can be:\n>\n> date-timezone=UTC\n>\n> date-precision=8hour\n\nThis sounds great. A few preliminary ideas on implementation:\n\n'date-precision' must round the author AND committer timestamps\notherwise it's useless\n\n'date-precision' must round down, never into the future\n\n'date-timezone' must convert the date from local time and not just\nreplace the timezone\n\nAny thoughts on making 'date-precision' also apply to GnuPG signature\ntimestamps? It's possible to specify a custom GnuPG command which does\nthis using gpg.program, but it's inconvenient. The relevant GnuPG option\nis '--faked-system-time !'\n\nIf that idea is no good, there should at least be a warning displayed\nwhen the user signs anything with GnuPG with 'date-precision' enabled.\n\nIf that idea is good, then there should be a conditional check that the\nrounding performed by 'date-precision' does not round down to before the\nsigning key was generated. Otherwise the signature will be invalid.\n"},{"id":"479569","messageId":"CU47D1G1Y1E2.GID9E4XI7W1K@anonymous","threadId":"59981","inReplyTo":"xmqq5y6jjlcs.fsf@gitster.g","subject":"Re: Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-17T05:36:48Z","receivedAt":"2023-07-17T05:36:29Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n> > and just use them), we should NOT be adding a \"--privacy\" option\n> > that picks rand(24)*60 as UTC offset and pretends that it the\n> > timezone of the author, and picks some random timestamp between the\n> > timestamp of the latest commit in the repository and the actual\n> > wallclock timestamp and pretends that is the author time. After\n> > all, our project is not about coming up with a quality time\n> > obfusucation.\n>\n> We could go to the extreme in the complete opposite, if we do not\n> care about the quality of the \"privacy\" feature, and you could\n> probably talk me into adopting below as long as the option or the\n> configuration are not named with the word \"privacy\" in them (a\n> \"--useless-time\" option, or a \"core.uselesstime\" configuration\n> variable, are OK).\n\nI hadn't considered it in my other responses, but calling it --privacy\nwould be a bad idea for exactly the reasons you laid out. Calling it\n--useless-time would be better.\n\n> When the feature is in effect, all timestamps in commit and tag\n> objects pretend to be in UTC timezone, and\n>\n> (1) the commits record the Epoch as its timestamps if there is no\n> parent;\n>\n> (2) the commits record one second after the largest of the\n> timestamps as its timestamps of all its parents;\n>\n> (3) in any case, the same (phoney) timestamp is used for author and\n> committer.\n>\n> (4) the tags record the Epoch as its timestamp if they point at\n> trees or blobs.\n>\n> (5) the tags record one second after the largest timestamp of\n> pointee as their timestamp, if they point at tags or commits.\n>\n> (6) as the reflog is a local matter, its timestamp may be local,\n> but it is OK if it ends up being just a useless number if that\n> is more convenient to implement.\n\nYou're the expert on Git's internals and clearly know best how to\nimplement this with the least amount of breakage. So I can't comment on\nthat.\n\nI will say these points seem to be sufficient to satisfy the privacy use\ncase. I don't think any more can reasonably be expected.\n\n> The resulting history will be shouting that \"I am privacy conscious\n> and hiding my activities behind a fake clock\" in capital letters,\n> which I would not call a quality design of a privacy feature, but it\n> does completely dissociate the wallclock time from the recorded\n> history without breaking the monotonicity of timestamps in the\n> recorded history.\n\nDepending on one's threat model, revealing the fact that one is using a\nprivacy feature/tool isn't necessarily a problem. I agree that perhaps a\nreally high-quality implementation of a privacy feature could do this,\nbut I think that's outside the scope and way too much to expect from\ndevs as you said.\n\n> When the useless-time feature is in use, you cannot expect features\n> like \"git log --since\" would work sensibly, but that is a given, I\n> would guess.\n\nThere could be a warning in the documentation that this feature may\ncause breakage.\n"},{"id":"479579","messageId":"xmqqedl6ijdy.fsf@gitster.g","threadId":"59981","inReplyTo":"xmqqsf9njmc9.fsf@gitster.g","subject":"Re: Git Privacy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-17T16:37:45Z","receivedAt":"2023-07-17T16:37:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> René Scharfe writes:\n>\n>> Not sure why there is no command line option for the latter, hmm.\n>\n> For two reasons.\n>\n> * While using the GIT_AUTHOR_DATE environment variable is perfectly\n> adequate (after all, we did not have the option before Git 1.7.0,\n> released in Feb 2010), overriding the author time with \"--date\"\n> had a good reason to exist, unlike the committer timestamp.\n>\n> Imagine you were relayed somebody else's changes, not via a\n> format that is kosher and acceptable by \"git am\", but somehow\n> managed to reproduce in your working tree. If you also have\n> learned when and in which timezone the original author made that\n> change, you'd want to have a way to record it.\n\nThe point here is that tweaking the author time has a general\nutility that is wider than \"I want to use a timestamp that is\ndisconnected to the reality\"---in fact, it is quite the opposite.\nThe above example is using the option as a tool to record what\nactually happened in reality and not about using a fake time at\nwhich nothing related to the resulting commit happened. That is why\nI said that it \"has a good reason to exist\".\n\nContrasted to this, the committer timestamp is about when the commit\nwas created, and there is no need to have an easy access from the\ncommand line like \"--date\" option does to tweak it [*]. It is\nupdated to the current time when you \"commit --amend\" for exactly\nthe same reason.\n\n> I think the existing two environment variables are very good place\n> to draw the line.\n> ...\n> Needless to say, such a \"privacy enhancing `date` command\" can be\n> used outside the context of Git, too. My point is that it is not\n> within the scope of this project to add an internal implementation\n> of such a command and drive that from a command line option or a\n> configuration variable.\n\nAnd I still think this is a reasonable way forward. We have offered\ntwo environment variables for their use and it is up to them to use\nit when driving \"git\" binary from their environment. Anything more\nis a distraction to this project, I would think.\n\n\n[Footnote]\n\n * As long as your system clock is reasonably accurate that does not\n need constant tweaking, that is. If not, you have a more serious\n problem than tweaking the string on the committer line---none of\n the timestamp based heuristics like \"make\" not rebuilding things\n unnecessarily would be broken on your system.\n"},{"id":"479585","messageId":"20230717205750.GA3901704@mit.edu","threadId":"59981","inReplyTo":"CU47D1G1Y1E2.GID9E4XI7W1K@anonymous","subject":"Re: Git Privacy","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2023-07-17T20:57:50Z","receivedAt":"2023-07-17T20:58:05Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jul 17, 2023 at 05:36:48AM +0000, nick wrote:\n> \n> I hadn't considered it in my other responses, but calling it --privacy\n> would be a bad idea for exactly the reasons you laid out. Calling it\n> --useless-time would be better.\n\nIt might also be worth pointing out that someone still might be able\nto figure out information from when a branch gets pushed to a git\nrepo. Even if the time in the timestamp is randomized, when someone\nsends a pull request to github is not going to be randomize. Or if\nsomeone pushes their branch to github, and github actions is set up to\nautomatically kick off regression tests as soon as the branch changes,\nthis can also leak information about when the push happened.\n\nThere are also integration test systems, such as the gce-xfstests's\nlightweight test manager, which polls the branch every 15 minutes, and\nthe moment the branch changes, tests immediately start running and the\ntimestamp when the test was kicked off is encoded in the testrunid.\n\nWhich is why, quite frankly, I'm a bit dubious about the whole \"I must\nobfuscate the time zone from which I am operating\", as something\nthat's really worth the effort, since it has a lot of downsides, and\nif the user is not careful, they may end up leaking information about\nwhen they are active anyway....\n\n\t\t\t\t\t- Ted\n"},{"id":"479589","messageId":"CU4TBVU6DREW.ZZDV1JX2BNGV@anonymous","threadId":"59981","inReplyTo":"20230717205750.GA3901704@mit.edu","subject":"Re: Git Privacy","fromName":"nick","fromEmail":"nick@nicholasjohnson.ch","sentAt":"2023-07-17T22:49:42Z","receivedAt":"2023-07-17T22:49:08Z","isPatch":false,"sender":{"key":"nick@nicholasjohnson.ch","avatar":null},"body":"Theodore Ts'o wrote:\n> It might also be worth pointing out that someone still might be able\n> to figure out information from when a branch gets pushed to a git\n> repo.\n\nGithub and other forges are actually known to track this information.\n\n> [...]\n>\n> Which is why, quite frankly, I'm a bit dubious about the whole \"I must\n> obfuscate the time zone from which I am operating\", as something\n> that's really worth the effort, since it has a lot of downsides, and\n> if the user is not careful, they may end up leaking information about\n> when they are active anyway....\n\nI'm fine with the argument against that it causes breakage, but I\ndisagree with the idea that it shouldn't be implemented because \"they\nmay end up leaking information about when they are active anyway\".\n\nThat is a defeatist argument that applies to many privacy technologies\nthat exist. Taken to its logical conclusion, it says \"Let's not try to\nimprove privacy ever because the same information may be obtainable in\nother ways.\" One has to start somewhere.\n"},{"id":"479612","messageId":"ZLcLQZfZK+QnG5cx@tapette.crustytoothpaste.net","threadId":"59981","inReplyTo":"CU3Z2NYP6BGG.1PQ6S5AF60XX6@anonymous","subject":"Re: Git Privacy","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-07-18T21:59:29Z","receivedAt":"2023-07-18T21:59:36Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-07-16 at 23:07:06, nick wrote:\n> nick wrote:\n> > The time zones reveal private information about developers and they\n> > don't even serve a use case, as far as I'm aware. A backwards-compatible\n> > way to solve this leak would be to convert timestamps to UTC by default\n> > and have a Git config option to revert back to the current behavior.\n> \n> Come to think of it, even if timezones were converted to UTC by default,\n> time of day would still leak information about a user's likely timezone.\n\nThis is true. My .signature indicates where I'm located (which isn't a\nsecret), but I have `TZ=UTC` set in my shell config. You'll notice that\nmy timestamp is +0000 in all my commits. I keep a reasonably regular\ndaytime schedule, so it's easy to tell what my hours are.\n\n> So based on that and keeping in mind Git's desire for strong\n> backwards-compatibility, I'm amending my proposal to just a standalone\n> Git option which would allow for forging timestamp and timezone\n> information, with timestamp information being forgeable to varying\n> degrees of granularity.\n\nOne thing I've wanted Git to do (which I'm not sure is backwards\ncompatible) is to set the timezone to -0000 (instead of +0000) to\nindicate that the user has intentionally refused to set the timezone,\nmuch like the equivalent syntax in RFC 5322. I think that's a fine\nchoice for lots of reasons, but it prevents people from accidentally\nconcluding that I live in Reykjavík and expecting a response from me\nwhen I'm actually in bed.\n\nI'd support a command-line and config option that did that, in addition\nto an option that adjusted the timezone.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"}]}