Ideas

[wojtekmach]

• [ ] Fedora support. On Ubuntu & Alpine, the CA store is /etc/ssl/certs/ca-certificates.crt but on fedora it is /etc/ssl/certs/ca-bundle.crt.
• [ ] Windows support
• [ ] SystemCAStore.cacerts/0 that can be given as SSL cacerts option. If we add this, perhaps worth caching in persistent_term as it shouldn't change much? This would also neatly solve our current macOS implementation where we cache the certs as separate file, we wouldn't need the extra file at all.

[hauleth]

I think that instead of providing path for the CA bundle, this library should provide function to check if the certificate is valid. This will allow using Swift API for validation certificates which should be more fool-proof than generating such file on-the-fly.

For Linux Swift NIO also have nice list of files and directories to search by.

[wojtekmach]

Interesting, thanks for the pointers!

[wojtekmach]

Note to self: see how https://crates.io/crates/rustls-native-certs and its per-OS deps do this.

[hauleth]

@wojtekmach if it will use NIFs/ports in that case, then maybe just wrap rustls-native-certs and call it a day?

[wojtekmach]

I didn't mean to link to rustls, just see how they do it and replicate it in pure elixir, if possible.

I think linking would work but then we complicate the build process and require the users to have compiler toolchain to install this package (fwiw, on macOS they likely already have if they got Erlang installed in the first place) which I'd avoid as much as possible unless it would be safer, more robust, etc to use the Security.framework rather than work around it.

We could ship precompiled binaries somewhere and download them when compiling the dep, see https://github.com/wojtekmach/cmark_precompiled, but we have an interesting chicken and egg problem, I kind of want to eventually be able to use system_castore to securely download such build artifacts :) (when Hex first-class support for per-arch binaries, that'd no longer be a problem.) We could ship all per-arch binaries in the same package but then we blow up the size.

[hauleth]

Maybe create EEP to add support for such functionality built-in into the Erlang's ssl or crypto directly. It shouldn't be hard to do and would make the Erlang implementation of SSL "more complete" by default.