greyp9 commented on PR #6821:
URL: https://github.com/apache/nifi/pull/6821#issuecomment-1401120102
@exceptionfactory this all looks really cool, thanks for the effort!
Did some usage testing, and wanted to share some feedback. I plan to follow
up with a pass at the code.
- The sample flow attached to the JIRA was really helpful to me to give a
sense of the depth of permutations. It occurs to me that those nine sample
configurations might form the basis of some helpful user documentation.
Something like a table that describes, for a particular `EncryptContent`
configuration, what an equivalent
`DecryptContentEncoded`/`DecryptContentCompatibility` configuration should be.
- EncryptContent
Key Derivation Function = NiFi Legacy KDF
Encryption Algorithm = MD5_DES
- DecryptContentCompatibilityMode
Encryption Scheme = PBE_WITH_MD5_AND_DES
Key Derivation Strategy = JASYPT_STANDARD
If not in the user documentation somewhere, maybe some other
reference-able place. The nine samples give a good sense of the
configurability; no need to document every permutation.
- After a FlowFile has gone through an encrypt / decrypt processor pair,
should any of the `encryptcontent.*` attributes be stripped out of the FF
attribute set? Not sure if that breaks an existing FF convention, but if those
are left over, they might confuse downstream processors, or lead to IV reuse,
for example.
- It looks like the encryption algorithms are specified in
`EncryptionMethod` (for `EncryptContent`) and
`CompatibilityModeEncryptionScheme` (for `DecryptContentCompatibilityMode`).
What do you think of these being alphabetized in the UI listbox? The choices
matching `DecryptContentCompatibilityMode` `PBE_WITH_MD5_*` appear in two
separate groupings in the UI listbox.
- `org.jasypt` has released a `1.9.3` version. Might this be a good time to
consider bumping the version dependency?
- When specifying a raw key (for `Key Specification Format`), it might be
nice for the tooltip to provide a hint as to the number of hex characters
expected. There might not be a single answer, given that many algorithms (AES)
have implementations with multiple key sizes. Maybe some blurb along the lines
of:
> Advanced Encryption Standard (AES) keys are symmetric keys that can be
three different key lengths (128, 192, or 256 bits).
This may be better handled as follow on work.
- In my usage testing, I was swapping back and forth between use of
`Password` versus `Raw Key (hexidecimal)`, using parameters `#{MyPassword}` and
`#{MyRawKey}`. These are two distinct properties in `EncryptContent`. But in
`DecryptContentEncoded`, one property is overridden to provide storage for both
`Key Specification Format` options. It might be nice for these to be two
distinct properties, so changing the format does not require changing the key
specification value. These could be presented in the UI the same way using
`PropertyDependency`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
