compromised account cleanup fails with database inconsistency

[ElectricNroff]

If there is a compromised user account, then an administrator must be able to use one of these to prevent access by that account:

PUT /org/{shortname}/user/{username}/reset_secret
PUT /registry/org/{shortname}/user/{username}/reset_secret
PUT /org/{shortname}/user/{username}
PUT /registry/org/{shortname}/user/{username}

Suppose that a user exists in 'registry' but not 'legacy' (e.g., through a bug that is not yet identified or is introduced later).

For reset_secret, this fails with TypeError:

cve-services/src/repositories/baseUserRepository.js

Line 612 in 15238d1

legUser.secret = secret

ultimately causing the transaction to be aborted.

For an attempt to set the user to active: false, this fails with TypeError:

cve-services/src/repositories/baseUserRepository.js

Line 420 in 15238d1

legacyUser.username = incomingParameters?.new_username ?? legacyUser.username

or this occurs:

cve-services/src/repositories/baseUserRepository.js

Lines 512 to 514 in 15238d1

	const legacyUser = await legacyUserRepo.findOneByUUID(identifier)
	if (!legacyUser) {
	throw new Error('Legacy user not found')

again ultimately causing the transaction to be aborted.

Thus, if this type of database desynchronization ever occurs, there is not simply a minor impact in which the affected user may see anomalous behavior, and instead there is a critical loss of administrative control until the database is repaired.