@xnox as you have found you can’t simply change the timestamp, since you need to change the timestamp on the account-key assertion which is what signs the model assertion, and account-key assertions are signed by canonical store keys, which will not sign something in the past for you.
I think at a minimum the first thing that we can do is have ubuntu-core-initramfs’s systemd bump it’s epoch every time it gets SRU’d, that would at least help in this case where someone just wants to build an image, the longest someone would be stuck waiting to be able to boot their image on the Pi if they register a new key would be until the next systemd SRU (which is not ideal but better than the current situation). Perhaps this kind of feature could even be extended to fast forward the time in the initrd to when the kernel initrd was built, by dropping some sort of epoch file in the initramfs that isn’t tied to systemd’s SRU cycle and thus have the time in the initrd monotonic and increase basically every kernel SRU cycle.
I think there are two issues with your approach of getting the time from these assertions:
- the initrd shouldn’t be using information from assertions if it is not fully parsing them and verifying their signatures, which currently is the role of snap-bootstrap/snapd (unless you want to write an assertion library in shell ), I don’t know exactly what kind of attack could be formulated here, but I imagine there is one, where the initrd reading info blindly out of assertions leads to bad things
- This creates a circular root of trust in that snap-bootstrap trusts that the time is correct in order to validate things like the model assertion before considering the individual snap-declaration assertions IIRC, so if the initrd already got it’s time from these assertions OOTB from snap-bootstrap, then when snap-bootstrap is validating that the assertions are correct it’s root of trust to time actually comes from the thing that it is verifying, creating a circular root of trust.
I think a more reasonable solution to our time woes in the initrd is to do what Ubuntu Core 16/18 did (and was discussed on the bug) and use something like fixrtc-mount to inspect the time that the superblock was last mounted, or alternatively start injecting some sort of file upon image build time that serves the same basic purpose.