Tails

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.

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?

Applied in changeset 88a59388c736ae21fdcde426a08703dbb6bd867a.

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.

Applied in changeset bd3c9b13bd2066f339ca6d4f719d50932fa64430.