Open aronowski opened 1 year ago
I think I'm hitting this too...
I also encountered a similar problem ,maybe you can solve like this
echo "passwd" > pinfile
pesign -t HSM -n ~/.nssdb -c example -i ~/shim-x64-*.x86_64/boot/efi/EFI/redhat/shimx64.efi.unsigned -o ~/shimx64.efi.example -s --pinfile=pinfile
@wynnfeng, This works fine for a usage, e.g., directly from an interactive shell, but I'm more concerned about the process, where rpmbuild
does its magic. In that case, I would have to at the very least rewrite some macros that handle all the stuff, e.g. determining whether to use pesign
or pesign-client
.
I tried my best, and if this was that simple, I could well have used a Process Substitution Bashism or export the PESIGN_TOKEN_PIN
shell variable - if only this worked as an rpmbuild
invocation...
In regard to the aforementioned variable, AFAIK it's undocumented in the official manuals, so I created a PR for this, but I wish this was already written officially. I guess we'll have to wait and rely on less-than-official community guides. Not that I'm blaming the pesign developers for this, because most likely their managers consider this to not be a priority during working hours.
Or I could use the client-server mode, that is, the pesign-client
binary, if not for the fact that it can't unlock my token on a RHEL 8/9 environment. If you want and have Vagrant in your toolbox, you can fork this repository I created and play around with the pesign utility on your own. Who knows, maybe you'll discover a breakthrough that makes this tool work as intended on the system it was intended to run on in the first place.
The commit 12f16710ee44ef64ddb044a3523c3c4c4d90039a introduced a regression that makes
pesign
fail instantly instead of asking for a token's password.Please perform the following steps to verify the behavior on Red Hat Enterprise Linux 9.1:
Install the prerequisites:
Initialize a SoftHSM token:
Create a .p12 file and import it to the token:
Get a binary that will be used for testing with
pesign
- I chose shim in this example:Install the packages required to build the good and bad
pesign
s:Witness the good and bad behavior yourself:
This report mentions Red Hat Enterprise Linux 9.1 and shim for a good reason. To sum it up: the entities that sign their shims with hardware tokens on RHEL and its replicas need to either:
pesign
release 113-21 which comes with e.g. CVE-2022-3560 so they need to secure their environments on another layerThe latter can be realized fairly easy in some cases like mine, e.g. having only a limited number of trusted individuals being able to access the machine that performs the signing so no one would utilize this CVE.