Bundles not signed after kernel update about sbctl HOT 14 CLOSED

Can you rm the bundles and type sbctl sign-all -g? Also what version is this?

from sbctl.

root@soji ~# pacman -Qi sbctl-git 
Name            : sbctl-git
Version         : r60.g2b09a8e-1
Description     : Secure Boot key manager
Architecture    : x86_64
URL             : https://github.com/Foxboron/sbctl
Licenses        : MIT
Groups          : None
Provides        : None
Depends On      : sbsigntools
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 5,84 MiB
Packager        : Unknown Packager
Build Date      : Fr 31 Jul 2020 14:42:54 CEST
Install Date    : Di 04 Aug 2020 08:25:57 CEST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : SHA-256 Sum

root@soji ~# rm /efi/EFI/Linux/linux-linux.efi
root@soji ~# rm /efi/EFI/Linux/linux-arch-zen.efi
root@soji ~# sbctl sign-all -g
==> Generating EFI bundles....
==> Wrote EFI bundle /efi/EFI/Linux/linux-arch-zen.efi
==> Wrote EFI bundle /efi/EFI/Linux/linux-linux.efi
==> /efi/EFI/BOOT/BOOTX64.EFI has been signed...
==> /efi/EFI/systemd/systemd-bootx64.efi has been signed...
==> /usr/lib/fwupd/efi/fwupdx64.efi has been signed...
root@soji ~# sbctl verify
==> Verifying file database and EFI images in /efi...
  -> /usr/lib/fwupd/efi/fwupdx64.efi.signed is signed
  -> /efi/EFI/BOOT/BOOTX64.EFI is signed
  -> /efi/EFI/systemd/systemd-bootx64.efi is signed
  -> WARNING: /efi/EFI/Linux/linux-arch-zen.efi is not signed
  -> WARNING: /efi/EFI/Linux/linux-linux.efi is not signed
  -> /efi/vmlinuz-linux-lts is signed

from sbctl.

Managed to reproduce the issue now :) Thanks!

from sbctl.

Glad that i could help! I must admit i was a little bit afraid of configuring and using Secure Boot but this tool makes it really easy 👍

I also had to chattr -i some files similar to #25

from sbctl.

Evidently, I forgot that bundles does not get added to the files database, this probably isn't super intuitive? We generate the bundles with -g, but they need to be added to the files database before sign-all finds them.

I wonder if it's a better logic to always sign stored bundles, or add them implicitly to the files database.

from sbctl.

Is there any reason to not simply iterate over files.db and bundles.db on sign-all? Since it's not called sign-all-files or similar.

from sbctl.

I guess I thought it would be better if they are logically separate systems, instead of intertwined. It's interesting when you forget the behaviour you implemented yourself :) I'll write some code to try figure out a better approach on this.

from sbctl.

@ericonr need an opinion.

Should we implicitly have the bundles database signed, or should we keep this separate and rather document this? What if we add a switch to auto-add the bundle to the files database?

I don't really feel like duplicating the logic, even if it doesn't seem like much. Can add a switch to ensure remove-bundle to ensure it gets removed from the files database as well.

from sbctl.

Just stumbled over this nice little piece of software today, but this issue confused me as well.

I spotted a lonely, unused flag called sign in generateBundlesCmd() and took the liberty to give it some purpose and make it actually sign the bundles after creation. ;)

This presents us with an easy solution:
Thanks to the sign flag, the bundles are only signed optionally on creation, which is good. We could of course introduce another flag, however in the situation where someone calls sign-all --generate, I think it's fair to assume that he/she also wants the generated bundles to be signed, considering the very name of that command. So whenever we call GenerateAllBundles from signAllCmd, we just pass true along with it, and that does the trick.

I'll create a PR for this in a moment.

from sbctl.

@Foxboron it seems I had missed your mention, for which I am very sorry!

It appears this has been solved :)

from sbctl.

No problem :) But if you had any opinion do share them. We can still change stuff

from sbctl.

Having taken a look at it, I think it would make sense to add an option for sbctl bundle ... to sign files, perhaps? And if the option to sign the file and save it is selected, the file should be added to the database - I don't think generate-bundles should save anything to the files database.

It would make the -s flag rather messy, since it'd have different meanings in bundle and generate-bundle. I think I would remove the short option from generate-bundle as well. It might be more consistent to only have sign be a long option with --sign.

Haven't looked into how the impl would work.

from sbctl.

generate-bundles doesn't save anything to the files database currently. It just assumes you want to sign everything when -s is present.

But you are being a bit unclear which databases you are referring to :D There are two of them!

from sbctl.

I meant the files (not bundles) database in all instances.

from sbctl.