Signatures

exav re-uses ClamAV’s signature formats so the whole ecosystem’s signatures work — but it ships with no real database of its own (only a tiny built-in EICAR test signature). You supply the signatures.

Why exav doesn’t ship signatures

The ClamAV signature database (main.cvd / daily.cvd) is GPL-licensed; using it inside another engine is considered a derivative work. exav ships under MIT and therefore never bundles or redistributes it.

• exav can read the CVD format — reading a format is interoperability, not redistribution.
• To get the signatures, you run Cisco’s own updater onto your own machine, then point exav at the directory. GPL governs distribution, not use.
• exav deliberately does not re-implement freshclam’s update protocol — no DNS TXT version probing, no .cdiff incremental patching, no GPG signature verification. cvdupdate (Apache-2.0) and freshclam are the supported path for the official database, and they avoid hammering Cisco’s CDN.

Then what is --auto-update?

A much smaller thing, and the distinction matters when you are deciding which to run. --auto-update does a plain conditional HTTPS GET of the URLs you supply (--sig-sources, or a prebuilt database at --db-url), on a schedule, and hot-reloads the result. That is the whole of it — the exav-update crate, behind the off-by-default http-update feature.

What it is not is a freshclam replacement: it will not discover the current version over DNS, will not apply .cdiff patches, and does not check the CVD’s GPG signature. So point it at a mirror you control or trust, or at a prebuilt .exavdb you built yourself — and use freshclam or cvdupdate against Cisco’s CDN.

Get the official signatures

Tip

Either updater works — use whichever you already run. Keep your existing update schedule when migrating; nothing about updating changes.

# Option A: cvdupdate (Cisco's Python updater; the command it installs is `cvd`)
pip install cvdupdate
cvd update
exav -d ~/.cvdupdate/database /data

# Option B: freshclam (ships with ClamAV)
freshclam
exav -d /var/lib/clamav /data

-d / --sig-dir loads a directory recursively (hidden .-prefixed sub-directories are skipped), so a nested layout is picked up in full.

Formats exav loads

From a .cvd/.cld container (a signed, gzip’d tar of typed files) or loose files in the directory:

Extension	Signature type
.ndb	literal/hex body signatures (incl. wildcards)
.ldb	logical signatures (boolean expressions over subsignatures)
.hdb / .hsb	whole-file MD5 / SHA hashes
.mdb / .msb	PE section hashes
.cdb	container-metadata signatures
.imp	PE import-hash (imphash)
.cbc	bytecode programs (run in a sandboxed interpreter)
.fp / .sfp / .ign / .ign2	allowlists
.pdb / .wdb / .gdb	phishing databases
.pwdb	password database (for encrypted archives)
.yar / .yara	YARA rules
.cvd / .cld	signed containers of the above

See Supported formats for the archive/container formats exav can unpack.

Note

Measured on a live ClamAV daily.cvd (273,587 signature lines): exav loads all of them, and all of main and of the third-party feeds tracked here. Anything it could not load would be counted and attributable by cause, never silently ignored — see how that was closed.

Unofficial & third-party feeds

Beyond the official database, a range of third-party and unofficial signature feeds exist — community YARA rulesets, commercial vendor feeds, and add-on signature sets. exav loads any of them the same way: drop the files (or a nested directory of them) into your signature directory and -d/--sig-dir picks them up recursively.

• Prefer permissively-licensed sets where you intend to redistribute them.
• Several third-party/commercial feeds are distributed through updater tools that lay signatures out in a nested directory — exav’s recursive load handles that layout unchanged.
• A database is recognised by its extension, not its contents: .cvd, .cld, .ndb, .hdb, .hsb, .ldb, .yar, .ign2, .pwdb and the rest of the ClamAV set. Anything else in the directory is passed over without being read, which is what lets .cdiff, .sign, .info and updater state files live there safely. A signature file saved under some other name is skipped just as quietly, so rename it rather than wondering why it never matched.

Built-in updater (--auto-update)

exav can fetch signatures itself — add --auto-update and point --sig-sources / EXAV_SIG_SOURCES at a file of source URLs, or even at your existing freshclam.conf (exav reads its source directives and warns about

• ignores the rest). It works alongside any --listen address, and on its own for a one-shot scan that should fetch before it scans; with no --listen and no paths it is an updater and nothing else. See the Docker guide, the CLI reference and Configuration.

Each source is saved under the filename its URL ends in, so the URL has to name the file it serves: https://mirror/daily.cvd works, while a CGI-style endpoint like https://feeds/get.php?db=daily saves as get.php — not an extension the loader routes. exav says so at startup rather than fetching it every interval and loading nothing.

Caution

The built-in updater does a plain HTTPS fetch with no signature verification — point it only at a mirror you trust. For cryptographically verified updates, use freshclam / cvdupdate and let exav hot-reload the volume.

Next

• Prebuilt database — compile signatures once for near-instant startup.
• YARA rules — the native YARA engine.