"failed to encode size of [$a]" may lead to data leaks

[nadavwr]

When encoding sensitive data, the last thing we want is to see "failed to encode size of [{ 'password': 'Supercalifragilisticexpialidocious' }]" end up in our log.

This message is generated at VariableSizeCodec:18, and is nigh impossible to avoid.

Perhaps a message that omits encoded payload would do? e.g.:
"failed to encode size for $codec using $sizeCodec"?

[mpilquist]

@nadavwr Hm, a couple of other options come to mind that I'd appreciate your thoughts on.

1. We could introduce a combinator like maskErrors[A](c: Codec[A]): Codec[A] that strips all details from error messages.
2. We could add a verbose flag to VariableSizeCodec and other codecs that include the toString of a value.

[ceedubs]

If you do something along the lines of number 2, it may be nice instead take an A => String (that could even default to identity). Sometimes I might have some useful information that I'd want to include in the error message without including the whole object. Beyond the security concern example, sometimes a structure may just have a really inefficient toString method -- at work we once hit a performance issue that turned out to be a toString call on a very large Map in a log message.

[nadavwr]

Revisiting this one year later, I can provide two references where this is addressed:

When http4s fails to parse something, their ParseFailure type allows providing both a detailed message, and a sanitized message that shouldn't leak data about the document. Since this is also an exception, they also make sure the exception will prefer the sanitized content, if present.

Akka HTTP also goes along these lines. They explain their rationale in ErrorInfo.

I guess this translates to option 2 above, except that this should really be explained as a security feature to offset the added complexity. That's why I like http4s' use of the word sanitized.