Signature: Make key management Actor-specific

[obenland]

Minor house keeping item in preparation for #1808, separating the key management bits out from the signature functionality itself. I'm hoping it'll make it easier to update the Signature class in the future.

Proposed changes:

• Moves key management functions to Actors class.
• Updates all references to those functions.
• Deprecates public functions in Signature class.
• Moves unit tests.

Other information:

• [x] Have you written new tests for your changes, if applicable?

Testing instructions:

• Subscribe to your test site from the Fediverse.
• Publish a new post.
• Make sure it still gets delivered to your subscriber and signature management still works.

Changelog entry

• [x] Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• [ ] Patch
• [x] Minor
• [ ] Major

Type

• [ ] Added - for new features
• [x] Changed - for changes in existing functionality
• [ ] Deprecated - for soon-to-be removed features
• [ ] Removed - for now removed features
• [ ] Fixed - for any bug fixes
• [ ] Security - in case of vulnerabilities

Message

Management of public/private keys for Actors now lives in the Actors collection, in preparation for Signature improvements down the line.

[obenland]

@pfefferle Is Actors the best place for this?

[pfefferle]

Is Actors the best place for this?

I would think so!

Maybe we can unify the get_public_key functions a bit to allow a similar functionality for remote users?

Either in the same function:

• if $id is an URI, check for the public key in the ap_actor post_content
• if it is an ID, use the current function

Or a dedicated get_remote_public_key!?

[obenland]

Maybe we can unify the get_public_key functions a bit to allow a similar functionality for remote users?

I was wondering about that, too, but couldn't think of a use case. To verify signatures on incoming requests I think we should always make remote requests to the keyId provided in the signature itself, even if it's from an actor in the db. I wouldn't want to rely on a cached version.

[obenland]

@pfefferle Third time's the charm!