I've been debugging some signature problems with #Pixelfed this evening and just discovered the root cause.

Justin Thomas

I've been debugging some signature problems with #Pixelfed this evening and just discovered the root cause. Using the param accessors on a rocket::request::Request strips the " characters from the header strings. That causes a verification string from Pixelfed to look like this:

(request-target): post /user/jdt/inbox
host: enigmatick.social
date: Mon, 20 Jan 2025 03:29:29 GMT
digest: SHA-256=tvVdCEGSoxNEj7oVFAP605tc/SddUSK7TvqoI51qAsI=
content-type: application/ld+json; profile=https://www.w3.org/ns/activitystreams
user-agent: (Pixelfed/0.11.9; +https://pixels.jdt.io)

However, Pixelfed signs a string that looks like this:

(request-target): post /user/jdt/inbox
host: enigmatick.social
date: Mon, 20 Jan 2025 03:29:29 GMT
digest: SHA-256=tvVdCEGSoxNEj7oVFAP605tc/SddUSK7TvqoI51qAsI=
content-type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"
user-agent: (Pixelfed/0.11.9; +https://pixels.jdt.io)

Note the content-type differences. For cryptographic purposes, that's a deal breaker.

I spent some time reading the Pixelfed source code and mocking up the verification routines to finally arrive at that discovery. Adding the double quotes manually allows the verification to be successful.

I'll look up the specifications in a second, but #lazyprogrammer question: is that a problem at Pixelfed or in Rocket? Are HTTP headers supposed to be stripped of double quotes?

#Rust #RustLang #ActivityPub

Justin Thomas

@jdt This may end up being the difference between:

let content_type = get_header("content-type");

…and…

let content_type = request.content_type().map(|x| x.to_string());

In the first, I'm using a function that interacts with the headers() map directly. In the second (which is what I had been using), I'm passing the processing through Rocket's ContentType struct. I think that may be where my problem lies.

Rebuilding now.