Mirrors/gotosocial
1
0
Fork 0
mirror of https://github.com/superseriousbusiness/gotosocial.git synced 2024-10-31 22:40:01 +00:00
Code Issues Projects Releases Packages Wiki Activity

[docs] Update HTTP signature docs a bit (#2721)

Browse source 
* [docs] Update HTTP signature docs a bit

* Update docs/federation/federating_with_gotosocial.md

Co-authored-by: Daenney <daenney@users.noreply.github.com>

* Update docs/federation/federating_with_gotosocial.md

Co-authored-by: Daenney <daenney@users.noreply.github.com>

---------

Co-authored-by: Daenney <daenney@users.noreply.github.com>
This commit is contained in:
tobi 2024-03-04 11:27:11 +01:00 committed by GitHub
parent 66d9297e64
commit 0b35257312
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 15 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
docs/federation/federating_with_gotosocial.md
View file

@ -12,6 +12,20 @@ This behavior is the equivalent of Mastodon's [AUTHORIZED_FETCH / "secure mode"]
GoToSocial uses the [superseriousbusiness/httpsig](https://github.com/superseriousbusiness/httpsign) library (forked from go-fed) for signing outgoing requests, and for parsing and validating the signatures of incoming requests. This library strictly follows the [Cavage http signature RFC](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12), which is the same RFC used by other implementations like Mastodon, Pixelfed, Akkoma/Pleroma, etc. (This RFC has since been superceded by the [httpbis http signature RFC](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures), but this is not yet widely implemented.)
### Query Parameters
The HTTP signature spec is open to interpretation about whether or not query parameters should be included in the URL used to generate and validate signatures.
Historically, GoToSocial included query parameters in the signature, whereas most other implementations did not. This caused compatibility issues when making signed GET requests, or validating signed GET requests, to Collection endpoints, which typically use query parameters to do paging.
Since 0.14, GoToSocial now attempts to sign and validate requests both with and without query parameters, to ensure better compatibility with other implementations.
When sending a request, GtS will attempt first *with* query parameters included. On receiving a `401` from the remote server, it will reattempt the request without query parameters included.
When receiving a request, GtS will attempt to validate the signature first *with* query parameters included. If the signature fails to validate, it will reattempt validation without query parameters included.
See [#894](https://github.com/superseriousbusiness/gotosocial/issues/894) for more details.
### Incoming Requests
GoToSocial request signature validation is implemented in [internal/federation](https://github.com/superseriousbusiness/gotosocial/blob/main/internal/federation/authenticate.go).
@ -33,7 +47,7 @@ When assembling signatures:
- outgoing `GET` requests use `(request-target) host date`
- outgoing `POST` requests use `(request-target) host date digest`
GoToSocial uses the `RSA_SHA256` algorithm for signing requests, which is in line with other ActivityPub implementations.
GoToSocial sets the "algorithm" field in signatures to the value `hs2019`, which essentially means "derive the algorithm from metadata associated with the keyId". The *actual* algorithm used for generating signatures is `RSA_SHA256`, which is in line with other ActivityPub implementations. When validating a GoToSocial HTTP signature, remote servers can safely assume that the signature is generated using `sha256`.
### Quirks