Put debug-dump-store behind a feature-flag

[sosthene-nitrokey]

When debugging Nitrokey/piv-authenticator#12 I realized this was not removed from production firmware. Putting it behind a feature flag will ensure that it does.

[szszszsz]

I thought the consensus is to not make a feature out of the debug switches (but use --cfg flag instead). Has this changed?

Ref: Nitrokey/trussed-secrets-app#23

[robin-nitrokey]

I think this is a misunderstanding. We almost never use rustc’s --cfg flag directly, just features. But in the source code, we use the cfg attribute to check for that feature.

Ah, I just saw the review comment you referred to. I’ll have to think about that option.

[sosthene-nitrokey]

I think the main difference between the two is that the addition of the debug-dump-store is purely additive, whereas the removal of encryption is not.

This flag does not change the test paths if you use --all-features, since it only adds new code.
For the encryption on the other hand, it removes code, so testing with --all-features does not test encryption.

Also removal of encryption is not something we want to encourage at any point, while features are easily discoverable, and therefore can mistakenly be enabled, which would be highly problematic.

[sosthene-nitrokey]

It's also consistent with the std features, that are here only for debugging/testing. They can be features because they're additive, and not that dangerous, contrary to the encryption flag.

[szszszsz]

dump-store in production firmware sounds dangerous to me, hence the question

[sosthene-nitrokey]

It makes the call available but you would still have to call it, and you would have to have the logs somehow accessible on a production device before this becomes really dangerous.

[nickray]

Did you come to consensus? :) Slight tendency to cfg-flag on my side (default "off" naturally).

[sosthene-nitrokey]

I moved it behind a CFG. This doesn't matter much if you prefer cfg we can merge it that way.