Date: Wed, 29 May 2019 20:28:17 -0600 From: Warner Losh <imp@bsdimp.com> To: Ed Maste <emaste@freebsd.org> Cc: Grzegorz Junka <list1@gjunka.com>, freebsd-git@freebsd.org Subject: Re: Git handling of commit times Message-ID: <CANCZdfr0u6_N1LS4frzeotmoP9xb3k%2BTGEVL13GO%2B%2BAUeEULuA@mail.gmail.com> In-Reply-To: <CAPyFy2AA=GzuRhG5z1Y2gWFJUsw94zOSk6c4j=wXi%2B9URwR7eQ@mail.gmail.com> References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> <CAPyFy2Bqg6m8D6rO%2Bg87Wk74iBYOGfq%2B=t6B_VhUM26mUZXO%2BQ@mail.gmail.com> <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> <CAPyFy2CkyET7v6hTfhv8ZQ=%2BSYM_yyhtBwzM3GfS3funaDBZHQ@mail.gmail.com> <82938a26-892e-0459-aa23-bdcd9e318b6c@gjunka.com> <CAPyFy2Dm9yWepO6P8jyF%2BNZDA=ZUpg0tYUQ8zRTAKkVWp6cHhw@mail.gmail.com> <CANCZdfpoaqpNpKZrPmkdvZxMty4ZA2xj51Zu_brJrAdydDAakg@mail.gmail.com> <CAPyFy2AA=GzuRhG5z1Y2gWFJUsw94zOSk6c4j=wXi%2B9URwR7eQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 29, 2019 at 8:18 PM Ed Maste <emaste@freebsd.org> wrote: > On Wed, 29 May 2019 at 17:26, Warner Losh <imp@bsdimp.com> wrote: > > > > The very simple work flow of > > > > git branch -b foo > > hack > > git commit > > <time passes> > > git checkout master > > git pull > > git rebase -i master foo > > <repeat sequence> > > > > would setup a situation where commits are in the past. By default, > rebase commits don't have their timestamps reset. > > Rebasing does reset the commit timestamp (and not the author > timestamp). I don't think we should impose any constraints on author > timestamps in a Git workflow. But these two things should be > invariants: the commit timestamp of a change is not earlier than any > of its parents, and the commit timestamp is not later than now. > How do I see this other timestamp. git log doesn't show it by default, hence the basis of my views... > > Also, resetting the time changes the hash of the commit, iirc. > > Yes, changing anything in the state of the tree or the commit's > metadata will change the hash. (Notes are not included in this.) > > > Depends on how far in the future. Time is an illusion. git commit time > doubly so :) But this assumes that all the world's clocks are in sync, and > they are not. minutes of difference often exist. it's a royal pita to be on > the wrong side of the sync when pushing commits upstream to a server you > have no control over the time of. > > I'd hope we can be reasonably sure about the time on (say) > git.freebsd.org, but point taken. Perhaps something like "not more > than 1 minute in the future, relative to the server's clock." > I have no clue what the time on git.freebsd.org is, nor do I know if it is sane or not in the face of all kinds of crazy stuff, including leap seconds, bad configuration, active attack, clock steps because someone[tm] though a different ntp daemon would be good enough and didn't understand all the nuanced differences? How sure can we really be about the time on git.freebsd.org in the face of enemy action, perhaps designed to prevent commits from happening for a period of time to prevent an exploit fix from being committed? Maybe I'm being too paranoid. Lord knows I spent a decade in the time and frequency business worrying about all these sorts of things, but many of the worries were, frankly, due to the weak time handling in edge cases in ntpd. So long as we can get a cryptographic sync of git.freebsd.org, or get one of the time and frequency companies too donate a stratum 1 GPS receiver + kit (their cheapest one will likely do fine), then we're golden. Otherwise it gets weird since ntp is basically an unauthenticated protocol unless you can jump through the right hoops... Again, don't mean to sound alarmist, but if we're going to enforce time synchronization, we'd better have a high assurance of no monkey business possible... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr0u6_N1LS4frzeotmoP9xb3k%2BTGEVL13GO%2B%2BAUeEULuA>