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@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
