[
https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189351#comment-17189351
]
Joe Witt commented on NIFI-7786:
--------------------------------
[~kundeng] It is important to provide the context for your request. I had to
search and have now linked for what you were talking about.
Your statement in the above linked comment suggests you really liked the
ability to disable verification. We understand and this is indeed why it was
there. But we also found users not realizing how TLS works and tweaking that
setting finding it suddenly working only to not realize they were insecure.
Who does that fall back to? That comes back to us. The notion of enforcing
security vs giving options, etc... this is a tricky balance frankly.
The only real path we've found that helps is to let users turn on a property in
something like "enable.unsafe.security.related.options" such that if a user
turns that on then we're free to support a range of options that while flexible
are not safe.... In short this isn't an easy line to walk. I get your point
from a user point of view and I hope you appreciate the challenge we face in
providing good software that favors security 'correctly'.
I'm not in favor of this property, or others like it, returning to the system
with forcing users to explicitly say they're intentionally enabling features
which allow non secure practices.
> 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)
