Open Gredin67 opened 2 years ago
I 'd like to help with this issue but I'm not sure how to make a PR. I know we should :
What is the synapse python path? $final_path/bin/python3
?
I would be uncomfortable enabling this by default, though, as everything that touches authentication is an extra security risk, and this is useless for people who don't use bridges.
You can see the python path with htop
on a running system: sudo -u matrix-synapse /opt/yunohost/matrix-synapse/bin/python -m pip list
Alternatively, and better yet, activate the virtual environment from the dedicated user's home directory:
sudo -u matrix-synapse bash # be careful about multi-instance, also not completely sure it works when executing as that user
source ~/bin/activate
pip3 install git+https://github.com/devture/matrix-synapse-shared-secret-auth
Installing the module is not an issue security-wise (unless someone takes over that repository), so it could be there by default; the more risky operation is enabling it in synapse's config.
What if synapse package install the module and add strictly this to the synapse's config :
modules:
- module: shared_secret_authenticator.SharedSecretAuthProvider
config:
shared_secret: "YOUR_SHARED_SECRET_GOES_HERE"
# By default, only login requests of type `com.devture.shared_secret_auth` are supported.
# Below, we explicitly enable support for the old `m.login.password` login type,
# which was used in v1 of matrix-synapse-shared-secret-auth and still widely supported by external software.
# If you don't need such legacy support, consider setting this to `false` or omitting it entirely.
m_login_password_support_enabled: false
The synapse package don't Generate a secret value and don't enable the module. This way, their will be no issue security-wise but it will make it much easier for Yunohost bridge packages.
We let Yunohost bridge packages do the last part :
In that case, you may as well let synapse generate the shared secret.
It might be valuable to provide the python SharedSecretAuthProvider separately in the synapse package, with a checksum, to avoid supply chain attacks, if the module gets loaded by default. Loaded but disabled by default sounds acceptable.
I am not sure if bridges should change that from true to false themselves, or if that configuration should be done from the synapse package.
I am not sure if bridges should change that from true to false themselves, or if that configuration should be done from the synapse package.
You meant from false to true as false would be by default if no bridge is installed, right? That sounds good to me then.
How the synapse package could know it should change from false to true after an admin has installed a bridge package?
Ideally it would be good if we add this also in the config pannel #356
So the user can enable if needed.
shared_secret_authenticator=$(date | sha256sum | base64 | head -c 60; echo)
J'espère juste que tu n'es pas sérieux à l'idée de générer un secret de cette manière? Il faut au minimum utiliser /dev/urandom
:
base64 < /dev/urandom | head -c 128
L'helper qui génère les fichiers de configuration remplace ce type de variables tout seul depuis la configuration: https://yunohost.org/en/packaging_apps_helpers#ynh-add-config
Pardonnez mes mots, mais en classique tradition yunohost, c'est fait de manière pas très propre via des variables globales, utilisées implicitement. Au moins il y a une erreur si les variables ne sont pas définies.
What about enabling double-puppeting automatically for bridge users? https://docs.mau.fi/bridges/general/double-puppeting.html#automatically
We would need to install this alongside synapse package https://github.com/devture/matrix-synapse-shared-secret-auth And enable the module