91-sbctl.install: don't sign without signing keys

[ajakk]

It's expected that signing doesn't work without having previously generated keys, so don't try to sign when keys don't exist.

Closes: #187
Signed-off-by: John Helmert III ajak@gentoo.org

[Foxboron]

sbctl --json status | grep installed | awk '{print $2}' | tr -d ','

or something like this would probably be a better idea?

[ajakk]

Seems like that doesn't always output something when the keys exist?

# sbctl create-keys
Created Owner UUID e8be777f-2cc7-4da5-bcfa-36fd80241bca
Creating secure boot keys...✓
Secure boot keys created!
c1ef6e49abfa / # sbctl --json status | grep installed | awk '{print $2}' | tr -d ','
c1ef6e49abfa / # sbctl --json status

[Foxboron]

Uhhhhhh, that is a bug :)

[ajakk]

I can reproduce like:

$ docker run --volume ~/git/sbctl:/sbctl -it archlinux bash
[root@f5c510c0e4a7 sbctl]# pacman --noconfirm --noprogressbar -Syu
[snip]
[root@f5c510c0e4a7 sbctl]# pacman --noconfirm --noprogressbar -S make go asciidoc gcc git
[snip]
[root@f5c510c0e4a7 sbctl]# go build -buildvcs=false -o sbctl ./cmd/sbctl
[snip]
[root@f5c510c0e4a7 sbctl]# ./sbctl create-keys
Created Owner UUID e0812b04-a6dd-4344-99a1-4691f4c20e07
Creating secure boot keys...✓
Secure boot keys created!
[root@f5c510c0e4a7 sbctl]# ./sbctl --json status

.. where ~/git/sbctl is this repository, updated to dcdc703, latest at the time of writing

[Foxboron]

Right, the docker container has access to efivars? Alternatively, do you get anything dropping --json?

[ajakk]

Ah, yes:

 ./sbctl status
system is not booted with UEFI

Which makes sense, because the container is indeed not booted with UEFI. So in this way, sbctl status seems unsuitable as a condition for signing, because signing does work after only doing sbctl create-keys in this environment.

[Foxboron]

I'd rather find a better solution using status --json than having another file where we hardcode the /usr/share/secureboot path.

I'll mill over the code a little bit and try have it always output some status output with --json. There isn't really any good reason for it to short-circuit itself when it see there is no UEFI available. It could very well check key location and stuff.

[ajakk]

I agree, thanks!

[ajakk]

Friendly ping! :)

[Foxboron]

Sorry, been busy with the lower layers in go-uefi so I can test more easily. That involves solving this as I have virtual FS support to cover all the test cases :)

[Foxboron]

Thanks!