[jira] [Created] (NIFI-7676) Nifi Processor dynamicallyModifiesClasspath doesn't work
Vijendra Kulhade created NIFI-7676:
--
Summary: Nifi Processor dynamicallyModifiesClasspath doesn't work
Key: NIFI-7676
URL: https://issues.apache.org/jira/browse/NIFI-7676
Project: Apache NiFi
Issue Type: Bug
Components: Configuration
Affects Versions: 1.11.4
Reporter: Vijendra Kulhade
I am trying to pass custom jar to add in the class path for my Custom Processor.
I have used below PropertyDescriptor
{code:java}
static final PropertyDescriptor ADDITIONAL_CLASSPATH_RESOURCES = new
PropertyDescriptor.Builder()
.name("Additional Classpath Resources")
.displayName("Additional Classpath")
.description("A comma-separated list of paths to files and/or
directories that will be added to the classpath and used for loading native
libraries. " +
"When specifying a directory, all files with in the directory
will be added to the classpath, but further sub-directories will not be
included.")
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
.dynamicallyModifiesClasspath(true)
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
.build();
{code}
Also in onTrigger trying to read get the Class like this.
{code:java}
Class cls =
Thread.currentThread().getContextClassLoader().loadClass("CustomerProto");
Method m = cls.getDeclaredMethod("getDefaultInstance");{code}
I am getting ClassNotFoundException.
I tried referring the existing Nifi JoltTransformRecord Processor.
[https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-jolt-record-bundle/nifi-jolt-record-processors/src/main/java/org/apache/nifi/processors/jolt/record/JoltTransformRecord.java#L156]
Tried checking the test cases for this processor
I found that there was no positive test case for dynamicallyModifiesClasspath.
All the test cases are ignoring the custom class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7638) Add PBE AEAD sensitive flow property protection scheme
[
https://issues.apache.org/jira/browse/NIFI-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7638:
Fix Version/s: 1.12.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add PBE AEAD sensitive flow property protection scheme
> --
>
> Key: NIFI-7638
> URL: https://issues.apache.org/jira/browse/NIFI-7638
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration Management, Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: aead, encryption, kdf, pbe, security
> Fix For: 1.12.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> A user requested a change from AES-CBC to AES-G/CM for the
> {{nifi.sensitive.props.algorithm}} in {{nifi.properties}}. The current
> possible values are all {{EncryptionMethod}} enum values, which includes raw
> (directly-keyed vs. PBE) AES-G/CM, but this would require a valid
> hexadecimal-encoded AES key in the {{nifi.sensitive.props.key}} value. One or
> more new {{EncryptionMethod}} entries which combine reasonable default values
> for a KDF (Argon2, bcrypt, scrypt, PBKDF2) and AEAD mode of operation
> (AES-G/CM) would allow for simpler configuration and migration. The other
> option is to enhance the {{EncryptionMethod}} enum values with custom values
> in the {{NiFiProperties}} or {{StringEncryptor}} class which provide an
> additional level of security without modifying the {{EncryptionMethod}} enum
> directly, as the {{EncryptContent}} processor already allows independent
> configuration of a KDF and cipher algorithm (see NIFI-7122 / [PR
> 4228|https://github.com/apache/nifi/pull/4228]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7638) Add PBE AEAD sensitive flow property protection scheme
[
https://issues.apache.org/jira/browse/NIFI-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164709#comment-17164709
]
ASF subversion and git services commented on NIFI-7638:
---
Commit 7d20c03f89358a5d5c6db63e631013e1c4be4bc4 in nifi's branch
refs/heads/main from Andy LoPresto
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=7d20c03 ]
NIFI-7638 Implemented custom nifi.sensitive.props.algorithm for AES-G/CM with
Argon2 KDF.
Added documentation for encryption of flow sensitive values.
Added unit tests.
This closes #4427.
> Add PBE AEAD sensitive flow property protection scheme
> --
>
> Key: NIFI-7638
> URL: https://issues.apache.org/jira/browse/NIFI-7638
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration Management, Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: aead, encryption, kdf, pbe, security
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> A user requested a change from AES-CBC to AES-G/CM for the
> {{nifi.sensitive.props.algorithm}} in {{nifi.properties}}. The current
> possible values are all {{EncryptionMethod}} enum values, which includes raw
> (directly-keyed vs. PBE) AES-G/CM, but this would require a valid
> hexadecimal-encoded AES key in the {{nifi.sensitive.props.key}} value. One or
> more new {{EncryptionMethod}} entries which combine reasonable default values
> for a KDF (Argon2, bcrypt, scrypt, PBKDF2) and AEAD mode of operation
> (AES-G/CM) would allow for simpler configuration and migration. The other
> option is to enhance the {{EncryptionMethod}} enum values with custom values
> in the {{NiFiProperties}} or {{StringEncryptor}} class which provide an
> additional level of security without modifying the {{EncryptionMethod}} enum
> directly, as the {{EncryptContent}} processor already allows independent
> configuration of a KDF and cipher algorithm (see NIFI-7122 / [PR
> 4228|https://github.com/apache/nifi/pull/4228]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7638) Add PBE AEAD sensitive flow property protection scheme
[
https://issues.apache.org/jira/browse/NIFI-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7638:
Status: Patch Available (was: In Progress)
> Add PBE AEAD sensitive flow property protection scheme
> --
>
> Key: NIFI-7638
> URL: https://issues.apache.org/jira/browse/NIFI-7638
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration Management, Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: aead, encryption, kdf, pbe, security
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> A user requested a change from AES-CBC to AES-G/CM for the
> {{nifi.sensitive.props.algorithm}} in {{nifi.properties}}. The current
> possible values are all {{EncryptionMethod}} enum values, which includes raw
> (directly-keyed vs. PBE) AES-G/CM, but this would require a valid
> hexadecimal-encoded AES key in the {{nifi.sensitive.props.key}} value. One or
> more new {{EncryptionMethod}} entries which combine reasonable default values
> for a KDF (Argon2, bcrypt, scrypt, PBKDF2) and AEAD mode of operation
> (AES-G/CM) would allow for simpler configuration and migration. The other
> option is to enhance the {{EncryptionMethod}} enum values with custom values
> in the {{NiFiProperties}} or {{StringEncryptor}} class which provide an
> additional level of security without modifying the {{EncryptionMethod}} enum
> directly, as the {{EncryptContent}} processor already allows independent
> configuration of a KDF and cipher algorithm (see NIFI-7122 / [PR
> 4228|https://github.com/apache/nifi/pull/4228]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [nifi] asfgit closed pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
asfgit closed pull request #4427: URL: https://github.com/apache/nifi/pull/4427 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] alopresto commented on pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
alopresto commented on pull request #4427: URL: https://github.com/apache/nifi/pull/4427#issuecomment-663786904 Thanks all for the reviews. Merging. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] mtien-apache commented on pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
mtien-apache commented on pull request #4427: URL: https://github.com/apache/nifi/pull/4427#issuecomment-663777695 +1 LGTM. Able to run a full build, confirmed I receive the exception message when password is too short or not provided. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (NIFI-7674) Toolkit diagnostic for Cluster configuration
[ https://issues.apache.org/jira/browse/NIFI-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Veda Kadam reassigned NIFI-7674: Assignee: Veda Kadam > Toolkit diagnostic for Cluster configuration > > > Key: NIFI-7674 > URL: https://issues.apache.org/jira/browse/NIFI-7674 > Project: Apache NiFi > Issue Type: Sub-task > Components: Configuration Management, Tools and Build >Affects Versions: 1.11.4 >Reporter: Veda Kadam >Assignee: Veda Kadam >Priority: Major > Labels: cluster, keystore, security, tls, tls-toolkit > > Refer NIFI-7673 for problems addressed. > # Cluster TLS configuration verification > # Priority 1 > # Addresses A, B, C, D, J, K > # Description: Verifies all nodes in the cluster have the ability to verify > and communicate with each other (TLS only) > # Steps > # Run on each node > # Start simple Jetty server using keystore & truststore from nifi.properties > on each node (using API port) > # Possible to run listening on multiple ports (API, CC, S2S, LB) > # Connect to embedded or external ZK and retrieve all cluster node hostnames > # Attempt to ping NiFi hostnames to resolve DNS/validate firewall > # Make simple request from each node to each other node and verify mTLS > # PKIX path building > # Cipher suite availability > # TLS protocol version availability > # Ports open -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-7675) Toolkit diagnostic should verify user provisions and policies
[ https://issues.apache.org/jira/browse/NIFI-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Veda Kadam reassigned NIFI-7675: Assignee: Veda Kadam > Toolkit diagnostic should verify user provisions and policies > - > > Key: NIFI-7675 > URL: https://issues.apache.org/jira/browse/NIFI-7675 > Project: Apache NiFi > Issue Type: Sub-task > Components: Configuration Management, Tools and Build >Affects Versions: 1.11.4 >Reporter: Veda Kadam >Assignee: Veda Kadam >Priority: Major > Labels: permission, policy, security, tls, tls-toolkit, user > > Refer NIFI-7673 for addressed problems. > # Verify user/group provisioning, permissions & policies > # Priority 2 > # Description: Verifies each node has the correct user & group configuration > files, the correct authorizer configuration, and can perform basic authorized > actions > # TBD -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7675) Toolkit diagnostic should verify user provisions and policies
Veda Kadam created NIFI-7675: Summary: Toolkit diagnostic should verify user provisions and policies Key: NIFI-7675 URL: https://issues.apache.org/jira/browse/NIFI-7675 Project: Apache NiFi Issue Type: Sub-task Components: Configuration Management, Tools and Build Affects Versions: 1.11.4 Reporter: Veda Kadam Refer NIFI-7673 for addressed problems. # Verify user/group provisioning, permissions & policies # Priority 2 # Description: Verifies each node has the correct user & group configuration files, the correct authorizer configuration, and can perform basic authorized actions # TBD -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7674) Toolkit diagnostic for Cluster configuration
Veda Kadam created NIFI-7674: Summary: Toolkit diagnostic for Cluster configuration Key: NIFI-7674 URL: https://issues.apache.org/jira/browse/NIFI-7674 Project: Apache NiFi Issue Type: Sub-task Components: Configuration Management, Tools and Build Affects Versions: 1.11.4 Reporter: Veda Kadam Refer NIFI-7673 for problems addressed. # Cluster TLS configuration verification # Priority 1 # Addresses A, B, C, D, J, K # Description: Verifies all nodes in the cluster have the ability to verify and communicate with each other (TLS only) # Steps # Run on each node # Start simple Jetty server using keystore & truststore from nifi.properties on each node (using API port) # Possible to run listening on multiple ports (API, CC, S2S, LB) # Connect to embedded or external ZK and retrieve all cluster node hostnames # Attempt to ping NiFi hostnames to resolve DNS/validate firewall # Make simple request from each node to each other node and verify mTLS # PKIX path building # Cipher suite availability # TLS protocol version availability # Ports open -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-3691) Provide utility to verify configured security settings and certificates
[ https://issues.apache.org/jira/browse/NIFI-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Veda Kadam updated NIFI-3691: - Parent: (was: NIFI-3407) Issue Type: New Feature (was: Sub-task) > Provide utility to verify configured security settings and certificates > --- > > Key: NIFI-3691 > URL: https://issues.apache.org/jira/browse/NIFI-3691 > Project: Apache NiFi > Issue Type: New Feature > Components: Configuration >Reporter: Aldrin Piri >Assignee: Andy LoPresto >Priority: Major > Labels: certificate, keystore, security, tls-toolkit > > It would be helpful to provide a utility that could analyze > keystores/truststores to verify compatibility and expected behavior with > configured security settings such as two way SSL (right hostname, alias, > etc). The idea is that as a diagnostic tool, we could provide users with > some help to verify and troubleshoot any issues that may exist with > certificates outside of more expensive change/restart loops with NiFi. As a > follow-on, it would be helpful to get a listing of key properties about the > configured keystore/truststore or files provided. An extension of this might > additionally setup a client/server test with the utility between instances, > again, to verify correct operation without doing so in NiFi itself as > suggested by the parent ticket. > It would be nice to provide this as part of the NiFi release and accessible > via nifi.sh. By extension, the functionality could also appear in the TLS > toolkit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7673) Toolkit in diagnostic mode should verify independent node
Veda Kadam created NIFI-7673: Summary: Toolkit in diagnostic mode should verify independent node Key: NIFI-7673 URL: https://issues.apache.org/jira/browse/NIFI-7673 Project: Apache NiFi Issue Type: Improvement Components: Configuration Management, Tools and Build Affects Versions: 1.11.4 Reporter: Veda Kadam Assignee: Veda Kadam * Incomplete chain * All nodes have wildcard certificates. Cannot identify one node from the other * Use any certs as long as prerequisites are aligned with NiFi. * Build monitoring for expiration of TLS certificates * Ambari using NiFi CA, overrides/corrupts if using external certs * Populate authorization.xml file if using external certs * Have internal method to avoid removal of authorization.xml and users.xml * Explicit document with prerequisites for certs * --additionalCACertificate for Client-Server model * Validate certs if not using CA toolkit * Firewall/DNS issues resolving multiple nodes in cluster * Independent node configuration verification # Priority 0 # Addresses B, C, D, J # Description: Verifies each node has the correct configuration files and passwords available, and that the key/certificate contents of the keystore and truststore are correct for that node # Steps # Run on each node # Read the nifi.properties file # Verify the keystore and truststore are located at the correct file path # Verify the keystore password, key password, and truststore password are correct # Verify that the keystore contains a single private key entry and a public certificate which identifies this host # CN # SAN # Not wildcard (or at least unique SAN present) # EKU # Certificate validity dates # Key size # Other OIDs # Verify that the truststore contains at least one public certificate # Verify that the truststore contains a public certificate which verifies the private key in the keystore for this node (i.e. this node would trust itself/the signer of itself) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-3691) Provide utility to verify configured security settings and certificates
[ https://issues.apache.org/jira/browse/NIFI-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto reassigned NIFI-3691: --- Assignee: Andy LoPresto > Provide utility to verify configured security settings and certificates > --- > > Key: NIFI-3691 > URL: https://issues.apache.org/jira/browse/NIFI-3691 > Project: Apache NiFi > Issue Type: Sub-task > Components: Configuration >Reporter: Aldrin Piri >Assignee: Andy LoPresto >Priority: Major > Labels: certificate, keystore, security, tls-toolkit > > It would be helpful to provide a utility that could analyze > keystores/truststores to verify compatibility and expected behavior with > configured security settings such as two way SSL (right hostname, alias, > etc). The idea is that as a diagnostic tool, we could provide users with > some help to verify and troubleshoot any issues that may exist with > certificates outside of more expensive change/restart loops with NiFi. As a > follow-on, it would be helpful to get a listing of key properties about the > configured keystore/truststore or files provided. An extension of this might > additionally setup a client/server test with the utility between instances, > again, to verify correct operation without doing so in NiFi itself as > suggested by the parent ticket. > It would be nice to provide this as part of the NiFi release and accessible > via nifi.sh. By extension, the functionality could also appear in the TLS > toolkit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] alopresto commented on a change in pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
alopresto commented on a change in pull request #4427:
URL: https://github.com/apache/nifi/pull/4427#discussion_r460294858
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/encrypt/StringEncryptor.java
##
@@ -267,6 +296,16 @@ private boolean paramsAreValid() {
return algorithmAndProviderValid && secretIsValid;
}
+private boolean customSecretIsValid(PBEKeySpec password, SecretKeySpec
key, String algorithm) {
+// Currently, the only custom algorithms use AES-G/CM with a password
via Argon2
+String rawPassword = new String(password.getPassword());
+final boolean secretIsValid = StringUtils.isNotBlank(rawPassword) &&
rawPassword.trim().length() >= 12;
+if (!secretIsValid) {
+logger.error("The nifi.sensitive.props.key password provided is
invalid for algorithm {}; must be >= 12 characters", algorithm);
Review comment:
Great point Bryan. Fixed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (NIFI-7622) updateParameterContext NullPointerException on StandardProcessGroup.java:4220
[
https://issues.apache.org/jira/browse/NIFI-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7622:
Fix Version/s: 1.12.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> updateParameterContext NullPointerException on StandardProcessGroup.java:4220
> -
>
> Key: NIFI-7622
> URL: https://issues.apache.org/jira/browse/NIFI-7622
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.4
>Reporter: Eric Secules
>Assignee: Bryan Bende
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: Inner_PG.snapshot, Outer_PG.snapshot, Screen Shot
> 2020-07-08 at 11.04.37 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I am getting this null pointer exception when importing one versioned flow
> from a registry which contains another versioned flow and each uses different
> parameter contexts.
> I am using version 1.11.4 of NiFi
> This error is blocking me from developing flows which comprise common
> components and project-specific components that use their own parameter
> contexts.
> Attached a screen cap of the state of the stack at
> StandardProcessGroup.java:4220
> {code:java}
> 2020-07-09 05:33:10,414 ERROR [NiFi Web Server-86]
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred:
> java.lang.NullPointerException. Returning Internal Server Error response.
> java.lang.NullPointerException: null
> at
> org.apache.nifi.groups.StandardProcessGroup.updateParameterContext(StandardProcessGroup.java:4220)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3754)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3653)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO.updateProcessGroupFlow(StandardProcessGroupDAO.java:408)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO$$FastClassBySpringCGLIB$$10a99b47.invoke()
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:736)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:84)
> at
> org.apache.nifi.audit.ProcessGroupAuditor.updateProcessGroupFlowAdvice(ProcessGroupAuditor.java:313)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:671)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO$$EnhancerBySpringCGLIB$$202f172f.updateProcessGroupFlow()
> at
> org.apache.nifi.web.StandardNiFiServiceFacade$14.update(StandardNiFiServiceFacade.java:5044)
> at
>
[jira] [Commented] (NIFI-7622) updateParameterContext NullPointerException on StandardProcessGroup.java:4220
[
https://issues.apache.org/jira/browse/NIFI-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164634#comment-17164634
]
Andy LoPresto commented on NIFI-7622:
-
Thanks for the fix Bryan.
> updateParameterContext NullPointerException on StandardProcessGroup.java:4220
> -
>
> Key: NIFI-7622
> URL: https://issues.apache.org/jira/browse/NIFI-7622
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.4
>Reporter: Eric Secules
>Assignee: Bryan Bende
>Priority: Major
> Attachments: Inner_PG.snapshot, Outer_PG.snapshot, Screen Shot
> 2020-07-08 at 11.04.37 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I am getting this null pointer exception when importing one versioned flow
> from a registry which contains another versioned flow and each uses different
> parameter contexts.
> I am using version 1.11.4 of NiFi
> This error is blocking me from developing flows which comprise common
> components and project-specific components that use their own parameter
> contexts.
> Attached a screen cap of the state of the stack at
> StandardProcessGroup.java:4220
> {code:java}
> 2020-07-09 05:33:10,414 ERROR [NiFi Web Server-86]
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred:
> java.lang.NullPointerException. Returning Internal Server Error response.
> java.lang.NullPointerException: null
> at
> org.apache.nifi.groups.StandardProcessGroup.updateParameterContext(StandardProcessGroup.java:4220)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3754)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3653)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO.updateProcessGroupFlow(StandardProcessGroupDAO.java:408)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO$$FastClassBySpringCGLIB$$10a99b47.invoke()
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:736)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:84)
> at
> org.apache.nifi.audit.ProcessGroupAuditor.updateProcessGroupFlowAdvice(ProcessGroupAuditor.java:313)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:671)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO$$EnhancerBySpringCGLIB$$202f172f.updateProcessGroupFlow()
> at
> org.apache.nifi.web.StandardNiFiServiceFacade$14.update(StandardNiFiServiceFacade.java:5044)
> at
> org.apache.nifi.web.revision.NaiveRevisionManager.updateRevision(NaiveRevisionManager.java:117)
> at
>
[GitHub] [nifi] asfgit closed pull request #4401: NIFI-7622 Use param context name from inside nested versioned PG when…
asfgit closed pull request #4401: URL: https://github.com/apache/nifi/pull/4401 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] bbende commented on a change in pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
bbende commented on a change in pull request #4427:
URL: https://github.com/apache/nifi/pull/4427#discussion_r460291793
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/encrypt/StringEncryptor.java
##
@@ -267,6 +296,16 @@ private boolean paramsAreValid() {
return algorithmAndProviderValid && secretIsValid;
}
+private boolean customSecretIsValid(PBEKeySpec password, SecretKeySpec
key, String algorithm) {
+// Currently, the only custom algorithms use AES-G/CM with a password
via Argon2
+String rawPassword = new String(password.getPassword());
+final boolean secretIsValid = StringUtils.isNotBlank(rawPassword) &&
rawPassword.trim().length() >= 12;
+if (!secretIsValid) {
+logger.error("The nifi.sensitive.props.key password provided is
invalid for algorithm {}; must be >= 12 characters", algorithm);
Review comment:
Just to clarify, we do print this first
```
2020-07-24 17:12:31,384 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
*A blank sensitive properties key was provided *
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
* Specify a unique key in nifi.properties*
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
* for nifi.sensitive.props.key *
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
* *
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
*The Encrypt Config Tool in NiFi Toolkit can be used to*
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
* migrate the flow to the new key*
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
2020-07-24 17:12:31,385 ERROR [main] org.apache.nifi.encrypt.StringEncryptor
The nifi.sensitive.props.key password provided is invalid for algorithm
NIFI_ARGON2_AES_GCM_256; must be >= 12 characters
```
but then after there are two stacktraces that I think overshadow this and
don't have any specifics.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (NIFI-7622) updateParameterContext NullPointerException on StandardProcessGroup.java:4220
[
https://issues.apache.org/jira/browse/NIFI-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164633#comment-17164633
]
ASF subversion and git services commented on NIFI-7622:
---
Commit 5cb8d246899df914781001415d0e155f90ef6ed3 in nifi's branch
refs/heads/main from Bryan Bende
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5cb8d24 ]
NIFI-7622 Use param context name from inside nested versioned PG when importing
This closes #4401.
Signed-off-by: Andy LoPresto
> updateParameterContext NullPointerException on StandardProcessGroup.java:4220
> -
>
> Key: NIFI-7622
> URL: https://issues.apache.org/jira/browse/NIFI-7622
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.4
>Reporter: Eric Secules
>Assignee: Bryan Bende
>Priority: Major
> Attachments: Inner_PG.snapshot, Outer_PG.snapshot, Screen Shot
> 2020-07-08 at 11.04.37 PM.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I am getting this null pointer exception when importing one versioned flow
> from a registry which contains another versioned flow and each uses different
> parameter contexts.
> I am using version 1.11.4 of NiFi
> This error is blocking me from developing flows which comprise common
> components and project-specific components that use their own parameter
> contexts.
> Attached a screen cap of the state of the stack at
> StandardProcessGroup.java:4220
> {code:java}
> 2020-07-09 05:33:10,414 ERROR [NiFi Web Server-86]
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred:
> java.lang.NullPointerException. Returning Internal Server Error response.
> java.lang.NullPointerException: null
> at
> org.apache.nifi.groups.StandardProcessGroup.updateParameterContext(StandardProcessGroup.java:4220)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3754)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.addProcessGroup(StandardProcessGroup.java:4324)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateProcessGroup(StandardProcessGroup.java:3876)
> at
> org.apache.nifi.groups.StandardProcessGroup.updateFlow(StandardProcessGroup.java:3653)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO.updateProcessGroupFlow(StandardProcessGroupDAO.java:408)
> at
> org.apache.nifi.web.dao.impl.StandardProcessGroupDAO$$FastClassBySpringCGLIB$$10a99b47.invoke()
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:736)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:84)
> at
> org.apache.nifi.audit.ProcessGroupAuditor.updateProcessGroupFlowAdvice(ProcessGroupAuditor.java:313)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:671)
> at
>
[GitHub] [nifi] alopresto commented on pull request #4401: NIFI-7622 Use param context name from inside nested versioned PG when…
alopresto commented on pull request #4401: URL: https://github.com/apache/nifi/pull/4401#issuecomment-663737262 Verified both the existing negative behavior using the 0.7.0 RC1 (steps described in Jira) and the fix after applying the PR. Ran `contrib-check` and all tests pass. +1, merging. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] bbende commented on a change in pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
bbende commented on a change in pull request #4427:
URL: https://github.com/apache/nifi/pull/4427#discussion_r460290036
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/encrypt/StringEncryptor.java
##
@@ -267,6 +296,16 @@ private boolean paramsAreValid() {
return algorithmAndProviderValid && secretIsValid;
}
+private boolean customSecretIsValid(PBEKeySpec password, SecretKeySpec
key, String algorithm) {
+// Currently, the only custom algorithms use AES-G/CM with a password
via Argon2
+String rawPassword = new String(password.getPassword());
+final boolean secretIsValid = StringUtils.isNotBlank(rawPassword) &&
rawPassword.trim().length() >= 12;
+if (!secretIsValid) {
+logger.error("The nifi.sensitive.props.key password provided is
invalid for algorithm {}; must be >= 12 characters", algorithm);
Review comment:
This message is really helpful for the user to know the problem. One
minor issue is that the exception that prints to the log doesn't end up
including this, it just ends with:
```
Caused by: org.apache.nifi.encrypt.EncryptionException: Cannot initialize
the StringEncryptor because some configuration values are invalid
at
org.apache.nifi.encrypt.StringEncryptor.initialize(StringEncryptor.java:270)
at
org.apache.nifi.encrypt.StringEncryptor.(StringEncryptor.java:137)
at
org.apache.nifi.encrypt.StringEncryptor.createEncryptor(StringEncryptor.java:236)
at
org.apache.nifi.encrypt.StringEncryptor.createEncryptor(StringEncryptor.java:209)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
... 58 common frames omitted
```
Was wondering if we could get that same message into the exception so its
not missed and is clear what needs to be fixed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] alopresto commented on pull request #4377: NIFI-7568 - Fixing Kerberos mappings
alopresto commented on pull request #4377: URL: https://github.com/apache/nifi/pull/4377#issuecomment-663720866 Closing this issue as it is OBE (PR 4416). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] alopresto closed pull request #4377: NIFI-7568 - Fixing Kerberos mappings
alopresto closed pull request #4377: URL: https://github.com/apache/nifi/pull/4377 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-7568) Ensure Kerberos mappings are applied correctly
[ https://issues.apache.org/jira/browse/NIFI-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7568: Resolution: Fixed Status: Resolved (was: Patch Available) > Ensure Kerberos mappings are applied correctly > -- > > Key: NIFI-7568 > URL: https://issues.apache.org/jira/browse/NIFI-7568 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.11.4 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.12.0 > > Time Spent: 5h > Remaining Estimate: 0h > > Kerberos mappings are not being applied consistently across user actions/JWT > authentication token creation. Ensure that the mappings are applied in all > instances, to ensure that the user database stores a mapped ID. Ensure login > and logout tokens utilize the mapped identity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7568) Ensure Kerberos mappings are applied correctly
[ https://issues.apache.org/jira/browse/NIFI-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7568: Status: Patch Available (was: Open) > Ensure Kerberos mappings are applied correctly > -- > > Key: NIFI-7568 > URL: https://issues.apache.org/jira/browse/NIFI-7568 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.11.4 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.12.0 > > Time Spent: 5h > Remaining Estimate: 0h > > Kerberos mappings are not being applied consistently across user actions/JWT > authentication token creation. Ensure that the mappings are applied in all > instances, to ensure that the user database stores a mapped ID. Ensure login > and logout tokens utilize the mapped identity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7568) Ensure Kerberos mappings are applied correctly
[ https://issues.apache.org/jira/browse/NIFI-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164621#comment-17164621 ] ASF subversion and git services commented on NIFI-7568: --- Commit d846a74730edb4d142e0a3051c60e9fec33f1f09 in nifi's branch refs/heads/main from Nathan Gough [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=d846a74 ] NIFI-7568 - Applied Kerberos mappings to authentication requests. Kerberos mappings should now be applied correctly in H2 database for username/password based login. Added tests. Logout now deletes signing key by key ID rather than identity. Validate token expiration now uses mapped identity instead, which allows logging of the mapped identity. Updated delete key to expect only 0 or 1 keys deleted. This closes #4416. Signed-off-by: Andy LoPresto > Ensure Kerberos mappings are applied correctly > -- > > Key: NIFI-7568 > URL: https://issues.apache.org/jira/browse/NIFI-7568 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.11.4 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.12.0 > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Kerberos mappings are not being applied consistently across user actions/JWT > authentication token creation. Ensure that the mappings are applied in all > instances, to ensure that the user database stores a mapped ID. Ensure login > and logout tokens utilize the mapped identity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] asfgit closed pull request #4416: NIFI-7568 - Ensure Kerberos mappings are applied correctly
asfgit closed pull request #4416: URL: https://github.com/apache/nifi/pull/4416 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] alopresto commented on pull request #4416: NIFI-7568 - Ensure Kerberos mappings are applied correctly
alopresto commented on pull request #4416: URL: https://github.com/apache/nifi/pull/4416#issuecomment-663714004 Also a +1 on this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-7325) Refactor EncryptContent to allow KDFs for raw algorithms
[ https://issues.apache.org/jira/browse/NIFI-7325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7325: Fix Version/s: 1.12.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Refactor EncryptContent to allow KDFs for raw algorithms > > > Key: NIFI-7325 > URL: https://issues.apache.org/jira/browse/NIFI-7325 > Project: Apache NiFi > Issue Type: Sub-task > Components: Security >Affects Versions: 1.11.1 >Reporter: M Tien >Assignee: Andy LoPresto >Priority: Major > Labels: kdf, security > Fix For: 1.12.0 > > > Refactor EncryptContent to allow KDFs for raw algorithms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7323) Introduce Argon2 Cipher Provider
[
https://issues.apache.org/jira/browse/NIFI-7323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7323:
Fix Version/s: 1.12.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Introduce Argon2 Cipher Provider
>
>
> Key: NIFI-7323
> URL: https://issues.apache.org/jira/browse/NIFI-7323
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework, Security
>Affects Versions: 1.11.1
>Reporter: M Tien
>Assignee: Andy LoPresto
>Priority: Major
> Labels: hashing, refactor, security
> Fix For: 1.12.0
>
>
> Introduce Argon2 Cipher Provider and implement in {{*CipherProvider}} classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7122) Refactor existing KDF implementations to use SecureHasher interface
[
https://issues.apache.org/jira/browse/NIFI-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7122:
Fix Version/s: 1.12.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Refactor existing KDF implementations to use SecureHasher interface
> ---
>
> Key: NIFI-7122
> URL: https://issues.apache.org/jira/browse/NIFI-7122
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Security
>Affects Versions: 1.11.1
>Reporter: Andy LoPresto
>Assignee: M Tien
>Priority: Major
> Labels: hashing, kdf, refactor, security
> Fix For: 1.12.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The existing KDF implementations ({{bcrypt}}, {{scrypt}}, and {{PBKDF2}}) in
> the {{*CipherProvider}} classes should be refactored to provide
> algorithm-specific {{*SecureHasher}} implementations and then have the
> hashing logic delegated from the respective cipher provider objects to the
> hasher.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [nifi] alopresto commented on a change in pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
alopresto commented on a change in pull request #4427:
URL: https://github.com/apache/nifi/pull/4427#discussion_r460260816
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/encrypt/StringEncryptor.java
##
@@ -408,27 +468,34 @@ public String decrypt(String cipherText) throws
EncryptionException {
private byte[] decryptPBE(byte[] cipherBytes) {
PBECipherProvider pbecp = (PBECipherProvider) cipherProvider;
-final EncryptionMethod encryptionMethod =
EncryptionMethod.forAlgorithm(algorithm);
+final EncryptionMethod encryptionMethod =
getEncryptionMethodForAlgorithm(algorithm);
// Extract salt
-int saltLength = CipherUtility.getSaltLengthForAlgorithm(algorithm);
+int saltLength = determineSaltLength(algorithm);
byte[] salt = new byte[saltLength];
System.arraycopy(cipherBytes, 0, salt, 0, saltLength);
-byte[] actualCipherBytes = Arrays.copyOfRange(cipherBytes, saltLength,
cipherBytes.length);
+// Read IV if necessary (allows for future use of Argon2, PBKDF2,
Bcrypt, or Scrypt)
+byte[] ivBytes = new byte[0];
Review comment:
The instantiation of the `byte[0]` is just to simplify the code which
concatenates all the byte arrays below -- rather than having duplicate logic
for IV present/not, it just appends the array whether it is populated or empty.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] alopresto commented on a change in pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
alopresto commented on a change in pull request #4427:
URL: https://github.com/apache/nifi/pull/4427#discussion_r460260432
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/encrypt/StringEncryptor.java
##
@@ -408,27 +468,34 @@ public String decrypt(String cipherText) throws
EncryptionException {
private byte[] decryptPBE(byte[] cipherBytes) {
PBECipherProvider pbecp = (PBECipherProvider) cipherProvider;
-final EncryptionMethod encryptionMethod =
EncryptionMethod.forAlgorithm(algorithm);
+final EncryptionMethod encryptionMethod =
getEncryptionMethodForAlgorithm(algorithm);
// Extract salt
-int saltLength = CipherUtility.getSaltLengthForAlgorithm(algorithm);
+int saltLength = determineSaltLength(algorithm);
byte[] salt = new byte[saltLength];
System.arraycopy(cipherBytes, 0, salt, 0, saltLength);
-byte[] actualCipherBytes = Arrays.copyOfRange(cipherBytes, saltLength,
cipherBytes.length);
+// Read IV if necessary (allows for future use of Argon2, PBKDF2,
Bcrypt, or Scrypt)
+byte[] ivBytes = new byte[0];
Review comment:
The actual `ivBytes` array is only instantiated when the algorithm
dictates a random IV. For 99.9% of users, this won't be the case and so it
makes sense not to instantiate it at all.
For users who select one of the custom algorithms, the `byte[16]` is
instantiated and filled with a random value, but this happens every time and is
intentionally unique on each invocation, so pre-allocating wouldn't gain
anything unless I am missing your concern.
The size of the object to be encrypted is independent of the IV size -- the
IV is always 0 or 16 bytes depending solely on the algorithm.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] joewitt commented on a change in pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
joewitt commented on a change in pull request #4427:
URL: https://github.com/apache/nifi/pull/4427#discussion_r460253175
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/encrypt/StringEncryptor.java
##
@@ -408,27 +468,34 @@ public String decrypt(String cipherText) throws
EncryptionException {
private byte[] decryptPBE(byte[] cipherBytes) {
PBECipherProvider pbecp = (PBECipherProvider) cipherProvider;
-final EncryptionMethod encryptionMethod =
EncryptionMethod.forAlgorithm(algorithm);
+final EncryptionMethod encryptionMethod =
getEncryptionMethodForAlgorithm(algorithm);
// Extract salt
-int saltLength = CipherUtility.getSaltLengthForAlgorithm(algorithm);
+int saltLength = determineSaltLength(algorithm);
byte[] salt = new byte[saltLength];
System.arraycopy(cipherBytes, 0, salt, 0, saltLength);
-byte[] actualCipherBytes = Arrays.copyOfRange(cipherBytes, saltLength,
cipherBytes.length);
+// Read IV if necessary (allows for future use of Argon2, PBKDF2,
Bcrypt, or Scrypt)
+byte[] ivBytes = new byte[0];
Review comment:
maybe it isn't worth the effort. by preallocating a 16 byte array to
reuse over and over seems like it would perform quite well and relax GC
pressure particularly in the event of larger objects. am I overthinking that
one?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] alopresto commented on pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
alopresto commented on pull request #4427: URL: https://github.com/apache/nifi/pull/4427#issuecomment-663699812 This PR is ready for review & merge. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-7122) Refactor existing KDF implementations to use SecureHasher interface
[
https://issues.apache.org/jira/browse/NIFI-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164606#comment-17164606
]
ASF subversion and git services commented on NIFI-7122:
---
Commit eeeda844747207102711cc2caad4c9a93982371a in nifi's branch
refs/heads/main from Andy LoPresto
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=eeeda84 ]
NIFI-7122 Introduced improvements to EncryptContent processor.
Added unit tests.
Refactored shared logic from various algorithm-specific secure hasher
implementations to AbstractSecureHasher.
Introduced secure hasher implementations for various KDFs.
Added custom validation to EncryptContent processor.
Implemented logic for EncryptContent to write operational metadata to flowfile
attributes.
Added encryption metadata attribute annotations to EncryptContent.
Added Argon2 KDF documentation and Bcrypt key derivation change notes to Admin
Guide.
Updated unit tests to calculate default/recommended cost parameters for Argon2.
This closes #4421.
Co-authored-by: mtien
> Refactor existing KDF implementations to use SecureHasher interface
> ---
>
> Key: NIFI-7122
> URL: https://issues.apache.org/jira/browse/NIFI-7122
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Security
>Affects Versions: 1.11.1
>Reporter: Andy LoPresto
>Assignee: M Tien
>Priority: Major
> Labels: hashing, kdf, refactor, security
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The existing KDF implementations ({{bcrypt}}, {{scrypt}}, and {{PBKDF2}}) in
> the {{*CipherProvider}} classes should be refactored to provide
> algorithm-specific {{*SecureHasher}} implementations and then have the
> hashing logic delegated from the respective cipher provider objects to the
> hasher.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [nifi] asfgit closed pull request #4421: NIFI-7122 Introduced improvements to EncryptContent processor.
asfgit closed pull request #4421: URL: https://github.com/apache/nifi/pull/4421 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] alopresto commented on pull request #4421: NIFI-7122 Introduced improvements to EncryptContent processor.
alopresto commented on pull request #4421: URL: https://github.com/apache/nifi/pull/4421#issuecomment-663674129 Thanks mtien. I'm going to merge this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-7672) Some controller services not enabled when calling /flow/process-groups/{id}/controller-services
[
https://issues.apache.org/jira/browse/NIFI-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Bende updated NIFI-7672:
--
Status: Patch Available (was: Open)
> Some controller services not enabled when calling
> /flow/process-groups/{id}/controller-services
> ---
>
> Key: NIFI-7672
> URL: https://issues.apache.org/jira/browse/NIFI-7672
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.4
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a process group has any services that are invalid only because a dependent
> service is disabled, these invalid services never get enabled when calling
> _/flow/process-groups/\{id}/controller-services_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [nifi] bbende opened a new pull request #4429: NIFI-7672 Remove filtering of invalid components when getting service…
bbende opened a new pull request #4429:
URL: https://github.com/apache/nifi/pull/4429
… ids to enable, lower layers will already skip enabling invalid services,
so we want to include services that may become valid when enabling their
dependent services
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Enables X functionality; fixes bug 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 `main`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### 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?
- [ ] Have you verified that the full build is successful on JDK 8?
- [ ] Have you verified that the full build is successful on JDK 11?
- [ ] 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 GitHub Actions CI for
build issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] mattyb149 commented on a change in pull request #4376: NIFI-7592: Allow NiFi to be started without a GUI/REST interface
mattyb149 commented on a change in pull request #4376:
URL: https://github.com/apache/nifi/pull/4376#discussion_r460155636
##
File path: nifi-server-api/src/main/java/org/apache/nifi/NiFiServer.java
##
@@ -33,6 +34,10 @@
void setBundles(Bundle systemBundle, Set bundles);
+void setNiFiProperties(NiFiProperties properties);
+
+default void init() {}
Review comment:
Makes sense, the `setBundles` method was already there so I just kept
the approach consistent, but since they're all called in the same place
(including `setExtensionMapping`), I can just move everything to a single
`initialize` method.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] hunyadi-dev commented on a change in pull request #849: MINIFICPP-1261 - Mark ScopeGuard class deprecated
hunyadi-dev commented on a change in pull request #849:
URL: https://github.com/apache/nifi-minifi-cpp/pull/849#discussion_r460144896
##
File path: extensions/opc/src/opc.cpp
##
@@ -302,7 +303,7 @@ void Client::traverse(UA_NodeId nodeId,
std::function cb,
UA_BrowseResponse bResp = UA_Client_Service_browse(client_, bReq);
- utils::ScopeGuard guard([]() {
+ gsl::finally guard([]() {
Review comment:
Oh, I see, will correct it. I wonder why my replacement did not produce
syntax errors locally though.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (NIFI-7672) Some controller services not enabled when calling /flow/process-groups/{id}/controller-services
Bryan Bende created NIFI-7672:
-
Summary: Some controller services not enabled when calling
/flow/process-groups/{id}/controller-services
Key: NIFI-7672
URL: https://issues.apache.org/jira/browse/NIFI-7672
Project: Apache NiFi
Issue Type: Bug
Affects Versions: 1.11.4
Reporter: Bryan Bende
Assignee: Bryan Bende
If a process group has any services that are invalid only because a dependent
service is disabled, these invalid services never get enabled when calling
_/flow/process-groups/\{id}/controller-services_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [nifi-minifi-cpp] szaszm commented on a change in pull request #849: MINIFICPP-1261 - Mark ScopeGuard class deprecated
szaszm commented on a change in pull request #849:
URL: https://github.com/apache/nifi-minifi-cpp/pull/849#discussion_r460123115
##
File path: extensions/opc/src/opc.cpp
##
@@ -302,7 +303,7 @@ void Client::traverse(UA_NodeId nodeId,
std::function cb,
UA_BrowseResponse bResp = UA_Client_Service_browse(client_, bReq);
- utils::ScopeGuard guard([]() {
+ gsl::finally guard([]() {
Review comment:
`gsl::finally` is a function, not a type.
```suggestion
const auto guard = gsl::finally([] {
```
https://github.com/gsl-lite/gsl-lite/blob/master/include/gsl/gsl-lite.hpp#L1377
https://github.com/microsoft/GSL/blob/master/include/gsl/gsl_util#L68
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a change in pull request #849: MINIFICPP-1261 - Mark ScopeGuard class deprecated
szaszm commented on a change in pull request #849:
URL: https://github.com/apache/nifi-minifi-cpp/pull/849#discussion_r460123115
##
File path: extensions/opc/src/opc.cpp
##
@@ -302,7 +303,7 @@ void Client::traverse(UA_NodeId nodeId,
std::function cb,
UA_BrowseResponse bResp = UA_Client_Service_browse(client_, bReq);
- utils::ScopeGuard guard([]() {
+ gsl::finally guard([]() {
Review comment:
`gsl::finally` is a function, not a type.
```suggestion
const auto guard = gsl::finally([] {
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a change in pull request #845: MINIFICPP-1277 - Create cross-platform API for querying memory usage
szaszm commented on a change in pull request #845:
URL: https://github.com/apache/nifi-minifi-cpp/pull/845#discussion_r459425267
##
File path: libminifi/src/utils/OsUtils.cpp
##
@@ -154,6 +160,80 @@ std::string OsUtils::userIdToUsername(const std::string
) {
return name;
}
+unsigned long long OsUtils::getMemoryUsage() {
+#ifdef __linux__
+ long resPages;
+ long sharedPages;
+ {
+std::string ignore;
+std::ifstream ifs("/proc/self/statm");
+ifs >> ignore >> resPages >> sharedPages;
+ }
+
+ if (sharedPages > resPages) {
+throw std::range_error("Shared memory page count ("
+ + std::to_string(sharedPages)
+ + ") should not be larger than resident set size ("
+ + std::to_string(resPages)
+ + "), that includes it"
+);
+ }
+
+ const long ownPages = resPages - sharedPages;
Review comment:
+1 for no `long`. If you need a 64 bit integer, why not make it explicit
by using `int64_t`?
https://google.github.io/styleguide/cppguide.html#Integer_Types
Other issue: I believe `statm` doesn't make a difference between normal
pages and hugepages, so while the number may be correct as the number of pages,
multiplying it with the default page size might yield an incorrect "memory
usage".
https://stackoverflow.com/questions/1558402/memory-usage-of-current-process-in-c#comment93410400_7212248
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] simonbence commented on pull request #4420: NIFI-7429 Adding status history for system level metrics
simonbence commented on pull request #4420: URL: https://github.com/apache/nifi/pull/4420#issuecomment-663589327 Thanks for the feedback @pvillard31 ! I fixed the order of the metrics. This is something was working the same semi-random way with other history panels as well. Now it orders based on "ordinal" of the metrics. Looks much more organized I also added the thread metrics you were asking for. I found no way to add multiple lines for the diagrams without serious refactors, so I hope it will meet your expectations the way it is. Furthermore I added detailed metrics about the given repositories as well (not only a summary for the given types) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] MikeThomsen opened a new pull request #4428: NIFI-7605 Removed user-agent default value so no header will be sent …
MikeThomsen opened a new pull request #4428:
URL: https://github.com/apache/nifi/pull/4428
…by default.
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Enables X functionality; fixes bug 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 `main`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### 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?
- [ ] Have you verified that the full build is successful on JDK 8?
- [ ] Have you verified that the full build is successful on JDK 11?
- [ ] 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 GitHub Actions CI for
build issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MINIFICPP-1261) Deprecate obsolete ScopeGuard class
[ https://issues.apache.org/jira/browse/MINIFICPP-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi updated MINIFICPP-1261: Description: *Background:* With the introduction of the gsl support library, we ported tools that work as sufficient substitute for scope guards. *Proposal:* Replace ScopeGuard objects with unique_ptrs and gsl::final_action objects. was: *Background:* With the introduction of the gsl support library, we ported tools that work as sufficient substitute for scope guards. *Proposal:* Replace ScopeGuard objects with unique_ptrs and gsl::final_action objects. > Deprecate obsolete ScopeGuard class > --- > > Key: MINIFICPP-1261 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1261 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: 0.7.0 >Reporter: Adam Hunyadi >Assignee: Adam Hunyadi >Priority: Minor > Labels: MiNiFi-CPP-Hygiene > Fix For: 0.8.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > *Background:* > With the introduction of the gsl support library, we ported tools that work > as sufficient substitute for scope guards. > *Proposal:* > Replace ScopeGuard objects with unique_ptrs and gsl::final_action objects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi-minifi-cpp] hunyadi-dev opened a new pull request #849: MINIFICPP-1261 - Mark ScopeGuard class deprecated
hunyadi-dev opened a new pull request #849: URL: https://github.com/apache/nifi-minifi-cpp/pull/849 Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. 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 MINIFICPP- 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: - [ ] 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? - [ ] If applicable, have you updated the NOTICE file? ### 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. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MINIFICPP-1261) Deprecate obsolete ScopeGuard class
[ https://issues.apache.org/jira/browse/MINIFICPP-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi updated MINIFICPP-1261: Summary: Deprecate obsolete ScopeGuard class (was: Remove obsolete ScopeGuard class) > Deprecate obsolete ScopeGuard class > --- > > Key: MINIFICPP-1261 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1261 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: 0.7.0 >Reporter: Adam Hunyadi >Assignee: Adam Hunyadi >Priority: Minor > Labels: MiNiFi-CPP-Hygiene > Fix For: 0.8.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > *Background:* > With the introduction of the gsl support library, we ported tools that work > as sufficient substitute for scope guards. > > *Proposal:* > Replace ScopeGuard objects with unique_ptrs and gsl::final_action objects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-6875) Nifi Zookeeper Cluster_Mode broken in 1.10.0
[ https://issues.apache.org/jira/browse/NIFI-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164269#comment-17164269 ] Jens M Kofoed commented on NIFI-6875: - I am running a single node cluster with nifi 1.11.4 and a 3 node external zookeeper cluster with zookeeper 3.6.1. I have experienced the same problem. I restarted my 3 zookeeper nodes and my nifi server start filling up the log. Abount 101MB logs within 90 seconds. The disk can be filled up very quickly, so now I have disabled the "org.apache.curator.framework.imps.CuratorFrameworkImpl" in the logback file. > Nifi Zookeeper Cluster_Mode broken in 1.10.0 > > > Key: NIFI-6875 > URL: https://issues.apache.org/jira/browse/NIFI-6875 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Flow Versioning >Affects Versions: 1.10.0 > Environment: Kubernetes, Linux >Reporter: Glenn Wolfe >Priority: Blocker > Labels: bug, cluster-mode, kubernetes > > Expected: Exact same configuration and setup works perfectly on prior version > (1.9.2), as soon as I upgrade version, NIfi is unable to initialize. > > With external zookeeper (cluster_mode) configuration, Nifi is unable to > successfully elect leader and stuck in 'Invalid State: The Flow Controller is > initializing the Data Flow'. > > Logs: (Stuck in Loop) > ``` > 2019-11-15 17:00:05,991 INFO [main-EventThread] > o.a.c.f.state.ConnectionStateManager State change: RECONNECTED > 2019-11-15 17:00:05,991 INFO [Curator-ConnectionStateManager-0] > o.a.n.c.l.e.CuratorLeaderElectionManager > org.apache.nifi.controller.leader.election.CuratorLeaderElectionManager$ElectionListener@256c961a > Connection State changed to RECONNECTED > 2019-11-15 17:00:06,092 INFO [main-EventThread] > o.a.c.f.state.ConnectionStateManager State change: SUSPENDED > 2019-11-15 17:00:06,092 WARN [main] o.a.nifi.controller.StandardFlowService > There is currently no Cluster Coordinator. This often happens upon restart of > NiFi when running an embedded ZooKeeper. Will register this node to become > the active Cluster Coordinator and will attempt to connect to cluster again > 2019-11-15 17:00:06,093 INFO [main] o.a.n.c.l.e.CuratorLeaderElectionManager > CuratorLeaderElectionManager[stopped=false] Attempted to register Leader > Election for role 'Cluster Coordinator' but this role is already registered > ``` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINIFICPP-1203) Set up cpplint so that it can be configured per-directory
[
https://issues.apache.org/jira/browse/MINIFICPP-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Hunyadi updated MINIFICPP-1203:
Description:
*Background:*
Currently cpplink checks are not checking all the files correctly and are
hiding some errors that are meant to be displayed. Manually running the
following cpplint check shows overreports the number of errors but it is a
decent estimate on the number of errors ignored:
{code:bash}
# This command shows some errors that we otherwise suppress in the project
cpplint --linelength=200
filter=-runtime/reference,-runtime/string,-build/c++11,-build/include_order,-build/include_alpha
`find libminifi/ -name \.cpp -o -name \*.h`
(...)
Total errors found: 1730
{code}
When running {{{color:#403294}{{make linter}}{color}}} these errors are
supressed. It runs the following command in
{{{color:#403294}run_linter.sh{color}}}:
{code:bash}
python ${SCRIPT_DIR}/cpplint.py --linelength=200 --headers=${HEADERS} ${SOURCES}
{code}
For some reason, it seems like the files specified in the
{{{color:#403294}{{--headers}}{color}}} flag are ignored altogether. For example
{code:bash}
# Running w/ headers option set
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 --headers=`find . -name "*.h" | tr '\n' ','`
libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
# Running w/ unspecified headers
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
Total errors found: 6
{code}
*Proposal:*
We should remove the header specification from {{{color:#403294}{{make
linter}}{color}}} and set up linter configuration files in the project
directories that set all the rules to be applied on the specific directory
contents recursively.
There is to approach for doing this: we can either specify files or rules to be
ignored when doing the linter check. The latter is preferable, so that when we
want to clear them up later, we can have separate commits/pull request for each
of the warning fixed (and potentially automatize fixes (eg. writing clang-tidy
rules or applying linter fixes).
(!) The commits on this Jira are not expected to fix any warnings reported by
the linter, but to have all the checks disabled.
*Update:*
We decided to replace header guards with {{{color:#403294}{{#pragma
once}}{color}}}. It is not standardized, but all the compilers we support have
it, and we already have it scattered in our headers, so we can consider this
update safe. This is now extracted into its own Jira (see related).
was:
*Background:*
Currently cpplink checks are not checking all the files correctly and are
hiding some errors that are meant to be displayed. Manually running the
following cpplint check shows overreports the number of errors but it is a
decent estimate on the number of errors ignored:
{code:bash}
# This command shows some errors that we otherwise suppress in the project
cpplint --linelength=200
filter=-runtime/reference,-runtime/string,-build/c++11,-build/include_order,-build/include_alpha
`find libminifi/ -name \.cpp -o -name \*.h`
(...)
Total errors found: 1730
{code}
When running {{{color:#403294}{{make linter}}{color}}} these errors are
supressed. It runs the following command in
{{{color:#403294}run_linter.sh{color}}}:
{code:bash}
python ${SCRIPT_DIR}/cpplint.py --linelength=200 --headers=${HEADERS} ${SOURCES}
{code}
For some reason, it seems like the files specified in the
{{{color:#403294}{{--headers}}{color}}} flag are ignored altogether. For example
{code:bash}
# Running w/ headers option set
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 --headers=`find . -name "*.h" | tr '\n' ','`
libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
# Running w/ unspecified headers
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
Total errors found: 6
{code}
*Proposal:*
We should remove the header specification from {{{color:#403294}{{make
linter}}{color}}} and set up linter configuration files in the project
directories that set all the rules to be applied on the specific directory
contents recursively.
There is to approach for doing this: we can either specify files or rules to be
ignored when doing the linter check. The latter is preferable, so that when we
want to clear them up later, we can have separate commits/pull request for each
of the warning fixed (and potentially automatize fixes (eg. writing clang-tidy
rules or applying linter fixes).
(!) The commits
[jira] [Updated] (MINIFICPP-1203) Set up cpplint so that it can be configured per-directory
[
https://issues.apache.org/jira/browse/MINIFICPP-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Hunyadi updated MINIFICPP-1203:
Summary: Set up cpplint so that it can be configured per-directory (was:
Set up cpplint so that it can be configured per-directory and use #pragma once)
> Set up cpplint so that it can be configured per-directory
> -
>
> Key: MINIFICPP-1203
> URL: https://issues.apache.org/jira/browse/MINIFICPP-1203
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adam Hunyadi
>Assignee: Adam Hunyadi
>Priority: Minor
> Labels: MiNiFi-CPP-Hygiene
> Fix For: 0.8.0
>
> Time Spent: 18h
> Remaining Estimate: 0h
>
> *Background:*
> Currently cpplink checks are not checking all the files correctly and are
> hiding some errors that are meant to be displayed. Manually running the
> following cpplint check shows overreports the number of errors but it is a
> decent estimate on the number of errors ignored:
> {code:bash}
> # This command shows some errors that we otherwise suppress in the project
> cpplint --linelength=200
> filter=-runtime/reference,-runtime/string,-build/c++11,-build/include_order,-build/include_alpha
> `find libminifi/ -name \.cpp -o -name \*.h`
> (...)
> Total errors found: 1730
> {code}
> When running {{{color:#403294}{{make linter}}{color}}} these errors are
> supressed. It runs the following command in
> {{{color:#403294}run_linter.sh{color}}}:
> {code:bash}
> python ${SCRIPT_DIR}/cpplint.py --linelength=200 --headers=${HEADERS}
> ${SOURCES}
> {code}
> For some reason, it seems like the files specified in the
> {{{color:#403294}{{--headers}}{color}}} flag are ignored altogether. For
> example
> {code:bash}
> # Running w/ headers option set
> cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
> --linelength=200 --headers=`find . -name "*.h" | tr '\n' ','`
> libminifi/include/processors/ProcessorUtils.h 2>/dev/null
> Done processing libminifi/include/processors/ProcessorUtils.h
> # Running w/ unspecified headers
> cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
> --linelength=200 libminifi/include/processors/ProcessorUtils.h 2>/dev/null
> Done processing libminifi/include/processors/ProcessorUtils.h
> Total errors found: 6
> {code}
> *Proposal:*
> We should remove the header specification from {{{color:#403294}{{make
> linter}}{color}}} and set up linter configuration files in the project
> directories that set all the rules to be applied on the specific directory
> contents recursively.
> There is to approach for doing this: we can either specify files or rules to
> be ignored when doing the linter check. The latter is preferable, so that
> when we want to clear them up later, we can have separate commits/pull
> request for each of the warning fixed (and potentially automatize fixes (eg.
> writing clang-tidy rules or applying linter fixes).
> (!) The commits on this Jira are not expected to fix any warnings reported by
> the linter, but to have all the checks disabled.
> *Update:*
> We decided to replace header guards with {{{color:#403294}{{#pragma
> once}}{color}}}. It is not standardized, but all the compilers we support
> have it, and we already have it scattered in our headers, so we can consider
> this update safe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MINIFICPP-1306) Replace header guards with #pragma once
Adam Hunyadi created MINIFICPP-1306:
---
Summary: Replace header guards with #pragma once
Key: MINIFICPP-1306
URL: https://issues.apache.org/jira/browse/MINIFICPP-1306
Project: Apache NiFi MiNiFi C++
Issue Type: Task
Affects Versions: 0.7.0
Reporter: Adam Hunyadi
Fix For: 1.0.0
*Background:*
The team decided to replace header guards with {{{color:#403294}{{#pragma
once}}{color}}} once. It is not standardized, but all the compilers we support
have it, and we already have it scattered in our headers, so we can consider
this update safe.
*Proposal:*
It should be easy to replace the header guards based on the linter
recommendations. Once we have all the linter warnings enabled, [[this function
from cpplint]|https://github.com/cpplint/cpplint/blob/1.5.3/cpplint.py#L2286]
can be used to find the header guard string and replaced in the
{{{color:#403294}{{#ifndef}}{color}}} and {{{color:#403294}{{#define}}{color}}}
and matching {{{color:#403294}{{#endif}}{color}}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MINIFICPP-1203) Set up cpplint so that it can be configured per-directory and use #pragma once
[
https://issues.apache.org/jira/browse/MINIFICPP-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Hunyadi reassigned MINIFICPP-1203:
---
Assignee: Adam Hunyadi
> Set up cpplint so that it can be configured per-directory and use #pragma once
> --
>
> Key: MINIFICPP-1203
> URL: https://issues.apache.org/jira/browse/MINIFICPP-1203
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adam Hunyadi
>Assignee: Adam Hunyadi
>Priority: Minor
> Labels: MiNiFi-CPP-Hygiene
> Fix For: 0.8.0
>
> Time Spent: 18h
> Remaining Estimate: 0h
>
> *Background:*
> Currently cpplink checks are not checking all the files correctly and are
> hiding some errors that are meant to be displayed. Manually running the
> following cpplint check shows overreports the number of errors but it is a
> decent estimate on the number of errors ignored:
> {code:bash}
> # This command shows some errors that we otherwise suppress in the project
> cpplint --linelength=200
> filter=-runtime/reference,-runtime/string,-build/c++11,-build/include_order,-build/include_alpha
> `find libminifi/ -name \.cpp -o -name \*.h`
> (...)
> Total errors found: 1730
> {code}
> When running {{{color:#403294}{{make linter}}{color}}} these errors are
> supressed. It runs the following command in
> {{{color:#403294}run_linter.sh{color}}}:
> {code:bash}
> python ${SCRIPT_DIR}/cpplint.py --linelength=200 --headers=${HEADERS}
> ${SOURCES}
> {code}
> For some reason, it seems like the files specified in the
> {{{color:#403294}{{--headers}}{color}}} flag are ignored altogether. For
> example
> {code:bash}
> # Running w/ headers option set
> cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
> --linelength=200 --headers=`find . -name "*.h" | tr '\n' ','`
> libminifi/include/processors/ProcessorUtils.h 2>/dev/null
> Done processing libminifi/include/processors/ProcessorUtils.h
> # Running w/ unspecified headers
> cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
> --linelength=200 libminifi/include/processors/ProcessorUtils.h 2>/dev/null
> Done processing libminifi/include/processors/ProcessorUtils.h
> Total errors found: 6
> {code}
> *Proposal:*
> We should remove the header specification from {{{color:#403294}{{make
> linter}}{color}}} and set up linter configuration files in the project
> directories that set all the rules to be applied on the specific directory
> contents recursively.
> There is to approach for doing this: we can either specify files or rules to
> be ignored when doing the linter check. The latter is preferable, so that
> when we want to clear them up later, we can have separate commits/pull
> request for each of the warning fixed (and potentially automatize fixes (eg.
> writing clang-tidy rules or applying linter fixes).
> (!) The commits on this Jira are not expected to fix any warnings reported by
> the linter, but to have all the checks disabled.
> *Update:*
> We decided to replace header guards with {{{color:#403294}{{#pragma
> once}}{color}}}. It is not standardized, but all the compilers we support
> have it, and we already have it scattered in our headers, so we can consider
> this update safe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MINIFICPP-1203) Set up cpplint so that it can be configured per-directory
[
https://issues.apache.org/jira/browse/MINIFICPP-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Hunyadi updated MINIFICPP-1203:
Description:
*Background:*
Currently cpplink checks are not checking all the files correctly and are
hiding some errors that are meant to be displayed. Manually running the
following cpplint check shows overreports the number of errors but it is a
decent estimate on the number of errors ignored:
{code:bash}
# This command shows some errors that we otherwise suppress in the project
cpplint --linelength=200
filter=-runtime/reference,-runtime/string,-build/c++11,-build/include_order,-build/include_alpha
`find libminifi/ -name \.cpp -o -name \*.h`
(...)
Total errors found: 1730
{code}
When running {{{color:#403294}{{make linter}}{color}}} these errors are
supressed. It runs the following command in
{{{color:#403294}run_linter.sh{color}}}:
{code:bash}
python ${SCRIPT_DIR}/cpplint.py --linelength=200 --headers=${HEADERS} ${SOURCES}
{code}
For some reason, it seems like the files specified in the
{{{color:#403294}{{--headers}}{color}}} flag are ignored altogether. For example
{code:bash}
# Running w/ headers option set
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 --headers=`find . -name "*.h" | tr '\n' ','`
libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
# Running w/ unspecified headers
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
Total errors found: 6
{code}
*Proposal:*
We should remove the header specification from {{{color:#403294}{{make
linter}}{color}}} and set up linter configuration files in the project
directories that set all the rules to be applied on the specific directory
contents recursively.
There is to approach for doing this: we can either specify files or rules to be
ignored when doing the linter check. The latter is preferable, so that when we
want to clear them up later, we can have separate commits/pull request for each
of the warning fixed (and potentially automatize fixes (eg. writing clang-tidy
rules or applying linter fixes).
(!) The commits on this Jira are not expected to fix any warnings reported by
the linter, but to have all the checks disabled.
*Update:*
We decided to replace header guards with {{{color:#403294}{{#pragma
once}}{color}}}. It is not standardized, but all the compilers we support have
it, and we already have it scattered in our headers, so we can consider this
update safe.
was:
*Background:*
Currently cpplink checks are not checking all the files correctly and are
hiding some errors that are meant to be displayed. Manually running the
following cpplint check shows overreports the number of errors but it is a
decent estimate on the number of errors ignored:
{code:bash}
# This command shows some errors that we otherwise suppress in the project
cpplint --linelength=200
filter=-runtime/reference,-runtime/string,-build/c++11,-build/include_order,-build/include_alpha
`find libminifi/ -name \.cpp -o -name \*.h`
(...)
Total errors found: 1730
{code}
When running {{{color:#403294}{{make linter}}{color}}} these errors are
supressed. It runs the following command in
{{{color:#403294}run_linter.sh{color}}}:
{code:bash}
python ${SCRIPT_DIR}/cpplint.py --linelength=200 --headers=${HEADERS} ${SOURCES}
{code}
For some reason, it seems like the files specified in the
{{{color:#403294}{{--headers}}{color}}} flag are ignored altogether. For example
{code:bash}
# Running w/ headers option set
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 --headers=`find . -name "*.h" | tr '\n' ','`
libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
# Running w/ unspecified headers
cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
--linelength=200 libminifi/include/processors/ProcessorUtils.h 2>/dev/null
Done processing libminifi/include/processors/ProcessorUtils.h
Total errors found: 6
{code}
*Proposal:*
We should remove the header specification from {{{color:#403294}{{make
linter}}{color}}} and set up linter configuration files in the project
directories that set all the rules to be applied on the specific directory
contents recursively.
There is to approach for doing this: we can either specify files or rules to be
ignored when doing the linter check. The latter is preferable, so that when we
want to clear them up later, we can have separate commits/pull request for each
of the warning fixed (and potentially automatize fixes (eg. writing clang-tidy
rules or applying linter fixes).
(!) The commits on this Jira are not expected to fix any warnings
[jira] [Updated] (MINIFICPP-1203) Set up cpplint so that it can be configured per-directory and use #pragma once
[
https://issues.apache.org/jira/browse/MINIFICPP-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Hunyadi updated MINIFICPP-1203:
Summary: Set up cpplint so that it can be configured per-directory and use
#pragma once (was: Set up cpplint so that it can be configured per-directory)
> Set up cpplint so that it can be configured per-directory and use #pragma once
> --
>
> Key: MINIFICPP-1203
> URL: https://issues.apache.org/jira/browse/MINIFICPP-1203
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adam Hunyadi
>Priority: Minor
> Labels: MiNiFi-CPP-Hygiene
> Fix For: 0.8.0
>
> Time Spent: 18h
> Remaining Estimate: 0h
>
> *Background:*
> Currently cpplink checks are not checking all the files correctly and are
> hiding some errors that are meant to be displayed. Manually running the
> following cpplint check shows overreports the number of errors but it is a
> decent estimate on the number of errors ignored:
> {code:bash}
> # This command shows some errors that we otherwise suppress in the project
> cpplint --linelength=200
> filter=-runtime/reference,-runtime/string,-build/c++11,-build/include_order,-build/include_alpha
> `find libminifi/ -name \.cpp -o -name \*.h`
> (...)
> Total errors found: 1730
> {code}
> When running {{{color:#403294}{{make linter}}{color}}} these errors are
> supressed. It runs the following command in
> {{{color:#403294}run_linter.sh{color}}}:
> {code:bash}
> python ${SCRIPT_DIR}/cpplint.py --linelength=200 --headers=${HEADERS}
> ${SOURCES}
> {code}
> For some reason, it seems like the files specified in the
> {{{color:#403294}{{--headers}}{color}}} flag are ignored altogether. For
> example
> {code:bash}
> # Running w/ headers option set
> cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
> --linelength=200 --headers=`find . -name "*.h" | tr '\n' ','`
> libminifi/include/processors/ProcessorUtils.h 2>/dev/null
> Done processing libminifi/include/processors/ProcessorUtils.h
> # Running w/ unspecified headers
> cpplint --filter="-runtime/reference,-runtime/string,-build/c++11"
> --linelength=200 libminifi/include/processors/ProcessorUtils.h 2>/dev/null
> Done processing libminifi/include/processors/ProcessorUtils.h
> Total errors found: 6
> {code}
> *Proposal:*
> We should remove the header specification from {{{color:#403294}{{make
> linter}}{color}}} and set up linter configuration files in the project
> directories that set all the rules to be applied on the specific directory
> contents recursively.
> There is to approach for doing this: we can either specify files or rules to
> be ignored when doing the linter check. The latter is preferable, so that
> when we want to clear them up later, we can have separate commits/pull
> request for each of the warning fixed (and potentially automatize fixes (eg.
> writing clang-tidy rules or applying linter fixes).
> (!) The commits on this Jira are not expected to fix any warnings reported by
> the linter, but to have all the checks disabled.
> *Update:*
> We decided to replace header guards with {{{color:#403294}{{#pragma
> once}}{color}}}. It is not standardized, but all the compilers we support
> have it, and we already have it scattered in our headers, so we can consider
> this update safe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
