[
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)
