[jira] [Updated] (NIFI-7961) Add option to disable caching for HTTP responses
[
https://issues.apache.org/jira/browse/NIFI-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7961:
Priority: Trivial (was: Major)
> Add option to disable caching for HTTP responses
>
>
> Key: NIFI-7961
> URL: https://issues.apache.org/jira/browse/NIFI-7961
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Core UI
>Affects Versions: 1.12.1
>Reporter: Andy LoPresto
>Priority: Trivial
> Labels: cache-control, http, jetty, security
>
> Some users are requesting the {{Cache-Control: no-store}} HTTP response
> header to be enabled for security reasons [1]. As NiFi is a SPA, this could
> significantly impact performance and we suspect it has minimal security
> impact. Adding this response header would necessitate an admin-configurable
> setting to enable/disable the header with the default value {{false}}
> (continuing existing behavior).
> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7962) NiFi should not respond with HTTP 500 errors for HTTP TRACK request
Andy LoPresto created NIFI-7962:
---
Summary: NiFi should not respond with HTTP 500 errors for HTTP
TRACK request
Key: NIFI-7962
URL: https://issues.apache.org/jira/browse/NIFI-7962
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.12.1
Reporter: Andy LoPresto
The HTTP {{TRACK}} method was not specified in RFC 2068 [1] for HTTP 1.1 but is
now available on some clients. NiFi currently responds to these requests with a
500 Internal Server Error page which reveals the version of the servlet API
being used but does not contain any sensitive information. As NiFi is an open
source project, the servlet API version would already be readily available to
an attacker.
The error page should be generic to obscure the servlet API version.
[1] https://tools.ietf.org/html/rfc2068
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7961) Add option to disable caching for HTTP responses
Andy LoPresto created NIFI-7961:
---
Summary: Add option to disable caching for HTTP responses
Key: NIFI-7961
URL: https://issues.apache.org/jira/browse/NIFI-7961
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework, Core UI
Affects Versions: 1.12.1
Reporter: Andy LoPresto
Some users are requesting the {{Cache-Control: no-store}} HTTP response header
to be enabled for security reasons [1]. As NiFi is a SPA, this could
significantly impact performance and we suspect it has minimal security impact.
Adding this response header would necessitate an admin-configurable setting to
enable/disable the header with the default value {{false}} (continuing existing
behavior).
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7924) Fallback claim(s) support in OIDC based authentication
[ https://issues.apache.org/jira/browse/NIFI-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216959#comment-17216959 ] Andy LoPresto commented on NIFI-7924: - Thanks for opening the ticket and proposing a change. Please don't set a fix version until the PR has been accepted and merged, as we use that field to track changes included in each release. > Fallback claim(s) support in OIDC based authentication > -- > > Key: NIFI-7924 > URL: https://issues.apache.org/jira/browse/NIFI-7924 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.12.1 >Reporter: Seokwon Yang >Assignee: Seokwon Yang >Priority: Minor > > Currently, 'nifi.security.user.oidc.claim.identifying.user' NiFi > configuration sets only one claim to bind ID token to username. There are > corner-case where fallback claim should search in case the configured claim > is not found in ID token. > For example, not all user directory objects has email address in Azure > Activity Directory > ([https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#email]). > We need a fallback claim support so that when there is no email address > claim available for a user, the OIDC identity provider should pick up > fallback claim(s) for the user name. For other users with emails, it should > continue to use the configured claim to set user name. > > I will introduce 'nifi.security.user.oidc.fallback.claims.identifying.user' > in NiFi properties and implement the fallback logic . > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7924) Fallback claim(s) support in OIDC based authentication
[ https://issues.apache.org/jira/browse/NIFI-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7924: Fix Version/s: (was: 1.13.0) > Fallback claim(s) support in OIDC based authentication > -- > > Key: NIFI-7924 > URL: https://issues.apache.org/jira/browse/NIFI-7924 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.12.1 >Reporter: Seokwon Yang >Assignee: Seokwon Yang >Priority: Minor > > Currently, 'nifi.security.user.oidc.claim.identifying.user' NiFi > configuration sets only one claim to bind ID token to username. There are > corner-case where fallback claim should search in case the configured claim > is not found in ID token. > For example, not all user directory objects has email address in Azure > Activity Directory > ([https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#email]). > We need a fallback claim support so that when there is no email address > claim available for a user, the OIDC identity provider should pick up > fallback claim(s) for the user name. For other users with emails, it should > continue to use the configured claim to set user name. > > I will introduce 'nifi.security.user.oidc.fallback.claims.identifying.user' > in NiFi properties and implement the fallback logic . > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7932) Allow MonitorActivity's "Threshold Duration" property to use variables
[ https://issues.apache.org/jira/browse/NIFI-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7932: Fix Version/s: (was: 1.12.1) > Allow MonitorActivity's "Threshold Duration" property to use variables > -- > > Key: NIFI-7932 > URL: https://issues.apache.org/jira/browse/NIFI-7932 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, Variable Registry >Affects Versions: 1.12.1 >Reporter: Kevin Barranco >Priority: Minor > Labels: features, newbie, starter > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the *MonitorActivity* processor does not support variables in the > *Threshold Duration* property. The idea is to allow the use of variables in > that property so we can maintain version control in ProcessGroup being > monitored with *MonitorActivity,* avoiding manually inserting the Time Period. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7932) Allow MonitorActivity's "Threshold Duration" property to use variables
[ https://issues.apache.org/jira/browse/NIFI-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216956#comment-17216956 ] Andy LoPresto commented on NIFI-7932: - Thanks for opening the ticket and submitting a patch. Please don't set a fix version until the PR has been accepted and merged, as we use that field to track changes included in each release. > Allow MonitorActivity's "Threshold Duration" property to use variables > -- > > Key: NIFI-7932 > URL: https://issues.apache.org/jira/browse/NIFI-7932 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, Variable Registry >Affects Versions: 1.12.1 >Reporter: Kevin Barranco >Priority: Minor > Labels: features, newbie, starter > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the *MonitorActivity* processor does not support variables in the > *Threshold Duration* property. The idea is to allow the use of variables in > that property so we can maintain version control in ProcessGroup being > monitored with *MonitorActivity,* avoiding manually inserting the Time Period. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7932) Allow MonitorActivity's "Threshold Duration" property to use variables
[ https://issues.apache.org/jira/browse/NIFI-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7932: Status: Patch Available (was: Open) > Allow MonitorActivity's "Threshold Duration" property to use variables > -- > > Key: NIFI-7932 > URL: https://issues.apache.org/jira/browse/NIFI-7932 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions, Variable Registry >Affects Versions: 1.12.1 >Reporter: Kevin Barranco >Priority: Minor > Labels: features, newbie, starter > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the *MonitorActivity* processor does not support variables in the > *Threshold Duration* property. The idea is to allow the use of variables in > that property so we can maintain version control in ProcessGroup being > monitored with *MonitorActivity,* avoiding manually inserting the Time Period. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7871) Correct errors in documentation for UUID3, UUID5 and hash in Expression Language Guide
[ https://issues.apache.org/jira/browse/NIFI-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7871: Fix Version/s: 1.13.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Correct errors in documentation for UUID3, UUID5 and hash in Expression > Language Guide > -- > > Key: NIFI-7871 > URL: https://issues.apache.org/jira/browse/NIFI-7871 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation Website >Affects Versions: 1.12.1 >Reporter: Andrew M. Lim >Assignee: Andrew M. Lim >Priority: Major > Labels: documentation, expression-language > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When the documentation for hash function was added, it was misplaced to > interfere with existing UUID3 and UUID5 documentation > ([https://github.com/apache/nifi/commit/0f4b79b55ec7e4a85334d4a0d3e7200021950d1a#diff-daac74ec3b89e26d99806d7a90254fe3).] > The examples provided for UUID3 and UUID5 could also be improved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7871) Correct errors in documentation for UUID3, UUID5 and hash in Expression Language Guide
[ https://issues.apache.org/jira/browse/NIFI-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7871: Affects Version/s: 1.12.1 Labels: documentation expression-language (was: ) Status: Patch Available (was: Open) > Correct errors in documentation for UUID3, UUID5 and hash in Expression > Language Guide > -- > > Key: NIFI-7871 > URL: https://issues.apache.org/jira/browse/NIFI-7871 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation Website >Affects Versions: 1.12.1 >Reporter: Andrew M. Lim >Assignee: Andrew M. Lim >Priority: Major > Labels: expression-language, documentation > Time Spent: 0.5h > Remaining Estimate: 0h > > When the documentation for hash function was added, it was misplaced to > interfere with existing UUID3 and UUID5 documentation > ([https://github.com/apache/nifi/commit/0f4b79b55ec7e4a85334d4a0d3e7200021950d1a#diff-daac74ec3b89e26d99806d7a90254fe3).] > The examples provided for UUID3 and UUID5 could also be improved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7898) Unit tests fail if alternative service is running on localhost
[
https://issues.apache.org/jira/browse/NIFI-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7898:
Description:
The unit test
{{testConvertOIDCTokenToNiFiTokenShouldHandleBlankIdentityAndNoEmailClaim(org.apache.nifi.web.security.oidc.StandardOidcIdentityProviderGroovyTest}}
fails if an unexpected service is running on {{localhost:80}} which responds
to an HTTP request but does not support TLS because the expected exception is
{{java.net.ConnectException}} but in this scenario the service (e.g. a Docker
container) causes {{javax.net.ssl.SSLHandshakeException: Remote host terminated
the handshake}}.
The unit test should be updated to be more accepting of reasonable exceptions.
was:
The unit test
{{testConvertOIDCTokenToNiFiTokenShouldHandleBlankIdentityAndNoEmailClaim(org.apache.nifi.web.security.oidc.StandardOidcIdentityProviderGroovyTest}}
fails if an unexpected service is running on {{localhost:8080}} which responds
to an HTTP request but does not support TLS because the expected exception is
{{java.net.ConnectException}} but in this scenario the service (e.g. a Docker
container) causes {{javax.net.ssl.SSLHandshakeException: Remote host terminated
the handshake}}.
The unit test should be updated to be more accepting of reasonable exceptions.
> Unit tests fail if alternative service is running on localhost
> --
>
> Key: NIFI-7898
> URL: https://issues.apache.org/jira/browse/NIFI-7898
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Tools and Build
>Affects Versions: 1.12.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: docker, exception, security, unit-test
>
> The unit test
> {{testConvertOIDCTokenToNiFiTokenShouldHandleBlankIdentityAndNoEmailClaim(org.apache.nifi.web.security.oidc.StandardOidcIdentityProviderGroovyTest}}
> fails if an unexpected service is running on {{localhost:80}} which responds
> to an HTTP request but does not support TLS because the expected exception is
> {{java.net.ConnectException}} but in this scenario the service (e.g. a Docker
> container) causes {{javax.net.ssl.SSLHandshakeException: Remote host
> terminated the handshake}}.
> The unit test should be updated to be more accepting of reasonable
> exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7898) Unit tests fail if alternative service is running on localhost
Andy LoPresto created NIFI-7898:
---
Summary: Unit tests fail if alternative service is running on
localhost
Key: NIFI-7898
URL: https://issues.apache.org/jira/browse/NIFI-7898
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework, Tools and Build
Affects Versions: 1.12.1
Reporter: Andy LoPresto
Assignee: Andy LoPresto
The unit test
{{testConvertOIDCTokenToNiFiTokenShouldHandleBlankIdentityAndNoEmailClaim(org.apache.nifi.web.security.oidc.StandardOidcIdentityProviderGroovyTest}}
fails if an unexpected service is running on {{localhost:8080}} which responds
to an HTTP request but does not support TLS because the expected exception is
{{java.net.ConnectException}} but in this scenario the service (e.g. a Docker
container) causes {{javax.net.ssl.SSLHandshakeException: Remote host terminated
the handshake}}.
The unit test should be updated to be more accepting of reasonable exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7777) CompressContent should accept password
[
https://issues.apache.org/jira/browse/NIFI-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-:
Fix Version/s: 1.13.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> CompressContent should accept password
> --
>
> Key: NIFI-
> URL: https://issues.apache.org/jira/browse/NIFI-
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.12.0
>Reporter: Andy LoPresto
>Assignee: David Handermann
>Priority: Major
> Labels: archive, compress, password, security
> Fix For: 1.13.0
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> As reported in a Stack Overflow question, some archive files are (or need to
> be) password-protected. The {{CompressContent}} processor does not currently
> have any mechanism for specifying a password for compression/decompression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-5481) Add new providers of protected sensitive configuration values
[
https://issues.apache.org/jira/browse/NIFI-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208885#comment-17208885
]
Andy LoPresto commented on NIFI-5481:
-
Hi Ruben. Unfortunately other priorities have taken my attention and I have not
been able to revisit this right now. The existing patches are not in a state to
be merged into the project.
> Add new providers of protected sensitive configuration values
> -
>
> Key: NIFI-5481
> URL: https://issues.apache.org/jira/browse/NIFI-5481
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Configuration, Configuration Management, Core Framework,
> Security
>Affects Versions: 1.7.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: configuration, encryption, kubernetes, security,
> toolkit, vault
> Time Spent: 5h
> Remaining Estimate: 0h
>
> In order to make NiFi more dynamically scalable in conjunction with tools
> like Docker and Kubernetes, the "encrypted config" handling should be
> enhanced to integrate with other secure configuration providers. The original
> design encompassed this idea, and the {{SensitivePropertyProvider}} interface
> is designed to be extended by various provider implementations. A provider
> which integrates with the [Hashicorp Vault|https://www.vaultproject.io] is a
> good next step.
> Vault is free and open source, widely adopted, and provides a
> [CLI|https://www.vaultproject.io/docs/commands/index.html], [HTTP
> API|https://www.vaultproject.io/api/index.html], and community-supported Java
> client library [vault-java-driver - MIT
> License|https://github.com/BetterCloud/vault-java-driver] and [Spring Vault -
> Apache 2.0 License|https://github.com/spring-projects/spring-vault].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7777) CompressContent should accept password
[
https://issues.apache.org/jira/browse/NIFI-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208465#comment-17208465
]
Andy LoPresto commented on NIFI-:
-
I think what you're proposing is fair. I didn't realize {{CompressContent}}
doesn't handle Zip format. Adding the password support for {{MergeContent}} can
be done in a different effort. We just need to create a new Jira and link it to
this one. Thanks.
> CompressContent should accept password
> --
>
> Key: NIFI-
> URL: https://issues.apache.org/jira/browse/NIFI-
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.12.0
>Reporter: Andy LoPresto
>Assignee: David Handermann
>Priority: Major
> Labels: archive, compress, password, security
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> As reported in a Stack Overflow question, some archive files are (or need to
> be) password-protected. The {{CompressContent}} processor does not currently
> have any mechanism for specifying a password for compression/decompression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7777) CompressContent should accept password
[
https://issues.apache.org/jira/browse/NIFI-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208448#comment-17208448
]
Andy LoPresto commented on NIFI-:
-
If the code change is as easy as the PR appears, I would suggest also adding
this functionality for {{CompressContent}}. The original question identified a
gap, but isn't a complete enumeration of requirements.
> CompressContent should accept password
> --
>
> Key: NIFI-
> URL: https://issues.apache.org/jira/browse/NIFI-
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.12.0
>Reporter: Andy LoPresto
>Assignee: David Handermann
>Priority: Major
> Labels: archive, compress, password, security
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> As reported in a Stack Overflow question, some archive files are (or need to
> be) password-protected. The {{CompressContent}} processor does not currently
> have any mechanism for specifying a password for compression/decompression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7885) Add global property for LFS access from HDFS processors
Andy LoPresto created NIFI-7885:
---
Summary: Add global property for LFS access from HDFS processors
Key: NIFI-7885
URL: https://issues.apache.org/jira/browse/NIFI-7885
Project: Apache NiFi
Issue Type: Sub-task
Components: Configuration, Core Framework, Extensions
Affects Versions: 1.12.1
Reporter: Andy LoPresto
>From https://issues.apache.org/jira/browse/NIFI-7884:
{quote}
This will also require introducing a global setting in {{nifi.properties}} that
an admin can set to allow local file system access via the HDFS processors
(default {{true}} for backward compatibility), and additional validation logic
in the HDFS processors (ideally the abstract shared logic) to ensure that if
this setting is disabled, the HDFS processors are not accessing the local file
system via the {{file:///}} protocol in their configuration.
{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7884) Separate "read-filesystem" restricted permission into local file system and HDFS file system permissions
Andy LoPresto created NIFI-7884:
---
Summary: Separate "read-filesystem" restricted permission into
local file system and HDFS file system permissions
Key: NIFI-7884
URL: https://issues.apache.org/jira/browse/NIFI-7884
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework, Extensions
Affects Versions: 1.12.1
Reporter: Andy LoPresto
Currently the {{read-filesystem}} value for {{RequiredPermission}} is used for
both the processors which read directly from the local file system of the
machine hosting NiFi ({{GetFile}}, {{ListFile}}, etc.) and the processors which
read from external file systems like HDFS ({{GetHDFS}}, {{PutHDFS}}, etc.).
There are use cases where NiFi users should be able to interact with the HDFS
file system without having permissions to access the local file system.
This will also require introducing a global setting in {{nifi.properties}} that
an admin can set to allow local file system access via the HDFS processors
(default {{true}} for backward compatibility), and additional validation logic
in the HDFS processors (ideally the abstract shared logic) to ensure that if
this setting is disabled, the HDFS processors are not accessing the local file
system via the {{file:///}} protocol in their configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7870) X-Content-Type missing for advanced UI resources
[ https://issues.apache.org/jira/browse/NIFI-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7870: Component/s: Core UI > X-Content-Type missing for advanced UI resources > > > Key: NIFI-7870 > URL: https://issues.apache.org/jira/browse/NIFI-7870 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.12.0, 1.12.1 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Critical > Labels: UI, content-type, header, security > > The X-Content-Type header was added in NiFi 1.12.0, which blocks resources in > the browser if they do not have the content type added. It appears that some > 'advanced UI' resources do not have the content type applied to their > resources and are blocked from loading. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7870) X-Content-Type missing for advanced UI resources
[ https://issues.apache.org/jira/browse/NIFI-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7870: Priority: Critical (was: Major) > X-Content-Type missing for advanced UI resources > > > Key: NIFI-7870 > URL: https://issues.apache.org/jira/browse/NIFI-7870 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.12.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Critical > Labels: UI, content-type, header, security > > The X-Content-Type header was added in NiFi 1.12.0, which blocks resources in > the browser if they do not have the content type added. It appears that some > 'advanced UI' resources do not have the content type applied to their > resources and are blocked from loading. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7870) X-Content-Type missing for advanced UI resources
[ https://issues.apache.org/jira/browse/NIFI-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7870: Affects Version/s: 1.12.1 > X-Content-Type missing for advanced UI resources > > > Key: NIFI-7870 > URL: https://issues.apache.org/jira/browse/NIFI-7870 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.12.0, 1.12.1 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Critical > Labels: UI, content-type, header, security > > The X-Content-Type header was added in NiFi 1.12.0, which blocks resources in > the browser if they do not have the content type added. It appears that some > 'advanced UI' resources do not have the content type applied to their > resources and are blocked from loading. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7836) Add Encrypt and Decrypt CMS Processors and Services
[ https://issues.apache.org/jira/browse/NIFI-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7836: Affects Version/s: 1.12.0 > Add Encrypt and Decrypt CMS Processors and Services > --- > > Key: NIFI-7836 > URL: https://issues.apache.org/jira/browse/NIFI-7836 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.12.0 >Reporter: David Handermann >Priority: Major > Labels: cms, encryption, security, smime, x509 > > The purpose of this issue is to add new Processors and Controller Services > supporting encryption and decryption using Cryptographic Message Syntax as > defined in RFC 5652. > CMS provides the underlying specification for S/MIME messages and also > supports encryption and decryption using X.509 certificates. Standard Java > Key Stores can be used to support encrypting messages for one or more > recipients. Decrypting messages can also be supported based on matching > certificate serial number and issuer attributes. > The current EncryptContent Processor supports encryption using passwords and > PGP keys, but does not support encryption using X.509 certificates. New > Processors for encryption and decryption would support encryption using X.509 > certificates using CMS classes in the Bouncy Castle library. New Controller > Services would provide access to certificate and private key information from > standard Java Key Stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7836) Add Encrypt and Decrypt CMS Processors and Services
[ https://issues.apache.org/jira/browse/NIFI-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7836: Labels: cms encryption security smime x509 (was: ) > Add Encrypt and Decrypt CMS Processors and Services > --- > > Key: NIFI-7836 > URL: https://issues.apache.org/jira/browse/NIFI-7836 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: David Handermann >Priority: Major > Labels: cms, encryption, security, smime, x509 > > The purpose of this issue is to add new Processors and Controller Services > supporting encryption and decryption using Cryptographic Message Syntax as > defined in RFC 5652. > CMS provides the underlying specification for S/MIME messages and also > supports encryption and decryption using X.509 certificates. Standard Java > Key Stores can be used to support encrypting messages for one or more > recipients. Decrypting messages can also be supported based on matching > certificate serial number and issuer attributes. > The current EncryptContent Processor supports encryption using passwords and > PGP keys, but does not support encryption using X.509 certificates. New > Processors for encryption and decryption would support encryption using X.509 > certificates using CMS classes in the Bouncy Castle library. New Controller > Services would provide access to certificate and private key information from > standard Java Key Stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7836) Add Encrypt and Decrypt CMS Processors and Services
[
https://issues.apache.org/jira/browse/NIFI-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200462#comment-17200462
]
Andy LoPresto commented on NIFI-7836:
-
Hi David, are you proposing to implement this or just requesting it? There are
outstanding tickets for refactoring the generic {{EncryptContent}} processor to
split out symmetric key management to controller services, PGP
encryption/decryption/signing/verification to separate processors sharing key
management controller services, etc. I think it makes sense to come up with a
standard organizational and naming approach and then implement each of the
algorithm families in that way.
> Add Encrypt and Decrypt CMS Processors and Services
> ---
>
> Key: NIFI-7836
> URL: https://issues.apache.org/jira/browse/NIFI-7836
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
>Reporter: David Handermann
>Priority: Major
>
> The purpose of this issue is to add new Processors and Controller Services
> supporting encryption and decryption using Cryptographic Message Syntax as
> defined in RFC 5652.
> CMS provides the underlying specification for S/MIME messages and also
> supports encryption and decryption using X.509 certificates. Standard Java
> Key Stores can be used to support encrypting messages for one or more
> recipients. Decrypting messages can also be supported based on matching
> certificate serial number and issuer attributes.
> The current EncryptContent Processor supports encryption using passwords and
> PGP keys, but does not support encryption using X.509 certificates. New
> Processors for encryption and decryption would support encryption using X.509
> certificates using CMS classes in the Bouncy Castle library. New Controller
> Services would provide access to certificate and private key information from
> standard Java Key Stores.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7832) HortonworksSchemaRegistry service fails when switching from password to keytab
[
https://issues.apache.org/jira/browse/NIFI-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7832:
Fix Version/s: 1.13.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> HortonworksSchemaRegistry service fails when switching from password to keytab
> --
>
> Key: NIFI-7832
> URL: https://issues.apache.org/jira/browse/NIFI-7832
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.13.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If you create a HWX Schema Registry service using kerberos principal +
> password, and then stop the service and reconfigure it to use a keytab
> service, it still thinks it is using a password...
> {code:java}
> 2020-09-22 15:11:52,549 ERROR
> org.apache.nifi.processors.standard.ConvertRecord:
> ConvertRecord[id=b657ce40-0174-1000--476e60a9] Failed to process
> StandardFlowFileRecord[uuid=478279cf-2ff2-4d19-9153-dd5748e9d319,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1600787222707-1, container=default,
> section=1], offset=55,
> length=11],offset=0,name=478279cf-2ff2-4d19-9153-dd5748e9d319,size=11]; will
> route to failure: org.apache.nifi.processor.exception.ProcessException: Could
> not retrieve schema with name 'person' from the configured Schema Registry
> org.apache.nifi.processor.exception.ProcessException: Could not retrieve
> schema with name 'person' from the configured Schema Registry
> at
> org.apache.nifi.processors.standard.AbstractRecordProcessor$1.process(AbstractRecordProcessor.java:169)
> at
> org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:3006)
> at
> org.apache.nifi.processors.standard.AbstractRecordProcessor.onTrigger(AbstractRecordProcessor.java:122)
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1176)
> at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:213)
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117)
> at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.nifi.schema.access.SchemaNotFoundException: Could not
> retrieve schema with name 'person' from the configured Schema Registry
> at
> org.apache.nifi.schema.access.SchemaNamePropertyStrategy.getSchema(SchemaNamePropertyStrategy.java:90)
> at
> org.apache.nifi.serialization.SchemaRegistryService.getSchema(SchemaRegistryService.java:126)
> at org.apache.nifi.csv.CSVReader.createRecordReader(CSVReader.java:145)
> 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.apache.nifi.controller.service.StandardControllerServiceInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:87)
> at com.sun.proxy.$Proxy192.createRecordReader(Unknown Source)
> at
> org.apache.nifi.processors.standard.AbstractRecordProcessor$1.process(AbstractRecordProcessor.java:126)
> ... 14 common frames omitted
> Caused by: java.lang.NullPointerException: null
> at
> com.hortonworks.registries.schemaregistry.client.SchemaRegistryClient$Configuration.getValue(SchemaRegistryClient.java:1454)
> at
> org.apache.nifi.schemaregistry.hortonworks.SchemaRegistryClientWithKerberosPassword.initializeSecurityContext(SchemaRegistryClientWithKerberosPassword.java:49)
> at
> com.hortonworks.registries.schemaregistry.client.SchemaRegistryClient.(SchemaRegistryClient.java:206)
> at
>
[jira] [Updated] (NIFI-7816) Correct documentation example for urlEncode function in Expression Language Guide
[ https://issues.apache.org/jira/browse/NIFI-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7816: Resolution: Fixed Status: Resolved (was: Patch Available) > Correct documentation example for urlEncode function in Expression Language > Guide > - > > Key: NIFI-7816 > URL: https://issues.apache.org/jira/browse/NIFI-7816 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation Website >Reporter: Nadeem >Assignee: Nadeem >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > The example of *urlEncode* function in NiFi Expression Language Guide has > incorrect evaluated result when it should actually be > *https%3A%2F%2Fnifi.apache.org%2Fsome+value+with+spaces* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7816) Correct documentation example for urlEncode function in Expression Language Guide
[ https://issues.apache.org/jira/browse/NIFI-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7816: Fix Version/s: 1.13.0 > Correct documentation example for urlEncode function in Expression Language > Guide > - > > Key: NIFI-7816 > URL: https://issues.apache.org/jira/browse/NIFI-7816 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation Website >Reporter: Nadeem >Assignee: Nadeem >Priority: Minor > Fix For: 1.13.0 > > Time Spent: 1h > Remaining Estimate: 0h > > The example of *urlEncode* function in NiFi Expression Language Guide has > incorrect evaluated result when it should actually be > *https%3A%2F%2Fnifi.apache.org%2Fsome+value+with+spaces* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7816) Correct documentation example for urlEncode function in Expression Language Guide
[
https://issues.apache.org/jira/browse/NIFI-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197964#comment-17197964
]
Andy LoPresto commented on NIFI-7816:
-
I think we should investigate why some characters are actually encoded with
{{%2F}} while spaces seem to be replaced with {{+}}.
> Correct documentation example for urlEncode function in Expression Language
> Guide
> -
>
> Key: NIFI-7816
> URL: https://issues.apache.org/jira/browse/NIFI-7816
> Project: Apache NiFi
> Issue Type: Bug
> Components: Documentation Website
>Reporter: Nadeem
>Assignee: Nadeem
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The example of *urlEncode* function in NiFi Expression Language Guide has
> incorrect evaluated result when it should actually be
> *https%3A%2F%2Fnifi.apache.org%2Fsome+value+with+spaces*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7804) Dependencies ending up in nifi-standard-services-api
[
https://issues.apache.org/jira/browse/NIFI-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7804:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Dependencies ending up in nifi-standard-services-api
>
>
> Key: NIFI-7804
> URL: https://issues.apache.org/jira/browse/NIFI-7804
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4
>Reporter: Bryan Bende
>Assignee: Andy LoPresto
>Priority: Critical
> Fix For: 1.13.0, 1.12.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> One of the changes in https://issues.apache.org/jira/browse/NIFI-7407 was a
> refactoring to the SSLContextService interface which added classes from
> nifi-security-utils. The result is that nifi-standard-services-api-nar now
> has transitive dependencies of nifi-security-utils included...
> {code:java}
> bcpkix-jdk15on-1.66.jar
> bcprov-jdk15on-1.66.jar
> bcrypt-0.9.0.jar
> bytes-1.3.0.jar
> commons-codec-1.14.jar
> commons-lang3-3.9.jar {code}
> This means any NAR that has a parent of nifi-standard-services-api-nar, which
> is most of them, now has these on the classpath which may conflict with
> versions of the same libraries used in the child NAR.
> We should come up with a way to not depend on nifi-security-utils, or split
> it up into more isolated modules so that these dependencies don't get brought
> in to the service APIs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7804) Dependencies ending up in nifi-standard-services-api
[
https://issues.apache.org/jira/browse/NIFI-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7804:
Status: Patch Available (was: Open)
> Dependencies ending up in nifi-standard-services-api
>
>
> Key: NIFI-7804
> URL: https://issues.apache.org/jira/browse/NIFI-7804
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.4, 1.11.3, 1.11.2, 1.11.1, 1.12.0, 1.11.0, 1.10.0
>Reporter: Bryan Bende
>Assignee: Andy LoPresto
>Priority: Critical
> Fix For: 1.13.0, 1.12.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> One of the changes in https://issues.apache.org/jira/browse/NIFI-7407 was a
> refactoring to the SSLContextService interface which added classes from
> nifi-security-utils. The result is that nifi-standard-services-api-nar now
> has transitive dependencies of nifi-security-utils included...
> {code:java}
> bcpkix-jdk15on-1.66.jar
> bcprov-jdk15on-1.66.jar
> bcrypt-0.9.0.jar
> bytes-1.3.0.jar
> commons-codec-1.14.jar
> commons-lang3-3.9.jar {code}
> This means any NAR that has a parent of nifi-standard-services-api-nar, which
> is most of them, now has these on the classpath which may conflict with
> versions of the same libraries used in the child NAR.
> We should come up with a way to not depend on nifi-security-utils, or split
> it up into more isolated modules so that these dependencies don't get brought
> in to the service APIs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7804) Dependencies ending up in nifi-standard-services-api
[
https://issues.apache.org/jira/browse/NIFI-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195682#comment-17195682
]
Andy LoPresto commented on NIFI-7804:
-
Thanks for summarizing Bryan. Aiming to have the PR up for this in the evening.
> Dependencies ending up in nifi-standard-services-api
>
>
> Key: NIFI-7804
> URL: https://issues.apache.org/jira/browse/NIFI-7804
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4
>Reporter: Bryan Bende
>Assignee: Andy LoPresto
>Priority: Critical
> Fix For: 1.13.0, 1.12.1
>
>
> One of the changes in https://issues.apache.org/jira/browse/NIFI-7407 was a
> refactoring to the SSLContextService interface which added classes from
> nifi-security-utils. The result is that nifi-standard-services-api-nar now
> has transitive dependencies of nifi-security-utils included...
> {code:java}
> bcpkix-jdk15on-1.66.jar
> bcprov-jdk15on-1.66.jar
> bcrypt-0.9.0.jar
> bytes-1.3.0.jar
> commons-codec-1.14.jar
> commons-lang3-3.9.jar {code}
> This means any NAR that has a parent of nifi-standard-services-api-nar, which
> is most of them, now has these on the classpath which may conflict with
> versions of the same libraries used in the child NAR.
> We should come up with a way to not depend on nifi-security-utils, or split
> it up into more isolated modules so that these dependencies don't get brought
> in to the service APIs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (NIFI-7804) Dependencies ending up in nifi-standard-services-api
[
https://issues.apache.org/jira/browse/NIFI-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reassigned NIFI-7804:
---
Assignee: Andy LoPresto (was: Bryan Bende)
> Dependencies ending up in nifi-standard-services-api
>
>
> Key: NIFI-7804
> URL: https://issues.apache.org/jira/browse/NIFI-7804
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4
>Reporter: Bryan Bende
>Assignee: Andy LoPresto
>Priority: Critical
> Fix For: 1.13.0, 1.12.1
>
>
> One of the changes in https://issues.apache.org/jira/browse/NIFI-7407 was a
> refactoring to the SSLContextService interface which added classes from
> nifi-security-utils. The result is that nifi-standard-services-api-nar now
> has transitive dependencies of nifi-security-utils included...
> {code:java}
> bcpkix-jdk15on-1.66.jar
> bcprov-jdk15on-1.66.jar
> bcrypt-0.9.0.jar
> bytes-1.3.0.jar
> commons-codec-1.14.jar
> commons-lang3-3.9.jar {code}
> This means any NAR that has a parent of nifi-standard-services-api-nar, which
> is most of them, now has these on the classpath which may conflict with
> versions of the same libraries used in the child NAR.
> We should come up with a way to not depend on nifi-security-utils, or split
> it up into more isolated modules so that these dependencies don't get brought
> in to the service APIs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[
https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189375#comment-17189375
]
Andy LoPresto commented on NIFI-7786:
-
The comment on NIFI-6019 says that if the remote endpoint has an "invalid
certificate", you need to be able to bypass it. Can you elaborate on why the
certificate is invalid? If it is not signed by a trusted certificate authority,
it can be imported into the local truststore explicitly. If the certificate
identifies the wrong service hostname, is expired, or is revoked, it is a good
idea to reach out to the responsible team, inform them of the issues, and ask
for a resolution.
As Joe mentioned, there is a difficult balance between providing security and
flexibility to users. Providing bypasses (e.g. {{curl -k}}) tends to become
quickly abused and misunderstood, and opens a number of visible/invisible
vulnerabilities that not all users are aware of. Because of the broad audience
for NiFi, there is rarely a single "correct" solution.
An admin override setting explicitly acknowledging the unsafe decision might be
the best path forward, but we actually have not received much pushback since
this decision was enacted (we received a number of issues before on the mailing
lists). If this is a blocker for you, you might want to also investigate
workarounds like {{ExecuteProcess}} using {{curl -k}} or forking the
project/building & deploying a custom processor using the previous version.
> Bring back Trusted Hostname property from InvokeHTTP processor
> --
>
> Key: NIFI-7786
> URL: https://issues.apache.org/jira/browse/NIFI-7786
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Kun Deng
>Priority: Major
>
> Removing this option is a mistake. Just google how many people need this
> option for various reasons.
> It is an option so that by using it, people are willing to take the risks.
>
> Please bring back this option.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7756) NIFI 1.12.0 doesn't work with wildcard certificates
[
https://issues.apache.org/jira/browse/NIFI-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188911#comment-17188911
]
Andy LoPresto commented on NIFI-7756:
-
I'm marking this as closed. As Pierre points out, true wildcard certs are not
supported, and certificates with multiple SAN or keystores with multiple certs
are supported and the regression in NIFI-7730 has been resolved.
> NIFI 1.12.0 doesn't work with wildcard certificates
> ---
>
> Key: NIFI-7756
> URL: https://issues.apache.org/jira/browse/NIFI-7756
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Security
>Affects Versions: 1.12.0
>Reporter: Heinz Mayer
>Assignee: Andy LoPresto
>Priority: Major
>
> After Upgrade to NIFI 1.12.0, NIFI doesn't start anymore
> The same keystore works with NIFI 1.11.4
> {code:java}
> 2020-08-21 07:52:21,462 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@2559c968(tomcat,h=[mic.co.at],w=[mic.co.at]) for
> SslContextFactory@37f3a1a0[provider=null,keyStore=file:///opt/nifi/conf/keystore.jks,trustStore=file:///opt/nifi/conf/keystore.jks]2020-08-21
> 07:52:21,462 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@2559c968(tomcat,h=[mic.co.at],w=[mic.co.at]) for
> SslContextFactory@37f3a1a0[provider=null,keyStore=file:///opt/nifi/conf/keystore.jks,trustStore=file:///opt/nifi/conf/keystore.jks]2020-08-21
> 07:52:21,469 WARN [main] org.apache.nifi.web.server.JettyServer Failed to
> start web server... shutting down.java.lang.IllegalStateException: KeyStores
> with multiple certificates are not supported on the base class
> org.eclipse.jetty.util.ssl.SslContextFactory. (Use
> org.eclipse.jetty.util.ssl.SslContextFactory$Server or
> org.eclipse.jetty.util.ssl.SslContextFactory$Client instead) at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1275)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1256)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231) at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.eclipse.jetty.server.Server.doStart(Server.java:385) at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1058) at
> org.apache.nifi.NiFi.(NiFi.java:158) at
> org.apache.nifi.NiFi.(NiFi.java:72) at
> org.apache.nifi.NiFi.main(NiFi.java:301) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (NIFI-7756) NIFI 1.12.0 doesn't work with wildcard certificates
[
https://issues.apache.org/jira/browse/NIFI-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto resolved NIFI-7756.
-
Fix Version/s: 1.13.0
Resolution: Duplicate
> NIFI 1.12.0 doesn't work with wildcard certificates
> ---
>
> Key: NIFI-7756
> URL: https://issues.apache.org/jira/browse/NIFI-7756
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Security
>Affects Versions: 1.12.0
>Reporter: Heinz Mayer
>Assignee: Andy LoPresto
>Priority: Major
> Fix For: 1.13.0
>
>
> After Upgrade to NIFI 1.12.0, NIFI doesn't start anymore
> The same keystore works with NIFI 1.11.4
> {code:java}
> 2020-08-21 07:52:21,462 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@2559c968(tomcat,h=[mic.co.at],w=[mic.co.at]) for
> SslContextFactory@37f3a1a0[provider=null,keyStore=file:///opt/nifi/conf/keystore.jks,trustStore=file:///opt/nifi/conf/keystore.jks]2020-08-21
> 07:52:21,462 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@2559c968(tomcat,h=[mic.co.at],w=[mic.co.at]) for
> SslContextFactory@37f3a1a0[provider=null,keyStore=file:///opt/nifi/conf/keystore.jks,trustStore=file:///opt/nifi/conf/keystore.jks]2020-08-21
> 07:52:21,469 WARN [main] org.apache.nifi.web.server.JettyServer Failed to
> start web server... shutting down.java.lang.IllegalStateException: KeyStores
> with multiple certificates are not supported on the base class
> org.eclipse.jetty.util.ssl.SslContextFactory. (Use
> org.eclipse.jetty.util.ssl.SslContextFactory$Server or
> org.eclipse.jetty.util.ssl.SslContextFactory$Client instead) at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1275)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1256)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231) at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.eclipse.jetty.server.Server.doStart(Server.java:385) at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1058) at
> org.apache.nifi.NiFi.(NiFi.java:158) at
> org.apache.nifi.NiFi.(NiFi.java:72) at
> org.apache.nifi.NiFi.main(NiFi.java:301) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (NIFI-7730) Jetty server does not start up when a keystore with multiple certificates is used
[
https://issues.apache.org/jira/browse/NIFI-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reassigned NIFI-7730:
---
Assignee: Andy LoPresto (was: Kotaro Terada)
> Jetty server does not start up when a keystore with multiple certificates is
> used
> -
>
> Key: NIFI-7730
> URL: https://issues.apache.org/jira/browse/NIFI-7730
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Kotaro Terada
>Assignee: Andy LoPresto
>Priority: Blocker
> Fix For: 1.13.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> In the newer Jetty version (which is recently upgraded on the main branch),
> Jetty's `SslContextFactory()` has been deprecated, and we can use
> `SslContextFactory.Server()` or `SslContextFactory.Client()` instead. If we
> use `SslContextFactory()`, Jetty server does not start when we use keystores
> with multiple certificates, with the following error log.
> In addition to that, we can remove
> `setEndpointIdentificationAlgorithm(null);` since it will be executed in the
> constructor of `SslContextFactory.Server()` if we replace with it.
> (See:
> [https://github.com/eclipse/jetty.project/blob/jetty-9.4.26.v20200117/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L2204])
>
> {code:java}
> 2020-08-07 19:50:32,299 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@3aac31b7(nifi-key,h=[],w=[]) for
> SslContextFactory@57def953[provider=null,keyStore=file:////keystore.jks,trustStore=file:////truststore.jks]
> 2020-08-07 19:50:32,308 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.IllegalStateException: KeyStores with multiple certificates are not
> supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory.
> (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server or
> org.eclipse.jetty.util.ssl.SslContextFactory$Client instead)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1275)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1256)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.eclipse.jetty.server.Server.doStart(Server.java:385)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1060)
> at org.apache.nifi.NiFi.(NiFi.java:160)
> at org.apache.nifi.NiFi.(NiFi.java:72)
> at org.apache.nifi.NiFi.main(NiFi.java:303)
> 2020-08-07 19:50:32,309 INFO [Thread-1] org.apache.nifi.NiFi Initiating
> shutdown of Jetty web server...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7730) Jetty server does not start up when a keystore with multiple certificates is used
[
https://issues.apache.org/jira/browse/NIFI-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7730:
Affects Version/s: 1.12.0
Status: Patch Available (was: In Progress)
> Jetty server does not start up when a keystore with multiple certificates is
> used
> -
>
> Key: NIFI-7730
> URL: https://issues.apache.org/jira/browse/NIFI-7730
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Kotaro Terada
>Assignee: Andy LoPresto
>Priority: Blocker
> Fix For: 1.13.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> In the newer Jetty version (which is recently upgraded on the main branch),
> Jetty's `SslContextFactory()` has been deprecated, and we can use
> `SslContextFactory.Server()` or `SslContextFactory.Client()` instead. If we
> use `SslContextFactory()`, Jetty server does not start when we use keystores
> with multiple certificates, with the following error log.
> In addition to that, we can remove
> `setEndpointIdentificationAlgorithm(null);` since it will be executed in the
> constructor of `SslContextFactory.Server()` if we replace with it.
> (See:
> [https://github.com/eclipse/jetty.project/blob/jetty-9.4.26.v20200117/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L2204])
>
> {code:java}
> 2020-08-07 19:50:32,299 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@3aac31b7(nifi-key,h=[],w=[]) for
> SslContextFactory@57def953[provider=null,keyStore=file:////keystore.jks,trustStore=file:////truststore.jks]
> 2020-08-07 19:50:32,308 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.IllegalStateException: KeyStores with multiple certificates are not
> supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory.
> (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server or
> org.eclipse.jetty.util.ssl.SslContextFactory$Client instead)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1275)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1256)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.eclipse.jetty.server.Server.doStart(Server.java:385)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1060)
> at org.apache.nifi.NiFi.(NiFi.java:160)
> at org.apache.nifi.NiFi.(NiFi.java:72)
> at org.apache.nifi.NiFi.main(NiFi.java:303)
> 2020-08-07 19:50:32,309 INFO [Thread-1] org.apache.nifi.NiFi Initiating
> shutdown of Jetty web server...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7730) Jetty server does not start up when a keystore with multiple certificates is used
[
https://issues.apache.org/jira/browse/NIFI-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7730:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Jetty server does not start up when a keystore with multiple certificates is
> used
> -
>
> Key: NIFI-7730
> URL: https://issues.apache.org/jira/browse/NIFI-7730
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Kotaro Terada
>Assignee: Andy LoPresto
>Priority: Blocker
> Fix For: 1.13.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> In the newer Jetty version (which is recently upgraded on the main branch),
> Jetty's `SslContextFactory()` has been deprecated, and we can use
> `SslContextFactory.Server()` or `SslContextFactory.Client()` instead. If we
> use `SslContextFactory()`, Jetty server does not start when we use keystores
> with multiple certificates, with the following error log.
> In addition to that, we can remove
> `setEndpointIdentificationAlgorithm(null);` since it will be executed in the
> constructor of `SslContextFactory.Server()` if we replace with it.
> (See:
> [https://github.com/eclipse/jetty.project/blob/jetty-9.4.26.v20200117/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L2204])
>
> {code:java}
> 2020-08-07 19:50:32,299 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@3aac31b7(nifi-key,h=[],w=[]) for
> SslContextFactory@57def953[provider=null,keyStore=file:////keystore.jks,trustStore=file:////truststore.jks]
> 2020-08-07 19:50:32,308 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.IllegalStateException: KeyStores with multiple certificates are not
> supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory.
> (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server or
> org.eclipse.jetty.util.ssl.SslContextFactory$Client instead)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1275)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1256)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.eclipse.jetty.server.Server.doStart(Server.java:385)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1060)
> at org.apache.nifi.NiFi.(NiFi.java:160)
> at org.apache.nifi.NiFi.(NiFi.java:72)
> at org.apache.nifi.NiFi.main(NiFi.java:303)
> 2020-08-07 19:50:32,309 INFO [Thread-1] org.apache.nifi.NiFi Initiating
> shutdown of Jetty web server...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7783) TLS Toolkit should include the CA CN as a SAN
Andy LoPresto created NIFI-7783:
---
Summary: TLS Toolkit should include the CA CN as a SAN
Key: NIFI-7783
URL: https://issues.apache.org/jira/browse/NIFI-7783
Project: Apache NiFi
Issue Type: Improvement
Components: Tools and Build
Affects Versions: 1.12.0
Reporter: Andy LoPresto
The NiFi CA ({{nifi-cert.pem}}) generated by the TLS Toolkit (in standalone or
server mode) does not contain the CN as a SAN entry. This should be explicitly
included.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7767) SAN not being added to certificates using tls-toolkit
[ https://issues.apache.org/jira/browse/NIFI-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7767: Fix Version/s: 1.13.0 Resolution: Fixed Status: Resolved (was: Patch Available) > SAN not being added to certificates using tls-toolkit > -- > > Key: NIFI-7767 > URL: https://issues.apache.org/jira/browse/NIFI-7767 > Project: Apache NiFi > Issue Type: New Feature > Components: Security >Affects Versions: 1.12.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Labels: tls-toolkit > Fix For: 1.13.0 > > Time Spent: 50m > Remaining Estimate: 0h > > There appears to be an issue with certificates generated using the > tls-toolkit. A few people have reported that the tls-toolkit server/client > mode does not include the SAN in the generated certificates. This results in > TLS errors when using these certificates in NiFi. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7767) SAN not being added to certificates using tls-toolkit
[ https://issues.apache.org/jira/browse/NIFI-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7767: Status: Patch Available (was: Open) > SAN not being added to certificates using tls-toolkit > -- > > Key: NIFI-7767 > URL: https://issues.apache.org/jira/browse/NIFI-7767 > Project: Apache NiFi > Issue Type: New Feature > Components: Security >Affects Versions: 1.12.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Labels: tls-toolkit > Time Spent: 50m > Remaining Estimate: 0h > > There appears to be an issue with certificates generated using the > tls-toolkit. A few people have reported that the tls-toolkit server/client > mode does not include the SAN in the generated certificates. This results in > TLS errors when using these certificates in NiFi. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7730) Jetty server does not start up when a keystore with multiple certificates is used
[
https://issues.apache.org/jira/browse/NIFI-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188830#comment-17188830
]
Andy LoPresto commented on NIFI-7730:
-
[~pkelly.nifi] [~czobrisky] Thanks for the additional info. I have verified
that the fix I posted in PR 4498 addresses this issue as well:
{code}
2020-09-01 14:49:28,475 INFO [main] o.e.jetty.server.handler.ContextHandler
Started
o.e.j.w.WebAppContext@376a0d86{nifi-error,/,file:///Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.13.0-SNAPSHOT-bin/nifi-1.13.0-SNAPSHOT/work/jetty/nifi-web-error-1.13.0-SNAPSHOT.war/webapp/,AVAILABLE}{./work/nar/framework/nifi-framework-nar-1.13.0-SNAPSHOT.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.13.0-SNAPSHOT.war}
2020-09-01 14:49:28,496 INFO [main] o.e.jetty.util.ssl.SslContextFactory
x509=X509@4a9d0c6f(nifi-key,h=[multiple_san.nifi, other_san.nifi,
third_san.nifi, fourth_san.nifi],w=[]) for
Server@62509b77[provider=null,keyStore=file:///Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.13.0-SNAPSHOT-bin/nifi-1.13.0-SNAPSHOT/conf/keystore.jks,trustStore=file:///Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.13.0-SNAPSHOT-bin/nifi-1.13.0-SNAPSHOT/conf/truststore.jks]
2020-09-01 14:49:28,521 INFO [main] o.eclipse.jetty.server.AbstractConnector
Started ServerConnector@35dab4eb{SSL,[ssl, http/1.1]}{multiple_san.nifi:9443}
2020-09-01 14:49:28,521 INFO [main] org.eclipse.jetty.server.Server Started
@21295ms
2020-09-01 14:49:28,545 INFO [main] org.apache.nifi.nar.NarAutoLoader Starting
NAR Auto-Loader for directory ./extensions ...
2020-09-01 14:49:28,546 INFO [main] org.apache.nifi.nar.NarAutoLoader NAR
Auto-Loader started
2020-09-01 14:49:28,546 INFO [main] org.apache.nifi.web.server.JettyServer NiFi
has started. The UI is available at the following URLs:
2020-09-01 14:49:28,546 INFO [main] org.apache.nifi.web.server.JettyServer
https://multiple_san.nifi:9443/nifi
2020-09-01 14:49:28,547 INFO [main] org.apache.nifi.BootstrapListener
Successfully initiated communication with Bootstrap
2020-09-01 14:49:28,548 INFO [main] org.apache.nifi.NiFi Controller
initialization took 15489116842 nanoseconds (15 seconds).
{code}
With a keystore containing a single private key entry that does have multiple
SAN entries:
{code}
✘ ..13.0-SNAPSHOT NIFI-7730 keytool -list -v -keystore
conf/keystore.jks 14:50:15
Enter keystore password:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: nifi-key
Creation date: Sep 1, 2020
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=multiple_san.nifi, OU=NIFI
Issuer: CN=localhost, OU=NIFI
Serial number: 1744ba3313f
Valid from: Tue Sep 01 14:47:00 PDT 2020 until: Mon Dec 05 13:47:00 PST 2022
Certificate fingerprints:
MD5: 30:8D:B5:9A:B1:15:F0:7C:31:14:32:68:AB:FA:E2:DA
SHA1: 16:75:B5:ED:E5:92:61:34:92:40:B8:9E:9F:FA:3B:5A:0D:50:21:1D
SHA256:
B4:DD:EF:1D:12:FB:EA:D2:34:BE:2C:5D:90:E5:C1:B3:34:F3:7B:CF:F9:67:5F:42:FB:FB:AC:E7:75:8F:3E:6E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
...
#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: multiple_san.nifi
DNSName: other_san.nifi
DNSName: third_san.nifi
DNSName: fourth_san.nifi
]
{code}
> Jetty server does not start up when a keystore with multiple certificates is
> used
> -
>
> Key: NIFI-7730
> URL: https://issues.apache.org/jira/browse/NIFI-7730
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Kotaro Terada
>Assignee: Kotaro Terada
>Priority: Blocker
> Fix For: 1.13.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> In the newer Jetty version (which is recently upgraded on the main branch),
> Jetty's `SslContextFactory()` has been deprecated, and we can use
> `SslContextFactory.Server()` or `SslContextFactory.Client()` instead. If we
> use `SslContextFactory()`, Jetty server does not start when we use keystores
> with multiple certificates, with the following error log.
> In addition to that, we can remove
> `setEndpointIdentificationAlgorithm(null);` since it will be executed in the
> constructor of `SslContextFactory.Server()` if we replace with it.
> (See:
> [https://github.com/eclipse/jetty.project/blob/jetty-9.4.26.v20200117/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L2204])
>
> {code:java}
> 2020-08-07 19:50:32,299 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@3aac31b7(nifi-key,h=[],w=[]) for
> SslContextFactory@57def953[provider=null,keyStore=file:////keystore.jks,trustStore=file:////truststore.jks]
> 2020-08-07
[jira] [Updated] (NIFI-7778) Correction in description of padLeft, padRight and plus in EL Guide
[ https://issues.apache.org/jira/browse/NIFI-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7778: Resolution: Fixed Status: Resolved (was: Patch Available) > Correction in description of padLeft, padRight and plus in EL Guide > --- > > Key: NIFI-7778 > URL: https://issues.apache.org/jira/browse/NIFI-7778 > Project: Apache NiFi > Issue Type: Improvement > Components: Documentation Website >Affects Versions: 1.12.0 >Reporter: Veda Kadam >Assignee: Veda Kadam >Priority: Minor > Labels: EL, documentaion > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add a missing # at the end of descriptions of padLeft, padRight and plus. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7778) Correction in description of padLeft, padRight and plus in EL Guide
[ https://issues.apache.org/jira/browse/NIFI-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7778: Fix Version/s: 1.13.0 Status: Patch Available (was: Open) > Correction in description of padLeft, padRight and plus in EL Guide > --- > > Key: NIFI-7778 > URL: https://issues.apache.org/jira/browse/NIFI-7778 > Project: Apache NiFi > Issue Type: Improvement > Components: Documentation Website >Affects Versions: 1.12.0 >Reporter: Veda Kadam >Assignee: Veda Kadam >Priority: Minor > Labels: EL, documentaion > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add a missing # at the end of descriptions of padLeft, padRight and plus. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7777) CompressContent should accept password
Andy LoPresto created NIFI-:
---
Summary: CompressContent should accept password
Key: NIFI-
URL: https://issues.apache.org/jira/browse/NIFI-
Project: Apache NiFi
Issue Type: Improvement
Components: Extensions
Affects Versions: 1.12.0
Reporter: Andy LoPresto
As reported in a Stack Overflow question, some archive files are (or need to
be) password-protected. The {{CompressContent}} processor does not currently
have any mechanism for specifying a password for compression/decompression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (NIFI-7752) KeyStores with multiple certificates are not supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory
[ https://issues.apache.org/jira/browse/NIFI-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto reassigned NIFI-7752: --- Assignee: Andy LoPresto > KeyStores with multiple certificates are not supported on the base class > org.eclipse.jetty.util.ssl.SslContextFactory > - > > Key: NIFI-7752 > URL: https://issues.apache.org/jira/browse/NIFI-7752 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.12.0 >Reporter: naveen kumar saharan >Assignee: Andy LoPresto >Priority: Major > > 020-08-20 02:56:06,449 WARN [main] org.apache.nifi.web.server.JettyServer > Failed to start web server... shutting down. > java.lang.IllegalStateException: KeyStores with multiple certificates are not > supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory. > (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server or > org.eclipse.jetty.util.ssl.SslContextFactory$Client instead) > at > org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1275) > at > org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1256) > at > org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374) > at > org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) > at > org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) > at > org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320) > at > org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81) > at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > at org.eclipse.jetty.server.Server.doStart(Server.java:385) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1058) > at org.apache.nifi.NiFi.(NiFi.java:158) > at org.apache.nifi.NiFi.(NiFi.java:72) > at org.apache.nifi.NiFi.main(NiFi.java:301) > 2020-08-20 02:56:06,450 INFO [Thread-0] org.apache.nifi.NiFi Initiating > shutdown of Jetty web server... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-7756) NIFI 1.12.0 doesn't work with wildcard certificates
[
https://issues.apache.org/jira/browse/NIFI-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reassigned NIFI-7756:
---
Assignee: Andy LoPresto
> NIFI 1.12.0 doesn't work with wildcard certificates
> ---
>
> Key: NIFI-7756
> URL: https://issues.apache.org/jira/browse/NIFI-7756
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Security
>Affects Versions: 1.12.0
>Reporter: Heinz Mayer
>Assignee: Andy LoPresto
>Priority: Major
>
> After Upgrade to NIFI 1.12.0, NIFI doesn't start anymore
> The same keystore works with NIFI 1.11.4
> {code:java}
> 2020-08-21 07:52:21,462 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@2559c968(tomcat,h=[mic.co.at],w=[mic.co.at]) for
> SslContextFactory@37f3a1a0[provider=null,keyStore=file:///opt/nifi/conf/keystore.jks,trustStore=file:///opt/nifi/conf/keystore.jks]2020-08-21
> 07:52:21,462 INFO [main] o.e.jetty.util.ssl.SslContextFactory
> x509=X509@2559c968(tomcat,h=[mic.co.at],w=[mic.co.at]) for
> SslContextFactory@37f3a1a0[provider=null,keyStore=file:///opt/nifi/conf/keystore.jks,trustStore=file:///opt/nifi/conf/keystore.jks]2020-08-21
> 07:52:21,469 WARN [main] org.apache.nifi.web.server.JettyServer Failed to
> start web server... shutting down.java.lang.IllegalStateException: KeyStores
> with multiple certificates are not supported on the base class
> org.eclipse.jetty.util.ssl.SslContextFactory. (Use
> org.eclipse.jetty.util.ssl.SslContextFactory$Server or
> org.eclipse.jetty.util.ssl.SslContextFactory$Client instead) at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1275)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1256)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231) at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.eclipse.jetty.server.Server.doStart(Server.java:385) at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1058) at
> org.apache.nifi.NiFi.(NiFi.java:158) at
> org.apache.nifi.NiFi.(NiFi.java:72) at
> org.apache.nifi.NiFi.main(NiFi.java:301) {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-6999) Encrypt Config Toolkit fails on very large flow.xml.gz files
[
https://issues.apache.org/jira/browse/NIFI-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182488#comment-17182488
]
Andy LoPresto commented on NIFI-6999:
-
I suggest you greatly increase the heap available to the toolkit (and greatly
decrease the size of your flow definition).
Gzip compression can often yield better than 10:1 compression, so for a
_compressed_ file size of ~ 1 GB, the uncompressed definition could easily be >
10 GB, and you have only 15 GB available for the toolkit heap. You should run
the toolkit with 45 GB as NiFi is.
> Encrypt Config Toolkit fails on very large flow.xml.gz files
>
>
> Key: NIFI-6999
> URL: https://issues.apache.org/jira/browse/NIFI-6999
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Tools and Build
>Affects Versions: 1.2.0, 1.10.0
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Critical
> Labels: documentation, encryption, heap, security, streaming,
> toolkit
>
> A user reported failure when using the encrypt config toolkit to process
> (encrypt) a large {{flow.xml.gz}}. The compressed file was 49 MB, but was 687
> MB uncompressed. It contained 545 encrypted values, and approximately 90
> templates. This caused the toolkit to fail during {{loadFlowXml()}} unless
> the toolkit invocation set the heap to 8 GB via {{-Xms2g -Xmx8g}}. Even with
> the expanded heap, the serialization of the newly-encrypted flow XML to the
> file system fails with the following exception:
> {code}
> Exception in thread "main" java.lang.OutOfMemoryError: Requested array size
> exceeds VM limit
> at java.lang.StringCoding.encode(StringCoding.java:350)
> at java.lang.String.getBytes(String.java:941)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:1857)
> at org.apache.commons.io.IOUtils$write$0.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:141)
> at
> org.apache.nifi.properties.ConfigEncryptionTool$_writeFlowXmlToFile_closure5$_closure20.doCall(ConfigEncryptionTool.groovy:692)
> 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.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1019)
> at groovy.lang.Closure.call(Closure.java:426)
> at groovy.lang.Closure.call(Closure.java:442)
> at
> org.codehaus.groovy.runtime.IOGroovyMethods.withCloseable(IOGroovyMethods.java:1622)
> at
> org.codehaus.groovy.runtime.NioGroovyMethods.withCloseable(NioGroovyMethods.java:1754)
> 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.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
> at
> org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:56)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at
> org.apache.nifi.properties.ConfigEncryptionTool$_writeFlowXmlToFile_closure5.doCall(ConfigEncryptionTool.groovy:691)
> {code}
> The immediate fix was to remove the duplicated template definitions in the
> flow definition, returning the file to a reasonable size. However, if run as
> an inline replacement, this can cause the {{flow.xml.gz}} to be overwritten
> with an empty file, potentially leading to data loss. The following steps
> should be taken:
> # Guard against loading/operating on/serializing large files (log statements,
> simple conditional checks)
> # Handle large files
[jira] [Created] (NIFI-7723) Upgrade BouncyCastle dependency to 1.66
Andy LoPresto created NIFI-7723: --- Summary: Upgrade BouncyCastle dependency to 1.66 Key: NIFI-7723 URL: https://issues.apache.org/jira/browse/NIFI-7723 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Affects Versions: 1.11.4 Reporter: Andy LoPresto Assignee: Andy LoPresto -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7572) Add a ScriptedTransformRecord processor
[
https://issues.apache.org/jira/browse/NIFI-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7572:
Resolution: Fixed
Status: Resolved (was: Patch Available)
Closing again after Matt Burgess resolved the "recompile script on change"
issue.
> Add a ScriptedTransformRecord processor
> ---
>
> Key: NIFI-7572
> URL: https://issues.apache.org/jira/browse/NIFI-7572
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> NiFi has started to put a heavier emphasis on Record-oriented processors, as
> they provide many benefits including better performance and a better UX over
> their purely byte-oriented counterparts. It is common to see users wanting to
> transform a Record in some very specific way, but NiFi doesn't make this as
> easy as it should. There are methods using ExecuteScript,
> InvokedScriptedProcessor, ScriptedRecordWriter, and ScriptedRecordReader for
> instance.
> But each of these requires that the Script writer understand a lot about NiFi
> and how to expose properties, create Property Descriptors, etc. and for
> fairly simple transformation we end up with scripts where the logic takes
> fewer lines of code than the boilerplate.
> We should expose a Processor that allows a user to write a script that takes
> a Record and transforms that Record in some way. The processor should be
> configured with the following:
> * Record Reader (required)
> * Record Writer (required)
> * Script Language (required)
> * Script Body or Script File (one and only one of these required)
> The script should implement a single method along the lines of:
> {code:java}
> Record transform(Record input) throws Exception; {code}
> If the script returns null, the input Record should be dropped. Otherwise,
> whatever Record is returned should be written to the Record Writer.
> The processor should have two relationships: "success" and "failure."
> The script should not be allowed to expose any properties or define any
> relationships. The point is to keep the script focused purely on processing
> the record itself.
> It's not entirely clear to me how easy the Record API works with some of the
> scripting languages. The Record object does expose a method named toMap()
> that returns a Map containing the underlying key/value pairs.
> However, the values in that Map may themselves be Records. It might make
> sense to expose a new method toNormalizedMap() or something along those lines
> that would return a Map where the values have been
> recursively normalized, in much the same way that we do for
> JoltTransformRecord. This would perhaps allow for cleaner syntax, but I'm not
> a scripting expert so I can't say for sure whether such a method is necessary.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7703) Update to latest Apache Commons Codec 1.13 or newer
[ https://issues.apache.org/jira/browse/NIFI-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7703: Affects Version/s: 1.11.4 Status: Patch Available (was: Open) > Update to latest Apache Commons Codec 1.13 or newer > --- > > Key: NIFI-7703 > URL: https://issues.apache.org/jira/browse/NIFI-7703 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 1.11.4 >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7703) Update to latest Apache Commons Codec 1.13 or newer
[ https://issues.apache.org/jira/browse/NIFI-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7703: Resolution: Fixed Status: Resolved (was: Patch Available) > Update to latest Apache Commons Codec 1.13 or newer > --- > > Key: NIFI-7703 > URL: https://issues.apache.org/jira/browse/NIFI-7703 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 1.11.4 >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7605) Make InvokeHttp not send User-Agent header as default behavior
[ https://issues.apache.org/jira/browse/NIFI-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7605: Resolution: Fixed Status: Resolved (was: Patch Available) > Make InvokeHttp not send User-Agent header as default behavior > -- > > Key: NIFI-7605 > URL: https://issues.apache.org/jira/browse/NIFI-7605 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7605) Make InvokeHttp not send User-Agent header as default behavior
[ https://issues.apache.org/jira/browse/NIFI-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7605: Status: Patch Available (was: Open) > Make InvokeHttp not send User-Agent header as default behavior > -- > > Key: NIFI-7605 > URL: https://issues.apache.org/jira/browse/NIFI-7605 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (NIFI-7688) NiFi Does Not Run on Windows 10 Pro
[
https://issues.apache.org/jira/browse/NIFI-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto resolved NIFI-7688.
-
Fix Version/s: 1.12.0
Resolution: Duplicate
> NiFi Does Not Run on Windows 10 Pro
> ---
>
> Key: NIFI-7688
> URL: https://issues.apache.org/jira/browse/NIFI-7688
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.11.4
> Environment: WIndows 10 Pro
>Reporter: Tim Wollin
>Priority: Major
> Fix For: 1.12.0
>
>
> The check on line 1040 of RunNiFi.java is always false on Win10 Pro. On
> Win10 Pro OpenJDK 11 outputs:
> d:\Development\nifi\nifi-1.11.4\bin>java --version
> openjdk 11 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11+28)
> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
> System.getProperty("java.version") is always set to "11".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7687) NiFi fails to start when running on first release of JDK major version
Andy LoPresto created NIFI-7687:
---
Summary: NiFi fails to start when running on first release of JDK
major version
Key: NIFI-7687
URL: https://issues.apache.org/jira/browse/NIFI-7687
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework
Affects Versions: 1.11.4
Reporter: Andy LoPresto
Assignee: Andy LoPresto
Fix For: 1.12.0
When the JDK reports the version without any minor component (e.g. as {{11}}),
the application fails to start.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-6976) Native integrations of Apache Nifi with Delta Lake
[ https://issues.apache.org/jira/browse/NIFI-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-6976: Affects Version/s: (was: 1.12.0) > Native integrations of Apache Nifi with Delta Lake > -- > > Key: NIFI-6976 > URL: https://issues.apache.org/jira/browse/NIFI-6976 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Martin >Priority: Major > Labels: ACID, delta, integration, spark, storage-layer > > "Delta Lake is an open-source storage layer that brings ACID transactions to > Apache Spar and big data workloads" ([https://delta.io/]) > > NiFi already offers many features that make it unique. A Delta integration > would complement this scope in a sensible way. > > Source: [https://github.com/delta-io/delta] > ## Update ## > Here is a demo how this looks at Streamsets. Having the same feature set on > Nifi would we awesome. > Video: [https://youtu.be/VLd_qOrKrTI] > > Here you can find all available integrations right now. > [https://docs.delta.io/0.5.0/integrations.html] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7640) HandleHttpRequest - define temporary files location
[
https://issues.apache.org/jira/browse/NIFI-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167503#comment-17167503
]
Andy LoPresto commented on NIFI-7640:
-
PR 4414 was linked to this Jira but only added documentation for the
{{HandleHttpRequest}} rather than implementing this property. Is there a
separate PR for that?
> HandleHttpRequest - define temporary files location
> ---
>
> Key: NIFI-7640
> URL: https://issues.apache.org/jira/browse/NIFI-7640
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Pierre Villard
>Assignee: Tamás Bunth
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A property should be added to the processor allowing users to define where
> temporary files are located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7669) Add flow protection key caching mechanism for derived keys
[ https://issues.apache.org/jira/browse/NIFI-7669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7669: Status: Patch Available (was: Open) > Add flow protection key caching mechanism for derived keys > -- > > Key: NIFI-7669 > URL: https://issues.apache.org/jira/browse/NIFI-7669 > Project: Apache NiFi > Issue Type: Improvement > Components: Configuration, Core Framework >Affects Versions: 1.12.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Major > Labels: caching, encryption, kdf, performance, security > > The specific algorithm introduced in NIFI-7638 introduces a ~1 sec delay in > every encryption operation (which occurs during every flow synchronization > and serialization to disk) due to the Argon2 KDF process. This is an > acceptable tradeoff for security-conscious users at this time, but can be > improved through a key caching mechanism in memory. Deriving the key once at > application startup and using it directly will remove this delay, and the key > cannot change without an application restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7669) Add flow protection key caching mechanism for derived keys
[ https://issues.apache.org/jira/browse/NIFI-7669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-7669: Affects Version/s: (was: 1.12.0) > Add flow protection key caching mechanism for derived keys > -- > > Key: NIFI-7669 > URL: https://issues.apache.org/jira/browse/NIFI-7669 > Project: Apache NiFi > Issue Type: Improvement > Components: Configuration, Core Framework >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Major > Labels: caching, encryption, kdf, performance, security > > The specific algorithm introduced in NIFI-7638 introduces a ~1 sec delay in > every encryption operation (which occurs during every flow synchronization > and serialization to disk) due to the Argon2 KDF process. This is an > acceptable tradeoff for security-conscious users at this time, but can be > improved through a key caching mechanism in memory. Deriving the key once at > application startup and using it directly will remove this delay, and the key > cannot change without an application restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7680) Set features on flow.xml.gz document builder factory
Andy LoPresto created NIFI-7680:
---
Summary: Set features on flow.xml.gz document builder factory
Key: NIFI-7680
URL: https://issues.apache.org/jira/browse/NIFI-7680
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.11.4
Reporter: Andy LoPresto
Assignee: Andy LoPresto
Fix For: 1.12.0
The {{DocumentBuilderFactory}} which loads and parses the {{flow.xml.gz}} file
can be updated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7679) Flow fingerprinting became extremely slow
[
https://issues.apache.org/jira/browse/NIFI-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7679:
Affects Version/s: (was: 1.12.0)
> Flow fingerprinting became extremely slow
> -
>
> Key: NIFI-7679
> URL: https://issues.apache.org/jira/browse/NIFI-7679
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Blocker
> Fix For: 1.12.0
>
>
> With recent commits (likely related to NIFI-7122 or NIFI-7638), NiFi will be
> extremely slow to start with relatively large flows definitions and will be
> extremely CPU intensive. According to a thread dump, it seems to be related
> to the fingerprinting logic:
> {code:java}
> "main" Id=1 RUNNABLE
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillBlock(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillSegment(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillMemoryBlocks(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.generateBytes(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.generateBytes(Unknown
> Source)
> at
> org.apache.nifi.security.util.crypto.Argon2SecureHasher.hash(Argon2SecureHasher.java:290)
> at
> org.apache.nifi.security.util.crypto.Argon2SecureHasher.hash(Argon2SecureHasher.java:258)
> at
> org.apache.nifi.security.util.crypto.AbstractSecureHasher.hashBase64(AbstractSecureHasher.java:188)
> at
> org.apache.nifi.security.util.crypto.CipherUtility.getLoggableRepresentationOfSensitiveValue(CipherUtility.java:450)
> at
> org.apache.nifi.security.util.crypto.CipherUtility.getLoggableRepresentationOfSensitiveValue(CipherUtility.java:435)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.getLoggableRepresentationOfSensitiveValue(FingerprintFactory.java:552)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.access$200(FingerprintFactory.java:70)
> at
> org.apache.nifi.fingerprint.FingerprintFactory$6.compare(FingerprintFactory.java:846)
> at
> org.apache.nifi.fingerprint.FingerprintFactory$6.compare(FingerprintFactory.java:831)
> at java.util.TimSort.binarySort(TimSort.java:296)
> at java.util.TimSort.sort(TimSort.java:221)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1464)
> at java.util.Collections.sort(Collections.java:177)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.sortElements(FingerprintFactory.java:880)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addFlowFileProcessorFingerprint(FingerprintFactory.java:488)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:370)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addFlowControllerFingerprint(FingerprintFactory.java:232)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:172)
> - waiting on org.apache.nifi.fingerprint.FingerprintFactory@6ae4b0f3
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:145)
> - waiting on org.apache.nifi.fingerprint.FingerprintFactory@6ae4b0f3
> at
> org.apache.nifi.controller.inheritance.FlowFingerprintCheck.checkInheritability(FlowFingerprintCheck.java:43)
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:206)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1425)
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:89)
> - waiting on
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO@48106119
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:792)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:537)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:72)
> at
>
[jira] [Updated] (NIFI-7679) Flow fingerprinting became extremely slow
[
https://issues.apache.org/jira/browse/NIFI-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7679:
Status: Patch Available (was: Open)
> Flow fingerprinting became extremely slow
> -
>
> Key: NIFI-7679
> URL: https://issues.apache.org/jira/browse/NIFI-7679
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.12.0
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Blocker
> Fix For: 1.12.0
>
>
> With recent commits (likely related to NIFI-7122 or NIFI-7638), NiFi will be
> extremely slow to start with relatively large flows definitions and will be
> extremely CPU intensive. According to a thread dump, it seems to be related
> to the fingerprinting logic:
> {code:java}
> "main" Id=1 RUNNABLE
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillBlock(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillSegment(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillMemoryBlocks(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.generateBytes(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.generateBytes(Unknown
> Source)
> at
> org.apache.nifi.security.util.crypto.Argon2SecureHasher.hash(Argon2SecureHasher.java:290)
> at
> org.apache.nifi.security.util.crypto.Argon2SecureHasher.hash(Argon2SecureHasher.java:258)
> at
> org.apache.nifi.security.util.crypto.AbstractSecureHasher.hashBase64(AbstractSecureHasher.java:188)
> at
> org.apache.nifi.security.util.crypto.CipherUtility.getLoggableRepresentationOfSensitiveValue(CipherUtility.java:450)
> at
> org.apache.nifi.security.util.crypto.CipherUtility.getLoggableRepresentationOfSensitiveValue(CipherUtility.java:435)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.getLoggableRepresentationOfSensitiveValue(FingerprintFactory.java:552)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.access$200(FingerprintFactory.java:70)
> at
> org.apache.nifi.fingerprint.FingerprintFactory$6.compare(FingerprintFactory.java:846)
> at
> org.apache.nifi.fingerprint.FingerprintFactory$6.compare(FingerprintFactory.java:831)
> at java.util.TimSort.binarySort(TimSort.java:296)
> at java.util.TimSort.sort(TimSort.java:221)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1464)
> at java.util.Collections.sort(Collections.java:177)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.sortElements(FingerprintFactory.java:880)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addFlowFileProcessorFingerprint(FingerprintFactory.java:488)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:370)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addFlowControllerFingerprint(FingerprintFactory.java:232)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:172)
> - waiting on org.apache.nifi.fingerprint.FingerprintFactory@6ae4b0f3
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:145)
> - waiting on org.apache.nifi.fingerprint.FingerprintFactory@6ae4b0f3
> at
> org.apache.nifi.controller.inheritance.FlowFingerprintCheck.checkInheritability(FlowFingerprintCheck.java:43)
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:206)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1425)
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:89)
> - waiting on
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO@48106119
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:792)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:537)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:72)
> at
>
[jira] [Assigned] (NIFI-7679) Flow fingerprinting became extremely slow
[
https://issues.apache.org/jira/browse/NIFI-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reassigned NIFI-7679:
---
Assignee: Andy LoPresto
> Flow fingerprinting became extremely slow
> -
>
> Key: NIFI-7679
> URL: https://issues.apache.org/jira/browse/NIFI-7679
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.12.0
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Blocker
> Fix For: 1.12.0
>
>
> With recent commits (likely related to NIFI-7122 or NIFI-7638), NiFi will be
> extremely slow to start with relatively large flows definitions and will be
> extremely CPU intensive. According to a thread dump, it seems to be related
> to the fingerprinting logic:
> {code:java}
> "main" Id=1 RUNNABLE
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillBlock(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillSegment(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.fillMemoryBlocks(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.generateBytes(Unknown
> Source)
> at
> org.bouncycastle.crypto.generators.Argon2BytesGenerator.generateBytes(Unknown
> Source)
> at
> org.apache.nifi.security.util.crypto.Argon2SecureHasher.hash(Argon2SecureHasher.java:290)
> at
> org.apache.nifi.security.util.crypto.Argon2SecureHasher.hash(Argon2SecureHasher.java:258)
> at
> org.apache.nifi.security.util.crypto.AbstractSecureHasher.hashBase64(AbstractSecureHasher.java:188)
> at
> org.apache.nifi.security.util.crypto.CipherUtility.getLoggableRepresentationOfSensitiveValue(CipherUtility.java:450)
> at
> org.apache.nifi.security.util.crypto.CipherUtility.getLoggableRepresentationOfSensitiveValue(CipherUtility.java:435)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.getLoggableRepresentationOfSensitiveValue(FingerprintFactory.java:552)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.access$200(FingerprintFactory.java:70)
> at
> org.apache.nifi.fingerprint.FingerprintFactory$6.compare(FingerprintFactory.java:846)
> at
> org.apache.nifi.fingerprint.FingerprintFactory$6.compare(FingerprintFactory.java:831)
> at java.util.TimSort.binarySort(TimSort.java:296)
> at java.util.TimSort.sort(TimSort.java:221)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1464)
> at java.util.Collections.sort(Collections.java:177)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.sortElements(FingerprintFactory.java:880)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addFlowFileProcessorFingerprint(FingerprintFactory.java:488)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:370)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addProcessGroupFingerprint(FingerprintFactory.java:398)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addFlowControllerFingerprint(FingerprintFactory.java:232)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:172)
> - waiting on org.apache.nifi.fingerprint.FingerprintFactory@6ae4b0f3
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:145)
> - waiting on org.apache.nifi.fingerprint.FingerprintFactory@6ae4b0f3
> at
> org.apache.nifi.controller.inheritance.FlowFingerprintCheck.checkInheritability(FlowFingerprintCheck.java:43)
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:206)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1425)
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:89)
> - waiting on
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO@48106119
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:792)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:537)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:72)
> at
>
[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] [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)
[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)
[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
>
[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] [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)
[jira] [Created] (NIFI-7670) Implement flow migration for PBE AEAD algorithms in Encrypt-Config toolkit
Andy LoPresto created NIFI-7670: --- Summary: Implement flow migration for PBE AEAD algorithms in Encrypt-Config toolkit Key: NIFI-7670 URL: https://issues.apache.org/jira/browse/NIFI-7670 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Affects Versions: 1.12.0 Reporter: Andy LoPresto Assignee: Andy LoPresto The toolkit does not support the new PBE AEAD algorithm because it is not a standard JCE algorithm (it is a custom combination of a KDF and cipher algorithm). The toolkit should be enhanced to support the full range of new algorithms introduced by NIFI-7668 (or at a minimum the custom algorithm introduced in NIFI-7638). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7668) Add configurable PBE AEAD algorithms to flow encryption
[
https://issues.apache.org/jira/browse/NIFI-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7668:
Affects Version/s: (was: 1.11.4)
1.12.0
> Add configurable PBE AEAD algorithms to flow encryption
> ---
>
> Key: NIFI-7668
> URL: https://issues.apache.org/jira/browse/NIFI-7668
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Core Framework
>Affects Versions: 1.12.0
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: aead, configuration, encryption, pbe, security
>
> NIFI-7638 introduced a single custom PBE algorithm (pair for 128/256-bit
> keys) which provided AEAD semantics using Argon2 for key derivation and
> AES-G/CM for authenticated encryption. This solution was a stop gap to allow
> more robust encryption than AES-CBC without modifying the
> {{EncryptionMethod}}, which is a single definition of encryption algorithms
> and (supposed) KDFs referenced throughout the codebase.
> Introducing changes to {{EncryptionMethod}} would have required massive
> regression testing, further support changes to {{EncryptContent}}, encrypted
> repository implementations, multiple documentation changes, etc. This change
> allows for a single custom algorithm which makes reasonable default decisions
> around cost parameters and algorithm selection, meeting the user requirements
> without demanding far-reaching changes.
> Instead, this ticket proposes an intentional enhancement to the
> {{nifi.properties}} structure to add a new {{nifi.sensitive.props.kdf}}
> property to complement the existing {{nifi.sensitive.props.algorithm}}
> property. This will allow arbitrary secure KDFs (Argon2, bcrypt, scrypt,
> PBKDF2) to be specified with custom cost parameters and combined with any
> keyed encryption algorithm (AES-CBC, AES-G/CM, AES-CTR) to derive a key and
> encrypt the flow sensitive properties.
> For backward compatibility, as this is likely to go in a 1.13.0 release, not
> a major release, an existing {{nifi.properties}} file will work fine. If the
> {{nifi.sensitive.props.kdf}} value is not specified, it will not be used,
> which is acceptable for all existing {{EncryptionMethod}} values which are
> already supported by the {{StringEncryptor}} class. If a _new_ algorithm is
> specified (e.g. one of the raw keyed algorithms), the KDF will need to be
> present and will be checked for appropriateness and cost parameter validity.
> No default value changes will be made. Thus, this will only affect
> security-conscious users who explicitly change those values to reflect more
> robust key derivation and data protection algorithm choices.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7669) Add flow protection key caching mechanism for derived keys
Andy LoPresto created NIFI-7669: --- Summary: Add flow protection key caching mechanism for derived keys Key: NIFI-7669 URL: https://issues.apache.org/jira/browse/NIFI-7669 Project: Apache NiFi Issue Type: Improvement Components: Configuration, Core Framework Affects Versions: 1.12.0 Reporter: Andy LoPresto Assignee: Andy LoPresto The specific algorithm introduced in NIFI-7638 introduces a ~1 sec delay in every encryption operation (which occurs during every flow synchronization and serialization to disk) due to the Argon2 KDF process. This is an acceptable tradeoff for security-conscious users at this time, but can be improved through a key caching mechanism in memory. Deriving the key once at application startup and using it directly will remove this delay, and the key cannot change without an application restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7668) Add configurable PBE AEAD algorithms to flow encryption
[
https://issues.apache.org/jira/browse/NIFI-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164087#comment-17164087
]
Andy LoPresto commented on NIFI-7668:
-
The specific algorithm introduced in NIFI-7638 also introduces a ~1 sec delay
in every encryption operation (which occurs during every flow synchronization
and serialization to disk) due to the Argon2 KDF process. This is an acceptable
tradeoff for security-conscious users at this time, but can be improved through
a key caching mechanism in memory TBA.
> Add configurable PBE AEAD algorithms to flow encryption
> ---
>
> Key: NIFI-7668
> URL: https://issues.apache.org/jira/browse/NIFI-7668
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: aead, configuration, encryption, pbe, security
>
> NIFI-7638 introduced a single custom PBE algorithm (pair for 128/256-bit
> keys) which provided AEAD semantics using Argon2 for key derivation and
> AES-G/CM for authenticated encryption. This solution was a stop gap to allow
> more robust encryption than AES-CBC without modifying the
> {{EncryptionMethod}}, which is a single definition of encryption algorithms
> and (supposed) KDFs referenced throughout the codebase.
> Introducing changes to {{EncryptionMethod}} would have required massive
> regression testing, further support changes to {{EncryptContent}}, encrypted
> repository implementations, multiple documentation changes, etc. This change
> allows for a single custom algorithm which makes reasonable default decisions
> around cost parameters and algorithm selection, meeting the user requirements
> without demanding far-reaching changes.
> Instead, this ticket proposes an intentional enhancement to the
> {{nifi.properties}} structure to add a new {{nifi.sensitive.props.kdf}}
> property to complement the existing {{nifi.sensitive.props.algorithm}}
> property. This will allow arbitrary secure KDFs (Argon2, bcrypt, scrypt,
> PBKDF2) to be specified with custom cost parameters and combined with any
> keyed encryption algorithm (AES-CBC, AES-G/CM, AES-CTR) to derive a key and
> encrypt the flow sensitive properties.
> For backward compatibility, as this is likely to go in a 1.13.0 release, not
> a major release, an existing {{nifi.properties}} file will work fine. If the
> {{nifi.sensitive.props.kdf}} value is not specified, it will not be used,
> which is acceptable for all existing {{EncryptionMethod}} values which are
> already supported by the {{StringEncryptor}} class. If a _new_ algorithm is
> specified (e.g. one of the raw keyed algorithms), the KDF will need to be
> present and will be checked for appropriateness and cost parameter validity.
> No default value changes will be made. Thus, this will only affect
> security-conscious users who explicitly change those values to reflect more
> robust key derivation and data protection algorithm choices.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7668) Add configurable PBE AEAD algorithms to flow encryption
Andy LoPresto created NIFI-7668:
---
Summary: Add configurable PBE AEAD algorithms to flow encryption
Key: NIFI-7668
URL: https://issues.apache.org/jira/browse/NIFI-7668
Project: Apache NiFi
Issue Type: Improvement
Components: Configuration, Core Framework
Affects Versions: 1.11.4
Reporter: Andy LoPresto
Assignee: Andy LoPresto
NIFI-7638 introduced a single custom PBE algorithm (pair for 128/256-bit keys)
which provided AEAD semantics using Argon2 for key derivation and AES-G/CM for
authenticated encryption. This solution was a stop gap to allow more robust
encryption than AES-CBC without modifying the {{EncryptionMethod}}, which is a
single definition of encryption algorithms and (supposed) KDFs referenced
throughout the codebase.
Introducing changes to {{EncryptionMethod}} would have required massive
regression testing, further support changes to {{EncryptContent}}, encrypted
repository implementations, multiple documentation changes, etc. This change
allows for a single custom algorithm which makes reasonable default decisions
around cost parameters and algorithm selection, meeting the user requirements
without demanding far-reaching changes.
Instead, this ticket proposes an intentional enhancement to the
{{nifi.properties}} structure to add a new {{nifi.sensitive.props.kdf}}
property to complement the existing {{nifi.sensitive.props.algorithm}}
property. This will allow arbitrary secure KDFs (Argon2, bcrypt, scrypt,
PBKDF2) to be specified with custom cost parameters and combined with any keyed
encryption algorithm (AES-CBC, AES-G/CM, AES-CTR) to derive a key and encrypt
the flow sensitive properties.
For backward compatibility, as this is likely to go in a 1.13.0 release, not a
major release, an existing {{nifi.properties}} file will work fine. If the
{{nifi.sensitive.props.kdf}} value is not specified, it will not be used, which
is acceptable for all existing {{EncryptionMethod}} values which are already
supported by the {{StringEncryptor}} class. If a _new_ algorithm is specified
(e.g. one of the raw keyed algorithms), the KDF will need to be present and
will be checked for appropriateness and cost parameter validity. No default
value changes will be made. Thus, this will only affect security-conscious
users who explicitly change those values to reflect more robust key derivation
and data protection algorithm choices.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7662) Add unit tests for Java 8 update 262 TLS v1.3 handling for different vendors
Andy LoPresto created NIFI-7662:
---
Summary: Add unit tests for Java 8 update 262 TLS v1.3 handling
for different vendors
Key: NIFI-7662
URL: https://issues.apache.org/jira/browse/NIFI-7662
Project: Apache NiFi
Issue Type: Improvement
Components: Tools and Build
Affects Versions: 1.11.4
Reporter: Andy LoPresto
While NIFI-7660 resolved the new build error due to a failing unit test
introduced by Azul Zulu JDK 8.48 (1.8.0_262-b18), the fix does not exercise the
new Azul platform. Explicit unit tests should be added for TLS v1.3 support on
Oracle/AdoptOpenJDK and Azul Zulu.
{code}
openjdk version "1.8.0_262"
OpenJDK Runtime Environment (Zulu 8.48.0.49-CA-macosx) (build 1.8.0_262-b18)
OpenJDK 64-Bit Server VM (Zulu 8.48.0.49-CA-macosx) (build 25.262-b18, mixed
mode)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7660) Change of Exception with latest Java 8
[
https://issues.apache.org/jira/browse/NIFI-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162380#comment-17162380
]
Andy LoPresto commented on NIFI-7660:
-
Azul Zulu throws a different exception than the other vendors. Fixed the unit
test.
> Change of Exception with latest Java 8
> --
>
> Key: NIFI-7660
> URL: https://issues.apache.org/jira/browse/NIFI-7660
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 1.8.0_262, vendor: Azul Systems, Inc., runtime:
> /Users/runner/hostedtoolcache/jdk/8.0.262/x64/jre
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.5", arch: "x86_64", family: "mac"
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 1.083
> s <<< FAILURE! - in org.apache.nifi.web.server.JettyServerGroovyTest
> 2231[ERROR]
> testShouldNotSupportTLSv1_3OnJava8(org.apache.nifi.web.server.JettyServerGroovyTest)
> Time elapsed: 0.689 s <<< FAILURE!
> 2232java.lang.AssertionError: Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2233 at
> org.apache.nifi.web.server.JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8(JettyServerGroovyTest.groovy:322)
> 2234
> 2235[ERROR] Failures:
> 2236[ERROR]
> JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8:322->GroovyTestCase.shouldFail:221
> Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2237[ERROR] Tests run: 22, Failures: 1, Errors: 0, Skipped: 1
> 2238[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project nifi-jetty: There are test failures.
> 2239[ERROR]
> 2240[ERROR] Please refer to
> /home/runner/work/nifi/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-jetty/target/surefire-reports
> for the individual test results.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7660) Change of Exception with latest Java 8
[
https://issues.apache.org/jira/browse/NIFI-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7660:
Status: Patch Available (was: Open)
> Change of Exception with latest Java 8
> --
>
> Key: NIFI-7660
> URL: https://issues.apache.org/jira/browse/NIFI-7660
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 1.8.0_262, vendor: Azul Systems, Inc., runtime:
> /Users/runner/hostedtoolcache/jdk/8.0.262/x64/jre
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.5", arch: "x86_64", family: "mac"
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 1.083
> s <<< FAILURE! - in org.apache.nifi.web.server.JettyServerGroovyTest
> 2231[ERROR]
> testShouldNotSupportTLSv1_3OnJava8(org.apache.nifi.web.server.JettyServerGroovyTest)
> Time elapsed: 0.689 s <<< FAILURE!
> 2232java.lang.AssertionError: Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2233 at
> org.apache.nifi.web.server.JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8(JettyServerGroovyTest.groovy:322)
> 2234
> 2235[ERROR] Failures:
> 2236[ERROR]
> JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8:322->GroovyTestCase.shouldFail:221
> Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2237[ERROR] Tests run: 22, Failures: 1, Errors: 0, Skipped: 1
> 2238[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project nifi-jetty: There are test failures.
> 2239[ERROR]
> 2240[ERROR] Please refer to
> /home/runner/work/nifi/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-jetty/target/surefire-reports
> for the individual test results.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7660) Change of Exception with latest Java 8
[
https://issues.apache.org/jira/browse/NIFI-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162348#comment-17162348
]
Andy LoPresto commented on NIFI-7660:
-
It looks like this is due to u262 adding TLS v1.3 support for Java 8, which
would negate the purpose of the specific unit test. However, I am still having
trouble reproducing this locally. Will make some diagnostic changes to the test
and hopefully figure out what is happening on the CI/CD machines remotely.
Oracle announcement:
https://www.oracle.com/java/technologies/javase/8u261-relnotes.html#JDK-8145252
Azul release notes:
https://docs.azul.com/zulu/zulurelnotes/Zulu_ReleaseNotes.pdf
JDK ticket for backporting TLS v1.3:
https://bugs.openjdk.java.net/browse/JDK-8248721
> Change of Exception with latest Java 8
> --
>
> Key: NIFI-7660
> URL: https://issues.apache.org/jira/browse/NIFI-7660
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 1.8.0_262, vendor: Azul Systems, Inc., runtime:
> /Users/runner/hostedtoolcache/jdk/8.0.262/x64/jre
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.5", arch: "x86_64", family: "mac"
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Major
> Fix For: 1.12.0
>
>
> {code:java}
> [ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 1.083
> s <<< FAILURE! - in org.apache.nifi.web.server.JettyServerGroovyTest
> 2231[ERROR]
> testShouldNotSupportTLSv1_3OnJava8(org.apache.nifi.web.server.JettyServerGroovyTest)
> Time elapsed: 0.689 s <<< FAILURE!
> 2232java.lang.AssertionError: Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2233 at
> org.apache.nifi.web.server.JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8(JettyServerGroovyTest.groovy:322)
> 2234
> 2235[ERROR] Failures:
> 2236[ERROR]
> JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8:322->GroovyTestCase.shouldFail:221
> Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2237[ERROR] Tests run: 22, Failures: 1, Errors: 0, Skipped: 1
> 2238[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project nifi-jetty: There are test failures.
> 2239[ERROR]
> 2240[ERROR] Please refer to
> /home/runner/work/nifi/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-jetty/target/surefire-reports
> for the individual test results.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7657) Lower log severity of expected exception for authentication on unsecured instance
[
https://issues.apache.org/jira/browse/NIFI-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7657:
Status: Patch Available (was: Open)
> Lower log severity of expected exception for authentication on unsecured
> instance
> -
>
> Key: NIFI-7657
> URL: https://issues.apache.org/jira/browse/NIFI-7657
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: error, log, security
> Time Spent: 10m
> Remaining Estimate: 0h
>
> All unsecured instances report an INFO log at startup and on additional
> requests due to the Kerberos authentication mechanism being unavailable. This
> log severity should be lowered and the message suppressed by default as it is
> an expected scenario but causes concern for many users.
> {code}
> 2020-07-17 11:37:38,023 INFO [NiFi Web Server-18]
> o.a.n.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException: Access
> tokens are only issued over HTTPS. Returning Conflict response.
> {code}
> A follow-on Jira should address removing the unnecessary request entirely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7658) Lower log severity of expected exception for missing content length filter size value
[
https://issues.apache.org/jira/browse/NIFI-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7658:
Status: Patch Available (was: In Progress)
> Lower log severity of expected exception for missing content length filter
> size value
> -
>
> Key: NIFI-7658
> URL: https://issues.apache.org/jira/browse/NIFI-7658
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: error, log, security
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Every WAR loaded by NiFi now prints two INFO logs at startup due to the
> default maximum web request size being unpopulated by default. This log
> severity should be lowered and the message suppressed by default as it is an
> expected scenario but causes concern for many users.
> {code}
> 2020-07-17 16:15:46,429 INFO [main] org.apache.nifi.web.server.JettyServer
> Can't parse valid max content length from
> 2020-07-17 16:15:46,429 INFO [main] org.apache.nifi.web.server.JettyServer
> Not adding content-length filter because nifi.web.max.content.size is not set
> in nifi.properties
> {code}
> A follow-on Jira should address removing the unnecessary request entirely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7660) Change of Exception with latest Java 8
[
https://issues.apache.org/jira/browse/NIFI-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161483#comment-17161483
]
Andy LoPresto commented on NIFI-7660:
-
I can't reproduce this locally. I'm wondering what would have changed on the
CI/CD build machine recently other than the Java version.
{code}
..orkspace/nifi NIFI-7660 mvn clean install -Pcontrib-check
-Pavoid-archive-formats -Dsurefire.skipAfterFailureCount=1 -Pinclude-grpc
...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 46:29 min
[INFO] Finished at: 2020-07-20T12:19:41-07:00
[INFO]
..orkspace/nifi NIFI-7660 java -version
12:19:42
openjdk version "1.8.0_262"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_262-b10)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.262-b10, mixed mode)
..orkspace/nifi NIFI-7660 mvn -v
12:20:11
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 1.8.0_262, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: "mac"
..orkspace/nifi NIFI-7660
{code}
> Change of Exception with latest Java 8
> --
>
> Key: NIFI-7660
> URL: https://issues.apache.org/jira/browse/NIFI-7660
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 1.8.0_262, vendor: Azul Systems, Inc., runtime:
> /Users/runner/hostedtoolcache/jdk/8.0.262/x64/jre
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.5", arch: "x86_64", family: "mac"
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Major
> Fix For: 1.12.0
>
>
> {code:java}
> [ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 1.083
> s <<< FAILURE! - in org.apache.nifi.web.server.JettyServerGroovyTest
> 2231[ERROR]
> testShouldNotSupportTLSv1_3OnJava8(org.apache.nifi.web.server.JettyServerGroovyTest)
> Time elapsed: 0.689 s <<< FAILURE!
> 2232java.lang.AssertionError: Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2233 at
> org.apache.nifi.web.server.JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8(JettyServerGroovyTest.groovy:322)
> 2234
> 2235[ERROR] Failures:
> 2236[ERROR]
> JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8:322->GroovyTestCase.shouldFail:221
> Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2237[ERROR] Tests run: 22, Failures: 1, Errors: 0, Skipped: 1
> 2238[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project nifi-jetty: There are test failures.
> 2239[ERROR]
> 2240[ERROR] Please refer to
> /home/runner/work/nifi/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-jetty/target/surefire-reports
> for the individual test results.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (NIFI-7660) Change of Exception with latest Java 8
[
https://issues.apache.org/jira/browse/NIFI-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reassigned NIFI-7660:
---
Assignee: Andy LoPresto
> Change of Exception with latest Java 8
> --
>
> Key: NIFI-7660
> URL: https://issues.apache.org/jira/browse/NIFI-7660
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
> Java version: 1.8.0_262, vendor: Azul Systems, Inc., runtime:
> /Users/runner/hostedtoolcache/jdk/8.0.262/x64/jre
> Default locale: en_JP, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.5", arch: "x86_64", family: "mac"
>Reporter: Pierre Villard
>Assignee: Andy LoPresto
>Priority: Major
> Fix For: 1.12.0
>
>
> {code:java}
> [ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 1.083
> s <<< FAILURE! - in org.apache.nifi.web.server.JettyServerGroovyTest
> 2231[ERROR]
> testShouldNotSupportTLSv1_3OnJava8(org.apache.nifi.web.server.JettyServerGroovyTest)
> Time elapsed: 0.689 s <<< FAILURE!
> 2232java.lang.AssertionError: Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2233 at
> org.apache.nifi.web.server.JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8(JettyServerGroovyTest.groovy:322)
> 2234
> 2235[ERROR] Failures:
> 2236[ERROR]
> JettyServerGroovyTest.testShouldNotSupportTLSv1_3OnJava8:322->GroovyTestCase.shouldFail:221
> Closure
> org.apache.nifi.web.server.JettyServerGroovyTest$_testShouldNotSupportTLSv1_3OnJava8_closure17@42435b98
> should have failed with an exception of type
> java.lang.IllegalArgumentException, instead got Exception
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 2237[ERROR] Tests run: 22, Failures: 1, Errors: 0, Skipped: 1
> 2238[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project nifi-jetty: There are test failures.
> 2239[ERROR]
> 2240[ERROR] Please refer to
> /home/runner/work/nifi/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-jetty/target/surefire-reports
> for the individual test results.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7631) Create a nifi.content.repository.implementation for Apache Pulsar
[ https://issues.apache.org/jira/browse/NIFI-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161380#comment-17161380 ] Andy LoPresto commented on NIFI-7631: - Thank you for the clarification. You've obviously put some thought into this proposal. I look forward to your contribution. > Create a nifi.content.repository.implementation for Apache Pulsar > -- > > Key: NIFI-7631 > URL: https://issues.apache.org/jira/browse/NIFI-7631 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Reporter: Ryan LaMothe >Priority: Major > > I would like to begin the development of a new > nifi.content.repository.implementation for Apache Pulsar. In our modern, > cloud-based streaming message environments, we are using Apache Pulsar for > all of our persistent message/data and stream management. Apache NiFi > currently supports only local disk (non-volatile) and in-memory (volatile) > content repository implementations. This means that Apache NiFi currently > performs double duty as both a workflow management environment and a > message/data management system, as there are no remote message/data > management content repository implementations available. > The proposed new feature development would create a new content repository > implementation designed around a streaming message/data architecture, in > essence replacing the concept of a "NiFi local queue" with an "Apache Pulsar > remote queue", allowing Apache Pulsar to remotely and independently manage > messages/data on the behalf of NiFi. This would also support NiFi as a pure > workflow management environment, decoupling it from its data management > responsibilities. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7658) Lower log severity of expected exception for missing content length filter size value
[
https://issues.apache.org/jira/browse/NIFI-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7658:
Description:
Every WAR loaded by NiFi now prints two INFO logs at startup due to the default
maximum web request size being unpopulated by default. This log severity should
be lowered and the message suppressed by default as it is an expected scenario
but causes concern for many users.
{code}
2020-07-17 16:15:46,429 INFO [main] org.apache.nifi.web.server.JettyServer
Can't parse valid max content length from
2020-07-17 16:15:46,429 INFO [main] org.apache.nifi.web.server.JettyServer Not
adding content-length filter because nifi.web.max.content.size is not set in
nifi.properties
{code}
A follow-on Jira should address removing the unnecessary request entirely.
was:
All unsecured instances report an INFO log at startup and on additional
requests due to the Kerberos authentication mechanism being unavailable. This
log severity should be lowered and the message suppressed by default as it is
an expected scenario but causes concern for many users.
{code}
2020-07-17 11:37:38,023 INFO [NiFi Web Server-18]
o.a.n.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException: Access
tokens are only issued over HTTPS. Returning Conflict response.
{code}
A follow-on Jira should address removing the unnecessary request entirely.
> Lower log severity of expected exception for missing content length filter
> size value
> -
>
> Key: NIFI-7658
> URL: https://issues.apache.org/jira/browse/NIFI-7658
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: error, log, security
>
> Every WAR loaded by NiFi now prints two INFO logs at startup due to the
> default maximum web request size being unpopulated by default. This log
> severity should be lowered and the message suppressed by default as it is an
> expected scenario but causes concern for many users.
> {code}
> 2020-07-17 16:15:46,429 INFO [main] org.apache.nifi.web.server.JettyServer
> Can't parse valid max content length from
> 2020-07-17 16:15:46,429 INFO [main] org.apache.nifi.web.server.JettyServer
> Not adding content-length filter because nifi.web.max.content.size is not set
> in nifi.properties
> {code}
> A follow-on Jira should address removing the unnecessary request entirely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7658) Lower log severity of expected exception for missing content length filter size value
Andy LoPresto created NIFI-7658:
---
Summary: Lower log severity of expected exception for missing
content length filter size value
Key: NIFI-7658
URL: https://issues.apache.org/jira/browse/NIFI-7658
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.11.4
Reporter: Andy LoPresto
Assignee: Andy LoPresto
All unsecured instances report an INFO log at startup and on additional
requests due to the Kerberos authentication mechanism being unavailable. This
log severity should be lowered and the message suppressed by default as it is
an expected scenario but causes concern for many users.
{code}
2020-07-17 11:37:38,023 INFO [NiFi Web Server-18]
o.a.n.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException: Access
tokens are only issued over HTTPS. Returning Conflict response.
{code}
A follow-on Jira should address removing the unnecessary request entirely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7657) Lower log severity of expected exception for authentication on unsecured instance
[
https://issues.apache.org/jira/browse/NIFI-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7657:
Description:
All unsecured instances report an INFO log at startup and on additional
requests due to the Kerberos authentication mechanism being unavailable. This
log severity should be lowered and the message suppressed by default as it is
an expected scenario but causes concern for many users.
{code}
2020-07-17 11:37:38,023 INFO [NiFi Web Server-18]
o.a.n.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException: Access
tokens are only issued over HTTPS. Returning Conflict response.
{code}
A follow-on Jira should address removing the unnecessary request entirely.
was:
All unsecured instances report an INFO log at startup and on additional
requests due to the Kerberos authentication mechanism being unavailable. This
log severity should be lowered and the message suppressed by default as it is
an expected scenario but causes concern for many users.
{code}
2020-07-17 11:37:38,023 INFO [NiFi Web Server-18]
o.a.n.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException: Access
tokens are only issued over HTTPS. Returning Conflict response.
{code}
> Lower log severity of expected exception for authentication on unsecured
> instance
> -
>
> Key: NIFI-7657
> URL: https://issues.apache.org/jira/browse/NIFI-7657
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: error, log, security
>
> All unsecured instances report an INFO log at startup and on additional
> requests due to the Kerberos authentication mechanism being unavailable. This
> log severity should be lowered and the message suppressed by default as it is
> an expected scenario but causes concern for many users.
> {code}
> 2020-07-17 11:37:38,023 INFO [NiFi Web Server-18]
> o.a.n.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException: Access
> tokens are only issued over HTTPS. Returning Conflict response.
> {code}
> A follow-on Jira should address removing the unnecessary request entirely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7657) Lower log severity of expected exception for authentication on unsecured instance
Andy LoPresto created NIFI-7657:
---
Summary: Lower log severity of expected exception for
authentication on unsecured instance
Key: NIFI-7657
URL: https://issues.apache.org/jira/browse/NIFI-7657
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.11.4
Reporter: Andy LoPresto
Assignee: Andy LoPresto
All unsecured instances report an INFO log at startup and on additional
requests due to the Kerberos authentication mechanism being unavailable. This
log severity should be lowered and the message suppressed by default as it is
an expected scenario but causes concern for many users.
{code}
2020-07-17 11:37:38,023 INFO [NiFi Web Server-18]
o.a.n.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException: Access
tokens are only issued over HTTPS. Returning Conflict response.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7638) Add PBE AEAD sensitive flow property protection scheme
Andy LoPresto created NIFI-7638:
---
Summary: 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
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-7304) Default value for content length filter blocks Site to Site communication
[
https://issues.apache.org/jira/browse/NIFI-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7304:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Default value for content length filter blocks Site to Site communication
> -
>
> Key: NIFI-7304
> URL: https://issues.apache.org/jira/browse/NIFI-7304
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.12.0
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Blocker
> Labels: cluster, filter, http, replication, security,
> site-to-site
> Fix For: 1.12.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> When the content-length filter was introduced in NIFI-7153, it did not
> separate Site to Site (S2S) or cluster request replication requests from
> user-generated requests. With the default value of 20 MB, it is very likely
> that legitimate requests of this nature will be unexpectedly blocked.
> The immediate fix is to change the default value in {{nifi.properties}} to
> empty and only enable this functionality when a value is provided.
> A subtask will be opened to investigate if these requests should be excluded
> from the length limiting filter (either by convention or via an
> admin-enumerated exclusion list/setting).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7614) Improve terminology around top-level key management for sensitive configuration values
[
https://issues.apache.org/jira/browse/NIFI-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7614:
Status: Patch Available (was: Open)
> Improve terminology around top-level key management for sensitive
> configuration values
> --
>
> Key: NIFI-7614
> URL: https://issues.apache.org/jira/browse/NIFI-7614
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Configuration Management, Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: security, terminology
>
> The top-level key and associated handling stored in {{bootstrap.conf}} and
> used to encrypt the sensitive properties in {{nifi.properties}}, etc. should
> be renamed from "master".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7614) Improve terminology around top-level key management for sensitive configuration values
[
https://issues.apache.org/jira/browse/NIFI-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7614:
Fix Version/s: 1.12.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Improve terminology around top-level key management for sensitive
> configuration values
> --
>
> Key: NIFI-7614
> URL: https://issues.apache.org/jira/browse/NIFI-7614
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Configuration Management, Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: security, terminology
> Fix For: 1.12.0
>
>
> The top-level key and associated handling stored in {{bootstrap.conf}} and
> used to encrypt the sensitive properties in {{nifi.properties}}, etc. should
> be renamed from "master".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7621) Remove legacy terminology around branch names from GitHub messaging and developer documentation
[
https://issues.apache.org/jira/browse/NIFI-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7621:
Status: Patch Available (was: Open)
> Remove legacy terminology around branch names from GitHub messaging and
> developer documentation
> ---
>
> Key: NIFI-7621
> URL: https://issues.apache.org/jira/browse/NIFI-7621
> Project: Apache NiFi
> Issue Type: Task
> Components: Documentation Website, Tools and Build
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: terminology
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Change references to {{master}} branch to reflect new name {{main}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7621) Remove legacy terminology around branch names from GitHub messaging and developer documentation
[
https://issues.apache.org/jira/browse/NIFI-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7621:
Fix Version/s: 1.12.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Remove legacy terminology around branch names from GitHub messaging and
> developer documentation
> ---
>
> Key: NIFI-7621
> URL: https://issues.apache.org/jira/browse/NIFI-7621
> Project: Apache NiFi
> Issue Type: Task
> Components: Documentation Website, Tools and Build
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: terminology
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Change references to {{master}} branch to reflect new name {{main}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7631) Create a nifi.content.repository.implementation for Apache Pulsar
[ https://issues.apache.org/jira/browse/NIFI-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156359#comment-17156359 ] Andy LoPresto commented on NIFI-7631: - We welcome feature development proposals, but I am slightly confused by some of the comments here. The content, flowfile, and provenance repositories are designed to be internal data structures for NiFi with no external interaction, and NiFi's "data management responsibilities" are inherent to its function as a flow manager. Without certain guarantees about the persistence/transience and availability of the data in these repositories, NiFi would hardly function, much less be able to route data between different components in the flow graph in a performant and reliable manner. For message persistence, NiFi currently consumes from and produces to systems like Pulsar, Kafka, etc., but this interaction is an external communication through the flow rather than the internal mechanics of the framework. Have you read the [Apache NiFi In-Depth|https://nifi.apache.org/docs/nifi-docs/html/nifi-in-depth.html] document, which goes into further detail around the implementation and design principles of these repositories and how they interact with the NiFi system? > Create a nifi.content.repository.implementation for Apache Pulsar > -- > > Key: NIFI-7631 > URL: https://issues.apache.org/jira/browse/NIFI-7631 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Reporter: Ryan LaMothe >Priority: Major > > I would like to begin the development of a new > nifi.content.repository.implementation for Apache Pulsar. In our modern, > cloud-based streaming message environments, we are using Apache Pulsar for > all of our persistent message/data and stream management. Apache NiFi > currently supports only local disk (non-volatile) and in-memory (volatile) > content repository implementations. This means that Apache NiFi currently > performs double duty as both a workflow management environment and a > message/data management system, as there are no remote message/data > management content repository implementations available. > The proposed new feature development would create a new content repository > implementation designed around a streaming message/data architecture, in > essence replacing the concept of a "NiFi local queue" with an "Apache Pulsar > remote queue", allowing Apache Pulsar to remotely and independently manage > messages/data on the behalf of NiFi. This would also support NiFi as a pure > workflow management environment, decoupling it from its data management > responsibilities. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7626) Provide default value for CDCMySQL processor property which claims it
Andy LoPresto created NIFI-7626:
---
Summary: Provide default value for CDCMySQL processor property
which claims it
Key: NIFI-7626
URL: https://issues.apache.org/jira/browse/NIFI-7626
Project: Apache NiFi
Issue Type: Improvement
Components: Extensions
Affects Versions: 1.11.4
Reporter: Andy LoPresto
The {{ChangeDataCaptureMySQL}} documentation states that the "Server ID"
property uses a default value of {{65535}} if not set. Rather than rely on the
silent default embedded in code, this processor property should receive a
default value of {{65535}} to make this evident to users.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
