canonical / canonical/cloud-init

improve oauth skew to base off uptime

Open
#2,607 0 comments 0 reactions 0 assignees View on GitHub
bug launchpad
Dominant language
Python
Stars
3.8k
Forks
1.1k
Avg merge
2d 23h
Merged PRs (30d)
18

Description

This bug was originally filed in Launchpad as [LP: #1531233](https://bugs.launchpad.net/cloud-init/+bug/1531233)

Launchpad details

affected_projects = ['curtin']

assignee = None
assignee_name = None
date_closed = None
date_created = 2016-01-05T18:26:54.077738+00:00
date_fix_committed = None
date_fix_released = None
id = 1531233
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1531233
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = confirmed
submitter = smoser
submitter_name = Scott Moser
tags = []
duplicates = []

_Launchpad user **Scott Moser(smoser)** wrote on 2016-01-05T18:26:54.077738+00:00_

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.