Bug #11574

Investigate security consequences of restarting htpdate until it succeeds

Added by bertagaz 2016-07-17 04:16:56 . Updated 2016-10-03 11:21:13 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Time synchronization
Target version:
Start date:
2016-07-17
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:
280

Description

While implementing Bug #10494, concerns were raised if restarting htpdate wouldn’t just break one of its main goal, which is to fail if one of its pool seems to be compromised because it reached allowed_per_pool_failure_ratio.

Before deciding what to do with Bug #10494, we should research about its security consequences.

Subtasks

Related issues

Blocks Tails - Bug #10494: Retry htpdate when it fails Rejected 2016-07-17

History

#1 Updated by bertagaz 2016-07-17 04:17:16

  • blocks Bug #10494: Retry htpdate when it fails added

#2 Updated by intrigeri 2016-07-18 07:11:16

  • Deliverable for set to 270

(Same as ticket blocked by this one.)

#3 Updated by intrigeri 2016-07-18 07:28:02

  • Deliverable for changed from 270 to SponsorS_Internal

You can move that to 2.6 if you wish.

#4 Updated by bertagaz 2016-07-19 04:17:26

  • Target version changed from Tails_2.5 to Tails_2.6

#5 Updated by anonym 2016-09-20 16:54:15

  • Target version changed from Tails_2.6 to Tails_2.7

#6 Updated by bertagaz 2016-10-03 09:13:28

  • Status changed from Confirmed to Rejected
  • Assignee deleted (bertagaz)
  • Target version deleted (Tails_2.7)

As discussed in Bug #10495#note-50, endless retries of htpdate won’t be the way we choose. So it’s not necessary to raise the question this ticket is about, which sounded bad at first glance anyway. Closing it.

#7 Updated by intrigeri 2016-10-03 09:30:59

JFTR I think you mean Bug #10494#note-50.

#8 Updated by bertagaz 2016-10-03 11:21:13

intrigeri wrote:
> JFTR I think you mean Bug #10494#note-50.

Right, I did, thanks!