search

swicg / activitypub-http-signature

Repository for a SocialCG report on how HTTP Signature is used with ActivityPub
https://swicg.github.io/activitypub-http-signature/
11 stars 1 forks source link

Distinction between GET and POST requests #44

Closed evanp closed 6 months ago

evanp commented 7 months ago

Section 2.1 describes how to implement HTTP Signature for a POST request (notably, generating a Digest for the body). This isn't necessary or even possible for a GET request. Since signed GET requests are needed for Authorized Fetch, it'd be good to include this in the procedure, too.

evanp commented 7 months ago

I guess similarly for section 2.2. No need to hash the body.

snarfed commented 6 months ago

Hmm! I didn't mean for that section to be POST-specific. My experience (and code) expects and sends Digest headers for GETs as well as POSTs; GETs just have an empty request body.

I don't know how many existing fediverse servers require Digest for GETs in practice. @nightpool @perillamint @aumetra any idea?

nightpool commented 6 months ago

Mastodon has 4 requirements, which can be seen here: https://github.com/mastodon/mastodon/blob/main/app/controllers/concerns/signature_verification.rb#L125

WRT digest, it requires both:

  1. For all requests, either "Digest" or "(request-target)" must be signed
  2. Separately, if the request is a POST, then Digest must be signed.

On Mon, Apr 8, 2024 at 1:53 PM Ryan Barrett @.***> wrote:

Hmm! I didn't mean for that section to be POST-specific. My experience (and code) expects and sends Digest headers for GETs as well as POSTs; GETs just have an empty request body.

I don't know how many existing fediverse servers require Digest for GETs in practice. @nightpool https://github.com/nightpool @perillamint https://github.com/perillamint @aumetra https://github.com/aumetra any idea?

— Reply to this email directly, view it on GitHub https://github.com/swicg/activitypub-http-signature/issues/44#issuecomment-2043332312, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV3Q7EZT2ST4TMC6M7TY4LKRDAVCNFSM6AAAAABF2Q7TFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGMZTEMZRGI . You are receiving this because you were mentioned.Message ID: @.***>

aumetra commented 6 months ago

In general Digest doesn't make sense for GET requests, since the digest is always about the request body and a GET request just doesn't have a request body.
So requiring one would always force the client to always send the same header

Digest: SHA-256=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

The hash of an empty string/null. So I don't think any fediverse server requires the Digest header in practice for GET requests.

snarfed commented 6 months ago

Thanks @nightpool!

@aumetra you're definitely right that it doesn't make sense, but code in the wild often does all sorts of things that don't necessarily make sense. 😁 Eg my own code in Bridgy Fed currently requires Digest on GET requests, even though it probably shouldn't. One common reason may be that most servers will use the same code path for verifying POST and GET signatures.

Anyway, I was curious to hear other examples in the wild. Mastodon's is useful!

perillamint commented 6 months ago

Misskey version after 2023.11.1-beta.1 Firefish version after 1.0.5-rc CherryPick version after 4.5.1

will require Digest header on POST /inbox

Also, AFAIK, as of now, Misskey and its forks does not support signed GET on their resources (so, if someone misses mentioned people only message in their inbox, it is impossible to fetch it, even the valid recipient knows the status URL)

snarfed commented 6 months ago

Thanks all. Added language to section 2.1 that Digest may sometimes/usually be optional for GETs. Tentatively closing. Feel free to re-open!