Hey @4ntoine, I'm in the process of refactoring how settings are handled by the Arduino CLI both in daemon and command line mode, I suggest you take a look at #1622 since I know you're using the daemon mode a lot.

I also added a way to customize all settings so I think it supersedes this one.

@silvanocerza Hi, Silvano. Thanks for letting me know! I've quickly looked into it and it looks good to me. The only thing i think is important is to have 0.0.0.0 as a default, no matter hardcoded or configurable (preferred) as in the MR you've linked. This does not limit in any way or cause any problems but will work for back-end/containers/vms out-of-box.

The other minor thing i'm thinking of - those settings separation can take some time. If it does not sound realistic to land it (and release) within a month for instance (le'ts say until February), i'd land this trivial MR first and then land those MR just to have it working oob earlier.

@silvanocerza Hi, Silvano. Thanks for letting me know! I've quickly looked into it and it looks good to me. The only thing i think is important is to have 0.0.0.0 as a default, no matter hardcoded or configurable (preferred) as in the MR you've linked. This does not limit in any way or cause any problems but will work for back-end/containers/vms out-of-box.

Won't do.
That would give the possibility to execute arbitrary code on a machine by anyone since we don't have an authentication step.

You're free to use 0.0.0.0 through configuration after #1622 is merged if you want to take the risks that come with it.

The other minor thing i'm thinking of - those settings separation can take some time. If it does not sound realistic to land it (and release) within a month for instance (le'ts say until February), i'd land this trivial MR first and then land those MR just to have it working oob earlier.

Am pretty confident that we'll have the rework ready in less than a month, we're not probably going to release a new major when that's finished.

In any case, am closing this PR because of the security issues.

Frankly speaking i'm not sure i understand what you mean by "arbitrary code" - it can call only what is downloaded by "core install" with package_index.json signature checked. "127.0.0.1" is not much different from "0.0.0.0". in that regard. Let's imagine any local (same host) script/app can connect and do some weird stuff.

Imo the right way would give the arduino-cli daemon only the limited rights not to hurt anything which is out of the scope of this MR.

Having it configurable would also satisfy my request.

Frankly speaking i'm not sure i understand what you mean by "arbitrary code" - it can call only what is downloaded by "core install" with package_index.json signature checked. "127.0.0.1" is not much different from "0.0.0.0". in that regard. Let's imagine any local (same host) script/app can connect and do some weird stuff.

Imo the right way would give the arduino-cli daemon only the limited rights not to hurt anything which is out of the scope of this MR.

Having it configurable would also satisfy my request.

@4ntoine @silvanocerza
In general, binding the daemon to 0.0.0.0, if not necessary, can expose to the application to CWE-1327 threats.
For this reason, in this circumstance, it is important to follow the Security-By-Design and Reduce Attack Surface security principles.
I think that the desired behaviour, alternatively, can also be obtained adopting some container networking rules or using tools like socat.

my two cents.