Tails

#3 Updated by BitingBird 2015-04-01 20:54:09

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

#5 Updated by sajolida 2015-04-08 18:23:40

• 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 2015-04-09 14:15:30

• 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?

#8 Updated by anonym 2015-04-15 10:53:16

• Status changed from Confirmed to In Progress

Applied in changeset commit:88a59388c736ae21fdcde426a08703dbb6bd867a.

#9 Updated by anonym 2015-04-15 10:53:58

• % 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:
>
> > # Add set +e at the top (live-config runs with set -e)
> > # 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 Bug #9234.

#10 Updated by BitingBird 2015-04-15 14:47:52

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

#11 Updated by intrigeri 2015-04-17 12:11:50

• 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 2015-04-17 19:22:44

• Assignee set to intrigeri

#13 Updated by intrigeri 2015-04-18 08:00:58

• Status changed from In Progress to Fix committed
• % Done changed from 50 to 100

Applied in changeset commit:bd3c9b13bd2066f339ca6d4f719d50932fa64430.

#14 Updated by intrigeri 2015-04-18 08:01:30

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

#15 Updated by BitingBird 2015-05-12 18:39:06

• Status changed from Fix committed to Resolved