Automatic double-puppeting for bridge users

[Gredin67]

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

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: true

[Thatoo]

I 'd like to help with this issue but I'm not sure how to make a PR.
I know we should :

• Install the python file in the synapse python path
• Add the module to the config
• Generate a secret value

What is the synapse python path? $final_path/bin/python3?

[MayeulC]

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.

[Thatoo]

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 :

• Check if the shared_secret is existing (not equal to YOUR_SHARED_SECRET_GOES_HERE) or it generates a secret value (if shared_secret value equal YOUR_SHARED_SECRET_GOES_HERE) and add the secret value to the place of YOUR_SHARED_SECRET_GOES_HERE .
• Change "m_login_password_support_enabled" from false to true

[MayeulC]

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.

[Thatoo]

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?

[Josue-T]

Ideally it would be good if we add this also in the config pannel #356

So the user can enable if needed.

[MayeulC]

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.