Thanks for the reply, Kevin. It means a lot to me, as I no longer feel alone with this
issue. I'll try the mock configuration later on, so I do not overcomplicate things
right now - once a basic config works for me, I'll then try mock.
I did try the strace method you suggested, and, as far as I can see, the socket can be
accessed since 0 is returned. This is part of my listing:
```
$ strace pesign-client --unlock --token "NSS Certificate DB" |& grep -i
r_ok
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
access("/run//pesign/socket", R_OK) = 0
```
I experimented a bit more, and via trial-and-error, I came to the conclusion that the
pesign suite of tools has most likely had some regressions, as it used to have these
historically. For instance, the one I mentioned earlier that I reported at:
https://github.com/rhboot/pesign/issues/105.
Why this conclusion? Let's take a deeper dive into this.
First, on April 11, I suggested some improvements to the manual page of `pesign` here:
https://github.com/rhboot/pesign/pull/106/files
I triple-checked that everything was OK on RHEL 9.1, which shipped pesign 115. However,
the command I suggested in the manual for generating a CA directly in a token no longer
works - the `-t HSM` option in `efikeygen`.
Second, I just tested `pesign` on both Fedora 38 (version 116) and CentOS 8.5 (version
112). Error handling seems different, and once I research this more, using `git bisect`,
I'll file an issue on GitHub too.
This happens on CentOS 8.5:
```
$ pesign-client --unlock --token "this token does not exist"
Enter passphrase for private key:
pesign-client: could not find token "this token does not exist"
```
The error message is fine. And this happens on Fedora 38:
```
$ pesign-client --unlock --token "this token does not exist"
Enter passphrase for private key:
pesign-client: pesignd starting (pid 2905)
```
The error message does not seem meaningful.
Third, I mentioned in my introductory message that `pesign` seems to work fine with the
internal NSS database, that is "NSS Certificate DB". Through some more
experiments I figured out that I can indeed build GRUB2 with `pesign` in client-server
mode with some tweaks. Here's what worked for me:
- I generated another CA directly in `pesign`'s database and named it `grub2-signer`
according to the macro in Fedora's GRUB2 SRPM (that is in the file `grub.macros`):
```
$ grep grub2-signer grub.macros
%{expand:%%define __pesign_client_cert grub2-signer} \
$ efikeygen -d /etc/pki/pesign -n grub2-signer --self-sign --common-name "CN=test
grub2 signer CN,OU=test grub2 signer OU,O=test grub2 signer O" --kernel
```
- and ran the build just fine:
```
$ rpmbuild -bb -D 'pe_signing_token NSS Certificate DB' -D 'pe_signing_cert
grub2-signer' *.spec
[...]
+ /usr/bin/pesign-client -t 'NSS Certificate DB' -c grub2-signer -s -i
grubx64.efi.orig -o grubx64.efi.onesig
+ [[ 2 -eq 2 ]]
[...]
```
Fourth, since I could unlock the tokens: "NSS Certificate DB" and "NSS
Generic Crypto Services", which are listed under the PKCS #11 module named "1.
NSS Internal PKCS #11 Module", but not those that either don't exist at all or
are located in the module named "2. p11-kit-proxy", I therefore suppose that
`pesign` version 116 only works with the first one properly.
Therefore, I suppose that the Fedora Project has some kind of configuration that makes the
smart card named "OpenSC Card (Fedora Signer)" be present in the slot that just
works - the most simple explanation.
So after this research, I'd like to ask the following:
- what is the output of the command `modutil -dbdir /etc/pki/pesign/ -list` ran on the
Koji build servers?
- where is the entry "token: OpenSC Card (Fedora Signer)" located? Under
"NSS Internal PKCS #11 Module" or under "p11-kit-proxy"?
- what is the output of the command `ls /usr/share/p11-kit/modules/`?
- are there any commands in the infrastructural Ansible playbooks/Salt states/shell
scripts used for provisioning Koji builders that manipulate that directory directly or
indirectly? If so, what are they?
- does a command similar to `modutil -dbdir /etc/pki/pesign/ -default p11-kit-proxy
-mechanisms
"RSA:DSA:RC2:RC4:RC5:AES:DES:DH:SHA1:SHA256:SHA512:SSL:TLS:MD5:MD2:RANDOM:FRIENDLY"`
that changes the default provider for security mechanisms run during the provisioning
stage?
- is filing issues on the `pesign` project's GitHub the proper way to keep in touch
with the developers, or is another way preferred? For instance, file them directly at
bugzilla.redhat.com.
- if it's possible to redact secrets (usernames, passwords, etc.) from the
provisioning specification (playbooks/states/scripts) Fedora Project uses for these
bootchain-related Koji servers, could these be shared with me, so I could replicate the
configuration 1:1 (apart from the physical smartcard connected to the servers)?
I appreciate your help, Kevin. Thank you for everything!