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

Don't update an existing config file #401

Open
wants to merge 17 commits into
base: main
Choose a base branch
from
Open

Conversation

Azrenbeth
Copy link
Contributor

@Azrenbeth Azrenbeth commented Sep 16, 2021

Followed by #402 and #404.

Currently, if you delete the signing key from the config file, a new one gets generated and the config file gets updated.

This causes two issues:

  • The config file cannot be set to be read-only.
  • You may want a minimal config file (with only the things you're overriding from the defaults) but this update will write all of the default values into your minimal config file as well.

How Sydent will now behave:

  • If there is no config file, generate a new one and then stop, with log message telling user to run the generate-key script.
  • If there is a config file and it has a base64 encoded signing key, run as normal.
  • If there is a config file and it has a hex encoded signing key, run as before but without updating the format of the signing key to base64 (instead log a warning telling the user to run the new update-key script) - note keys haven't been Hex encoded since 2015
  • If there is a config file and it has no signing key, exit with log message telling user to run the generate-key script

The idea is that in the future the user can/must instead run a generate-config script before the first run of Sydent, and there will be documentation on how the configuration works.

This isn't particularly a loss of backwards compatability, for people updating from previous versions:

  • If they have an existing config, the only change they'll experience is having to run the the generate-key script to make new keys instead of just being able to delete their value from the config.
  • If they don't have an existing config, they need to run the generate-key script before they can get Sydent to start. (Or generate-config script added in Add generate-config script and document config options #404)

@Azrenbeth Azrenbeth marked this pull request as ready for review September 20, 2021 11:13
@Azrenbeth Azrenbeth requested a review from a team September 20, 2021 11:15
@Azrenbeth Azrenbeth marked this pull request as draft September 20, 2021 12:11
@Azrenbeth Azrenbeth removed the request for review from a team September 20, 2021 12:11
@Azrenbeth Azrenbeth marked this pull request as ready for review September 20, 2021 12:42
@Azrenbeth Azrenbeth requested a review from a team September 20, 2021 12:43
@clokep
Copy link
Member

clokep commented Sep 20, 2021

Do we want to put upgrade notes for this somewhere? It seems like it would mostly be copying out of the description. Probably in the CHANGELOG.md file directly?

@@ -49,5 +49,8 @@ ENV SYDENT_DB_PATH=/data/sydent.db
WORKDIR /sydent
USER sydent:sydent
VOLUME ["/data"]

RUN python3 /sydent/scripts/generate-key >> /data/sydent.conf
Copy link
Member

Choose a reason for hiding this comment

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

Is there any risk here of adding keys to the file more than once?

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, since the file now won't get written to by Sydent if it exists, and running this script is the place where the file gets created.

One thing that might be of concern though - which I'd initially overlooked - is if this docker image gets used by more than one person, they'd be using the same keys! (Since the key gets generated while it's being built, whereas before it was generated when it was run). Do you think this is an issue?

Copy link
Member

Choose a reason for hiding this comment

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

Do you think this is an issue?

That's probably not good, yes. It also means that anyone would have access to the keys just by loading the image.

Does the same provider (e.g. matrix.org) need to use the same keys over time or would it be OK to rotate them for every release or something else?

Copy link
Member

Choose a reason for hiding this comment

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

yes, let's not hardcode the keys into the docker image.

Technically, I think it's ok for a server to use a different key each time it is started. I think this means that there is a much simpler option here: at startup, if there is no key in the config file, emit a warning and make up a key for the duration of that run.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why would it be ok for it to use a different key each time it started? Wouldn't that mean any verification messages sent before a restart could no longer be used?

Instead of using different keys for each run, the docker file could run a script which checked for the existance of the config file, if it doesn't exist (which it won't on the first run) generate keys and then start sydent, else just start sydent.

Copy link
Member

Choose a reason for hiding this comment

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

Why would it be ok for it to use a different key each time it started?

because, iirc, the key used to sign a given 3pid invite event is embedded in that event. Though I might be misremembering how all this works.

Copy link
Member

Choose a reason for hiding this comment

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

ok, looking harder, I think this is nonsense, so we better go with your suggestion :)

Copy link
Member

Choose a reason for hiding this comment

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

alternatively, I think it would be reasonable to require the user to do a manual step to generate the keys, and just refuse to start if they are not present.

scripts/update-key Show resolved Hide resolved
scripts/update-key Outdated Show resolved Hide resolved
sydent/config/crypto.py Outdated Show resolved Hide resolved
@clokep clokep requested review from a team and removed request for clokep September 21, 2021 12:53
@clokep
Copy link
Member

clokep commented Sep 21, 2021

I'm going to throw this back on the @matrix-org/synapse-core pile as I'm not sure I have enough context into how these keys are used to be confident in my review!

Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

a few thoughts on this!

scripts/generate-key Outdated Show resolved Hide resolved
scripts/update-key Outdated Show resolved Hide resolved
@@ -49,5 +49,8 @@ ENV SYDENT_DB_PATH=/data/sydent.db
WORKDIR /sydent
USER sydent:sydent
VOLUME ["/data"]

RUN python3 /sydent/scripts/generate-key >> /data/sydent.conf
Copy link
Member

Choose a reason for hiding this comment

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

yes, let's not hardcode the keys into the docker image.

Technically, I think it's ok for a server to use a different key each time it is started. I think this means that there is a much simpler option here: at startup, if there is no key in the config file, emit a warning and make up a key for the duration of that run.

scripts/update-key Outdated Show resolved Hide resolved
scripts/generate-key Outdated Show resolved Hide resolved
sydent/config/__init__.py Show resolved Hide resolved
sydent/config/__init__.py Outdated Show resolved Hide resolved
changelog.d/401.removal Outdated Show resolved Hide resolved
- update changelog
- multiline strings in script output
- add --quiet option to generate-key
@richvdh richvdh removed their request for review September 27, 2021 13:17
@richvdh
Copy link
Member

richvdh commented Sep 27, 2021

@Azrenbeth I'm going to put this back in your court to do something about #401 (comment).

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