Support for historical/alternative package names

[luhring]

Context

Every once in a while, a distro package's name changes. One reason for this is that we create a version stream for that package, such as in this PR when we renamed php to php-8.2.

Advisory documents reference packages by their name (in .package.name). So one problem that can arise is if a distro package Melange file changes the package name without updating the corresponding advisory document, the link is broken. In this case, no distro package can be found for the given advisory document.

A more user-visible problem with this scenario is that vulnerability scanners will no longer know to apply security data derived from our advisory document when analyzing the installed distro package. This can result in false positives and false negatives, depending on the scanner matching strategy being used.

One last consideration: it's also possible that simply updating the package name in both the Melange file and the advisory document causes a problem. Although we've updated the distro package name, the former package name has been used in published APKs and still exists "in the wild". If we update the package name in the advisory data, scans of installations of these former versions of the APK will can become less accurate, since relevant data is not being leveraged by the scanner.

Proposal

We could add a new field to the advisory document schema where we can list historical/alternative names for the package described in the given advisory document.

For example, in the above PHP example, we might have an advisory document that now looks like this:

schema-version: 2.0.1

package:
  name: php-8.2
  alternative-names:
    - php

advisories:
# ...

Intended benefits of this change

1. Downstream data artifacts avoid missing this data link. For example, the secdb could include copies of this advisory data listed under both "php-8.2" and "php", ensuring that scanners are never in a place to miss out on this data.
2. Our advisory tooling is able to link to additional related APKs or entries in the APKINDEX when needed.

[puerco]

Mmh interesting. This also has ramifications on "dumber" environments where automation may not have all the context expressed in the advisories. For example when relying on a purl string :/

Also, alternate names to me invoke an idea of bifurcation, where from that point on there may be more than one package name for the same thing. I'm wondering if something like "obsoletes" in rpm may fit better. While we're not really talking about obsolescence here, the sense is to always prefer the new name.

[luhring]

@puerco I think I see what you're saying, and it's a good point. What about naming the field former-names: instead of alternative-names:?

I'm not sure whether this notion will be successfully represented in all downstream formats, but at a minimum it will help us maintain the advisories better; and, we could try to incorporate the concept in future export formats if we believe it would benefit data consumers.