Add integration test for when remote actor username changes

[angusmcleod]

See further https://socialhub.activitypub.rocks/t/changeable-usernames/830/13?u=angus

[ClearlyClaire]

Hi! Thank you for your PR!
Mastodon doesn't officially support renaming, but as you've seen, it should still handle things relatively gracefully (even though there's still room for improvement).

At a glance, the PR looks ok, but I will do a full review later.

It's still marked as a draft, so is there something in particular you want feedback on?

[angusmcleod]

@ClearlyClaire Thanks for taking a look, it's much appreciated. I've added a few more tests for this case, so it's ready for review now.

[angusmcleod]

@ClearlyClaire Thanks for the feedback. This is what I've done:

• Made the formatting changes you suggested
• Removed the Update Note and Follow specs as suggested
• Added update username support for Update Actor. I think it makes more sense to directly update the username in this case instead of performing a migration, as it's a contained case (i.e. nothing else is going on).
• Added more tests for the Search case (it occurred to me that some services may still return the actor for the old handle).

[ClearlyClaire]

• Added update username support for Update Actor. I think it makes more sense to directly update the username in this case instead of performing a migration, as it's a contained case (i.e. nothing else is going on).

I think we should do something like this eventually, but this is a much more complex endeavour. Indeed, we enforce uniqueness of (username, domain) tuples, so this introduces a new failure path (another account with the same username already exists) that needs extra consideration.

[angusmcleod]

@ClearlyClaire Ensuring username uniqueness is something the remote domain has responsibility for in this case. We can protect against that within the context of Update Actor: angusmcleod@138fee1

[angusmcleod]

Just a gentle bump on this one. If there's anything I can do to make this easier to review, let me know.

[ClearlyClaire]

The proposed behavior changes have some issues, and since doing it right is pretty tricky, I think I'd much prefer if this PR focused on describing the current behavior, even if that is suboptimal.

[ClearlyClaire]

This breaks the assumption that the preferredUsername has been verified to resolve to the right account through webfinger, which could be exploited in the following theoretical setting:

1. identity provider example.com allows its users to point at arbitrary external ActivityPub servers
2. eve creates an account eve@example.com pointing at her ActivityPub server eve.social and gets known as eve@example.com to Mastodon
3. eve@example.com sends an Update to Mastodon where preferredUsername is set to bob
4. eve@example.com is thus renamed to bob@example.com as far as Mastodon is concerned, even though bob@example.com is a different person using a different ActivityPub server

[angusmcleod]

If all of those premises were true that would be an exploit of example.com, not an exploit of Mastodon. To make the point clearer, flesh out the implicit premises:

2.a bob has an account bob@example.com and is not already known to Mastodon (otherwise 3 would not succeed).

2.b example.com allows, or is vulnerable to, actors setting preferredUsernames already used by other actors on the domain (otherwise 3 would not be possible).

Or, more simply, consider the scenario in which example.com does not enforce any kind of username uniqueness, in which case this scenario could already exist, i.e.

2. eve creates an account bob@example.com pointing at her ActivityPub server eve.social and gets known as bob@example.com to Mastodon

In short, as long as Mastodon applies the same username uniqueness rules consistently there isn't really any difference between when an actor from a remote domain is created and when it is updated.

[ClearlyClaire]

In the case I'm describing, example.com would delegate all ActivityPub logic to arbitrary third-party servers and only implement webfinger, so 2.b would be irrelevant, as example.com would not be involved with the preferredUsernames change at all.

[angusmcleod]

That would still be an exploit of example.com not Mastodon. You could do the same thing without this PR, just using the initial activity:

eve creates an account bob@example.com pointing at her ActivityPub server eve.social and gets known as bob@example.com to Mastodon

There is no difference between Create and Update in that scenario.

[ClearlyClaire]

Mastodon does not support Create for actors, and before processing actors, it requires the webfinger discovery to loop back to the actor, as described in https://docs.joinmastodon.org/spec/webfinger/#mastodons-requirements-for-webfinger

Your proposed change skips that test, and that is what I was pointing out.