Thanks for this!

I know poetry makes it easy lock every little thing down, and it makes testing easier, higher assurance, yadda yadda, but practically, it's quite inflexible when the effective ranges are very small... and on a self-declared lib to boot.

Specifically, hooray for declaring a setuptools dependency: so many pkgutils-using packages forget to.

However the size of the range covered by setuptools ^50.3.2 makes it relatively hard to appease (as in: exactly 1 version).

Selfishly, this is blocking me downstream in packaging this and ultimately jake 1.x for conda-forge.

The same goes for importlib_metadata which unfortunately gets pinned in a number of packages, and seems to change a lot for a backport package.

Anyhow: would the maintainers be open to a PR that:

• loosened the range of e.g. setuptools to be something more like >=50.3.2,<59
• added a CI test excursion for the lowest and highest bound

In the meantime, I may try patching the pin over on conda-forge and running the full test suite...

Hi there! Thanks a ton for this library.

We currently use it to generate SBOMs in pip-audit, and I noticed an interested regression upon upgrading to 2.5.0: it looks like Component.add_vulnerability attempts to add the underlying Vulnerability model to a SortedSet, which in turn fails because Vulnerability doesn't appear to implement the standard comparable operators (e.g. __lt__).

Here's the failing code on our side, which worked in 2.4.0:

        for (dep, vulns) in result.items():
            if dep.is_skipped():
                continue
            dep = cast(service.ResolvedDependency, dep)

            c = Component(name=dep.name, version=str(dep.version))
            for vuln in vulns:
                c.add_vulnerability(
                    Vulnerability(
                        id=vuln.id,
                        description=vuln.description,
                        recommendation="Upgrade",
                    )
                )

            self._components.append(c)

and the failing CI tests on 2.5.0: https://github.com/trailofbits/pip-audit/runs/6832431942?check_suite_focus=true

In my estimation, this looks like a bug/regression, rather than a SemVer breakage -- the Vulnerability model also comes from CycloneDX, so it probably should have been made comparable at the same time that comparability was assumed by introducing SortedSet.

xref https://github.com/trailofbits/pip-audit/pull/292

Creating issue to track adoption of the forthcoming version 1.4 schema specification for CycloneDX.

Preview work can be seen here, but this IS NOT FINAL.

Current estimates are that version 1.4 will be finalised late 2021, early 2022.

Added __lt__() to all model classes used in SortedSet, with tests Explicitly declared Enums as (str, Enum) to allow sorting Added dependency to sortedcollections package Added ComparableTuple to make sorting compound objects easier

Signed-off-by: Rodney Richardson [email protected]

The schema documents suggest that components can be nested inside other components (i.e. for/with hierarchical merging).

Hoewever, if I try to generate such a bom an exception is raised in the validate method here: https://github.com/CycloneDX/cyclonedx-python-lib/blob/6e12be70fb2a71de60428155b4d0ae82fa43ef2d/cyclonedx/model/bom.py#L384 The reason for that is, because nested bom_refs underneath other components are not found by the implementation inside validate.

Am I misunderstanding the schema or is this missing from the validation?

I would like the tool to create exactly the same output if I run it on the same (Pipfile.lock) input file twice. This would make it easier to detect changes over time.

There are several places where the outputs differ:

1. The bom-ref is a GUID, newly generated on each run. This could be the purl (as cyclonedx-dotnet appears to do).
2. The order of externalReferences is not maintained.
3. The order of components/libraries is not maintained.

To be able to use new types, which will be introduced in Python 3.11, the package version shouldn't be pinned to 3.10.x and the package can be installed with any Python version, because you can't know, what the user will use. Here is the official explanation on version pinning

Starting with version 4.0.0, typing_extensions uses Semantic Versioning. The major version is incremented for all backwards-incompatible changes. Therefore, it’s safe to depend on typing_extensions like this: typing_extensions >=x.y, <(x+1), where x.y is the first version that includes all features you need.

Signed-off-by: gruebel [email protected]

• adjusted the type hint for get_component_by_purl and added a test for it 🙂
• changed the list/filter expression to use a list comprehension, which is almost 2x faster in this case 🚀

have a license factory, a thing that i feed a string and that returns the appropriate license model: expression, named license, spdx license.

required for

• https://github.com/CycloneDX/cyclonedx-python/discussions/377
• https://github.com/CycloneDX/cyclonedx-python/issues/378

as a contrast implementation of https://github.com/CycloneDX/cyclonedx-python/pull/410

solution ala

• https://github.com/CycloneDX/cyclonedx-javascript-library/blob/main/src/factories/license.ts
• https://github.com/CycloneDX/cyclonedx-php-library/blob/master/src/Core/Factories/LicenseFactory.php

See https://github.com/CycloneDX/cyclonedx-python-lib/runs/4595932920?check_suite_focus=true.

This appears to be the case since #93 was merged.

FYI: @jkowalleck

Mainly the BOM receives a newly generated uuid assigned on the fly. This is basically a fix to enable passing an optional parameter within the constructor to be used as the uuid.

Bumps Gr1N/setup-poetry from 7 to 8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

the library supports python 3.11 in general.

• [ ] add py 311 support to tox
• [ ] add py 311 support to GH workflows
• [ ] add py 311 support to trove classifiers

Bumps relekang/python-semantic-release from 7.31.2 to 7.32.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

When a BOM is created that has Patch objects with a non empty resolves property, the Issues are ignored and do not appear in the output.

The resolves property stored in a ReleaseNote object is already correctly serialized, so it is just a matter of some code reuse.

See: https://github.com/CycloneDX/cyclonedx-python-lib/pull/312 for a patch and test.