28 releases

new 0.7.3 May 15, 2024
0.6.0 Apr 26, 2024
0.6.0-alpha.8 Feb 23, 2024
0.5.4 Oct 27, 2023

#810 in Parser implementations

Download history 86/week @ 2024-01-21 83/week @ 2024-01-28 102/week @ 2024-02-04 134/week @ 2024-02-11 126/week @ 2024-02-18 206/week @ 2024-02-25 305/week @ 2024-03-03 285/week @ 2024-03-10 72/week @ 2024-03-17 10/week @ 2024-03-24 109/week @ 2024-03-31 52/week @ 2024-04-07 210/week @ 2024-04-14 610/week @ 2024-04-21 203/week @ 2024-04-28 25/week @ 2024-05-05

1,050 downloads per month
Used in 3 crates (2 directly)

Apache-2.0 and LGPL-2.0-or-later

3.5K SLoC

CSAF Walker

crates.io docs.rs GitHub release (latest SemVer) CI

"Walk" CSAF data from a remote server, allowing one to work with the data.

In addition, this repository also has a tool for working with SBOM data. Most of the options explained are valid for both SBOM and CSAF.

From the command line

There's a command line tool, which can be used right away.


cargo install csaf-cli
cargo install sbom-cli

You can also install this using cargo binstall:

cargo binstall csaf-cli
cargo binstall sbom-cli


You can download all documents by providing a domain of the CSAF trusted provider:

mkdir out
csaf sync -3 -v -d out/ redhat.com

It is also possible to only download files, skipping the validation step (which can be done later using an already downloaded copy):

mkdir out
csaf download -3 -v -d out/ redhat.com

[!NOTE] In cases where data is signed with a GPG v3 signature, you can use the -3 flag, which considers this still valid.

An alternative is to use the --policy-date argument, and provide a manual policy date. Also see: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html.

Differential sync

By default, timestamps reported by the HTTP server will be applied to the downloaded files. When re-running, the changes.csv file will be used as a source to discover when a file was changed. If a file is already present and has a newer modification timestamp in the changes.csv file, then it will be downloaded again. Otherwise, it will be skipped.

Using the --since option, it is possible to provide a start timestamp, which will skip all changes reported before this timestamp, and force all changes after this timestamp (independent of the file local file timestamp) to be re-synced.

Using the --since-file option, it is possible to automate the "since" value, by initially loading the "since" value from a file, and storing it into a file at the end of a successful run. The timestamp stored will be the timestamp, when the application started processing.

If both --since and --since-file are provided, then the "since file" will be used first, and the "since" value will act as a fallback if the file is not present.

Sending data

Instead of storing, it is also possible to send data to a remote instance (using the Vexination or Bombastic API).

csaf send -3 redhat.com http://localhost:8083

Of course, it is also possible to use the filesystem as a source:

csaf send -3 file:out/ http://localhost:8083

As a library

Using the crate csaf-walker, this can also be used as a library:

use anyhow::Result;
use url::Url;
use csaf_walker::source::HttpSource;
use csaf_walker::walker::Walker;
use csaf_walker::retrieve::RetrievingVisitor;
use csaf_walker::validation::{ValidatedAdvisory, ValidationError, ValidationVisitor};
use walker_common::fetcher::Fetcher;

async fn walk() -> Result<()> {
    let fetcher = Fetcher::new(Default::default()).await?;
    let metadata = MetadataRetriever::new("redhat.com");
    let source = HttpSource::new(metadata, fetcher, Default::default());

                move |advisory: Result<ValidatedAdvisory, ValidationError>| async move {
                    log::info!("Found advisory: {advisory:?}");
                    Ok::<_, anyhow::Error>(())



~1M SLoC