pacman keyrings should be initialized after time is synced

In current archiso releases, pacman-init.service runs on boot, before system time is synced, and the initialized keys are copied to the newly installed system later. This unfortunately causes future archlinux-keyring updates and installing foreign keyring packages to result in failing to be locally signed when timezone is UTC+x. The culprit is that most of the users would have Windows installed on their system before installing Arch, so the system time is in local timezone. The only way to resolve this is to reset all the keys.

To avoid this, we should wait for NTP service to complete syncing before running pacman-key --init. For example, systemd provides systemd-time-wait-sync.service. Because NTP services require network connection, perhaps the service can be removed and we can let users do that manually instead.

changed the description

This unfortunately causes future archlinux-keyring updates and installing foreign keyring packages to result in failing to be locally signed when timezone is UTC+x.

Could you post the error message that indicates the failure.

Some of the logs are taken from other users in Telegram group @archlinuxcn_group.

https://fars.ee/cdz0.png https://fars.ee/YmJd.jpg https://fars.ee/6e4e.jpg

Also some issues from third-party keyrings:

https://github.com/archlinuxcn/repo/issues/406

To avoid this, we should wait for NTP service to complete syncing before running pacman-key --init.

According to systemd.special(7), pacman-init.service would need After=time-sync.target and we'd need to enable systemd-timesyncd.service and systemd-time-wait-sync.service.

I don't really like the idea of automating and pre-configuring even more things.

Or maybe we can reinitialize the keys instead of copying them during pacstrap. Users following the Installation guide should have their system time synced by then.

This can probably solve another problem too—sometimes the shipped archlinux-keyring package in monthly released archiso becomes outdated and needs manual intervention because some of the core packages are signed using the new keys. While pacstrapping we can install the latest one first and initialize the keys in the new system.

pacstrap uses the host's pacman keyring even if it doesn't copy it to the target. If any package you're pacstrapping is signed with a key not in the host's pacman keyring, it will fail.

Well, at least letting pacstrap initialize the keys solves the original issue...

the initialized keys are copied to the newly installed system

This can be avoided with pacstrap's -G option. Though that may not be the nicest solution, since now you'd need to manually create the pacman keyring in the new system.

changed title from pacman-init.service should always run after time is synced to pacman keyrings should be initialized after time is synced

added scopebug label

@klausenbusk, this should affect archlinux/arch-boxes> too if a image is booted on a system where the hardware clock is in UTC+_X_.

Since arch-boxes enable systemd-timesyncd.service, the solution for it would be to additionally enable systemd-time-wait-sync.service and add After=time-sync.target to arch-boxes' pacman-init.service.

To summarize, the only solutions I can see are:

• Automate more. Enable systemd-timesyncd.service and systemd-time-wait-sync.service. Order pacman-init.service after time-sync.target.
• Automate less. Get rid of pacman-init.service entirely.

Both solutions will need an Installation guide change.

mentioned in issue #191 (closed)

mentioned in commit nl6720/arch-boxes@9901417c

mentioned in merge request arch-boxes!183 (merged)

https://github.com/archlinux/arch-install-scripts/pull/23 (pending next release) together with a Installation guide change (Talk:Installation guide#Use pacstrap -K) will fix this for the pacstrap target (i.e. new installs).

For the live environment itself, a solution still needs to be thought up.

added statuswaiting-upstream label

mentioned in commit nl6720/arch-boxes@515043b8

removed statuswaiting-upstream label

mentioned in commit nl6720/arch-boxes@e23d3c57

mentioned in commit 14f2738f

mentioned in merge request !285 (closed)

mentioned in commit de8923f8

changed milestone to %v67

With #191 (closed) going for a proper fix in pacman-key and thus decoupling it from this issue, the option of automating more (i.e. enabling systemd-timesyncd.service and systemd-time-wait-sync.service, and ordering pacman-init.service after time-sync.target) becomes viable here.

assigned to @dvzrv

infrastructure@1ae3a815 says that waiting for systemd-time-wait-sync.service can take about 30 seconds. Hopefully the delay will not be that noticeable.

I've added this in a local test:

mentioned in merge request !287 (merged)

closed with merge request !287 (merged)

mentioned in issue archlinux-keyring#199 (moved)

mentioned in issue keyringctl#3

mentioned in merge request arch-boxes!201 (merged)