Hmm, so... The default log level is "warn/error" - you shouldn't by default see the info/debug messages.

Another thing is in Logs you can adjust the log level of each specific log source -- so in your application if you desire to shut up the ca-certs log source, you could:

let silence_ca_certs () =
  match List.find_opt (fun src -> String.equal (List.Src.name src) "ca-certs") (Logs.Src.list ()) with
  | Some src -> Logs.Src.set_level src None
  | None -> assert false

But I agree that what you see is unpleasant - and we should demote some of these messages to debug. Also the "ignore non certificate" isn't very useful - maybe in the fold we should collect the errors and only print a single warning. The same strategy should be applied to the windows_trust_anchors -- and finally the error message (originating from x509) should be improved.

Would that work for you -- to have a single warning that 25000 things have been ignored (and on debug level, you get an explanation for each one)?

Thanks for the snippet, that solves my immediate problem :)
Note: This is undone by the next call to Logs.set_level.
To make this easier, shouldn't the log source be exposed in the library ? After all, logs are side effects that user might want to control.

The default log level is "warn/error" - you shouldn't by default see the info/debug messages.

I also don't want these to show up in the verbose output of my app. I changed everything to the debug level because at that level cohttp is also extremely verbose and I might still want to see what's wrong with certificates sometimes.

Would that work for you -- to have a single warning that 25000 things have been ignored (and on debug level, you get an explanation for each one)?

That's not satisfying to me as ca-certs just works (everytime for now) or errors-out. I don't want to see a permanent warning that I can't fix and also doesn't mean anything about the state of my app.

Perhaps that's only the case for the "ignore non certificate" warning, which could be completely silented while keeping the other warnings ?
Looking at x509's code, I'm thinking that this is just the result of the library not understanding some feature of certificates that is also not needed.

I pushed a commit to emit a single warning how many trust anchors have been ignored. I hope that is fine with you (i.e. you can live with this one log message), and plan to merge and release this.

Exposing the log source

I somehow agree. But am hesitant since this is not common in the Mirage ecosystem, and it would be great to have this uniform.

Looking at x509's code, I'm thinking that this is just the result of the library not understanding some feature of certificates that is also not needed.

My suspicion is your ca-certs file contains both pem-encoded certificates and their plain text dump -- where the latter is (rightfully) ignored.

Thanks a lot for your report, PR, and your patience.

Thanks for looking at this :)

I've recently discovered how lwt_log helps setting libraries log levels with add_rule and I wonder if a similar mechanism could be interesting for the mirage ecosystem ?
This can possibly be implemented using a custom Logs reporter.

Basically it would allow to say things like "all logs from all mirage libraries are Info", "all logs from this rogue library are Error", "all logs from this part of my app are Debug". All while working with strings, which is interesting for tuning logs at runtime.

My suspicion is your ca-certs file contains both pem-encoded certificates and their plain text dump -- where the latter is (rightfully) ignored.

Perhaps we could avoid counting the rightfully ignored data when counting ignored data ? This could help remove the warning in some cases.

Dear @Julow, thanks for your reply.

add_rule

So, in MirageOS unikernels we have the -l parameter where you can specify the log level -- both the default, and also for a specific source, i.e. -l ca-certs:error,*:debug. This is not programmatically, and indeed modifies global mutable state.

Perhaps we could avoid counting the rightfully ignored data when counting ignored data?

Sure, that's a good idea. But I'm not sure how to classify the "rightfully ignored data"... We may have to dig a bit deeper.