[question] Does Akkoma handle (created)
pseudo-header in HTTP signatures
#797
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#797
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hiya, in GoToSocial v0.16.0-rc1 we've switched from using the
Date
header in outgoing HTTP signatures to using the(created)
pseudo-header described here: https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12#section-2.1.4So the
Signature
header on outgoing GtS GET requests now looks something like this:I tested this against Mastodon and the *keys and it seems to work just fine there, but I was recently told it might not be working correctly for Akkoma, and indeed trying to fetch something from akko.wtf using a GtS 0.16.0-rc1 instance has the Akkoma instance return
Request not signed
.Just wanted to check: does Akkoma (or rather the Pleroma library it depends on) handle the
(created)
pseudo-header? Or does it always assume theDate
header will be present and fail if it's not?This part of the spec would suggest that the latter behavior is correct when
algorithm="rsa-sha256"
:However in GtS's case it uses
algorithm="hs2019"
, so omittingDate
and including(created)
should be OK.One workaround we could do if necessary would be to include both
(created)
ANDDate
, but since they essentially convey the same information I'd rather avoid that if possible.Could you give more info on what might be needed here?
For a bit of context on this, this issue is why we're trying this different way of creating signatures, and this bit of code in Mastodon is what gracefully handles the
hs2019
(created)
case.seems to be the case that the upstream lib doesn't support it, and that's been known about for a while (apparently)
see: https://git.pleroma.social/pleroma/elixir-libraries/http_signatures/-/issues/2
so yeah seems like we'll need to poke around and see if we can fix it our side
Thanks!
I've opened an issue here to track GtS switching to
(created)
: https://github.com/superseriousbusiness/gotosocial/issues/2991As soon as this is fixed in at least Akkoma (but preferably Pleroma as well) I think we can switch back to
(created)
from Date.worth noting there's a merge request for adding support for that: https://git.pleroma.social/pleroma/elixir-libraries/http_signatures/-/merge_requests/8
perhaps this could be added to the akkoma fork of the library until it's upstreamed?
EDIT: seems like this was added to the
created-pseudoheader
branch of the akkoma library forkthe
created-pseudoheader
branch was actually my experiment to do the same thing that doesn't quite work (hence the wip tag)i'll look at this PR, maybe they've beaten me to the punch and saved me trauma trying to fix my own branch
I am running an updated version of the library/akkoma on https://ihatebeinga.live
you should be able to communicate with this instance using the new psudoheader now 🦐
updated over at https://github.com/superseriousbusiness/gotosocial/issues/2991 - merged our update
reopen this if you don't find it works