Open sysvinit opened 3 months ago
The change is missing a changelog entry.
From the initial pull request description:
I intentionally have not added a changelog entry just yet, as I'm not sure if this is suitable for the 2.4.2 point release, or whether this change is better introduced in 2.5.
I haven't added a changelog entry yet because I'm not sure in which section of the changelog file it should be added :)
The
File
component has asensitive_data
flag, which is a boolean value which can be set by the operator to indicate that the content of a file is sensitive and so batou should not print a diff to the terminal. In addition, theFile
component will automatically check if file content contains words which appear in the encrypted secrets, and if so will not print a diff to avoid secrets being leaked (see #198). However, it's not possible to turn the automatic sensitivity detection off, and there are some cases where this logic is undesirable.A concrete example: I have a deployment where an SSH public key is provided in the environment's encrypted secrets. This means that batou will include the key type string (e.g.
ssh-ed25519
) in the list of sensitive words. As a consequence, if I later add a known_hosts file to the deployment, batou will consider this file sensitive (because it contains other key type strings) and will not show a diff -- however a known_hosts file is one instance where I really want to see a diff, as changes in the contents of the known_hosts file might be security-relevant.This change converts
sensitive_data
to a tri-state value, which defaults to None. This means by default the automatic detection logic determines if a diff is sensitive, which can be overridden with True so that a diff is never printed (as with the previous behaviour), or with False so that a diff is always printed. There is additionally a new end-to-end test to check all three possible cases of auto-detection, positive override, and negative override.I intentionally have not added a changelog entry just yet, as I'm not sure if this is suitable for the 2.4.2 point release, or whether this change is better introduced in 2.5.