Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for dependency graph #1

Closed
nscuro opened this issue Mar 8, 2021 · 4 comments
Closed

Add support for dependency graph #1

nscuro opened this issue Mar 8, 2021 · 4 comments
Labels
enhancement New feature or request
Milestone
v0.2.0

Comments

@nscuro
Copy link
Member

nscuro commented Mar 8, 2021

CycloneDX supports dependency graphs.

Coincidentally, Go's go mod graph command provides a module graph in pretty much the same structure:

$ go mod graph
github.com/CycloneDX/cyclonedx-gomod github.com/CycloneDX/cyclonedx-go@v0.1.0
github.com/CycloneDX/cyclonedx-gomod github.com/google/uuid@v1.2.0
github.com/CycloneDX/cyclonedx-gomod golang.org/x/mod@v0.4.1
github.com/CycloneDX/cyclonedx-go@v0.1.0 github.com/bradleyjkemp/cupaloy/v2@v2.6.0
github.com/CycloneDX/cyclonedx-go@v0.1.0 github.com/stretchr/testify@v1.7.0
golang.org/x/mod@v0.4.1 golang.org/x/crypto@v0.0.0-20191011191535-87dc89f01550
golang.org/x/mod@v0.4.1 golang.org/x/tools@v0.0.0-20191119224855-298f0cb1881e
golang.org/x/mod@v0.4.1 golang.org/x/xerrors@v0.0.0-20191011141410-1b5146add898
github.com/bradleyjkemp/cupaloy/v2@v2.6.0 github.com/davecgh/go-spew@v1.1.1
github.com/bradleyjkemp/cupaloy/v2@v2.6.0 github.com/pmezard/go-difflib@v1.0.0
github.com/bradleyjkemp/cupaloy/v2@v2.6.0 github.com/stretchr/objx@v0.1.1
github.com/bradleyjkemp/cupaloy/v2@v2.6.0 github.com/stretchr/testify@v1.6.1
github.com/stretchr/testify@v1.7.0 github.com/davecgh/go-spew@v1.1.0
github.com/stretchr/testify@v1.7.0 github.com/pmezard/go-difflib@v1.0.0
github.com/stretchr/testify@v1.7.0 github.com/stretchr/objx@v0.1.0
github.com/stretchr/testify@v1.7.0 gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c
golang.org/x/crypto@v0.0.0-20191011191535-87dc89f01550 golang.org/x/net@v0.0.0-20190404232315-eb5bcb51f2a3
golang.org/x/crypto@v0.0.0-20191011191535-87dc89f01550 golang.org/x/sys@v0.0.0-20190412213103-97732733099d
golang.org/x/tools@v0.0.0-20191119224855-298f0cb1881e golang.org/x/net@v0.0.0-20190620200207-3b0461eec859
golang.org/x/tools@v0.0.0-20191119224855-298f0cb1881e golang.org/x/sync@v0.0.0-20190423024810-112230192c58
golang.org/x/tools@v0.0.0-20191119224855-298f0cb1881e golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7
github.com/stretchr/testify@v1.6.1 github.com/davecgh/go-spew@v1.1.0
github.com/stretchr/testify@v1.6.1 github.com/pmezard/go-difflib@v1.0.0
github.com/stretchr/testify@v1.6.1 github.com/stretchr/objx@v0.1.0
github.com/stretchr/testify@v1.6.1 gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c
gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c gopkg.in/check.v1@v0.0.0-20161208181325-20d25e280405
golang.org/x/net@v0.0.0-20190404232315-eb5bcb51f2a3 golang.org/x/crypto@v0.0.0-20190308221718-c2843e01d9a2
golang.org/x/net@v0.0.0-20190404232315-eb5bcb51f2a3 golang.org/x/text@v0.3.0
golang.org/x/net@v0.0.0-20190620200207-3b0461eec859 golang.org/x/crypto@v0.0.0-20190308221718-c2843e01d9a2
golang.org/x/net@v0.0.0-20190620200207-3b0461eec859 golang.org/x/sys@v0.0.0-20190215142949-d0b11bdaac8a
golang.org/x/net@v0.0.0-20190620200207-3b0461eec859 golang.org/x/text@v0.3.0
golang.org/x/crypto@v0.0.0-20190308221718-c2843e01d9a2 golang.org/x/sys@v0.0.0-20190215142949-d0b11bdaac8a

An MVP implementation could simply take this output, convert <path>@<version> expressions to package URLs and be done with it.

Will have to figure out how to deal with replacements though. We currently treat replaced modules as ancestors in the replacement component's pedigree. However, the module graph will still reference the replaced module, not the replacement.
@nscuro nscuro added the enhancement New feature or request label Mar 8, 2021
nscuro added a commit that referenced this issue Mar 10, 2021
@nscuro
feat: dependency graph support (#1) �
d0ecdb7
@nscuro
Copy link
Member Author

nscuro commented Mar 10, 2021

Basic dependency graph support is done, as can be seen in this example BOM. Won't close this issue unless I have a good solution for replacements though.

@nscuro
Copy link
Member Author

nscuro commented Mar 11, 2021

The graph provided by go mod graph contains multiple versions of the same module (e.g. golang.org/x/net in the output above). We need to rewire the graph so that it lines up with the module list returned by go list -json -m all. Roughly speaking, Go will use the latest version of a module if multiple versions are in the graph.

@nscuro nscuro added this to the v0.2.0 milestone Mar 11, 2021
nscuro added a commit that referenced this issue Mar 12, 2021
@nscuro
feat: filter & rewire module graph #1
6cb25a9 
Go will only include the latest requested version of a module when compiling, which is reflected in the module list obtained by GetModules. This commit makes it so that the module graph reflects that behavior.
nscuro added a commit that referenced this issue Mar 12, 2021
@nscuro
feat: handle replacements in module graph (#1)
7b06d18
@nscuro
Copy link
Member Author

nscuro commented Mar 12, 2021

As per golang/go#40513, dependencies of replacements are evaluated, but attributed to the replaced module in the module graph. Addressed this by rewiring the all references to the replacement instead.

@nscuro
Copy link
Member Author

nscuro commented Mar 12, 2021

Delivered with v0.2.0 ✔

@nscuro nscuro closed this as completed Mar 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
v0.2.0
Development

No branches or pull requests
1 participant
@nscuro