Bug 1766340
Summary: | can't access host trusted certificates from fedora firefox flatpak | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dusty Mabe <dustymabe> |
Component: | firefox | Assignee: | Gecko Maintainer <gecko-bugs-nobody> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 33 | CC: | 0xalen+redhat, anto.trande, cglombek, chris.collins, crypto-team, dueno, elxreno, erack, gecko-bugs-nobody, james, jhorak, jkoten, john.j5live, kai-engert-fedora, kengert, klaas, klember, mcatanza, mcatanzaro+wrong-account-do-not-cc, mpreisle, otaylor, pjasicek, rhughes, rstrode, sandmann, stefw, stransky, tmraz, tpopela, vrutkovs |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | firefox-105.0.2-1.fc38 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-07-21 07:47:20 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dusty Mabe
2019-10-28 19:04:39 UTC
Add Stransky to cc at request of Owen. This should be working since bug #1484449. I guess something's wrong somewhere. If I go into the "Preferences/Privacy & Security/Security Devices" dialog in Firefox, I see 3 devices: * NSS Internal PKCS #11 Module * p11-kit-proxy (p11-kit-proxy.so) * Builtin Roots Modules (libnssckbi.so => p11-kit-trust.so via alternatives) p11-kit-proxy.so shows no entries under it. If I add, a "P11 Client" device with /usr/lib64/pkcs11/p11-kit-client.so and restart Firefox, then system certs are seen. p11-kit list-modules shows: =========== p11-kit-trust: p11-kit-client.so library-description: PKCS#11 Kit Proxy Module library-manufacturer: PKCS#11 Kit library-version: 1.1 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized token: Default Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized ============= The redirection is from the /etc/pkcs11/modules/p11-kit-trust.module snippet that Flatpak mounts into the container: ====== # This overrides the runtime p11-kit-trusted module with a client one talking to the trust module on the host module: p11-kit-client.so ====== I'll leave it to someone who understands this all better to say what that means and what the right fix is :-) Thanks Owen. I think that seems to work. Any idea what we can do to get this fixed in the flatpak itself? I guess it will need to be solved in either Fedora's Firefox or NSS package. The flatpak packaging is at https://src.fedoraproject.org/flatpaks/firefox/tree/master but there's nothing to see there. Soooo, reading the above comments, do we need to make sure /usr/lib64/pkcs11/p11-kit-client.so is automatically added to the module list in firefox when running as flatpak? How can we do that? I chatted with Daiki yesterday and he says that should not be required. I think he might look into it. Thanks Daiki! Sorry for the delay; this turned out to be a bug in p11-kit server, which doesn't handle the C_GetAttributeValue call just for getting the length of a CK_DATE value: https://github.com/p11-glue/p11-kit/pull/279 This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. https://github.com/p11-glue/p11-kit/pull/279 merged but there was a comment made that indicates it doesn't fully fix this bug. Anything we can track for the remaining work? Still having this issue on F33. Any help to figure out what the final piece of the puzzle is would be much appreciated. It's been a while, but you've mentioned we need to fix something in the Firefox to make this working. Could you be more specific, or at least give me some hints where to start investigating this issue? Thanks. I think that question was for Michael All I can say is: probably something is wrong in either NSS or p11-kit. Looks like Daiki spent some time debugging this last year. Maybe he will remember something. The situation I remember is the following: flatpak apps are provided with the host trust store forwarded through p11-kit-server (host) -> p11-kit-client.so (inside flatpak) -> p11-kit-proxy.so (automatically loaded by NSS or GnuTLS). In theory, this setup could work with any NSS and GnuTLS applications, but Firefox loads trust store in a bit special way; the PKCS #11 library name is hard-coded as "libnssckbi.so". On both host and firefox flatpak, libnssckbi.so a symlink to p11-kit-trust.so, which can only see the locally stored CAs (i.e., inside flatpak, from firefox flatpak). I suspect it might help, if we could have a symlink libnssckbi.so -> p11-kit-client.so, but I haven't had time to check that; let me try to build firefox flatpak with that setup (or similar). The theory on comment 16 seems to be correct; I've managed to make Firefox flatpak load the system trust store on the host by adjusting the library load path: $ sudo trust anchor <some test CA> $ flatpak run --command=sh org.mozilla.Firefox [📦 org.mozilla.Firefox ~]$ cd $XDG_RUNTIME_DIR/app [📦 org.mozilla.Firefox app]$ ln -s /usr/lib64/libnss3.so libnss3.so [📦 org.mozilla.Firefox app]$ ln -s /usr/lib64/pkcs11/p11-kit-client.so libnssckbi.so [📦 org.mozilla.Firefox app]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$XDG_RUNTIME_DIR/app [📦 org.mozilla.Firefox app]$ firefox and then you will see <some test CA> in the Authorities tab in the settings. My local build of Firefox flatpak is still in progress, but I've filed a PR at: https://src.fedoraproject.org/rpms/firefox/pull-request/34 > My local build of Firefox flatpak is still in progress, but I've filed a PR at:
> https://src.fedoraproject.org/rpms/firefox/pull-request/34
Now the build has completed and I confirm it works.
I guess we can close it now, as the latest firefox flatpak (firefox-stable-3420210714075341.1) from registry.fedoraproject.org works with host certificates (thanks Kalev for the adjustment). FEDORA-2022-f0988ea008 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f0988ea008 FEDORA-2022-f0988ea008 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. |