[ https://issues.apache.org/jira/browse/NIFI-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy LoPresto resolved NIFI-2652. --------------------------------- Resolution: Fixed Fix Version/s: (was: 1.2.0) 1.1.0 > 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.1.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)