From owner-freebsd-git@freebsd.org  Thu May 30 02:28:30 2019
Return-Path: <owner-freebsd-git@freebsd.org>
Delivered-To: freebsd-git@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 462CF15B477B
 for <freebsd-git@mailman.ysv.freebsd.org>;
 Thu, 30 May 2019 02:28:30 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com
 [IPv6:2607:f8b0:4864:20::733])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 server-signature RSA-PSS (4096 bits)
 client-signature RSA-PSS (2048 bits) client-digest SHA256)
 (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 2E3426B492
 for <freebsd-git@freebsd.org>; Thu, 30 May 2019 02:28:29 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: by mail-qk1-x733.google.com with SMTP id c70so2864320qkg.7
 for <freebsd-git@freebsd.org>; Wed, 29 May 2019 19:28:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bsdimp-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=KgU/RHFLcggctYDw3Tw5cXPJxY74di1lnTtwmfaAmv4=;
 b=cwfnJYqGpa8TLZdD6N0He+p6qzZD1DM5vXeZTRz1mqbY73QDWXa8dn/G9Yd5Z0m84u
 60fvkYFJ8Bx/l7CLXJRPUTk05Y6W1iD9i2th655xhGgA34xB4uhyQCSFKU4chceYyUSf
 kcoqMuW9WoMrWWeHL1G4A/UbK2khzDDNdjrtTk2vvZsYNaC3lE2nUoLDFtyg5YkNYI9U
 kA4zn+AlHDpTrpqhNBXfCPRyBzgc/BAXW4KAJQI5EIUsbanz9/S32/opGpzkDieM888G
 3DfW7pidN6IZukP3Kf6iqOgPrdkzTTdwTxLPPZhOg5QBoFn29EomkG+dhprWh/Tqs0Ta
 ZX0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=KgU/RHFLcggctYDw3Tw5cXPJxY74di1lnTtwmfaAmv4=;
 b=YjA8dA/4niJjTOGGzv6B8wXpYLCpm/6N0Khw3/4DMjo58GMdEwmg7yBtYubh4iwfzf
 FC3726rhj9P+ePb1JJ67UQpP19YZY9VDb6s50cykagyOMZkhDjSdS6syF0UAGn6aTgZC
 IzEvPPCIriWmJRgYuNI+wGs20C3im7cHzWzAn5lRDGQS3DobA5OzjEbFTn2+8e07Ksip
 6vWFIHGgli+mZgYd6Hj5lsmP2heYfyHnHsphkDSAuE3VwWY9GfmB5wkvGSWHrdoXGqXh
 nLMCTa+3izSclQxaVx7c6d1v7SYr2PbNZQ2ObrX86/WMEkz+qHbXfF2VaF4P9TasadY7
 UfXQ==
X-Gm-Message-State: APjAAAUEcLrrWPQswXETfja3qf6WL2EqrcP4GL31bekWRbaaFTgOp6zZ
 p0C+7aj10lDkxBVTb0WYfYHVNnicv0Qo9kJR5JxjTYpk
X-Google-Smtp-Source: APXvYqzZfZS6EJ691vTXWwOF/cpE1U5rb4JHDaqx1BaDRYqeRVFoiDroVv6qdlGs6ieOUh/VukPHo0ATsO8bjy+5Swo=
X-Received: by 2002:a05:620a:125b:: with SMTP id
 a27mr1031646qkl.112.1559183308495; 
 Wed, 29 May 2019 19:28:28 -0700 (PDT)
MIME-Version: 1.0
References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org>
 <CAPyFy2Bqg6m8D6rO+g87Wk74iBYOGfq+=t6B_VhUM26mUZXO+Q@mail.gmail.com>
 <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com>
 <CAPyFy2CkyET7v6hTfhv8ZQ=+SYM_yyhtBwzM3GfS3funaDBZHQ@mail.gmail.com>
 <82938a26-892e-0459-aa23-bdcd9e318b6c@gjunka.com>
 <CAPyFy2Dm9yWepO6P8jyF+NZDA=ZUpg0tYUQ8zRTAKkVWp6cHhw@mail.gmail.com>
 <CANCZdfpoaqpNpKZrPmkdvZxMty4ZA2xj51Zu_brJrAdydDAakg@mail.gmail.com>
 <CAPyFy2AA=GzuRhG5z1Y2gWFJUsw94zOSk6c4j=wXi+9URwR7eQ@mail.gmail.com>
In-Reply-To: <CAPyFy2AA=GzuRhG5z1Y2gWFJUsw94zOSk6c4j=wXi+9URwR7eQ@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Wed, 29 May 2019 20:28:17 -0600
Message-ID: <CANCZdfr0u6_N1LS4frzeotmoP9xb3k+TGEVL13GO++AUeEULuA@mail.gmail.com>
Subject: Re: Git handling of commit times
To: Ed Maste <emaste@freebsd.org>
Cc: Grzegorz Junka <list1@gjunka.com>, freebsd-git@freebsd.org
X-Rspamd-Queue-Id: 2E3426B492
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
 dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623
 header.b=cwfnJYqG
X-Spamd-Result: default: False [-6.02 / 15.00]; ARC_NA(0.00)[];
 NEURAL_HAM_MEDIUM(-1.00)[-1.000,0];
 R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623];
 FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3];
 TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0];
 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
 PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org];
 DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[];
 DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+];
 MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com];
 RCVD_IN_DNSWL_NONE(0.00)[3.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org
 : 127.0.5.0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0];
 R_SPF_NA(0.00)[];
 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
 MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[];
 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
 IP_SCORE(-3.02)[ip: (-9.42), ipnet: 2607:f8b0::/32(-3.32), asn: 15169(-2.30),
 country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2]
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: freebsd-git@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of git use in the FreeBSD project <freebsd-git.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-git>,
 <mailto:freebsd-git-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-git/>
List-Post: <mailto:freebsd-git@freebsd.org>
List-Help: <mailto:freebsd-git-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-git>,
 <mailto:freebsd-git-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 30 May 2019 02:28:30 -0000

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