thanka for your pr. would you mind to move the decode_pem_multiple_log_error (or similar) to x509 (best on top of the string pr) -- then we can have that included in the upcoming x509 release.

OCAML_EXTRA_CA_CERTS - I'm pretty unsure about that, esp. since SSL_CERT_FILE / NIX_SSL_CERT_FILE is already supported - and I find these environment variable escape hatches very ugly. Would/should the SSL_CERT_FILE take a list of files, and/or have a way to specify "also add the system certs" (using sth like the path "+system") be sufficient for your use case?

maybe @dinosaure or @reynir, would you mind to open a PR for x509 which has an improved version of decode_pem_multiple (more like a fold, the signature I have in mind: val decode_pem_multiple : ('a -> (Certificate.t, `Msg of string) result -> 'a) -> 'a -> string -> 'a -- thus the caller can decide what do to with errors.

what do you think? (of course @art-w , feel free to jump in and open a pr to x509)

maybe a new function fold_decode_multiple_pem would be the way forward.

Yes a fold makes sense in x509, I'll get at it right away!

Changing the behavior of SSL_CERT_FILE might introduce some problems however, as this environment variable is also used by other applications (notably curl), so I don't think it's ideal..

I added two commits, one for compatibility with the latest X509 library and one to use its fold_decode_pem_multiple implementation. Should I open a separate PR for the cstructs removal? :)

there's #29 already which removes cstruct.

I'm still puzzled about this PR. So, what is the interoperability story, in terms of macOS/windows/Unix?

Also, in the documentation you write "Additional CAs can be enabled by setting the environment variable [OCAML_EXTRA_CA_CERTS] to a file path containing more trust anchors" - so that file is supposed to contain a list of certificates? PEM encoded? Maybe worth specifying?

Why is SSL_CERT_FILE / NIX_SSL_CERT_FILE used and documented for trust_anchors, and your proposed OCAML_EXTRA_CA_CERTS for authenticator? I'd semantically-wise find it cleaner if trust_anchors would do the environment variable stuff.

What is the information and error paths? Shouldn't there be specific messages about "using OCAML_EXTRA_CA_CERTS from %s" (path) [to inform the user] and as questioned, what should the failure behaviour be (if the file does not exist or has invalid data)?

the second commit slurps the previous log messages - I don't understand why (but please don't bother, I'll have that as a separate PR anyways).

in case you like to have this merged (also addressing #25 (comment)), it would be great if you could:

• rebase on the current main branch (with Use fold decode pem #34 and No cstruct #32 merged)
• address or discuss the questions raised in Facilitate the use of extra CA certificates #30 (comment)

I'll cut a release without the OCAML_EXTRA_CA_CERTS, but I'm happy to merge and release it once the semantics is more clear.

The PR was rebased 👍.

Thanks! (sorry for the late reply, I was on holidays without internet for a long time)

I still think this is useful, and tried to address your feedback (log reports, trust_anchors includes the extra CA certs, documentation of pem-encoded file format)... but do let me know if the semantics are still unclear?
Regarding the interoperability story, the OCAML_EXTRA_CA_CERTS is used on all platforms. Are there specific issues on eg windows that would make this a bad idea?

PS: May I suggest a patch for trust_anchors to return an X509.Certificate.t list instead of a string? :) (I don't need it but think it would be cleaner)

thanks