probonopd
commented
12 months ago https://gitlab.com/probono/platformissues#certificates
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL
"/etc/ssl/ca-bundle.pem", // OpenSUSE
"/etc/pki/tls/cacert.pem", // OpenELEC
"/etc/ssl/certs", // SLES10/SLES11, https://golang.org/issue/12139
"/usr/share/ca-certs/.prebuilt-store/", // Clear Linux OS; https://github.com/knapsu/plex-media-player-appimage/issues/17#issuecomment-437710032
"/system/etc/security/cacerts", // Android
"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
"/etc/ssl/cert.pem", // Alpine LinuxFreeBSD:
file /etc/ssl/cert.pem
/etc/ssl/cert.pem: symbolic link to ../../usr/local/share/certs/ca-root-nss.crt
TheAssassin
We can tell from experience that using prebuilt libcurl binaries can lead to problems when used outside of the distribution they were built for. Most commonly, it cannot find the system CA chain as the paths vary quite drastically across platforms.
In our officially released AppImages, we embed Alpine Linux's static build of libcurl. We should investigate whether we need a custom, cross-platform certificate chain lookup to make our tool work reliably across a defined (minimum, tested) set of platforms.
Note: we could even add some automated smoke testing on a variety of distributions with Docker on GitHub actions.
As an alternative, we could ship a CA chain as a fallback. In the past, we always considered that to be a UX quality degradation and strongly preferred using the system chains, though.
@probonopd please link to the related point in your desktop platform issues list.