Behaviour of 'arch' param in debian package request

[nnobelis]

Hello,

This is more a question than a bug.
The api/docs of VulnerableCode gives the following quest example:
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie

I try to play with the arch param.
If I query pkg:deb/debian/apt@2.2.4?distro=bullseye to VulnerableCode I receive:

  {
    "url": "http://localhost:9999/api/packages/613937",
    "unresolved_vulnerabilities": [
      {
        "url": "http://localhost:9999/api/vulnerabilities/7783",
        "vulnerability_id": "CVE-2011-3374",
        "references": [
          {
            "reference_id": "CVE-2011-3374",
            "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3374",
            "scores": [
              [...]

And if I look on https://security-tracker.debian.org/tracker/CVE-2011-3374 I see that all versions are vulnerable.

Then when I query
pkg:deb/debian/apt@2.2.4?distro=bullseye&arch=amd64
why do I get no vulnerabilities ?

[
  {
    "type": "deb",
    "namespace": "debian",
    "name": "apt",
    "version": "2.2.4",
    "qualifiers": {
      "arch": "amd64",
      "distro": "bullseye"
    },
    "subpath": null,
    "unresolved_vulnerabilities": [],
    "resolved_vulnerabilities": [],
    "purl": "pkg:deb/debian/apt@2.2.4?distro=bullseye&arch=amd64"
  }
]

Shouldn't the same vulnerability be returned since it affects all versions ?

Version of VulnerableCode used: 4677f70

[sbs2001]

@nnobelis there are two problems in this case:

1. The advisory mentions all versions are vulnerable, but vulnerablecode only considers 2.2.4 vulnerable because it is explicitly mentioned. It doesn't really read the description of advisory. It is also likely that the statement "all versions are vulnerable" is no longer true, since it's been like 10 years since it was published.

2. Regarding the arch thing, the API would only return results if the qualifier part is exact match. And after running the import I don't see packages with such qualifiers. I'm not sure that we want to deviate from this behaviour. Since if the package is being looked up by a specific purl in the API, giving fuzzy result might not be ideal. @pombredanne thoughts ?

[pombredanne]

Great catch. This is a bug. 🐛 We need have a different behavior and when querying with qualifiers, then purls without qualifiers should also be returned.

[pombredanne]

@sbs2001 our posts crossed and I had not seen your reply before posting mine!

You wrote:

Since if the package is being looked up by a specific purl in the API, giving fuzzy result might not be ideal. @pombredanne thoughts ?

I think we need to have a correct way to handle this concern:

1. one way is to ensure that we have all the known qualifiers permutations recorded and stored
2. another way is to have a mode where qualifiers can be processed in a smarter way. Here for instance If the vulnerability query is for a given arch qualifier only, then we should match that exactly... but if it is not we could also lookup a package without the qualifiers. And this could be the default or an option.... TBD

[pombredanne]

@sbs2001 also in this case the statement in https://security-tracker.debian.org/tracker/CVE-2011-3374 "It was found that apt-key in apt, all versions, ..." is correct. All version are affected including the current latest ones on multiple streams, even though this is 10+ years old. It could be one of these cases where curation is the way out ?

There is another interesting issue related here too: https://web.archive.org/web/20150926125956/https://security-tracker.debian.org/tracker/CVE-2011-3374 ... the versions 6 years ago were very different and also 6 months ago https://web.archive.org/web/20210328044526/https://security-tracker.debian.org/tracker/CVE-2011-3374

.... which our approach with resolving versions would catch and enumerating versions would catch too. To enumerate safely, we likely might need to collect the whole set of historical changes for Debian as the JSON API otherwise only expose the latest and greatest package versions when there are open ranges like these.

[nnobelis]

My 2 cents: it seems that Debian does not expose on which arch a package is vulnerable.
I found an example of a vulnerability where they explain, in the description that 64 bits packages are not vulnerable.
https://security-tracker.debian.org/tracker/CVE-2021-25217

Therefore one can not assume that, because the bug is in a given package, it will be present on all architectures :(

I am in favour of @pombredanne solution of a lenient or fuzzy parameter to control VulnerableCode behaviour.
But any solution will do really. Current I don't pass the arch to get all results.