Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/1986
Some thoughts on this thread. First it is good to get this cleaned up and
easier for the user so this is a great discussion.
1. It sounds prudent that we delineate our SSLContextService along two
lines. One is StandardSSLContextService which works as our current one does,
supports numerous protocols including those we do not recommend be in continued
use but that we need to support for interacting/initiating connections to
systems using legacy protocols. The other would be a more
restricted/conservative set of protocols like TLSv1.2. I recommend we call
that RestrictedSSLContextService. We can document on the existing Standard
service what it is for and allowable for. And we can do the same on restricted
indicating it is only for 'safe' protocols and may evolve as more is
learned/made available. Both would follow the same interface most likely.
2. We update ListenHTTP,HandleRequest,(any proc that acts as a
listen/server) to allow only the RestrictedSSLContextService. This is within
the documented transition changes between minor versions, can be captured in
our release/migration notes, and will improve the user experience to only
accept allowed protocols.
3. We should avoid to the extent possible ever doing validation of a given
configuration of a component/processor only once started. And we should avoid
using onScheduled to block startup/etc.. Once a user is passed the validation
phase this is what process yielding is for. The logic to test whether the
protocols used, which would not matter if (1) and (2) above are done, should be
done as early in the lifecycle as possible to let the user resolve the issue
before we slap their hand by stopping their process (and that is only when
considering this done in a non-programmatic case). I realize this isn't purely
clear all the time but am saying this from an intent of the API, thinking about
when we bind validation issues, and considering that the API is for both
programmatic and human interaction.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
