API key migration must account for keys that pre-date introduction of the odt_ prefix

[nscuro]

Current Behavior

#4566 introduced a migration to the new API key format, which now includes a "public ID" segment.

The migration does not consider keys that do not match the length of prefix + key:

dependency-track/src/main/java/org/dependencytrack/upgrade/v4130/v4130Updater.java

Lines 74 to 77 in b42212f

	clearKey = rs.getString("apikey");
	if (clearKey.length() != ApiKey.LEGACY_FULL_KEY_LENGTH) {
	continue;
	}

This fails to account for API keys that were generated prior to DT v4.9.0, which is where the odt_ prefix was first introduced. Keys generated prior to that version won't match the migration logic's length check, and thus won't be migrated.

This happened in @msymons' test instance, where the first and oldest key has no public ID assigned (it shows as null), and is not marked as legacy (no yellow triangle):

Steps to Reproduce

N/A

Expected Behavior

API keys that pre-date v4.9.0 should be migrated correctly.

Dependency-Track Version

4.13.0-SNAPSHOT

Dependency-Track Distribution

Container Image

Database Server

N/A

Database Server Version

No response

Browser

N/A

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[netomi]

after upgrading to the latest snapshot version (from another 4.13.0-SNAPSHOT) the api key migration seems to have failed in my instance:

Trying to remove that key leads to this frontend error:

no error seems to be logged on the api server.

[nscuro]

@netomi Thanks, we're working on a fix.

[netomi]

I did try the latest snapshot version and the keys remained and I still could not delete them via the UI.
However, I deleted them manually in the database and I figure that the fix prevents the problem in the first place when the migration happens.

[netomi]

Now when creating a new API Key I get this error on the api server logs:

Caused by: org.postgresql.util.PSQLException: ERROR: null value in column "APIKEY" of relation "APIKEY" violates not-null constraint
Detail: Failing row contains (10, null, 2025-02-24 07:55:58.242+00, null, null, vshx9lYX, f, xxxxxxxxxxxxxxxxxx).

Edit: I had to delete the column "APIKEY" manually in the database for the APIKEY table, then it worked again.

[nscuro]

@netomi It seems like for some reason the new migration did not run for you. The remaining keys should have been migrated, and the APIKEY column should have been dropped automatically. @msymons tested it yesterday and it worked for him. I also tested various upgrade paths before merging the changes.

Can you please check your logs for any errors during the migration?

[netomi]

I am sorry, I do not have the logs anymore, I restarted the pod after the first failure.

However, when looking at the changes, I see that the condition to run the migration is as follows:

      return version.isNewerThan(currentVersion)
               || (version.equals(currentVersion) && didOldUpgradeVersionRun);

but in my case it might not have evaluated to true? Maybe a safer check would be to see if the APIKEY column is still present?

[Gepardgame]

@netomi It seems like for some reason the new migration did not run for you. The remaining keys should have been migrated, and the APIKEY column should have been dropped automatically. @msymons tested it yesterday and it worked for him. I also tested various upgrade paths before merging the changes.

Can you please check your logs for any errors during the migration?

The migration wasn't running threw, cause the upgrader thougth he was already on 4.13-SNAPSHOT

after upgrading to the latest snapshot version (from another 4.13.0-SNAPSHOT)
Easiest fix would be to revert the verson in the DB to 4.12, so he is running the upgrades. Happend to me a few times during development of this.