[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452899#comment-16452899 ] Mark Payne commented on NIFI-5119: -- OK great, [~jomach], I'm glad that you're able to get everything working as you expected! > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452890#comment-16452890 ] ASF GitHub Bot commented on NIFI-5119: -- Github user jomach commented on the issue: https://github.com/apache/nifi/pull/2656 This is not a issue > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452889#comment-16452889 ] ASF GitHub Bot commented on NIFI-5119: -- Github user jomach closed the pull request at: https://github.com/apache/nifi/pull/2656 > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452886#comment-16452886 ] Jorge Machado commented on NIFI-5119: - [~markap14] So that was really the issue. I was testing with Nifi 1.5.0 and Nifi 1.6.0. I tested it locally on my laptop with Nifi 1.6.0 and it works good. So this is a problem on Nifi 1.5.0 Only. I will close this PR and this is *not* a bug. Thanks all for the support. > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452799#comment-16452799 ] Mark Payne commented on NIFI-5119: -- [~jomach] what version of NiFi are you running into this with? I ask because I believe that NIFI-4920 should have addressed this already. This was part of the latest release only, version 1.6.0. To be honest, I don't understand, off the top of my head, how your PR would change things. With the change, the properties map that is returned would have the sensitive properties, true. However, in the way that it is used, that map is simply passed to the ProcessorNode.setProperties method. Because that method will ignore any property not in the map, it would have the same affect as leaving the property out of the map all together, no? > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452347#comment-16452347 ] Jorge Machado commented on NIFI-5119: - We are using Kerberos and we have 3 nodes on each of the Nifi Instances. I will try that. But From the Code I think there is a bug. Check the StandardProcessorGroup.java# populatePropertiesMap at the end we are returning fullPropertyMap which does not contain the sensitive Information. That's my PR does > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452270#comment-16452270 ] Pierre Villard commented on NIFI-5119: -- I just did the following: * Create a workflow GetFTP (with login/password) -> LogAttribute on NiFi A, and commit as version 1 * Pull on NiFi B the workflow, password is empty as expected, and I set it to mynewpassword * Then I do changes on NiFi A on my workflow: I change the login of my GetFTP, I add processors, etc and commit version 2 * I update to version 2 on NiFi B, password is still set in my GetFTP processor I don't think I'm able to replicate your issue. Since I'm running on master code, it could be something already fixed if you're using older versions. > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452248#comment-16452248 ] Jorge Machado commented on NIFI-5119: - Yes. and when you pull from B if there is sensitive values set they get lost, that's the bug > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452241#comment-16452241 ] Pierre Villard commented on NIFI-5119: -- I'm not sure to understand the use case: why would you perform changes to your flow on both sides? if you have version 1 on B and you want to make some changes, you'd probably do the changes on A, commit version 2, and then pull version 2 on B, no? > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452227#comment-16452227 ] Jorge Machado commented on NIFI-5119: - If you follow the 5 steps that I described on the Ticket you should be able to see it. If you can't let me know and I will take some time to make a video showing it. > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452206#comment-16452206 ] Joseph Witt commented on NIFI-5119: --- [~jomach] Can you please restate what you believe is a bug within the context of the currently supported behaviors? Perhaps you could attach a series of screenshots showing what is happening versus what you believe is the supported/designed behavior. > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452190#comment-16452190 ] Jorge Machado commented on NIFI-5119: - Hi [~joewitt], yes I know we are not there yet. I think we should never save sensitive information into the registry. But the point that I'm trying to make is that Nifi does not Honor the variables that are already set after an update. I created a PR for it but I'm not able to create a unit test for it. If you agree with the PR would be great if someone helped me out with the Unit test for this. For now I marked it as expected Exception > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452180#comment-16452180 ] ASF GitHub Bot commented on NIFI-5119: -- GitHub user jomach opened a pull request: https://github.com/apache/nifi/pull/2656 NIFI-5119: Pulling changes from Registry does not respect sensitive Informations on Destination * Fix missing sensetive information. * missing unit test Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jomach/nifi master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2656.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2656 commit 07f4ccb2cf4f25922ae6f1dade3ff71da9143433 Author: Jorge Machado Date: 2018-04-25T12:37:20Z NIFI-5119 * Fix missing sensetive information. * missing unit test > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5119) Pulling changes from Registry does not respect sensitive Informations on Destination
[ https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452168#comment-16452168 ] Joseph Witt commented on NIFI-5119: --- [~jomach] There is no support as of yet for the concept of a 'sensitive variable' as highlighted here [1]. We do not send the value of a processor/component property to the flow registry if that property is marked sensitive. As a result when importing a versioned flow with sensitive properties on it (regardless of whether those properties point at things from variable registry or not) we cannot pull the values in on the initial import. However, after the initial import and the user enters those sensitive values we can retain and honor them. We can certainly add a way for someone entering variables into the variable registries of a given process group to flag that what they're entering is sensitive, should be encrypted and never displayed in plain text. Things we have to sort out then are what do we do with the encrypted sensitive value when we publish the flow to the flow registry. It will be encrypted on the nifi flow with the key of that nifi instance/cluster. If it were imported to another instance/cluster with a different key (which should be the case) then they'd not be able to decrypt and use it. We could perhaps have a key on the registry side for it to be re-encrypted with that key acting as a broker for ensuring the sensitive value is set. Then re-encrypted on the other flow, etc.. Or we could just say sensitive variables never get published and must be set locally in the respective variable registry instances. We have options but all this needs to be explored and built. Then there is the other matter of how to handle entering sensitive values on component/processor properties when those are actually referencing this new concept of sensitive variables. It is not enough for us to detect an EL statement as there could be multiple EL statements or intermixed EL and static values. We cannot then automatically treat a sensitive property referenced variable as sensitive in the variable reg because it could be used otherwise too, etc.. So, one option here is that we provide an additional entry mode for fields whereby users indicate they want to select a specific variable and then we let them enter/select a single one. This eliminates the ambiguity/etc.. I said all that to point out that we'd love to support this as well but the design/implementation just isnt there. The way to work with it as-is is still a huge step forward and we've not compromised security in doing it. I think this JIRA could be rewritten to reflect these ideas and intent to improve it but it should also be a feature/improvement and not a bug. It is working as designed and we just need to keep improving it. But the concept is certainly not broken and the benefits are huge. [1] https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#show-local-changes > Pulling changes from Registry does not respect sensitive Informations on > Destination > > > Key: NIFI-5119 > URL: https://issues.apache.org/jira/browse/NIFI-5119 > Project: Apache NiFi > Issue Type: Bug > Components: Variable Registry >Affects Versions: 1.5.0, 1.6.0 > Environment: all >Reporter: Jorge Machado >Priority: Major > Fix For: 1.7.0 > > > When pulling changes from registry if a sensitive variable is set then it > gets reset to its default. > I have found out a use case that destroys the complete concept of the > Registry. > # Setup a flow with a sensitive field on Nifi Server A. > # Push that to Registry > # Pull the Flow in Nifi Server B. (this is expected to be reseted because > is the first time) > # Make changes on Nifi Server B and Push > # Pull the changes from Nifi Server A. > > On Step 5 the sensitive Information from Nifi Server A get's deleted. > This breaks the whole concept IMHO. > Relates to : NIFI-5028 -- This message was sent by Atlassian JIRA (v7.6.3#76005)