Project

General

Profile

Bug #9149

Random Pidgin nicknames are not generated on boot when the system clock is wrong

Added by uiop over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
Start date:
04/01/2015
Due date:
% Done:

100%

Feature Branch:
bugfix/9149-set-sane-clock-at-early-boot
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Instant Messaging

Description

Macbook Pro (Retina, I guess all of them)

isn't generating random nicknames on boot in Pidgin.

Tested XX times. Nicknames on IRC's are always just XXX_NICK_XXX

What is the issue? I have no idea.


Related issues

Related to Tails - Bug #9234: Abort boot when any live-config hook fails Confirmed 04/15/2015

Associated revisions

Revision 88a59388 (diff)
Added by anonym over 4 years ago

Make sure the system clock isn't before the build date (Will-fix: #9149).

Our live-config hook that imports our signing keys depend on that the
system clock isn't before the date when the keys where created (sanity
check by gpg). To avoid this, we ensure (via an early live-config
hook) that the system clock cannot be before the Tails image build
date (up to one day, to deal with potential timezone
differences/mismatches).

Revision bd3c9b13
Added by intrigeri over 4 years ago

Merge remote-tracking branch 'origin/bugfix/9149-set-sane-clock-at-early-boot' into stable

Fix-committed: #9149

History

#1 Updated by uiop over 4 years ago

is screenshot required?

If there are any other Mac users, can they approve this bug?

#2 Updated by BitingBird over 4 years ago

Please report a bug using whisperback: https://tails.boum.org/doc/first_steps/bug_reporting

#3 Updated by BitingBird over 4 years ago

  • Assignee set to uiop
  • QA Check set to Info Needed

#4 Updated by sajolida over 4 years ago

We add similar things happen in the past, see #6273. But that could be caused by weird conditions that indeed a WhisperBack bug will hopefully clarify. Make sure to mention this ticket number (#9149) in your bug report.

#5 Updated by sajolida over 4 years ago

  • Status changed from New to Confirmed
  • Priority changed from Normal to Elevated
  • Target version set to Tails_1.4

We received report b4fa244d96fa1462bef1419ef6eaf839.

The log for /var/log/live/config.log stop with:

gpg: key 0xDBB802B258ACD84F was created 32925448 seconds in the future (time warp or clock problem)
gpg: key 0xDBB802B258ACD84F: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 5
gpg:           w/o user IDs: 3
gpg:               imported: 2  (RSA: 2)
gpg: no ultimately trusted keys found
:ERROR

while they usually say:

gpg: key 58ACD84F: public key "Tails developers (offline long-term identity key) <tails@boum.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: no ultimately trusted keys found
- configuring Pidgin
- fixing permissions

So could a bad clock at startup cause this?

Marking as Elevated until some discards this as not being a regression.

#6 Updated by anonym over 4 years ago

  • Assignee deleted (uiop)

sajolida wrote:

So could a bad clock at startup cause this?

That looks like a very plausible explanation, and I can reproduce this by booting with nosplash break=bottom on the kernel cmdline, running something like date --set "Jan 1 00:00:00 2000", and then continue booting.

I guess we could add another live-config hook that runs before anything else, e.g. config/chroot_local-includes/lib/live/config/0001-sane-time that looks like this:

#!/bin/sh

BUILD_DATE="$(sed -n -e '1s/^.* - \([0-9]\+\)$/\1/p;q' /tmp/version)" 
if [ "$(date +%s)" +%s)" -lt "$(date -d "${BUILD_DATE} +%s" ]; then
    date --set "${BUILD_DATE}" 
fi

I.e. if the system clock is set to before the image build date, then we set it to the build date. Unless we have screwed up majorly, this will ensure that the keys/uids are valid, and possibly help with other issues too (like time syncing!). However, I'm tempted to allow the system clock to be up to 1 day before the build date to deal with potential issues from timezones when an image is booted immediately after it's built (especially around the edge cases, i.e. just before and after 00:00:00). I actually didn't look if such a problem could arise, but I'd rather skip that and stay on the safe side so we don't make this time fix trigger unnecessarily all the time one our autobuild + autotest dream comes true. Does this make sense?

On a related note, I'm not sure I loke how live-config aborts the rest of our hooks if one fails. Perhaps we should do something about it? For instance, in all our hooks we could:

  1. Add set +e at the top (live-config runs with set -e)
  2. Add set -e (to set it back in live-config) and exit 0 (to ensure script "success") at the bottom

Thoughts?

#7 Updated by intrigeri over 4 years ago

I actually didn't look if such a problem could arise, but I'd rather skip that and
stay on the safe side so we don't make this time fix trigger unnecessarily all the
time one our autobuild + autotest dream comes true. Does this make sense?

It does make sense to me.

On a related note, I'm not sure I loke how live-config aborts the rest of our hooks
if one fails. Perhaps we should do something about it? For instance, in all our hooks
we could:

  1. Add set +e at the top (live-config runs with set -e)
  2. Add set -e (to set it back in live-config) and exit 0 (to ensure script "success") at the bottom

I dislike getting rid of catching all errors the programmer didn't carefully check for, which set -e gives us. But on error, we should abort the boot and display a useful error message, instead of going on booting a misconfigured Tails.

#8 Updated by anonym over 4 years ago

  • Status changed from Confirmed to In Progress

#9 Updated by anonym over 4 years ago

  • % Done changed from 0 to 50
  • QA Check changed from Info Needed to Ready for QA
  • Feature Branch set to bugfix/9149-set-sane-clock-at-early-boot

intrigeri wrote:

I actually didn't look if such a problem could arise, but I'd rather skip that and
stay on the safe side so we don't make this time fix trigger unnecessarily all the
time one our autobuild + autotest dream comes true. Does this make sense?

It does make sense to me.

Implemented.

On a related note, I'm not sure I loke how live-config aborts the rest of our hooks
if one fails. Perhaps we should do something about it? For instance, in all our hooks
we could:

  1. Add set +e at the top (live-config runs with set -e)
  2. Add set -e (to set it back in live-config) and exit 0 (to ensure script "success") at the bottom

I dislike getting rid of catching all errors the programmer didn't carefully check for, which set -e gives us. But on error, we should abort the boot and display a useful error message, instead of going on booting a misconfigured Tails.

Filed as #9234.

#10 Updated by BitingBird over 4 years ago

  • Related to Bug #9234: Abort boot when any live-config hook fails added

#11 Updated by intrigeri over 4 years ago

  • Subject changed from [MAC] Pidgin not generating random nicknames on boot to Random Pidgin nicknames are not generated on boot when the system clock is wrong

#12 Updated by intrigeri over 4 years ago

  • Assignee set to intrigeri

#13 Updated by intrigeri over 4 years ago

  • Status changed from In Progress to 11
  • % Done changed from 50 to 100

#14 Updated by intrigeri over 4 years ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#15 Updated by BitingBird over 4 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF