search

certifi / erlang-certifi

SSL Certificates for Erlang
Other
131 stars 33 forks source link

Keep cacerts in persistent_term, for OTP 21+ #45

Closed paulo-ferraz-oliveira closed 3 years ago

paulo-ferraz-oliveira commented 3 years ago

https://github.com/erlang/rebar3/pull/2442 opened an issue to us in regards to code paths.

Our code is compiled in such a way, that certifi's priv folder is not actually our own (inside _build), but rebar3's (e.g. rebar3/certifi/priv/cacerts.pem).

44 introduces visibility for this, but doesn't solve the underlying issue. (the latter being that the certificates don't get bundled, thus we get an error at runtime, regarding "ca unknown").

Though many solutions are possible, some of which might include tweaking rebar3's code, or make it not depend on certifi most don't seem OK in the short term (those optimizations/changes to rebar3 were necessary and not depending on certifi is not a choice, at the moment).

This issue was discussed in #rebar3 (Slack) and now opened here for reference (I'll create a draft pull request, possibly today, to "address" it).

If the use of persistent_term is accepted it should be OK to use it instead of the ct_expand-based mechanism, though this might introduce potential performance degradation in long-living servers, with thousands of processes, after a code reload to certifi itself (this is a supposition, not actually tested). We could make the use of persistent_term optional so as to not force certifi to bump to OTP 21, which would, also, affect rebar3.

@g-andrade @ferd @max-au

ferd commented 3 years ago

This might be a thing that rebar3 really has to fix more than certifi, and I just want to make sure we're stating that we're not pushing the responsibility of dealing with our path idiosyncrasies to other libraries who had nothing to do with these choices. We should fix things in rebar3 regardless. That being said, if there's a feeling that things are worth mitigating in here in the mean time, I won't stand in its way.

paulo-ferraz-oliveira commented 3 years ago

I just want to make sure we're stating that we're not pushing the responsibility of dealing with our path idiosyncrasies to other libraries

@ferd, I hope I didn't imply that. If I did, it was wrong, and not my intention. I'll close this one and open one with no references to rebar3. Again, sorry for any misunderstanding.

paulo-ferraz-oliveira commented 3 years ago

Upon further thought, this wouldn't be a real solution (using persistent_term either) because when I'd try to fetch from priv I'd get the same result.