-
Notifications
You must be signed in to change notification settings - Fork 84
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
base: main
Are you sure you want to change the base?
Conversation
44fb10a
to
55ef37a
Compare
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 |
@@ -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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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.
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! |
There was a problem hiding this 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!
@@ -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 |
There was a problem hiding this comment.
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.
- update changelog - multiline strings in script output - add --quiet option to generate-key
@Azrenbeth I'm going to put this back in your court to do something about #401 (comment). |
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:
How Sydent will now behave:
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: