Page Comparison

...

To preserve the confidentiality of our customer data, we are careful to isolate user-provided data from strings that are fixed inside CockroachDB. We call this “redactability”.

(A separate wiki page will be linked here with more explanations about redactability.)See the page Log and error redactability for more details.

General concepts:

• When something is potentially sensitive / confidential, we call it “unsafe” and it is automatically deleted / redacted out when sent to CRL Tech support.

  • This conservative approach maximally protects customer confidentiality.

  • We need to work extra to include bits of known-safe data into errors to make the error reports more useful during troubleshooting.

• The CockroachDB errors library already knows about redactability and helps engineers as follows:

  • The first literal string arguments to errors.New , errors.Newf, errors.Wrap etc is automatically considered non-confidential / non-redactable.

  • Most “simple” numeric values are automatically considered non-redactable.

  • All string values passed as positional arguments to error constructors and annotation functions are considered sensitive and thus redactable.

  • More non-redactability for values passed to error constructors are possible via the SafeFormatter interface (see implementations of SafeFormat throughout the source code)

  • Error objects used as input to a new error object are decomposed into redactable and non-redactable bits automatically.

• Errors constructed outside of cockroachdb/errors, e.g. via fmt.Errorf, are considered sensitive and thus fully redactable.

...