Want to make a note to anyone using a mixed footprint of cipher filter versions. Particularly patched v2.0.2 and older cipher filter encryptors with v2.0.3+ decryptors (and vice-versa)
Such a setup would be a unique edge case where you happen to be encrypting with logstash agents using the patched code from this original PR #3, rather than the official 2.0.2 (and older) plugin release (which is unlikely as it did not work properly anyway)
This particular change (i.e. moving from non-strict b64 en/decoding to strict) may cause the following error on either side (likely the decoding/decrypting side) in the logstash log, something to the effect of: ArgumentError: invalid base64.
The solution is to bring both sides of your encryption/decryption inline to the same cipher filter version. i.e. Both sides running v2.0.3+ or both sides running the patched code from PR #3
This really doesn't affect the official v2.0.2 and lesser released versions due to other bugs where it didn't work properly anyways.
Please see here, for line notes: 01311b3
Lastly, we could add an option to v2.0.3+ such as base64_strict: true|false to permit folks to toggle the use of strict vs non-strict base64 to permit such a mixed mode as described above, however I think this option would be pretty short-lived.
Want to make a note to anyone using a mixed footprint of cipher filter versions. Particularly patched v2.0.2 and older cipher filter encryptors with v2.0.3+ decryptors (and vice-versa)
Such a setup would be a unique edge case where you happen to be encrypting with logstash agents using the patched code from this original PR #3, rather than the official 2.0.2 (and older) plugin release (which is unlikely as it did not work properly anyway)
This particular change (i.e. moving from non-strict b64 en/decoding to strict) may cause the following error on either side (likely the decoding/decrypting side) in the logstash log, something to the effect of:
ArgumentError: invalid base64.The solution is to bring both sides of your encryption/decryption inline to the same cipher filter version. i.e. Both sides running v2.0.3+ or both sides running the patched code from PR #3
This really doesn't affect the official v2.0.2 and lesser released versions due to other bugs where it didn't work properly anyways.
Please see here, for line notes: 01311b3
Lastly, we could add an option to v2.0.3+ such as
base64_strict: true|falseto permit folks to toggle the use of strict vs non-strict base64 to permit such a mixed mode as described above, however I think this option would be pretty short-lived.