Anything other than the standard OS-specific bundle is going to look magic to the user. For example, if the path were set to /etc/motd:/etc/pki/tls/certs/ca-bundle.crt then a file created at /etc/motd would magically (i.e. unexpectedly) cause TLS connections to stop working.
I don't see why a user would add that path. If a user would compile libcurl with /etc/motd as the main CA certificate bundle path at the moment, unexpected behavior will occur as well. It is the job of the developer who generates the libcurl binary to provide proper paths.
Yes, that's a contrived worst-case example, and if AppImage points it to an internal sandboxed path and documents it appropriately it shouldn't be a problem.
AppImages are not sandboxed. Think of them as a slightly more advanced alternative to a self-extracting archive (the "extract" process is replaced by mounting the payload using FUSE). Also, I mentioned previously that I'd prefer not to ship a CA certificate bundle within the application bundle but use the system bundle.
The most straightforward example is if the path included a world-writable location, then an attacker could place a bad certificate there and enable a MITM attack. Since there currently is no search within libcurl, there is currently no danger.
Whether you support one bundle or multiple bundles doesn't make a big difference. The proposed paths are all in read-only, root-writable locations, as per the FHS. Only distributions which ignore this standard could maybe be affected by such an issue. But then again, the existing single CA bundle path may be writable as well.
But then again you need to take into consideration that AppImages (or tarballs or any other relocatable bundle) are owned by the user who executes them. There is no security gain if a libcurl contained inside such a bundle would just check a single location, since an attacker could just replace that libcurl and rebuild the bundle. This feature doesn't open a new attack vector that is worse than that (which requires access to the host computer first anyway).
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
