Lanzatool skips already existing files even if they are not signed #39

Closed
opened 2022-12-26 02:20:10 +00:00 by RaitoBezarius · 10 comments
RaitoBezarius commented 2022-12-26 02:20:10 +00:00 (Migrated from github.com)

If you remove a sig of a systemd-bootx64.efi, lanzatool will turn a blind eye and not sign it.

Causing surprising behaviors such as security violation :-((((

If you remove a sig of a systemd-bootx64.efi, lanzatool will turn a blind eye and not sign it. Causing surprising behaviors such as security violation :-((((
nikstur commented 2022-12-26 02:23:03 +00:00 (Migrated from github.com)

sd-boot is not signed by lanzatool if it already existed

sd-boot is not signed by lanzatool if it already existed
RaitoBezarius commented 2022-12-26 02:23:59 +00:00 (Migrated from github.com)

same for kernels or any file actually I think

same for kernels or any file actually I think
nikstur commented 2022-12-26 02:25:30 +00:00 (Migrated from github.com)

Yes, but for sd-boot it matters even on an "ignore" policy where we ignore old kernels and initrds

Yes, but for sd-boot it matters even on an "ignore" policy where we ignore old kernels and initrds
blitz commented 2023-01-09 00:04:47 +00:00 (Migrated from github.com)

Related to #56 and #55.

Related to #56 and #55.
vroad commented 2023-01-13 04:12:26 +00:00 (Migrated from github.com)

Can't we just verify signature of existing files and sign them too, instead of just signing only non-existing files?

Can't we just verify signature of existing files and sign them too, instead of just signing only non-existing files?
RaitoBezarius commented 2023-01-14 16:44:20 +00:00 (Migrated from github.com)

Can't we just verify signature of existing files and sign them too, instead of just signing only non-existing files?

Yes this is what is planned.

> Can't we just verify signature of existing files and sign them too, instead of just signing only non-existing files? Yes this is what is planned.
nikstur commented 2023-01-25 22:34:23 +00:00 (Migrated from github.com)

#76 solved our issue with newer/malformed/unsiged systemd-boot binaries. It did not solve the issue with existing unsiged kernels.

#76 solved our issue with newer/malformed/unsiged systemd-boot binaries. It did not solve the issue with existing unsiged kernels.
nikstur commented 2023-01-29 13:41:37 +00:00 (Migrated from github.com)

#75 & Implementing a solution for #68 will fix this issue.

#75 & Implementing a solution for #68 will fix this issue.
mweinelt commented 2023-01-31 22:49:12 +00:00 (Migrated from github.com)

Hit this and one more nix-collect-garbage -d and another rebuild solved this for me.

Hit this and one more `nix-collect-garbage -d` and another `rebuild` solved this for me.
nikstur commented 2023-02-12 15:39:53 +00:00 (Migrated from github.com)

Now that #75 is merged, the only issue left here is that the stub/UKI might not be signed and will not be resigned or overwritten. This, however, could only happen if the user manually removed the signature from one of them.

Now that #75 is merged, the only issue left here is that the stub/UKI might not be signed and will not be resigned or overwritten. This, however, could only happen if the user manually removed the signature from one of them.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: raito/lanzaboote#39
No description provided.