Bug #9149
Random Pidgin nicknames are not generated on boot when the system clock is wrong
100%
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
Associated revisions
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).
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
#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:
- Add
set +e
at the top (live-config runs withset -e
) - Add
set -e
(to set it back in live-config) andexit 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:
- Add
set +e
at the top (live-config runs withset -e
)- Add
set -e
(to set it back in live-config) andexit 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
Applied in changeset 88a59388c736ae21fdcde426a08703dbb6bd867a.
#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:
- Add
set +e
at the top (live-config runs withset -e
)- Add
set -e
(to set it back in live-config) andexit 0
(to ensure script "success") at the bottomI 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
Applied in changeset bd3c9b13bd2066f339ca6d4f719d50932fa64430.
#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