guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#49957] [PATCH] gnu: p11-kit: Fix certificate errors from flatpak ap


From: John Kehayias
Subject: [bug#49957] [PATCH] gnu: p11-kit: Fix certificate errors from flatpak apps
Date: Mon, 25 Oct 2021 19:33:49 +0000

Hi Ludo’ and Andrew,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, October 25th, 2021 at 3:13 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Andrew Whatson whatson@gmail.com skribis:
>
> > Flatpak has a soft dependency on p11-kit, which was configured without
> > knowledge of the system-wide CA certificate store. This caused some
> > flatpak apps to fail with ERR_CERT_AUTHORITY_INVALID errors.
> >
> > -   gnu/packages/tls.scm (p11-kit): Configure with
> >     /etc/ssl/certs/ca-certificates.crt as a trusted path.
>
> I pushed a similar fix on ‘master’ based on John’s patch as
> b4d29851e412c6f4fea5b2d98160258b9768dee3.
>
> We might as well update the default p11-kit though? (Somehow I was
> assuming it had many dependents, but it only has 80+.)
>

Flatpak's dependency doesn't show up on a guix refresh --list-dependents 
p11-kit, as it comes through some other package somehow (I never looked how 
exactly). But I guess that is more "using" than needing to build against? 
Wondering if there are some hidden runtime cases to look out for. (Probably 
more relevant when thinking of changing that configure flag?)

For this bug, the fixes that I wrote did need a cleaning out of previous 
Flatpaks (checking how you launch Flatpak apps as our previous version put the 
full store path in .desktop files) as p11-kit gets started in some indirect 
way. I think via D-Bus and its portal, but the system p11-kit could be used 
instead of the fixed version. I made sure to remove previous Flatpak installs 
from my profile and did a restart to be sure. Noting here for completeness.

John





reply via email to

[Prev in Thread] Current Thread [Next in Thread]