[
https://issues.apache.org/jira/browse/MINIFICPP-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ferenc Gerlits updated MINIFICPP-2787:
--------------------------------------
Description:
By encrypting blank sensitive properties, we cause a bug in
SmbConnectionControllerService, and potentially other processors and controller
services.
Note that by not encrypting blank properties, we are not exposing new
information, since the current encryption does not add random padding, so the
length of sensitive value is easily recoverable already. (We may want to
address this later.)
Steps to reproduce the existing bug:
# Create a flow with an SmbConnectionControllerService, eg. ListSmb ->
FetchSmb -> PutFile. Leave both the Username and Password properties blank.
# Start minifi; the first time everything is fine.
# Restart minifi; after the second startup, you will see errors like this:
{noformat}
[2026-04-17 18:12:32.038]
[org::apache::nifi::minifi::core::controller::StandardControllerServiceNode]
[warning] Service 'SmbConnectionControllerService' failed to enable: Process
Schedule Operation: Either both a username and a password, or neither of them
should be provided.{noformat}
# The controller service will not be started. Any processors which depend on
the SmbConnectionControllerService will not be started, either.
This is because after the first startup, both properties will be read as unset
at first; then minifi will encrypt the (blank) Password property in config.yml.
After the second startup, the Username property will be read as unset but the
Password property will be read as set to the empty string; this causes the
error here:
{noformat}
if (password.has_value() != username.has_value())
throw Exception(PROCESS_SCHEDULE_EXCEPTION, "Either both a username and a
password, or neither of them should be provided.");{noformat}
Workaround: if no username/password is required, set them both to some
arbitrary value instead of leaving them blank.
was:
By encrypting blank sensitive properties, we cause a bug in
SmbConnectionControllerService, and potentially other processors and controller
services.
Note that by not encrypting blank properties, we are not exposing new
information, since the current encryption does not add random padding, so the
length of sensitive value is easily recoverable already. (We may want to
address this later.)
Steps to reproduce the existing bug:
# Create a flow with an SmbConnectionControllerService, eg. ListSmb ->
FetchSmb -> PutFile. Leave both the Username and Password properties blank.
# Start minifi; the first time everything is fine.
# Restart minifi; after the second startup, you will see errors like this:
{noformat}
[2026-04-17 18:12:32.038]
[org::apache::nifi::minifi::core::controller::StandardControllerServiceNode]
[warning] Service 'SmbConnectionControllerService' failed to enable: Process
Schedule Operation: Either both a username and a password, or neither of them
should be provided.{noformat}
# The controller service will not be started. Any processors which depend on
the SmbConnectionControllerService will not be started, either.
I think this is because after the first startup, both properties will be read
as unset at first; then minifi will encrypt the (blank) Password property in
config.yml. After the second startup, the Username property will be read as
unset but the Password property will be read as set to the empty string; this
causes the error here:
{noformat}
if (password.has_value() != username.has_value())
throw Exception(PROCESS_SCHEDULE_EXCEPTION, "Either both a username and a
password, or neither of them should be provided.");{noformat}
Workaround: if no username/password is required, set them both to some
arbitrary value instead of leaving them blank.
> Do not encrypt sensitive properties if they are empty
> -----------------------------------------------------
>
> Key: MINIFICPP-2787
> URL: https://issues.apache.org/jira/browse/MINIFICPP-2787
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
> Reporter: Ferenc Gerlits
> Assignee: Ferenc Gerlits
> Priority: Minor
>
> By encrypting blank sensitive properties, we cause a bug in
> SmbConnectionControllerService, and potentially other processors and
> controller services.
> Note that by not encrypting blank properties, we are not exposing new
> information, since the current encryption does not add random padding, so the
> length of sensitive value is easily recoverable already. (We may want to
> address this later.)
>
> Steps to reproduce the existing bug:
> # Create a flow with an SmbConnectionControllerService, eg. ListSmb ->
> FetchSmb -> PutFile. Leave both the Username and Password properties blank.
> # Start minifi; the first time everything is fine.
> # Restart minifi; after the second startup, you will see errors like this:
> {noformat}
> [2026-04-17 18:12:32.038]
> [org::apache::nifi::minifi::core::controller::StandardControllerServiceNode]
> [warning] Service 'SmbConnectionControllerService' failed to enable: Process
> Schedule Operation: Either both a username and a password, or neither of them
> should be provided.{noformat}
> # The controller service will not be started. Any processors which depend on
> the SmbConnectionControllerService will not be started, either.
> This is because after the first startup, both properties will be read as
> unset at first; then minifi will encrypt the (blank) Password property in
> config.yml. After the second startup, the Username property will be read as
> unset but the Password property will be read as set to the empty string; this
> causes the error here:
> {noformat}
> if (password.has_value() != username.has_value())
> throw Exception(PROCESS_SCHEDULE_EXCEPTION, "Either both a username and a
> password, or neither of them should be provided.");{noformat}
> Workaround: if no username/password is required, set them both to some
> arbitrary value instead of leaving them blank.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
