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

[nativehyun]

💡 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]

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]

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

[KisaragiEffective]

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

[nativehyun]

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]

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]

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]

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]

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]

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]

I think this code should update user public key:

misskey/packages/backend/src/core/activitypub/models/ApPersonService.ts

Lines 550 to 555 in 44f6216

	if (person.publicKey) {
	await this.userPublickeysRepository.update({ userId: exist.id }, {
	keyId: person.publicKey.id,
	keyPem: person.publicKey.publicKeyPem,
	});
	}

[Hoto-Cocoa]

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]

I think this issue caused by cache of ApDbResolverService

The ApInboxService calls ApPersonService:

misskey/packages/backend/src/core/activitypub/ApInboxService.ts

Lines 767 to 770 in 44f6216

	if (isActor(object)) {
	await this.apPersonService.updatePerson(actor.uri, resolver, object);
	return 'ok: Person updated';
	} else if (getApType(object) === 'Question') {

and the ApPersonService updates user's public key when requested:

misskey/packages/backend/src/core/activitypub/models/ApPersonService.ts

Lines 550 to 555 in 44f6216

	if (person.publicKey) {
	await this.userPublickeysRepository.update({ userId: exist.id }, {
	keyId: person.publicKey.id,
	keyPem: person.publicKey.publicKeyPem,
	});
	}

but ApDbResolverService has cache for public key:

misskey/packages/backend/src/core/activitypub/ApDbResolverService.ts

Lines 38 to 39 in 44f6216

	private publicKeyCache: MemoryKVCache<MiUserPublickey | null>;
	private publicKeyByUserIdCache: MemoryKVCache<MiUserPublickey | null>;

and ApPersonService doesn't dispose that cache.

[Hoto-Cocoa]

and the cache expires after 12h:

misskey/packages/backend/src/core/activitypub/ApDbResolverService.ts

Lines 57 to 58 in 44f6216

	this.publicKeyCache = new MemoryKVCache<MiUserPublickey | null>(1000 * 60 * 60 * 12); // 12h
	this.publicKeyByUserIdCache = new MemoryKVCache<MiUserPublickey | null>(1000 * 60 * 60 * 12); // 12h

so I think this issue will be fixed automatically.

Note: That code introduced in 2024.8.0.

[nativehyun]

and the cache expires after 12h:

misskey/packages/backend/src/core/activitypub/ApDbResolverService.ts

Lines 57 to 58 in 44f6216

	this.publicKeyCache = new MemoryKVCache<MiUserPublickey | null>(1000 * 60 * 60 * 12); // 12h
	this.publicKeyByUserIdCache = new MemoryKVCache<MiUserPublickey | null>(1000 * 60 * 60 * 12); // 12h

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! 😊