On Tue, Jul 19, 2016 at 11:23 AM, Andrew Savchenko
wrote:
> On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote:
> > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
> > >
> > > As I wrote earlier in this thread, ntp server is not a guarantee
> > >
On Tue, 19 Jul 2016 13:22:29 -0700
Patrick McLean wrote:
> On Tue, 19 Jul 2016 21:23:16 +0300
> Andrew Savchenko wrote:
> > On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote:
> > > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko
On Tue, Jul 19, 2016 at 4:31 AM, Consus wrote:
> On 18:03 Fri 15 Jul, Robin H. Johnson wrote:
> > Hi all,
> >
> > In tracing down problems with the git->rsync path, it has been noticed
> > that some developers have significant clock drift on their local systems
> > (up to one
On Tue, 19 Jul 2016 21:23:16 +0300
Andrew Savchenko wrote:
> On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote:
> > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
> > >
> > > As I wrote earlier in this thread, ntp server is not a guarantee
> >
On Tue, Jul 19, 2016 at 1:23 PM, Andrew Savchenko wrote:
> - System may become *vulnerable* because of time stamp based attack.
> Though it is not easy to use such behaviour, it is still possible.
All offline attacks are harder, even ones which haven't been invented yet.
On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote:
> On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
> >
> > As I wrote earlier in this thread, ntp server is not a guarantee
> > that such problems will not happen. If hardware clocked was
> > significantly offset
waltd...@waltdnes.org schrieb:
And even if the system is behind time, it can cause problems. cronjobs
running unexpectedly close to each other (or missed cronjobs in extreme
cases). User sessions expiring early, etc.
And even if there is only one second, and that is known well ahead
(e.g. leap
On 18:03 Fri 15 Jul, Robin H. Johnson wrote:
> Hi all,
>
> In tracing down problems with the git->rsync path, it has been noticed
> that some developers have significant clock drift on their local systems
> (up to one case of 14 days wrong), and it's potentially contributing to
> problems in
On Tue, Jul 19, 2016 at 10:07:12AM +0200, Chí-Thanh Christopher Nguy???n wrote
> Kent Fredric schrieb:
> > On Mon, 18 Jul 2016 22:21:22 -0400
> > waltd...@waltdnes.org wrote:
> >
> >>I'm amazed that "robust linux servers" are deathly afraid of simply
> >> setting the time, and being done with
On Mon, 18 Jul 2016 16:25:34 -0500 james wrote:
> On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:
> > * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> >> On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko
> >> wrote:
> >>> Set it for a minute or two. This will
Kent Fredric schrieb:
On Mon, 18 Jul 2016 22:21:22 -0400
waltd...@waltdnes.org wrote:
I'm amazed that "robust linux servers" are deathly afraid of simply
setting the time, and being done with it.
There's problems at the software level everywhere that are not so
simply solved.
A more
On Mon, 18 Jul 2016 22:21:22 -0400
waltd...@waltdnes.org wrote:
> I'm amazed that "robust linux servers" are deathly afraid of simply
> setting the time, and being done with it.
There's problems at the software level everywhere that are not so
simply solved.
A more obvious example is in the
On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
>
> As I wrote earlier in this thread, ntp server is not a guarantee
> that such problems will not happen. If hardware clocked was
> significantly offset during boot, it may take several _hours_ for
> ntp to fix this via clock skew.
On 19/07/16 07:06, Mart Raudsepp wrote:
> Ühel kenal päeval, E, 18.07.2016 kell 16:25, kirjutas james:
>> On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:
>>> * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko
Ühel kenal päeval, E, 18.07.2016 kell 16:25, kirjutas james:
> On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:
> > * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> > > On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko > > o.org> wrote:
> > > > Set it for a minute or
On Sat, Jul 16, 2016 at 5:33 AM, Andrew Savchenko wrote:
>
> On Fri, 15 Jul 2016 18:03:30 + Robin H. Johnson wrote:
>>
>> The tolerances are presently set to:
>> - 5 seconds of clock drift.
>
> Set it for a minute or two. This will protect from commits from
> really
> On Mon, 18 Jul 2016, Rafael Goncalves Martins wrote:
> On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko wrote:
>> Why such tight requirement? Why not a minute, which will not hurt
>> git, but will help with system _temporarily_ out-of-sync.
>>
>> Some hardware clocks
On Mon, 18 Jul 2016 22:03:35 +0200 Marc Schiffbauer wrote:
> * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> > On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko
> > wrote:
> > > Set it for a minute or two. This will protect from commits from
> > > really
On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:
* Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko wrote:
Set it for a minute or two. This will protect from commits from
really out-of-sync systems (like 14 days
* Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko wrote:
> > Set it for a minute or two. This will protect from commits from
> > really out-of-sync systems (like 14 days mentioned above) and will
> > keep usablity
Hi,
On Fri, 15 Jul 2016 18:03:30 + Robin H. Johnson wrote:
> Hi all,
>
> In tracing down problems with the git->rsync path, it has been noticed
> that some developers have significant clock drift on their local systems
> (up to one case of 14 days wrong), and it's potentially contributing to
21 matches
Mail list logo