The Component __lt__ function can result in invalid components SortedSet

[joe-dipilato]

Since the lt function only compares type, group, name, version, the components SortedSet can have their ordering violated
This violates the constraints that containers use to track their elements.

Since adding or removing items from the sorted set will only be ordered based on the lt operator, items that have the same type/group/name/version are not ordered deterministically. this can result in checks for contains to pass for ._set but fail for _list.

An example use case is when an SBOM has multiple components that have the same type, group, name, and version, but DIFFERENT qualifiers etc..

The solution just requires updating the lt function to include additional criteria including the purl, cpe, etc...

An additional side-effect of the current lt operation is that the contents produced from the exact same code can produce different outputs.

[madpah]

Whilst ordering is not important according to the CycloneDX schemas, the current implementation with it's use of SortedSet does attempt to provide ordering.

I see no reason to update the __lt__ method to consider all parts of the Component.

[joe-dipilato]

If the bom has multiple components that have the same type/group/name/version, performing components.remove(component) can result in a ValueError since it is possible for the SortedSet to report:
component in components._set -> True
component in components._list -> False

And since the remove SortedSet remove function tries to remove from both _set and _list, the command will raise an Exception.

[jkowalleck]

re: #586 (comment)
@joe-dipilato could you provide a practical example? Something that could e used in regression test?

[joe-dipilato]

An example would be having packages for:

https://repo1.maven.org/maven2/com/google/googlejavaformat/google-java-format/1.19.1

Which contains jars for
-all-deps.jar -javadoc.jar -sources.jar .jar

This is distinguished via purl. e.g.

• pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1?classifier=all-deps
• pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1
• pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1?classifier=javadoc
• pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1?classifier=sources

though the actual components have the same type/group/name/version

[joe-dipilato]

    {
      "bom-ref": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1",
      "group": "com.google.googlejavaformat",
      "name": "google-java-format",
      "purl": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1",
      "type": "library",
      "version": "1.19.1"
    },
    {
      "bom-ref": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1?classifier=all-deps",
      "group": "com.google.googlejavaformat",
      "name": "google-java-format",
      "purl": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1?classifier=all-deps",
      "type": "library",
      "version": "1.19.1"
    },
    {
      "bom-ref": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1?classifier=sources",
      "group": "com.google.googlejavaformat",
      "name": "google-java-format",
      "purl": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1?classifier=sources",
      "type": "library",
      "version": "1.19.1"
    },

[jkowalleck]

re: #586 (comment)
re: #586 (comment)

@joe-dipilato I do not understand. Why do you have the exact same component used multiple times?

Is the following not the only correct form?

{
  "bom-ref": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1",
  "group": "com.google.googlejavaformat",
  "name": "google-java-format",
  "purl": "pkg:maven/com.google.googlejavaformat/google-java-format@1.19.1",
  "type": "library",
  "version": "1.19.1",
  "externalReferences": [
    {
     "type": "distribution",
      "url": "https://repo1.maven.org/maven2/com/google/googlejavaformat/google-java-format/1.19.1/google-java-format-1.19.1.jar"
    }
    // other external refs here ... maybe to `bom`, `sources`, etc...
  ]
}

what is the practical use case in which you would have 4 different versions of com.google.googlejavaformat.google-java-format in the path? Is this a thing in Java, that you install all and hope that the path resolution does not shadow the wrong one? Does this actually happen in the real world?

[joe-dipilato]

@jkowalleck - Yeah this is based on a real-world example.

If you take a look at https://repo1.maven.org/maven2/com/google/googlejavaformat/google-java-format/1.19.1/
there are 4 different jars, so the qualifier is necessary to distinguish between them.

There are many packages that need a qualifier to distinguish.

[jkowalleck]

@joe-dipilato and you have a CycloneDX which includes multiple of the com.google.googlejavaformat.google-java-format? how comes?

[joe-dipilato]

In this case it's included in a bundled software artifact along several other software items that are distinguished by qualiers. As long as it's part of a real software distribution, I believe that the CycloneDx format is intended be able to represent the software dependencies.

[jkowalleck]

thank you for clarification. 💡