search

spantaleev / matrix-docker-ansible-deploy

🐳 Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker
GNU Affero General Public License v3.0
4.9k stars 1.04k forks source link

Automated MMR signing key generation process #3469

Closed Michael-Hollister closed 3 months ago

Michael-Hollister commented 3 months ago

Automated signing key setup process described in https://docs.t2bot.io/matrix-media-repo/v1.3.5/installation/signing-key/

Homeserver backup key is kept alongside the merged signing key in case server administrator needs to revert.

Michael-Hollister commented 3 months ago

Thanks for the feedback, updated PR with your suggestions.

  1. I wonder if this should be enabled by default, or if we should have some way for the user to control it. Right now, people can force-set matrix_media_repo_generate_signing_key to false to disable this behavior, but they must do it before it has already been done. Thoughts?
  2. Given that the procedure is somewhat invasive, I wonder if we should mention it (and the upstream docs page and playbook behavior - merging, backup, etc.) on our matrix-media-repo docs page?

Key generation is enabled by default and can be disabled by setting matrix_media_repo_generate_signing_key to false as you said. I think having the MMR docs page explaining the process would be sufficient. I've updated the MMR docs page explaining the process in more detail, and feel free to let me know if any further changes you'd like to see.

  1. Someone removing matrix-media-repo and deleting all its files (from matrix_media_repo_base_path) and re-enabling it would probably end up with a signing key which contains 3 keys (homeserver original key + 1st matrix-media-repo signing key + 2nd matrix-media-repo signing key). This may not be as bad as it sounds, I guess.

Yeah true, if a user manually deletes the MMR directory and re-runs the setup role, old keys will not be removed. If the user operates outside the playbook, I don't think this is a case we can easily protect against.

We could potentially auto remove old keys if the user runs the setup role with MMR disabled. However perhaps its best if left to the user to manually remove the key for the following reasons:

  1. The playbook could restore from the .backup homeserver signing key. This could be destructive however since if the user modifies the signing key file after running the MMR setup role, those changes will be lost.
  2. The playbook could instead search for the MMR key id in the homeserver signing key file before removal in the uninstall task. This could work, though a bit more code to maintain.
  3. Its recommended to update your homeserver config when revoking/expiring old keys (old_signing_keys field for Synapse and old_private_keys for Dendrite). This would be harder to automate, and changes to the config would be lost when re-running the homeserver setup roles.

Feel free to discuss if you think otherwise.