Fix issue 2017: setting localhost as default in docker-compose based setups #2601

pasindutennage-da · 2025-10-08T14:54:17Z

Fixes #2017

Set localhost as the default in SV, localhost, and validator docker-compose in cluster/compose

For SV and Validator, there is an option to expose externally using -E flag, in the respective start.sh scripts.

For localnet, it is hardcoded, because no extra traffic is expected.

…on to expose externally. [static] Signed-off-by: Pasindu Tennage <[email protected]>

…to chose between localhost and 0.0.0.0 [static] Signed-off-by: Pasindu Tennage <[email protected]>

…r deployment. Hardcoded to localhost, with no option to run externally. Since localnet only runs locally, no need to expose externally. [ci] Signed-off-by: Pasindu Tennage <[email protected]>

martinflorian-da · 2025-10-08T17:21:50Z

cluster/compose/localnet/compose.yaml

-      - "${SV_UI_PORT}:${SV_UI_PORT}"
-      - "${APP_PROVIDER_UI_PORT}:${APP_PROVIDER_UI_PORT}"
-      - "${APP_USER_UI_PORT}:${APP_USER_UI_PORT}"
+      - "127.0.0.1:${SV_UI_PORT}:${SV_UI_PORT}"


Ah your idea being that these should never be public? Hm not 100% sure about that change - perhaps someone do wants to make them public after all, as part of their testing?

Probably nicest to make them optionally public like for the other compose file?

cc @isegall-da WDYT?

I have some mixed feeling about this, and the following is my reasoning.

In any realistic setting, localnet will never host a real deployment, and hence nothing bad can happen if no port is opened for the outside (the open ports accept traffic only from 127.0.0.1).

Now validator is a bit tricky -- Validator initiates the connection with the SV (and not the other way), and therefor it is OK if the validator only accepts new connection requests (or just requests) from localhost. But, I am curious about the case where any other component (a front end) connects with the validator, in which case validator does have to listen to new connections from outside it's local machine. If the later is a realistic scenario, then the user has to put -E in the start.sh.

The SV case: SV often gets external requests, so I believe it's default behavior should listen to 0.0.0.0 (all interfaces), instead of localhost. But a counter argument to that is, SV in production use helm charts, and in any realistic setting this docker-compose will be used for local testing. Hence for all practical purposes, I think it is ok to let SV accept connections from localhost only.

@moritzkiefer-da Please let me know what you think.

Thanks

I would actually drop SV and localnet from this PR altogether, and focus only on validators. Everything else is dev tooling, so I'd keep those simple (and vulnerable).

For validators, I think that your all-or-nothing approach of the -E flag makes sense.

I'd look at it this way:

The whole reason we're adding this is that it got flagged as a security issue. Imho the best course of action on that is to change the default for everything including localnet (so yes I strongly disagree with @isegall-da here) Yes it is only localnet but that doesn't really matter. If someone gets an RCE on your machine because you exposed localnet publicly that's bad.

Which then leaves the question of where we allow changing it. There I'd also keep it simple: Allow overwriting it everywhere. If nothing else this is useful for backwards compatibility and there is no real downside. Trying to justify why you really don't need it for e.g. localnet only to then have a user complain that we broke their setup with no option to fix it seems more trouble than just adding the flag.

martinflorian-da · 2025-10-08T17:24:43Z

Looks reasonable to me, nice work @pasindutennage-da !

CI is unhappy, AFAICT due to the log checker. Ideally you can avoid the problematic log; it looks like the better option in this case (the other option being adding it to the right "ignore" file):

Found problems in the sbt output:
time="2025-10-08T15:17:21Z" level=warning msg="The \"HOST_BIND_IP\" variable is not set. Defaulting to a blank string."
time="2025-10-08T15:17:23Z" level=warning msg="The \"HOST_BIND_IP\" variable is not set. Defaulting to a blank string."
Total: 2 lines with problems.

This looks to me like a change we should make more public. How about adding something to docs/src/release_notes.rst?

[ci] Signed-off-by: Pasindu Tennage <[email protected]>

pasindutennage-da · 2025-10-08T18:07:34Z

The CI error comes because the test is not exporting the HOST_BIND_IP correclty. I made a revision, and now if the variable is not set, it uses the default value.

isegall-da · 2025-10-08T18:41:42Z

The CI error comes because the test is not exporting the HOST_BIND_IP correclty. I made a revision, and now if the variable is not set, it uses the default value.

The message was probably from stop.sh. You might want instead to just add HOST_BIND_IP here:

splice/cluster/compose/validator/stop.sh

Line 33 in 38602fd

export VALIDATOR_NEW_PARTICIPANT_IDENTIFIER=""

(where we just export a bunch of env vars, for the exact purpose of avoiding these warnings)

moritzkiefer-da · 2025-10-09T06:24:35Z

Thanks! Changes lgtm overall, definitely should go in the release notes including mentioning the option to turn it back on.

Also please ask someone on macos to test this (probably spin up localnet and check that you can still open the wallet or something like that) as we discussed in slack. Docker on macos can be a bit finicky

Added release notes. Added LocalNet docker-compose the option to chose between 0.0.0.0 and 127.0.0.1 Added exports to stop.sh to avoie CI complains. [ci] Signed-off-by: Pasindu Tennage <[email protected]>

martinflorian-da

Nice job, thank you @pasindutennage-da !

Mainly to try it out (90% sure this doesn't break anything there), you might want to consider doing a (basic) cluster test as well before you merge: https://github.com/hyperledger-labs/splice/blob/main/TESTING.md#requesting-cluster-tests

martinflorian-da · 2025-10-10T17:11:52Z

docs/src/release_notes.rst


    - Replace ``-Dscala.concurrent.context.minThreads=8`` with ``-Dscala.concurrent.context.numThreads=8`` and set ``-XX:ActiveProcessorCount=8``  in the ``defaultJvmOptions`` for all the helm charts that deploy scala apps. This should ensure that the internal execution contexts spawn 8 threads to handle processing and that the JVM is configured for 8 CPUs as well. The previous behavior would spawn up to number of available processors, which can be up to the number of CPUs on the actual node if no CPU limit is set. This should avoid overloading the nodes during heavy processing.

+    - Docker-compose based deployment of LocalNet, Validator, and SuperValidator expose only to 127.0.0.1 by default. If you want to expose externally, use ``-E`` in Validator and SuperValidator ``start.sh``. For LocalNet, ``export HOST_BIND_IP=0.0.0.0`` manually.


Suggested change

- Docker-compose based deployment of LocalNet, Validator, and SuperValidator expose only to 127.0.0.1 by default. If you want to expose externally, use ``-E`` in Validator and SuperValidator ``start.sh``. For LocalNet, ``export HOST_BIND_IP=0.0.0.0`` manually.

- Docker-compose based deployments of LocalNet, validator, and SV now expose only to 127.0.0.1 by default. If you want to expose externally, use ``-E`` in validator and SV ``start.sh``. For LocalNet, set ``export HOST_BIND_IP=0.0.0.0`` manually.

wording nit

martinflorian-da · 2025-10-10T18:14:59Z

...and actually, how annoying would it be to extend our integration tests for these flows to check that all opened ports are bound to localhost?

I.e., DockerComposeFullNetworkFrontendIntegrationTest and DockerComposeValidatorFrontendIntegrationTest.

martinflorian-da · 2025-10-10T18:19:28Z

...and actually, how annoying would it be to extend our integration tests for these flows to check that all opened ports are bound to localhost?

I.e., DockerComposeFullNetworkFrontendIntegrationTest and DockerComposeValidatorFrontendIntegrationTest.

From a quick look at the code there it looks like a reasonable investment; let's do this so we guard against regressions?

pasindutennage-da added 3 commits October 8, 2025 14:19

Fixed Validator docker-compose to use localhost by default, with opti…

82ce972

…on to expose externally. [static] Signed-off-by: Pasindu Tennage <[email protected]>

Added option for cluster/compose/sv docker setup to get external arg …

e405ee6

…to chose between localhost and 0.0.0.0 [static] Signed-off-by: Pasindu Tennage <[email protected]>

Set localhost as the default option in cluster/compose/localnet docke…

88837fe

…r deployment. Hardcoded to localhost, with no option to run externally. Since localnet only runs locally, no need to expose externally. [ci] Signed-off-by: Pasindu Tennage <[email protected]>

pasindutennage-da requested a review from martinflorian-da October 8, 2025 14:54

martinflorian-da reviewed Oct 8, 2025

View reviewed changes

fix(docker): Default HOST_BIND_IP to 127.0.0.1 in Nginx port mapping

272ab1c

[ci] Signed-off-by: Pasindu Tennage <[email protected]>

pasindutennage-da requested a review from isegall-da October 8, 2025 18:32

Added Release notes, and missing flags

b2226ee

Added release notes. Added LocalNet docker-compose the option to chose between 0.0.0.0 and 127.0.0.1 Added exports to stop.sh to avoie CI complains. [ci] Signed-off-by: Pasindu Tennage <[email protected]>

pasindutennage-da requested a review from martinflorian-da October 10, 2025 16:39

pasindutennage-da marked this pull request as ready for review October 10, 2025 16:41

martinflorian-da approved these changes Oct 10, 2025

View reviewed changes


		- Replace ``-Dscala.concurrent.context.minThreads=8`` with ``-Dscala.concurrent.context.numThreads=8`` and set ``-XX:ActiveProcessorCount=8`` in the ``defaultJvmOptions`` for all the helm charts that deploy scala apps. This should ensure that the internal execution contexts spawn 8 threads to handle processing and that the JVM is configured for 8 CPUs as well. The previous behavior would spawn up to number of available processors, which can be up to the number of CPUs on the actual node if no CPU limit is set. This should avoid overloading the nodes during heavy processing.

		- Docker-compose based deployment of LocalNet, Validator, and SuperValidator expose only to 127.0.0.1 by default. If you want to expose externally, use ``-E`` in Validator and SuperValidator ``start.sh``. For LocalNet, ``export HOST_BIND_IP=0.0.0.0`` manually.

	- Docker-compose based deployment of LocalNet, Validator, and SuperValidator expose only to 127.0.0.1 by default. If you want to expose externally, use ``-E`` in Validator and SuperValidator ``start.sh``. For LocalNet, ``export HOST_BIND_IP=0.0.0.0`` manually.
	- Docker-compose based deployments of LocalNet, validator, and SV now expose only to 127.0.0.1 by default. If you want to expose externally, use ``-E`` in validator and SV ``start.sh``. For LocalNet, set ``export HOST_BIND_IP=0.0.0.0`` manually.

Fix issue 2017: setting localhost as default in docker-compose based setups #2601

Are you sure you want to change the base?

Fix issue 2017: setting localhost as default in docker-compose based setups #2601

Uh oh!

Conversation

pasindutennage-da commented Oct 8, 2025

Uh oh!

martinflorian-da Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

pasindutennage-da Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

isegall-da Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

moritzkiefer-da Oct 9, 2025

Choose a reason for hiding this comment

Uh oh!

martinflorian-da commented Oct 8, 2025

Uh oh!

pasindutennage-da commented Oct 8, 2025

Uh oh!

isegall-da commented Oct 8, 2025

Uh oh!

moritzkiefer-da commented Oct 9, 2025

Uh oh!

martinflorian-da left a comment

Choose a reason for hiding this comment

Uh oh!

martinflorian-da Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

martinflorian-da commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinflorian-da commented Oct 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

martinflorian-da commented Oct 10, 2025 •

edited

Loading