sbctl direct access to efivarsfs (with no database in between)

[jimmykarily]

In the same context as this PR, I'm looking at the existing functionality of sbctl. If I understand correctly, all actions/commands except the enroll-keys, are not touching the actual efivarsfs but rather files in the DatabasePath (/usr/share/secureboot/).

The linked PR introduces a new set of commands that bypass the "database" and directly access the efivarsfs of the running system. If we are to introduce more commands like this (e.g. "remove this cert from my KEK list"), it would be good to make it clear, which commands are mutating the efivarsfs and which not.

For example, we could namespace the "direct to efivarsfs" commands like so:

sbctl enrolled list
sbctl enrolled delete
sbctl enrolled export
sbctl enrolled add

then for backwards compatibility keep the current commands as they are (with a deprecation notice?) and introduce aliases like:

sbctl db list-files # alias of list-files
sbctl db import-keys # alias of import-keys

My suggestion only makes sense if the "enrolled" commands make sense (e.g. can we delete a unique key from the db?)

(CCing my team: @mauromorales @mudler @Itxaka)

[Foxboron]

If I understand correctly, all actions/commands except the enroll-keys, are not touching the actual efivarsfs but rather files in the DatabasePath (/usr/share/secureboot/).

sbctl reset and sbctl rotate-keys also does a dance with the efivarfs to reset and rotate the keys in your hierarchy.

When it comes to the other commands I need to think a bit. Currently I want to do some heavy refactoring so everything is easier to test. I'm also contemplating more options to mess with the dbx variable that needs to be sorted out.