search

misskey-dev / misskey

🌎 A completely free and open interplanetary microblogging platform 🚀
https://misskey-hub.net/
GNU Affero General Public License v3.0
10.03k stars 1.37k forks source link

Posts are not federated with Misskey on the Mastodon server where RSA Key reset was performed. #14458

Open nativehyun opened 2 months ago

nativehyun commented 2 months ago

💡 Summary

Hello, I am the operator of the pointless.chat mastodon server and I recently reset all users' RSA Keys. After that, it is possible to receive posts from Misskey users from Mastodon, but posts sent from pointless.chat Mastodon to Misskey will not be federated.

🥰 Expected Behavior

All users' posts should be federated normally.

🤬 Actual Behavior

Posts sent to Misskey from a Mastodon instance that has reset the RSA Key are not federated. Only Posts sent from Misskey to the Mastodon instance are federated properly.

📝 Steps to Reproduce

  1. Misskey and Mastodon users are followed each other
  2. Run user's RSA Key reset on Mastodon server.
  3. Federation is not working normally on Misskey instance

💻 Frontend Environment

No response

🛰 Backend Environment (for server admin)

No response

nativehyun commented 2 months ago

I found this issue #9877 and it was not fixed on Misskey 2024.08 I tried restarting my personal Misskey server as indicated in the issue, but federation is still not possible.

nativehyun commented 2 months ago
스크린샷 2024-08-24 22 31 48 스크린샷 2024-08-24 22 33 04

Looking at the logs, it seems that Misskey is ignoring requests for accounts whose RSA keys have changed.

KisaragiEffective commented 2 months ago

Could I ask you to paste logs with plain text to improve search-ability for future reference?

nativehyun commented 2 months ago

Could I ask you to paste logs with plain text to improve search-ability for future reference?

Sure. Here is the plane text of the log.

ERR  1 [queue inbox] failed(UnrecoverableError: skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/zicbakguri#main-key 
    message: 'skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/zicbakguri#main-key', 
    stack: 'UnrecoverableError: skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/zicbakguri#main-key\n' + 
    failedReason: 'skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/zicbakguri#main-key', 
      'UnrecoverableError: skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/zicbakguri#main-key\n' + 
    at async Worker.retryIfFailed (/misskey/node_modules/.pnpm/bullmq@5.10.4/node_modules/bullmq/dist/cjs/classes/worker.js:634:24)) id=4373 attempts=1/8 age=7ms activity=https://pointless.chat/users/zicbakguri/statuses/113017147555239701/activity { 

ERR  1 [queue inbox] failed(UnrecoverableError: skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/Native#main-key 

    message: 'skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/Native#main-key', 
    stack: 'UnrecoverableError: skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/Native#main-key\n' + 
    failedReason: 'skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/Native#main-key', 
      'UnrecoverableError: skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/Native#main-key\n' + 
    at async Worker.retryIfFailed (/misskey/node_modules/.pnpm/bullmq@5.10.4/node_modules/bullmq/dist/cjs/classes/worker.js:634:24)) id=689 attempts=1/8 age=7ms activity=https://pointless.chat/users/Native/statuses/113011930050079754/activity { 
ERR  1 [queue inbox] failed(UnrecoverableError: skip: http-signature verification failed and no LD-Signature. keyId=https://pointless.chat/users/Native#main-key
anatawa12 commented 2 months ago

I feel failing http signature verification is intended because this make impossible to verify the request is from (same as previously) verified author. I'm sorry if replacing keys is permitted (and support is required) in activity pub or other related specs.

nativehyun commented 2 months ago

I feel failing http signature verification is intended because this make impossible to verify the request is from (same as previously) verified author. I'm sorry if replacing keys is permitted (and support is required) in activity pub or other related specs.

As mentioned in issue #9877, when Key Rotation is performed, the instance should receive a new Key from the new remote instance and proceed with federation again. Mastodon is federating normally. Shouldn't Misskey also verify the user's new Key and proceed with federation normally?

nativehyun commented 2 months ago

I feel failing http signature verification is intended because this make impossible to verify the request is from (same as previously) verified author. I'm sorry if replacing keys is permitted (and support is required) in activity pub or other related specs.

As mentioned in issue #9877, when Key Rotation is performed, the instance should receive a new Key from the new remote instance and proceed with federation again. Mastodon is federating normally. Shouldn't Misskey also verify the user's new Key and proceed with federation normally?

In one Misskey instance in Korea, a user's private key was leaked, and the instance was shut down. This is because Misskey cannot rotate the user's RSA Key. I think Misskey also needs a process to receive a new RSA Key from the user, re-verify it, and federate it, and a function to rotate the user's RSA Key.

nativehyun commented 2 months ago

I feel failing http signature verification is intended because this make impossible to verify the request is from (same as previously) verified author. I'm sorry if replacing keys is permitted (and support is required) in activity pub or other related specs.

As mentioned in issue #9877, when Key Rotation is performed, the instance should receive a new Key from the new remote instance and proceed with federation again. Mastodon is federating normally. Shouldn't Misskey also verify the user's new Key and proceed with federation normally?

In one Misskey instance in Korea, a user's private key was leaked, and the instance was shut down. This is because Misskey cannot rotate the user's RSA Key. I think Misskey also needs a process to receive a new RSA Key from the user, re-verify it, and federate it, and a function to rotate the user's RSA Key.

And when the post is renote from another Mastodon instance or Misskey instance, and when the post URL is directly viewed, the post is federated normally.

The problem is that when following an account whose RSA key has been replaced, the follow is not possible, the post from the account whose RSA key has been replaced does not appear in the timeline, and the post does not appear when the account whose RSA key has been replaced mentions the Misskey account.

This seems to be a bug, as some posts are federated normally even from accounts whose RSA keys have been replaced. The problem is that it is not federated immediately.

nativehyun commented 2 months ago

I feel failing http signature verification is intended because this make impossible to verify the request is from (same as previously) verified author. I'm sorry if replacing keys is permitted (and support is required) in activity pub or other related specs.

As mentioned in issue #9877, when Key Rotation is performed, the instance should receive a new Key from the new remote instance and proceed with federation again. Mastodon is federating normally. Shouldn't Misskey also verify the user's new Key and proceed with federation normally?

In one Misskey instance in Korea, a user's private key was leaked, and the instance was shut down. This is because Misskey cannot rotate the user's RSA Key. I think Misskey also needs a process to receive a new RSA Key from the user, re-verify it, and federate it, and a function to rotate the user's RSA Key.

And when the post is renote from another Mastodon instance or Misskey instance, and when the post URL is directly viewed, the post is federated normally.

The problem is that when following an account whose RSA key has been replaced, the follow is not possible, the post from the account whose RSA key has been replaced does not appear in the timeline, and the post does not appear when the account whose RSA key has been replaced mentions the Misskey account.

This seems to be a bug, as some posts are federated normally even from accounts whose RSA keys have been replaced. The problem is that it is not federated immediately.

In issue #9877, it is written that restarting the server will fix the issue, but in the latest version of Misskey 2024.08, restarting the server does not seem to have any effect.

Hoto-Cocoa commented 2 months ago

I think this code should update user public key: https://github.com/misskey-dev/misskey/blob/44f62160cb4b876f415b48b0574592f87bea9b3d/packages/backend/src/core/activitypub/models/ApPersonService.ts#L550-L555

Hoto-Cocoa commented 2 months ago

So I restarted my instance and the federation works perfectly. Our instance using customized (but not customized that code) 2024.5.0 version.

Hoto-Cocoa commented 2 months ago

I think this issue caused by cache of ApDbResolverService

The ApInboxService calls ApPersonService: https://github.com/misskey-dev/misskey/blob/44f62160cb4b876f415b48b0574592f87bea9b3d/packages/backend/src/core/activitypub/ApInboxService.ts#L767-L770

and the ApPersonService updates user's public key when requested: https://github.com/misskey-dev/misskey/blob/44f62160cb4b876f415b48b0574592f87bea9b3d/packages/backend/src/core/activitypub/models/ApPersonService.ts#L550-L555

but ApDbResolverService has cache for public key: https://github.com/misskey-dev/misskey/blob/44f62160cb4b876f415b48b0574592f87bea9b3d/packages/backend/src/core/activitypub/ApDbResolverService.ts#L38-L39

and ApPersonService doesn't dispose that cache.

Hoto-Cocoa commented 2 months ago

and the cache expires after 12h: https://github.com/misskey-dev/misskey/blob/44f62160cb4b876f415b48b0574592f87bea9b3d/packages/backend/src/core/activitypub/ApDbResolverService.ts#L57-L58

so I think this issue will be fixed automatically.

Note: That code introduced in 2024.8.0.

nativehyun commented 2 months ago

and the cache expires after 12h:

https://github.com/misskey-dev/misskey/blob/44f62160cb4b876f415b48b0574592f87bea9b3d/packages/backend/src/core/activitypub/ApDbResolverService.ts#L57-L58

so I think this issue will be fixed automatically.

Note: That code introduced in 2024.8.0.

Glad to hear that! Thank you so much! 😊