-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Update Actor preferredUsername support #30361
base: main
Are you sure you want to change the base?
Add Update Actor preferredUsername support #30361
Conversation
Hi! Thank you for your PR! 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? |
@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. |
Co-authored-by: Claire <[email protected]>
….com/angusmcleod/mastodon into add_username_change_integration_test
@ClearlyClaire Thanks for the feedback. This is what I've done:
|
I think we should do something like this eventually, but this is a much more complex endeavour. Indeed, we enforce uniqueness of |
@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 |
Just a gentle bump on this one. If there's anything I can do to make this easier to review, let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
if @account.username != @object['preferredUsername'] | ||
account_proxy = @account.dup | ||
account_proxy.username = @object['preferredUsername'] | ||
UniqueUsernameValidator.new.validate(account_proxy) | ||
opts[:allow_username_update] = account_proxy.errors.blank? | ||
end | ||
|
||
ActivityPub::ProcessAccountService.new.call(@account.username, @account.domain, @object, opts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
- identity provider
example.com
allows its users to point at arbitrary external ActivityPub servers eve
creates an account[email protected]
pointing at her ActivityPub servereve.social
and gets known as[email protected]
to Mastodon[email protected]
sends anUpdate
to Mastodon wherepreferredUsername
is set tobob
[email protected]
is thus renamed to[email protected]
as far as Mastodon is concerned, even though[email protected]
is a different person using a different ActivityPub server
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 [email protected]
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.
eve
creates an account[email protected]
pointing at her ActivityPub servereve.social
and gets known as[email protected]
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 [email protected] pointing at her ActivityPub server eve.social and gets known as [email protected] to Mastodon
There is no difference between Create and Update in that scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm not being clear. I simply mean that, given the scenario you've established, as far as Mastodon is concerned, I don't think there is any difference in the risk profile between this scenario (which is currently possible):
eve creates an account [email protected] pointing at her ActivityPub server eve.social and gets known as [email protected] to Mastodon
And this scenario:
[email protected] sends an Update to Mastodon where preferredUsername is set to bob
In both scenarios, it doesn't matter what Mastodon does with Webfinger, or how many times it re-checks the Actor, as the same risk will be present. Given that, as you've required, this identity server is not performing any username uniqueness checks, assuming that sending a Webfinger request to example.com with [email protected] is always returning the "right" Actor, or the same Actor it returned last time, is equally circumspect. Fundamentally, in both scenarios, Mastodon has no control over the cogency or consistency of external identities. All you can (possibly) control is spoofing (i.e. using HTTP signatures) and your own registration of those identities, e.g. enforcing unique preferredUsername
s on a domain when storing the Actor.
Nevertheless, I think I understand what you're saying, i.e. that Mastodon makes this assumption (that Webfinger entails identity consistency) to an extent, and that this assumption should be followed here too. In that vein I've added in a Webfinger check of the updated username:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will require more careful review to make sure nothing can go wrong, but this looks good after a first review pass. The PR title needs a change though as this is no longer about adding tests, but changing the actual behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the title. Let me know if there's anything more I can do to help the review, whether it be adding more tests or staging this branch somewhere.
Hi there, just chiming in to provide another voice in support of this PR. NodeBB sends Thank you for your hard work :) |
This pull request has merge conflicts that must be resolved before it can be merged. |
See further https://socialhub.activitypub.rocks/t/changeable-usernames/830/13?u=angus