This is a collection of information about determining the dependencies of a projects, or determining the SBOM, the bill of material for a project.
All information shown on Nuget (https://www.nuget.org/) is pulled from
the nuget packages itself - no additional information is added manually.
Examples:
- Name (mandatory)
- Version (mandatory)
- Description (mandatory)
- Authors (mandatory)
- Website (
projectUrl
, optional) - Version Control System (
repository
, optional) - License (
license
orlicenseUrl
(deprecated), optional) - Copyright (
copyright
, optional) - Release Notes (
releaseNotes
, optional) - Title = user friendly name of the package (
title
, optional) - Dependencies (optional)
There is no reliable information about the source code. A heuristic would be to look for the version control system or website. If it is GitHub, then try to guess the source code file, see GitHub section.
CaPyCLI 1.0 reads the packages.config
, .csproj
or .sln
file and extracts name
and version. From this information the package-url is created.
There is no support to download the source code.
CycloneDX (https://github.com/CycloneDX/cyclonedx-dotnet) searches recursively all Visual Studio solution or project files for package references. The meta data of the packages is retrieved from the nuspec file on the NuGet packages. The NuGet packages are found in the global NuGet cache folder.
CC Automation needs access to all build results of the project, especially to
the deps.json
files and the packages
folder. The tool allows to provide
a list of packages that should get ignored.
(some magic)
CC Automation uses the NuGet API to retrieve meta data about the packages.
This meta information also can contain repository meta data like the
repository URL and the commit id. Only if this information is available,
the source code URL can then be created like this:
https://github.com/{WebUtility.UrlEncode(owner)}/{WebUtility.UrlEncode(name)}/archive/{commitSha}.tar.gz
This method is clever, but does not work for Microsoft packages.
- Name
- Version
- Description (optional?)
- Homepage (optional)
- Repository (optional)
- Author (optional?)
- License (optional)
- Dependencies (optional)
Examples:
CaPyCLI 1.0 reads the packages.json
or better package-lock.json
file and extracts name
and version. From this information the package-url is created.
If a resolved
entry is found, then it is used as URL of the binary.
The URL for meta information is guessed as
url = "https://registry.npmjs.org/" + Name + Version
If the URL exists, then the following properties may get extracted:
- Homepage
- SourceUrl
- Description
- BinaryFileHash
...detailed analysis pending...
CycloneDX (https://github.com/CycloneDX/cyclonedx-node-module) uses the package
read-installed
to determine all packages. This list in then transferred to a CycloneDX
bill of material.
Available information:
- Name
- Version
- Description
- License
- package-url
- Homepage
- Repository
All information shown on PyPi (https://pypi.org/) is pulled from
the pypi packages itself - no additional information is added manually.
Examples:
Available Information:
- Name
- Version
- Homepage
- Repository
CaPyCLI v1.0 can either parse a requirements.txt
file or call pip3 list --format json
.
For a requirements.txt
file we only get the component name and version and create the
package-url out of it.
With internet access we can guess the PyPi URL:
url = https://pypi.org/pypi/ + name + / + version + /json
If the URL exists, then the following properties may get extracted:
- ProjectSite
- DeclaredLicense
- Description
- BinaryFile
- BinaryFileUrl
- SourceFile
- SourceFileUrl
...detailed analysis pending...
...detailed analysis pending...
...detailed analysis pending...
...detailed analysis pending...
People are working on support for Debian packages and Ruby, but it may still take some time...
Nearly no component management system provides reliable information of the source code. From the development point this is only optional - an application only requires the binary. Information on the sourec code repository or website if often available. What we can do, is to guess the source code download address from the website.
Assume we have the component Tethys.Logging, 1.6.1
and the website address
https://github.com/tngraf/Tethys.Logging
. The we can guess the source code download
address https://github.com/tngraf/Tethys.Logging/archive/refs/tags/v1.6.1.zip
.
If the URL exists, then we are fine; otherwise a human have to look up the source code.
- Q: Why does CaPyCLI provided only limited support for dependency detection?
A: At beginning most people where happy with a very simple automation that just created components and releases on SW360. All other meta has been entered manually. At the end all is inner source - if you need something, fell free to implement it ;-) Please keep also in mind that getting more meta information often requires to pull additional information from the internet - which is not available on all build machines.