Bug 412826 - Server Authenticity check dialog pops up on startup and on wake from sleep, even though the certificate is saved forever.
Summary: Server Authenticity check dialog pops up on startup and on wake from sleep, e...
Status: REPORTED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.7.5
Platform: Flatpak Linux
: NOR normal
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-10 18:42 UTC by langdon
Modified: 2019-12-13 21:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description langdon 2019-10-10 18:42:15 UTC
I use konversation in a flatpak on Fedora Silverblue (f31 beta atm) against a znc server with a self-signed cert and the "accept cert forever" function seems to not be working. 

I get the prompt every time I start konversation and every time my computer wakes from sleep (or any network disconnect). I thought at first this might be not having persistence where this was flag was stored might be the problem however, the wake from sleep scenario makes me think this is not it.

I can confirm, on f30 (and maybe f31) with a native install this was working with my setup.
Comment 1 langdon 2019-12-13 21:25:24 UTC
I just wanted to add that I have now done some further investigation with no luck :(. 

In /home/$HOME/.var/app/org.kde.konversation/config/ (where konversationrc is) I added (individual tests):
* a blank ksslcertificatemanager via touch from inside the flatpak with nobody:nobody 
* a blank ksslcertificatemanager chown'd to $USER:GROUP chown'd inside the flatpak
* a "correct" ksslcertificatemanager from another machine
* symlink $HOME/.config/ksslcertificatemanager -> to correct /home/$HOME/.var/app/org.kde.konversation/config/ksslcertificatemanager
* a "correct" ksslcertificatemanager from another machine in $HOME/.config/ksslcertificatemanager

I also confirmed (ls -lZ) that the selinux perms appeared correct as well.  


none of ^^ makes a difference. I am not sure why as it "should work"