key-init: force user to change time if <2024, give warnings on key import errors #1776
Conversation
Signed-off-by: Thierry Laurion <[email protected]>
|
Legacy individual keys import gives an error. To be put only if directory exists (oem-factory-reset creates trusdb/pubring which is injected because contains a seed as opposed to key injection which creates pubring with said seed) : this should be deprecated, we do not use individual keys since maybe 5 years!) |
|
@JonathonHall-Purism please approve trace |
…xists, skip otherwise Signed-off-by: Thierry Laurion <[email protected]>
tlaurion
changed the title
|
@macpijan Docs should be clearer on effect of disconnecting CMOS battery resulting in being back in 1970 at https://docs.dasharo.com/unified/novacustom/initial-deployment/#installing-dasharo |
|
@JonathonHall-Purism forgot to tag you here for review |
|
Goes alongside documentation needed fix opened issue at Dasharo/dasharo-issues#1040 @JonathonHall-Purism open internal issue if Purism documentation misses that step too, while less important because Pureboot should pick up on that change on next release automatically once merged? Dido @daringer. |
This is great, thanks for putting this together 💪 Surprisingly, on Librem 14 (and others IIRC), the clock resets to 2070, not 1970. Maybe if I enable the RTC century bit in CMOS it'll reset to 1970 instead. I think I would rather try that before something like asking to reset if the clock is set to 2070. 46 years seems like a long time, but who knows 😉 Anyway this is great, so don't hold it up while I figure out another improvement for Librems. If you agree with the changes I suggested, let's merge, otherwise feel free to discuss 👍 |
…me_give-warning-on-gpg-errors
The 'warn' message was not very effective, because change-time.sh clears the screen right after. Prompt with whiptail instead, which also lets the user know what's happening before we drop them into a series of prompts. Let the user skip changing time if they really want to. While they usually should set the time, it's rather frustrating if Heads forces them to go through these prompts when they don't want to. Signed-off-by: Jonathon Hall <[email protected]> Signed-off-by: Thierry Laurion <[email protected]>
tlaurion
force-pushed
the
key-init_fix-time_give-warning-on-gpg-errors
branch
from
6ab0c88
to
62c8366
Compare
That would help, should most probably set it everywhere if it works for you.
Again should not trigger bug, will create weird logs in rootfs, but won't frezze nor create weird behavior under heads, which are because keys imported > 1970 < 2070. I still belive we should sync clock from network but this is not possible nor easy as part of a traditionnal OEM factory reset. IDeally, we would have all computers be in 1970 if possible after CMOS battery disconnection otherwise we do not have a stable behavior to correct upon.
@JonathonHall-Purism merged master+cherry-picked cbd1f28 |
|
@JonathonHall-Purism let's merge whenever you are ready to push merge button |
|
Button pushed! Thanks |
Fixes #1775 : without this, a machine that had CMOS battery disconnected for initial flashing will show weird and unexpected behaviors, early under key-init since gpg keys imported there have a creation date in the future.
This is a bug, and since we now have #1737 merged in, we can force users to change system clock if in an impossible past, in all case (<2024. Could also be 1970, but why not <2024 just as the GUI forces, today).
This PR: