3 Commits (3679de0630ffbe67fa8d2ff299891dfdcb01cd6a)

Author	SHA1	Message	Date
Alisdair McDiarmid	5e30d58dc2	command/jsonplan: Add output change sensitivity ... When an output value changes, we have a small amount of information we can convey about its sensitivity. If either the output was previously marked sensitive, or is currently marked sensitive in the config, this is tracked in the output change data. This commit encodes this boolean in the change struct's `before_sensitive` and `after_sensitive` fields, in the a way which matches resource value sensitivity. Since we have so little information to work with, these two values will always be booleans, and always equal each. This is logically consistent with how else we want to obscure sensitive data: a changing output which was or is marked sensitive should not have the value shown in human-readable output.	5 years ago
Alisdair McDiarmid	63613ca1b0	command/jsonconfig: Add variable sensitive flag	5 years ago
Alisdair McDiarmid	e27aacebf9	command/jsonplan: Add sensitive value mapping data ... Similar to `after_unknown`, `before_sensitive` and `after_sensitive` are values with similar structure to `before` and `after` which encode the presence of sensitive values in a planned change. These should be used to obscure sensitive values from human-readable output. These values follow the same structure as the `before` and `after` values, replacing sensitive values with `true`, and non-sensitive values with `false`. Following the `after_unknown` precedent, we omit non-sensitive `false` values for object attributes/map values, to make serialization more compact. One difference from `after_unknown` is that a sensitive complex value (collection or structural type) is replaced with `true`. If the complex value itself is sensitive, all of its contents should be obscured.	5 years ago