Note that a user can still make this zero cost in the binary / at runtime by enabling the log/release_max_level_off feature, so I wouldn't worry about the cost here.

Do we need to defined policy around whether the security critical (hax compiled) parts may log? If critical parts don't log, that makes it easy on the safety/privacy aspects, because code outside that (even though being in the same crate) should probably not get access to secrets anyway. (We may want to vet debug impls for that though). If we log from critical code, is there a log level that is guaranteed not to contain key material? I'm unsure of the answer because while logged keys and secrets are useful during plug tests, they are a no-go in production systems. Not sure whether setting up cfg flags around it helps.

make this zero cost by enabling the log/release_max_level_off feature

Thanks for the heads up, added a way to set it from the application.

As for the policy, yes that's important. As a first step, I was first looking into adding some sort of skip directive for the Debug derives in the state structs (e.g. to avoid logging secrets), but it turns out it is still not supported in Rust.

We can start with very basic logs just to "know where it went wrong", and build on top of it. Pushed a commit in that direction. Results look like this:

$ RUST_LOG=debug cargo run --bin coapserver
     Running `target/debug/coapserver`
[2024-05-29T07:09:37Z INFO  coapserver] Starting EDHOC CoAP Server
Waiting for CoAP messages...
Received message from 127.0.0.1:33736
[2024-05-29T07:09:40Z INFO  lakers] Initializing EdhocInitiator
[2024-05-29T07:09:40Z INFO  lakers] Enter process_message_1
[2024-05-29T07:09:40Z DEBUG lakers_shared::edhoc_parser] Enter parse_message_1
[2024-05-29T07:09:40Z DEBUG lakers_shared::edhoc_parser] Enter parse_suites_i
[2024-05-29T07:09:40Z INFO  lakers] Enter prepare_message_2
Received message from 127.0.0.1:36994
Received message 3
Found state with connection identifier ConnId(3)
[2024-05-29T07:09:40Z INFO  lakers] Enter parse_message_3
[2024-05-29T07:09:40Z DEBUG lakers_shared::edhoc_parser] Enter decode_plaintext_3
[2024-05-29T07:09:40Z INFO  lakers] Enter credential_check_or_fetch
[2024-05-29T07:09:40Z INFO  lakers] Enter verify_message_3
EDHOC exchange successfully completed

@chrysn I changed the level to trace!, and moved the log dependency to the application, so that the library doesn't need an extra flag for that.