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!
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
