[
https://issues.apache.org/jira/browse/NIFI-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645129#comment-15645129
]
ASF GitHub Bot commented on NIFI-2652:
--------------------------------------
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/1186
@YolandaMDavis I believe I have resolved the issue you were encountering,
and the unrelated test failure was due to DNS settings on my machine which I
have now fixed. Please perform the review. Thank you.
> Handle multiple invocations of the encrypt-config tool
> ------------------------------------------------------
>
> Key: NIFI-2652
> URL: https://issues.apache.org/jira/browse/NIFI-2652
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Tools and Build
> Affects Versions: 1.0.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Labels: bootstrap, config, encryption, security
> Fix For: 1.2.0
>
>
> A discussion between [~jtstorck] and myself led to some possible scenarios
> with the {{encrypt-config}} tool. If a user invokes the tool multiple times
> on the same input files (updating in place), what should happen?
> Currently:
> The tool will not operate on any already-protected properties. So sensitive
> properties present and unprotected would be protected by the first
> invocation. If, before the second invocation, new sensitive values were
> provided in the {{nifi.properties}} file, they would be protected by the
> second invocation. If the user provides the same key/password as the first
> invocation, all properties would be encrypted with the same key. However, if
> a different key/password were used, the properties encrypted on the second
> invocation would be protected with a different key, and the new key would
> overwrite the key in the {{bootstrap.conf}} file, rendering the first set of
> properties unrecoverable.
> Possible solutions:
> On invocation of the tool, it first tries to read the existing key from
> {{bootstrap.conf}}. If no key is present, operate as normal.
> * Possibly require second entry of the key/password for confirmation to
> ensure it was not mistyped
> If a key *is* present (one of the following):
> * (Derive if necessary and) validate the key against the existing key and if
> it does not match, fail to run
> * Decrypt any existing encrypted properties with the persisted key and
> re-encrypt all sensitive properties with the new key
> The second option does not require the same key/password to be used
> repeatedly and also provides a mechanism for key migration/rollover.
> Another possible error scenario is if the first invocation was run with the
> JCE unlimited strength cryptographic jurisdiction policies not present (so
> the system was limited to 128-bit encryption) and subsequent invocations are
> run with the policies installed (in which case the tool will attempt to use
> 256-bit encryption). The individual properties will be marked with key
> strength available at the time they were encrypted, so this would also
> indicate the second option above is more robust. However, if the opposite
> flow occurs (256-bit available at first invocation, 128-bit subsequently),
> the tool will not be able to decrypt and re-encrypt the existing protected
> properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
