@p@pwm@kallisti@nyx No one actually implements those properly, there is no good spec and only a mashup of drafts and different implementations, and no one can fix it because otherwise it breaks the network down. Misskey and Peertube tried changing the signing algorithm to some automatic signature type detection system, mastodon couldn’t handle it and decided that it’d continue rolling with RSA-SHA256; it does not support any of the alternatives, not even RSA-SHA512 and the latest drafts of HTTP signatures aren’t any better in that regard, because all of these algorithms are deprecated and the entire HTTP signature thing has been reworked. GoToSocial goes on to do yet another different thing, but dialed it back to be Mastodon-compatible. Everyone’s stuck with this way of doing things for now. That’s what happens when implementing very active IETF drafts, really… I would blame Mastodon for introducing something improperly documented (no info on how to determine actor keys without reading source, and they don’t even do it exactly right either) and incomplete (a mash of different versions for the same IETF draft), but honestly, Pleroma isn’t much better in that regard either; and I find it baffling that no proper discussion was had on this subject. Oh well.
For now, HTTP signatures are RSA-SHA256, no PSS, no SHA512, nothing; because no one supports it and it’s a disaster. And Pleroma (before one of my recent patches in develop) will fail to validate signatures for requests with a query string if you include it in your signature (/abc?a signed /abc?a would fail, /abc?a signed /abc would not) because of how poorly read the IETF draft was. Well, expect disasters around it.
> what the hell do you do to get signatures working?
The answer to that is excessively long. I more or less followed the code in Honk/Pleroma/ActivityRelay/Masto and some random Masto blog post (it's https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/ but it is also dated as hell and it doesn't work as-is). Support for ED25519 seems to be aspirational so I just used RSA everywhere, and I sign "(request-target)" (fucking fuck i hate that entire thing), Date, Host, and Digest (extra header for the body; I don't know how it handles GETs because I'm not planning to add signed fetches, SHA-256 works). What is it that you're doing? Might be easier than describing the entire process.
Pleroma often 500s on messages that it doesn't understand because they rely on pattern-matching pretty heavily and don't tend to handle the case where it doesn't match. Use PKIX for the pubkey you're serving or Masto will just break without explaining anything.
> Relevant, I am using cavage draft 6 as that seems to be what both use
iono, man. Specs and documentation seem to have been useless during this entire process.
@p@kallisti@nyx Random, but what the hell do you do to get signatures working? Somehow I managed to get them talking to mastodon but not pleroma. I've looked at the relevant code for both but whatever I do I cannot get pleroma to validate. It even started 500ing on messages mastodon validated.
Relevant, I am using cavage draft 6 as that seems to be what both use (but maybe pleroma doesn't and I didn't pick up on that from their http signatures library)
@nyx@kallisti It is such a pain to debug and Masto's code is nigh-unreadable. I spent an entire day trying to get signatures correct because the documentation does not match the behavior. I can only imagine what new horrors await me the more I try to add.
LitePub was essentially Pleroma forking the spec because ActivityPub authors were ignoring everything that wasn't Mastodon. The prospect of forking the network made them reconsider and they started working with Pleroma's dev team, so fleshing out LitePub became a lower priority, but lanodan said if there's interest in it, then it might get picked back up.
@p@kallisti I see, I was wondering about that because litepub sounded nice in concept since AP in practice is all just implemented as "copy whatever Mastodon does", which makes me extremely not interested in ever developing software that would use it, along with some other issues. but then I saw litepub is also dead =_=
@helene (This is just remotely related...) > That’s what happens when implementing very active IETF drafts, really. Anyone remeber draft-ietf-ipsec-isakmp-xauth-06?
@helene@p@kallisti@nyx literally the first thing you need to implement a new activitypub server is this signature or you're effectively unable to federate. How there is __no__ real documentation other than a stub wiki page linked from an appendix in the w3 published spec is fucking incredible
@pwm@p@kallisti@nyx Yeah, been considering writing that kind of stuff for a while already, and not just on HTTP signatures (+ actor key discovery). Just haven't had the time to get around to doing it so far, my hands are quite full already.
@p@pwm@kallisti@nyx Mastodon has some of the best support for the keyId field in HTTP signatures, with the ability resolving Key objects into Actors, and figuring that out all by itself; what matters to it is having an URI to the Actor as the keyId or set to the URI of a Key object with the owner field set to the Actor’s URI. This allows for having the Actor’s public key separated from the Actor itself and very useful for authentication purposes/locking access to some Actors/etc. The issue is that Mastodon seems to be the only software that supports it so far. GoToSocial seems to be mostly okay with it but it’s barely working, it somewhat works by accident. Misskey remembers keyIds and can map them into Actors; but if it can’t find it, it will use the given activity’s Actor to discover its public key.
Pleroma does the worst thing I’ve seen amongst all fedi software: it assumes the keyId in the signature is an actor URI. It broke down when Misskey decided to have Key objects separated from their Actors and to give them in a subpath (/users/:id/publickey). Instead of actually bothering, someone decided to remove the /publickey from the keyId if it was found at the end of the URI; because that’d give the actor URI with Misskey. That was done around 5 years ago, and I’m still ranting about this. I don’t think I need to explain why that’s terrible…
@p@kallisti@nyx I actually did get signatures working shortly after asking and I cannot quite explain why. I just moved all the signing code into it's own file and will never ever touch it again.
I actually was referencing that blog post too. I still cannot explain the pleroma bad behavior.
Now time to figure out if you `remove` or `undo` or `unfucking-believably-unclear-semantics` to unfollow someone.
@helene In the end It was never integrated into the IPSec RFCs for good reasons but the whole industry created VPN-Appliances and client software with XAUTH that was completely incompatible between vendors. It was an "industry standard" that never worked and the quality of the (mostly windows) client software was abysmal. (And the software in the appliances was not much better...) (Mind you, that was around 2000, but then Windows 2000 and following had (and IMHO still has) quite a clean IPSec implementation... MS abstained from XAUTH for good reasons.)
@p@pwm@kallisti@nyx My guess is that Mastodon expected people to use the given activity’s Actor to discover the associated Actor; which is what Misskey does; but Mastodon doesn’t even do that itself, it removes the fragment from the keyId and uses that as an Actor URI.
I did bring this up last time I complained about actor discovery and HTTP signatures, and it led to this issue on the Mastodon side of things, which I would think is better behaviour.