[ https://issues.apache.org/jira/browse/NIFI-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694365#comment-16694365 ]
ASF GitHub Bot commented on NIFI-5833: -------------------------------------- Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/3180#discussion_r235285755 --- Diff: nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/test/groovy/org/apache/nifi/controller/serialization/FlowFromDOMFactoryTest.groovy --- @@ -135,6 +140,83 @@ class FlowFromDOMFactoryTest { assert msg.message =~ "Check that the ${KEY} value in nifi.properties matches the value used to encrypt the flow.xml.gz file" } + @Test + void testShouldDecryptSensitiveFlowValueRegardlessOfPropertySensitiveStatus() throws Exception { + // Arrange + + // Create a mock Element object to be parsed + + // TODO: Mock call to StandardFlowSynchronizer#readFlowFromDisk() + final String FLOW_XML = """<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<flowController encoding-version="1.3"> + <maxTimerDrivenThreadCount>10</maxTimerDrivenThreadCount> + <maxEventDrivenThreadCount>5</maxEventDrivenThreadCount> + <registries/> + <rootGroup> + <id>32aeba59-0167-1000-fc76-847bf5d10d73</id> + <name>NiFi Flow</name> + <position x="0.0" y="0.0"/> + <comment/> + <processor> + <id>32af5e4e-0167-1000-ad5f-c79ff57c851e</id> + <name>Example Processor</name> + <position x="461.0" y="80.0"/> + <styles/> + <comment/> + <class>org.apache.nifi.processors.test.ExampleProcessor</class> + <bundle> + <group>org.apache.nifi</group> + <artifact>nifi-test-nar</artifact> + <version>1.9.0-SNAPSHOT</version> + </bundle> + <maxConcurrentTasks>1</maxConcurrentTasks> + <schedulingPeriod>0 sec</schedulingPeriod> + <penalizationPeriod>30 sec</penalizationPeriod> + <yieldPeriod>1 sec</yieldPeriod> + <bulletinLevel>WARN</bulletinLevel> + <lossTolerant>false</lossTolerant> + <scheduledState>STOPPED</scheduledState> + <schedulingStrategy>TIMER_DRIVEN</schedulingStrategy> + <executionNode>ALL</executionNode> + <runDurationNanos>0</runDurationNanos> + <property> + <name>Plaintext Property</name> + <value>plain value</value> + </property> + <property> + <name>Sensitive Property</name> + <value>enc{29077eedc9af7515cc3e0d2d29a93a5cbb059164876948458fd0c890009c8661}</value> + </property> + </processor> + </rootGroup> + <controllerServices/> + <reportingTasks/> +</flowController> +""" + + // TODO: Mock call to StandardFlowSynchronizer#parseFlowBytes() --- End diff -- Do we still need this TODO comment? > Treat Twitter tokens as sensitive values in GetTwitter > ------------------------------------------------------ > > Key: NIFI-5833 > URL: https://issues.apache.org/jira/browse/NIFI-5833 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions > Affects Versions: 1.8.0 > Reporter: Andy LoPresto > Assignee: Andy LoPresto > Priority: Major > Labels: api, key, properties, security, sensitive, token, twitter > > The {{GetTwitter}} processor marks properties {{Consumer Secret}} and > {{Access Token Secret}} as *sensitive*, but {{Consumer Key}} and {{Access > Token}} are not marked as such. The [Twitter API > documentation|https://developer.twitter.com/en/docs/basics/authentication/guides/securing-keys-and-tokens] > says: > {quote} > Your applications’ API keys should be guarded very closely. They represent > your unique access to the API and if leaked/used by other parties, this could > lead to abuse and restrictions placed on your application. *User access > tokens are even more sensitive*. When access tokens are generated, the user > they represent is trusting your application to keep them secure. If the > security of both API keys and user access tokens are compromised, your > application would potentially expose access to private information and > account functionality. > {quote} > Once the processor code is updated to treat these properties as sensitive, > there may need to be backward-compatibility changes added to ensure that > existing flows and templates do not break when deployed on the "new" system > (following, marked as *1.X*). The following scenarios should be tested: > * 1.8.0 flow (unencrypted {{CK}} and {{AT}}) deployed on 1.X > * 1.8.0 template (unencrypted {{CK}} and {{AT}}) deployed on 1.X > * 1.X flow (encrypted {{CK}} and {{AT}}) deployed on 1.X > * 1.X template (no {{CK}} and {{AT}}) deployed on 1.X > The component documentation should also be appropriately updated to note that > a 1.X flow (encrypted {{CK}} and {{AT}}) will not work (immediately) on a > <=1.8.0 instance. Rather, manual intervention will be required to re-enter > the {{Consumer Key}} and {{Access Token}}, as the processor will attempt to > use the raw value {code} enc{ABCDEF...} {code} from the {{flow.xml.gz}} file > as the literal {{CK}} and {{AT}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)