Add user:keys:verify command

[SystemKeeper]

Summary

This occ command checks if the stored public key belongs to the stored private key. In case of a mismatch, some nextcloud functionality is broken (e.g. push proxy registration fails). While this should not happen, it is hard to debug when we end up in such a situation. The command is for verification only, in a next step we could add a second command to update the stored public key.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[SystemKeeper]

Doc add at nextcloud/documentation#11580

[SystemKeeper]

I saw that on a production instance for a single user. Is it possible that two requests end up generating a new keypair and one wins to store the private key and one the public key? Otherwise I am not really sure how to end up in that situation. The instance in question uses S3 to store data, in case that makes a difference.

Ref

server/lib/private/Security/IdentityProof/Manager.php

Lines 99 to 103 in 1d8d43f

	$folder = $this->appData->getFolder($id);
	$folder->newFile('private')
	->putContent($this->crypto->encrypt($privateKey));
	$folder->newFile('public')
	->putContent($publicKey);

Ref

• Not getting notifications on 1 account in the talk app talk-ios#1491

[come-nc]

Good apart from nitpick

[SystemKeeper]

Good apart from nitpick

Thanks! Changed as suggested and updated the documentation.

[come-nc]

Shouldn’t that be part of the encryption application actually?

[SystemKeeper]

Since the keypair is handled in server (https://github.com/nextcloud/server/blob/master/lib/private/Security/IdentityProof/Manager.php) and is also used outside of encryption (e.g. for push at https://github.com/nextcloud/notifications/blob/8c752c19903c7db7e7ea766289258cc9f9df2130/lib/Push.php#L320), I don't think so?