On Thu, Jul 06, 2023 at 02:18:04PM -0000, Kamil Aronowski wrote:
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.
Sure.
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.
...snip...
I can't really help you with upstream or RHEL versions. We run Fedora on
our builders, currently pesign-116-2.fc38.x86_64
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?
Listing of PKCS #11 Modules
-----------------------------------------------------------
1. NSS Internal PKCS #11 Module
uri:
pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.90
slots: 2 slots attached
status: loaded
slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
uri:
pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
uri:
pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
2. p11-kit-proxy
library name: p11-kit-proxy.so
uri:
pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1
slots: 1 slot attached
status: loaded
slot: Alcor Micro AU9520 00 00
token: OpenSC Card (Fedora Signer)
uri:
pkcs11:token=OpenSC%20Card%20(Fedora%20Signer);manufacturer=OpenSC%20Project;serial=25b585160722;model=PKCS%2315
-----------------------------------------------------------
- where is the entry "token: OpenSC Card (Fedora Signer)"
located? Under "NSS Internal PKCS #11 Module" or under
"p11-kit-proxy"?
The latter.
- what is the output of the command `ls /usr/share/p11-kit/modules/`?
opensc.module p11-kit-trust.module
- 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?
All our ansible content is available at
https://pagure.io/fedora-infra/ansible
Nothing touches the p11-kit dir that I can see.
- 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?
no
- 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.
I don't know. I would think github.
- 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)?
See above. Do note that our builders are Fedora, not RHEL.
I appreciate your help, Kevin. Thank you for everything!
Good luck! Sorry it's being such a pain...
kevin