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 searching for rooms in the ubuntu.com instance from federation #126

Closed
ilvipero opened this issue Dec 13, 2023 · 8 comments
Closed

Comments

@ilvipero
Copy link

Your use case

What would you like to do?

I would like to grant external users from federated servers to be able to add ubuntu.com to the server search list.
This is currently not allowed, as shown in the attached screenshot.

Why would you like to do it?

I would like to enable this feature so that users that are not logging in directly on our instance can still search rooms on the ubuntu.com instance. This will make our instance more accessible to people that do not have direct links to our rooms and spaces.

How would you like to achieve it?

This article on Matrix.org goes through a couple of relevant options in the homeserver.yaml file: https://matrix.org/blog/2019/11/09/avoiding-unwelcome-visitors-on-private-matrix-servers/

unable-to-search-matrix-homeserver

Have you considered any alternatives?

No response

Additional context

No response

@amandahla
Copy link
Collaborator

The allow_public_rooms_over_federation is true by default and it was added as configuration in case we decided to change it.
The allow_public_rooms_without_auth defaults to false and is not handled by the charm.

I'm concerned that enabling it could be a potential security risk:
"Relying on security-by-obscurity is a very bad idea: all it takes is for someone to scan the whole internet for Matrix servers, and then trying to join (say) #finance on each discovered domain (either by signing up on that server or by trying to join over federation) to cause problems."

Note: this option only relates to public room list/search. If a user know the name of the room, they can join it by federation as expected.

@merkata @gregory-schiano thoughts?

@gregory-schiano
Copy link
Contributor

My understanding of the feature request is to have them enabled for federated servers, but not for unauth
I would like to grant external users from federated servers to be able to add ubuntu.com to the server search list.
So it makes reference to allow_public_rooms_over_federation, could we have a bug ?

@3v1n0
Copy link

3v1n0 commented Dec 14, 2023

"Relying on security-by-obscurity is a very bad idea: all it takes is for someone to scan the whole internet for Matrix servers, and then trying to join (say) #finance on each discovered domain (either by signing up on that server or by trying to join over federation) to cause problems."

Well, in my opinion to avoid this problem we should just have different homeservers for ubuntu.com and canonical.com where only ubuntu one needs to be fully publicly federated.

As currently having ubuntu.com as federated but not browsable, makes it almost impossible to use for the whole community, and it will make very hard to get users from other matrix servers, as they won't easily find us. Basically trashing the most important point of moving to to matrix.

@merlijn-sebrechts
Copy link

merlijn-sebrechts commented Jan 6, 2024

Can we get an update on this issue? This makes it difficult for external users to actually join our rooms. Some observations from my side:

The allow_public_rooms_over_federation is true by default and it was added as configuration in case we decided to change it.

Adding the server search list from matrix.org is not possible. Matrix.org is federated, so this seems to conflict with your statement. Is this a bug in the operator?

I'm concerned that enabling it could be a potential security risk:
"Relying on security-by-obscurity is a very bad idea: all it takes is for someone to scan the whole internet for Matrix servers, and then trying to join (say) #finance on each discovered domain (either by signing up on that server or by trying to join over federation) to cause problems."

I think it's the other way around: the blogpost states that relying on these two configuration values for security is bad. Even with both config options set to true, users can still join any public room, simply by guessing the name. So enabling both config options would have very little impact on security.

If some rooms should not be joined by the public, then those rooms need to be private. This is already the case: people using the server correctly anticipate that public rooms can be joined by anyone on the federated network. All private rooms are set to private, from what I can tell.

@nbuechner
Copy link

nbuechner commented Feb 12, 2024

I had to explicitly set this on my homeserver to make public room discovery work:

allow_public_rooms_without_auth: true
allow_public_rooms_over_federation: true

It should be the default setting but did not work until i set the values.

@3v1n0
Copy link

3v1n0 commented Feb 12, 2024

Ok this is fixed now, at least I've been able to browse the rooms from both element and nheko

@cbartz
Copy link
Contributor

cbartz commented Nov 12, 2024

@gregory-schiano #126 (comment) indicates this is fixed now, can you confirm and close the ticket, please?

@gregory-schiano
Copy link
Contributor

Fixed with #119

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

No branches or pull requests

7 participants