Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow 127.0.0.1 in bindTo #851

Closed
wants to merge 0 commits into from

Conversation

ArneBab
Copy link
Contributor

@ArneBab ArneBab commented Aug 29, 2023

For a Tor bridge that excludes all other IPs from the noderef to avoid spilling the real IP

@ArneBab ArneBab force-pushed the allow-127.0.0.1-in-bindTo branch from aa8bc85 to f9b449a Compare September 9, 2023 03:21
@ArneBab ArneBab force-pushed the allow-127.0.0.1-in-bindTo branch from a168b0d to 86bca5f Compare February 18, 2024 09:08
@ArneBab
Copy link
Contributor Author

ArneBab commented Feb 18, 2024

I now added a config option for this.

@ArneBab ArneBab force-pushed the allow-127.0.0.1-in-bindTo branch from 86bca5f to f783938 Compare February 18, 2024 09:09

@Override
public void set(Boolean val) throws NodeNeedRestartException {
if (allowBindToLocalhost != val) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will throw a NullPointerException if val is null.

@Override
public void set(Boolean val) throws NodeNeedRestartException {
if (allowBindToLocalhost != val) {
synchronized(this) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This synchronization is broken, as long as there are places where allowBindToLocalhost is accessed without synchronization, such as in the get() method.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change belongs to a different pull request, doesn’t it?

@gits7r
Copy link

gits7r commented Feb 21, 2024

Binding to localhost already works for darknet node, at least I can decode 127.0.0.1:port from my base64 encoded physical.udp line, so this feature is only related to opennet mode. In this case, shouldn't we register config as node.opennet.allowBindToLocalhost instead of Node.allowBindToLocalhost ?

We could add a comment that it should probably (not mandatory) be used along with node.opennet.includeLocalAddressesInNoderefs and node.opennet.alwaysAllowLocalAddresses, but those latter two config parameters will also work for other Local Addresses even if Bind to Localhost is set to false.

Also, would be good to add 0:0:0:0:0:0:0:1 and/or ::1 in addition to 127.0.0.1 everywhere in order to eliminate any confusion.

A sane description would be for this config param (of please someone make it shorter if possible, I'm not too good at shorting phrases):

"In Opennet mode it would be impossible for someone else to connect to your node using the localhost loopback address. This feature is needed if you use other applications that provides a reachable address of any sort and proxies that to localhost. Currently this node has no way to guess those kind of addresses and add them to your physical.udp line, and there might be no other peers that can reach certain type of addresses. Set this to "true" only if you know what you are doing".

It would be really neat if this would make it into the next. Covers at least few use cases reported on FMS.

* @param set accepts the new value and return an Exception or null (if no exception)
*/
public static <T> ConfigCallback<T> from(Supplier<T> get, Function<T, Exception> set) {
return new ConfigCallback<T>() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did somebody forget to write a test for this? 🤣

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. That was „I can do this quickly before going to bed“ 😓

*
* @param set accepts the new value and return an Exception or null (if no exception)
*/
public static <T> ConfigCallback<T> from(Supplier<T> get, Function<T, Exception> set) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get why you’re doing this but functions returning exceptions rub me all kinds of wrong ways. I’d prefer something like this:

public interface ConfigConsumer<T> {
    void accept(T value) throws InvalidConfigValueException, NodeNeedRestartException;
}

This way we don’t need casting in the set() method, and we don’t have to return anything from the Consumer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that’s much nicer — thank you!

@@ -63,7 +65,7 @@ public void shouldUpdate(){
/** Explicit forced IP address in string form because we want to keep it even if it's invalid and therefore unused */
String overrideIPAddressString;
/** config: allow bindTo localhost? */
boolean allowBindToLocalhost;
Boolean allowBindToLocalhost;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually necessary? The compiler should take care of all the boxing/unboxing…

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it isn’t — thank you!

import freenet.config.ConfigCallback;

/**
* A callback to be called when a config value of integer type changes.
* Also reports the current value.
*/
public abstract class BooleanCallback extends ConfigCallback<Boolean> {
public static BooleanCallback fromBoolean(Supplier<Boolean> get, Function<Boolean, Exception> set) {
return (BooleanCallback) ConfigCallback.from(get, set);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm… this is not how casting works. ConfigCallback.from returns a ConfigCallback object, no amount of casting will magically turn it into a BooleanCallback.

You know, you would have caught that if you had written tests for this. 😠

@ArneBab ArneBab closed this Mar 16, 2024
@ArneBab ArneBab force-pushed the allow-127.0.0.1-in-bindTo branch from ec8a54f to 94d4685 Compare March 16, 2024 22:30
@ArneBab
Copy link
Contributor Author

ArneBab commented Mar 16, 2024

accidentally merged, then undid that merging

@ArneBab ArneBab deleted the allow-127.0.0.1-in-bindTo branch March 16, 2024 22:32
@ArneBab ArneBab restored the allow-127.0.0.1-in-bindTo branch March 16, 2024 22:32
@ArneBab
Copy link
Contributor Author

ArneBab commented Mar 16, 2024

I didn’t find a way to actually undo the closing here, so please check here: #951

I’m sorry for the inconvenience :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants