Bug 1766340 - can't access host trusted certificates from fedora firefox flatpak
Summary: can't access host trusted certificates from fedora firefox flatpak
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-28 19:04 UTC by Dusty Mabe
Modified: 2022-10-05 12:56 UTC (History)
30 users (show)

Fixed In Version: firefox-105.0.2-1.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-21 07:47:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github p11-glue p11-kit pull 279 0 None closed rpc: Add missing null checks in attribute value serializers 2020-11-30 16:51:58 UTC

Description Dusty Mabe 2019-10-28 19:04:39 UTC
Description of problem:

I'm trying to run firefox in a flatpak from the fedora registry on F31 Silverblue. I have certificates on the host but they aren't available in the flatpak for some reason.

I engaged upstream and was told this was not a flatpak bug but an issue with the packaging.

see https://github.com/flatpak/flatpak/issues/2721#issuecomment-546724096

Version-Release number of selected component (if applicable):

F31 silverblue at:

```
    Version: 31.20191028.0 (2019-10-28T01:12:12Z)
 BaseCommit: 17c5051b00a49a9cfeef2d687540d33a7210db25227014672d0d6c97e50399b5

```

Flatpak at:

```
$ flatpak --user info org.mozilla.Firefox

Firefox - Browse the Web

          ID: org.mozilla.Firefox
         Ref: app/org.mozilla.Firefox/x86_64/stable
        Arch: x86_64
      Branch: stable
      Origin: fedora
  Collection: 
Installation: user
   Installed: 369.0 MB
     Runtime: org.fedoraproject.Platform/x86_64/f30
         Sdk: org.fedoraproject.Sdk/x86_64/f30

      Commit: 19e5b7f8d1745f1456bb47525cdeeaebe284e9501d07ec787b3c822c54e3a772
     Subject: Export org.mozilla.Firefox
        Date: 2019-10-23 10:08:03 +0000
      Alt-id: 445138d3b3fbdf203c44481fe2f8be5a667d53a2a5336bd0182176dad5bde21e
```

How reproducible:
Always

Steps to Reproduce:
1. Have local trusted certs on your f31 SB system
2. `flatpak --user run org.mozilla.Firefox`


Expected results:

Certs from systemwide config show up in Firefox.

Comment 1 Dusty Mabe 2019-10-28 19:05:15 UTC
Add Stransky to cc at request of Owen.

Comment 2 Michael Catanzaro 2019-10-28 19:16:36 UTC
This should be working since bug #1484449. I guess something's wrong somewhere.

Comment 3 Owen Taylor 2019-10-28 19:52:35 UTC
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 :-)

Comment 4 Dusty Mabe 2019-11-04 15:56:22 UTC
Thanks Owen. I think that seems to work. Any idea what we can do to get this fixed in the flatpak itself?

Comment 5 Michael Catanzaro 2020-01-20 16:10:30 UTC
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.

Comment 6 Kalev Lember 2020-01-21 11:54:16 UTC
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?

Comment 7 Michael Catanzaro 2020-01-21 13:59:29 UTC
I chatted with Daiki yesterday and he says that should not be required. I think he might look into it.

Comment 8 Dusty Mabe 2020-01-27 13:12:04 UTC
Thanks Daiki!

Comment 9 Daiki Ueno 2020-02-07 17:01:47 UTC
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

Comment 10 Ben Cotton 2020-02-11 16:37:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 11 Dusty Mabe 2020-03-11 15:14:17 UTC
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?

Comment 12 Dusty Mabe 2021-03-30 17:11:06 UTC
Still having this issue on F33. Any help to figure out what the final piece of the puzzle is would be much appreciated.

Comment 13 Jan Horak 2021-04-15 11:18:04 UTC
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.

Comment 14 Dusty Mabe 2021-06-10 13:58:38 UTC
I think that question was for Michael

Comment 15 Michael Catanzaro 2021-06-10 14:10:34 UTC
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.

Comment 16 Daiki Ueno 2021-06-10 14:54:00 UTC
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).

Comment 17 Daiki Ueno 2021-06-23 09:08:52 UTC
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

Comment 18 Daiki Ueno 2021-06-23 10:58:02 UTC
> 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.

Comment 19 Daiki Ueno 2021-07-21 07:47:20 UTC
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).

Comment 20 Fedora Update System 2022-10-05 12:46:30 UTC
FEDORA-2022-f0988ea008 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f0988ea008

Comment 21 Fedora Update System 2022-10-05 12:56:40 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.