This allows e.g. aggregate time statistics if you really care about it
by adding grapevine::database::abstraction::rocksdb=trace to the tracing
filter.
The vast majority of spans are at the info level, so increasing the log
level to info will greatly increase the amount of (useful!) inforamtion
included in the logs.
However, `ruma_state_res` generates a substantial amount of logs, so
that one gets to stay fixed at `warn` for now.
I hate `log_error`. A better way to do this would be to not reuse the
same error type literally everywhere, so you could distinguish, in
`crate::service::sending::Service::handle_response`, whether to emit an
event based on which function created the error. Fixing that is a lot
more work, though.
I think it'd also be good to have a document explaining how to set up
and work with the development environment for contributing code, but I
think that should probably live on a separate, dedicated page.
This adds some new tools in CI for lint the book and also sets up
automated deployment to GitLab Pages. Also adds a readme that suggests
reading the book, since that's where all the information will be.
We don't support this anyway. OCI images will be needed for testing with
Complement, but there are a bunch of other special requirements that has
so these oci image outputs won't be very useful for that anyway.
This is supported on conduwuit, and I liked it because it's faster for
me to type than tab-completing the bot user, and because it makes it a
little easier to copy-paste admin commands.
We want to be able to disable colors for complement logs (since they
are likely to be opened in a text editor). There's no pressing need for
alternative log formats, but I'm interested in whether the 'pretty'
format will be easier for debugging.
I chose to add 'log_*' options rather than making a separate 'log'
section for now. There's been some discussion about trying to separate
the tracing/logging stuff into more structured sections, but that can
happen later.
The "listening for incoming traffic on ..." log line is new, but
something I've wanted even when we only supported one listener.
I considered getting rid of `clippy::too_many_lines` by factoring out
the construction of `app` to a separate function, but found that
specifying it's type (or relevant traits) got quite hairy.
This is a config compatibility break.
The ability to listen on multiple ports, including both TLS and non-TLS,
is necessary for running complement against grapevine.
This isn't exploitable in any way, it just meant that the bot could
receive and run commands from users who were already in the admin room
despite the bot not being in the room, which also means the bot would be
unable to send response messages.
Now, the bot will simply ignore admin room messages if the bot isn't in
the admin room.
This allows the error handling to be done upfront instead of for each
use. In particular, the `toml` error now points to the span of text in
the config file where the misconfigured EnvFilter value is. This is much
better than the previous error that did not indicate what was actually
causing it to happen.
This separates concerns a bit more. We will probably want to extend the
logic for config loading in the future, and that stuff should all live
in the relevant place. This change points us in the right direction.
This functionality was never actually used AFAICT, as no way to provide
alternate profiles was ever provided.
This changes the configuration format to remove the `[global]` section,
everything that was previously under that namespace is now at the top
level.
Just `cat` the config file. Also this code would be very annoying to
maintain. Getting rid of this also revealed that another config option
is specific to RocksDB, so `cfg`s for that have been added.
The configuration file is now the canonical way to, well, configure.
This change is desirable because it gives us much more flexibility with
how configuration is structured. Environment variables are insufficient
because, for example, they're a flat namespace and have no built-in way
to represent lists.
Previously, we only fetched keys once, only requesting them again if we have any missing, allowing for ancient keys to be used to sign PDUs and transactions
Now we refresh keys that either have or are about to expire, preventing attacks that make use of leaked private keys of a homeserver
We also ensure that when validating PDUs or transactions, that they are valid at the origin_server_ts or time of us receiving the transaction respectfully
As to not break event authorization for old rooms, we need to keep old keys around
We move verify_keys which we no longer see in direct requests to the origin to old_verify_keys
We keep old_verify_keys indefinitely as mentioned above, as to not break event authorization (at least until a future MSC addresses this)
Original patch by Matthias. Benjamin just rebased it onto grapevine and
fixed clippy/rustc warnings.
Co-authored-by: Benjamin Lee <benjamin@computer.surgery>
