Created attachment 1766912 [details] Brief video of the behavior. Description of problem: Cannot accept self-signed certs in GNOME Calendar flatpak. The dialog window appears to do so, but when clicking accept (or reject, or anything besides cancel) it simply disappears and reappears. Version-Release number of selected component (if applicable): [andythurman@rockhopper ~]$ rpm -qa evolution-data-server evolution-data-server-3.40.0-2.fc34.x86_64 [andythurman@rockhopper ~]$ flatpak info org.gnome.Calendar Calendar - Calendar for GNOME ID: org.gnome.Calendar Ref: app/org.gnome.Calendar/x86_64/stable Arch: x86_64 Branch: stable Version: 3.38.2 License: GPL-3.0-or-later Origin: flathub Collection: org.flathub.Stable Installation: system Installed: 16.8 MB Runtime: org.gnome.Platform/x86_64/3.38 Sdk: org.gnome.Sdk/x86_64/3.38 Commit: 77ac076fff6756f630482bb10f63d3754c9eb231510943f24676f11e989e807b Parent: d646a20edfaa629ddb385e79462043e42bdf5df64e4c62825cb051baec4dce85 Subject: Update to 3.38.2 (838e8058) Date: 2020-12-17 16:42:46 +0000 How reproducible: Always. Steps to Reproduce: 1. Launch GNOME calendar or wait for the evolution-data-server background tasks. 2. Attempt to accept self-signed cert (Nextcloud specifically.) Actual results: Cannot accept as described above. Expected results: Can accept and use calendar (behavior present currently in 33) Additional info: Things like mounting the https share in Nautilus and signing in the account in gnome-online-accounts works fine and accepts the cert, so I belive the problem is exclusive to this component.
Thanks for a bug report. This is a bit problematic. The Flathub's GNOME Calendar builds with evolution-data-server 3.38.2, while the system runs 3.40.0. The 3.40 switched from SHA1 hashes to SHA256 hashes of the certificates. As the SHA hash is computed "by the client", the Calendar computes SHA1 hash, which doesn't match the SHA256 hash, thus it's re-asked for the certificate trust. I'll add a workaround for the transition period to accept also SHA1 hashes.
Ok, thanks. I'll also take a look upstream to see if rebasing to evolution 40 would be in order.
This work is already being done: https://github.com/flathub/org.gnome.Calendar/pull/29 Seems to still be having issues, so a local fix would be great!
FEDORA-2021-e53897d7e9 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e53897d7e9
I fixed this upstream in commit [1] for 3.41.1 and 3.40.1+. I'm building a new evolution-data-server for Fedora until the new upstream version is released. This requires an evolution-calendar-factory process restart once the new version is installed. As a workaround, run a host system version on the application and accept the certificate there. [1] https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/8c9b1cde5dcd5e20fcb6d3a84908ef536e39268a
Alright, I'll test when I get a chance.
Fixed! Thanks!
FEDORA-2021-e53897d7e9 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e53897d7e9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e53897d7e9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e53897d7e9 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.