trivy-java-db does not provide a 'latest' tag

[Amndeep7]

Description

You cannot pull trivy-java-db without explicitly specifying a tag, specifically '1' which I presume is the schema version for that db.

trivy-db provides '1' or 'v1.x' (old schema version, exact tag depends on registry), '2' (new schema version), and 'latest'. trivy-checks provides 'latest', major ('1'), major.minor ('1.6'), and major.minor.patch ('1.6.1') tags for the past several versions.

Desired Behavior

While I would prefer if there were consistency across all of the databases in terms of the types of tags provided, I would really appreciate it if trivy-java-db provided a 'latest' tag.

Actual Behavior

Not supplying a tag when trying to pull down trivy-java-db caused the operation to fail.

Reproduction Steps

$ skopeo --policy skopeo.policy.json copy docker://aquasec/trivy-java-db oci-archive:trivy-java-db.tar
FATA[0000] initializing source docker://aquasec/trivy-java-db:latest: reading manifest latest in docker.io/aquasec/trivy-java-db: manifest unknown

### Target

None

### Scanner

None

### Output Format

None

### Mode

None

### Debug Output

```bash
n/a

Operating System

n/a

Version

n/a

Checklist

• Run trivy clean --all
• Read the troubleshooting

[DmitriyLewen]

Honestly, I don't remember why I removed latest tag.

@knqyf263 wdyt? Would you mind adding latest tag (maybe I forgot something)?

[knqyf263]

Unlike typical container images, different versions of trivy-db and trivy-java-db are always incompatible. For example, while an update of debian:latest from version 10 to 11 might not cause significant issues, if trivy-db:latest changes from version 1 to 2 (or from 2 to 3 in the future), it will undoubtedly break. In short, the tag “latest” holds no real meaning for our artifacts. Providing “latest” for trivy-db was a mistake, but we are keeping it only for those already using it.

[DmitriyLewen]

I also remembered that we didn't want to add lastets tag for trivy-java-db, but I was confused by the fact that trivy-db has it.
Thanks for the clarification

[knqyf263]

From the client's perspective, it's important to note that a client of a given version cannot handle multiple DB schemas. For example, version 0.59.0 cannot work with both trivy-db:2 and trivy-db:3. An increase in the DB schema version means the client must be updated accordingly, like v0.59.0 supports trivy-db:2 but not trivy-db:3, while v0.60.0 would have the opposite compatibility. In other words, if v0.59.0 is set to use trivy-db:latest, it will inevitably break when version 3 is released, rendering the benefits of "latest" meaningless. The same applies to trivy-java-db.

[Amndeep7]

Isn't that the behavior with all software that gets released that has major version upgrades? There's an understanding that the user will take on the risk when using the 'latest' tag.

[knqyf263]

What is the benefit for users in our case? Using latest always breaks your workflow when the version is updated. It's not a risk. It'll just break it.