Defense policies: who defends which unwanted results and where to test?

defense-policies.md

Background

I am finally getting around to capturing my "dot files" and other setup parameters because I need to re-create my development environment on different hardware and new VMs. As I go through the setup, I am carefully documenting the steps in README.md and also adding functions to a setup script. The script will, I hope, semi-automate or completely automate the large majority of my re-establishing my personal settings. Many developers have great "dot files," setup scripts, & methods in their public github. I am writing my own from scratch because I am enjoying the process, not because I think mine will be better.

Testing Script functions

While writing tests for my setup script, I decided to write mostly "negative" tests to attack the functions and handle corner cases I have seen fail in others' code (frequently). In my previous job, I was very saddened by the culture of 100% "happy path" tests written exclusively to pass some "test coverage" target but serving almost no real verification purpose. So I am intentionally over-indexing on negative tests; coverage will be a side-benefit. While writing tests for a log wrapper function, I thought about cases where the payload might contain binary sequences that are annoying or mildly harmful when viewed in a terminal. Think about character sequences that make the font color white (on a white background) or switch the character set to NKo letters from the terminal user's native alphabet.

Who defends whom from what?

If I want to defend the log message viewer from binary or escape-sequences that could be annoying or bad, should the logging function faithfully log all binary and give terminal defense responsibility to the log message viewer? Or should the logging wrapper itself prevent everything but "acceptable" bytes from entering the logs? I cannot foresee the need for a shell wrapper of a logging function to pass binary to the logs as part of the logging message. So I am leaning towards adding the "strings(1)" command to the logging function. However, when we separate concerns, adding the defense responsibility to the logging wrapper feels wrong.