Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2350#discussion_r159101938
--- Diff:
nifi-toolkit/nifi-toolkit-encrypt-config/src/main/groovy/org/apache/nifi/properties/ConfigEncryptionTool.groovy
---
@@ -730,6 +821,42 @@ class ConfigEncryptionTool {
}
}
+ String decryptAuthorizers(String encryptedXml, String existingKeyHex =
keyHex) {
+ AESSensitivePropertyProvider sensitivePropertyProvider = new
AESSensitivePropertyProvider(existingKeyHex)
+
+ try {
+ def doc = new XmlSlurper().parseText(encryptedXml)
+ // Find the provider element by class even if it has been
renamed
+ def passwords = doc.userGroupProvider.find { it.'class' as
String == LDAP_USER_GROUP_PROVIDER_CLASS }.property.findAll {
+ it.@name =~ "Password" && it.@encryption =~
"aes/gcm/\\d{3}"
+ }
+
+ if (passwords.isEmpty()) {
+ if (isVerbose) {
+ logger.info("No encrypted password property elements
found in authorizers.xml")
+ }
+ return encryptedXml
+ }
+
+ passwords.each { password ->
+ if (isVerbose) {
--- End diff --
Informational note: in the event the file is in an unsupported state
(perhaps manually decrypted but the `encryption` attribute is still present),
this will log the plaintext password to the console output before attempting to
decrypt. This is not necessarily a vulnerability of the tool, as the incoming
data is not in the expected format. It would take additional effort to capture
the "raw" value, compare the attempted decryption and the original value, and
output the raw value if the contents are different. This would still allow the
tool to print the attempted decryption input value if the attempt throws an
exception, but this level of effort is unnecessary for this edge case. Just a
note for the future.
---
