yahoo-eng-team team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

Public bug reported:

when doing oauth, each request needs to include a timestamp that matches a window of the host's clock.
So, if our local clock is broken we need to adjust it.  Cloud-init and curtin handle this by adding a 'skew', and recently store that skew in a dictionary for later reference.  The issue though is that currently we store the skew off the current local time.  This works fine until the local time is updated, and then it would result in us having a *bad* offset where using none would work.

During boot, ntp or systemd-network-timed might update the clock, so we
have to be aware of that.

My plan for a fix is to use uptime as an always increasing/stable clock.

To address the fact that a clock could be wildly inaccurate, we can
discard the stored skew if it is older than 10 minutes or some
reasonably large value.

** Affects: cloud-init
     Importance: Medium
         Status: Confirmed

** Affects: curtin
     Importance: Medium
         Status: Confirmed

** Changed in: cloud-init
       Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Also affects: curtin
   Importance: Undecided
       Status: New

** Changed in: curtin
       Status: New => Confirmed

** Changed in: curtin
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1531233

Title:
  improve oauth skew to base off uptime

Status in cloud-init:
  Confirmed
Status in curtin:
  Confirmed

Bug description:
  when doing oauth, each request needs to include a timestamp that matches a window of the host's clock.
  So, if our local clock is broken we need to adjust it.  Cloud-init and curtin handle this by adding a 'skew', and recently store that skew in a dictionary for later reference.  The issue though is that currently we store the skew off the current local time.  This works fine until the local time is updated, and then it would result in us having a *bad* offset where using none would work.

  During boot, ntp or systemd-network-timed might update the clock, so
  we have to be aware of that.

  My plan for a fix is to use uptime as an always increasing/stable
  clock.

  To address the fact that a clock could be wildly inaccurate, we can
  discard the stored skew if it is older than 10 minutes or some
  reasonably large value.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1531233/+subscriptions