Let's call this "PM mode":
AUTH_DISABLED=true cargo run --bin trustdIf you haven't setup your Rust development environment yet, i.e. you
don't have cargo, you can alternatively use the latest "trustd-pm"
release binary.
That will create its own database in your current directory beneath
.trustify/.
- To use the GUI, navigate to: http://localhost:8080.
- To use the REST API, navigate to: http://localhost:8080/openapi/.
The app's not much fun without data, e.g. SBOM's and Advisories. There are a few ways to ingest some:
There are some bundles of related data beneath etc/datasets. You can use any HTTP command line client, e.g. curl, wget, or httpie to ingest a zipped archive of SBOMs and/or Advisories like so:
cd etc/datasets
make
http POST localhost:8080/api/v1/dataset @ds1.zipThere is an "Upload" menu option in the GUI: http://localhost:8080/upload
You can also interact with the API directly in a shell:
cat some-sbom.json | http POST localhost:8080/api/v1/sbom
cat some-advisory.json | http POST localhost:8080/api/v1/advisoryYou may configure importers to regularly fetch data from remote sites. See modules/importer/README.md for details.
When testing the app using "PM mode", it may be convenient to set an
environment variable, AUTH_DISABLED=true, to bypass all auth checks.
By default, authentication is enabled. It can be disabled using the
flag --auth-disabled when running the server. Also. by default,
there is no working authentication/authorization configuration. For
development purposes, one can use --devmode to use the Keycloak
instance deployed with the compose deployment.
Also see: docs/oidc.md
HTTP requests must provide the bearer token using the Authorization
header. For that, a valid access token is required. There are
tutorials using curl on getting such a token. It is also possible
the use the oidc client tool:
Installation:
cargo install oidc-cliThen, set up an initial client (needs to be done every time the client/keycloak instance if re-created):
oidc create confidential --name trusty --issuer http://localhost:8090/realms/chicken --client-id walker --client-secret ZVzq9AMOVUdMY1lSohpx1jI3aW56QDPSThen one can perform http request using HTTPie like this:
http localhost:8080/purl/asdf/dependencies Authorization:$(oidc token trusty -b)Model-like bits shared between multiple contexts.
Database entity models, implemented via SeaORM.
SeaORM migrations for the DDL.
The primary behavior of the application.
The REST API server.
The server CLI tool trustd
Arbitrary test-data used for unit tests
Integrated data bundles that show off the features of the app.
Deployment-related (such as compose) files.
If you haven't already, get started!
Potentially our concurrent Postgres installations during testing can exhaust shared-memory. Adjusting shared-memory on OSX is not straight-forward. Use this guide.
Unit tests and "PM mode" use an embedded instance of Postgres that is installed as required on the local filesystem. This is convenient for local development but you can also configure the app to use an external database.
Starting a containerized Postgres instance:
podman-compose -f etc/deploy/compose/compose.yaml upConnect to PSQL:
env PGPASSWORD=trustify psql -U postgres -d trustify -h localhost -p 5432If you don't have the psql command available, you can also use the podman-compose command:
podman-compose -f etc/deploy/compose/compose.yaml exec postgres psql -U postgres -d trustifyPoint the app at an external db:
cargo run --bin trustd api --help
RUST_LOG=info cargo run --bin trustd api --db-password trustify --devmode --auth-disabledA package exists or it does not. Represented by a pURL. No source-tracking required.
Rework to Package. VersionedPackage. QualifiedVersionedPackage. and VersionRangePackage for vulnerable references. Plus appropriate junction tables.
Platonic form of a product may have 0+ CPEs/pURLs. Platonic form of a product may have 0+ known hashable artifacts.
A CVE exists or it does not. Represented by an identifier. No source-tracking required.
A CWE exists or it does not. Represented by an identifier. No source-tracking required.
An Advisory exists or it does not. Represented by a location/hash/identifier. Source tracked from an Advisory Source.
There is probably always an advisory from NVD for every CVE.
Something like GHSA, Red Hat VEX, etc. Maybe? Based on source URL? Regexp! Still unsure here.
They should just point us towards first order advisories to ingest. OSV just tells us to look elsewhere. They are helpers not nouns.
Package Range + Advisory + CVE.
QualifiedPackage + Advisory + CVE.
Both impl'd for pURL and CPE.
hashed document that claims things about stuff. All package/product relationships exist only within the context of an SBOM making the claim.
CPE (Product?) and/or pURLs described by the SBOM