clamav-unofficial-sigs fetches third party signature databases and tests each one before installing

The core idea: test every database before installing it

clamav-unofficial-sigs is described as the ClamAV Unofficial Signatures Updater, maintained and provided by eXtremeSHOK.com, and the project description sets out its scope in one long sentence.

The script provides a simple way to download, test and update third party signature databases provided by Sanesecurity, including FOXHOLE, Porcupine and other distributed signatures, SecuriteInfo, Linux Malware Detect, URLhaus, interServer, MalwarePatrol, Malware Expert, ditekshen/detection, twinclams and custom additional databases.

The clause that matters is this: every downloaded database is integrity tested with clamscan before it is installed.

That is the design decision that makes an unofficial updater defensible. A signature database is executable content as far as ClamAV is concerned, and a corrupted or tampered download that is dropped straight into the signature directory is a way to break a scanner quietly. Verifying with clamscan before the files are installed turns a silent failure into a visible one, and it means a source that is serving rubbish gets skipped rather than adopted.

The script also generates and installs cron, logrotate and man files, so the whole operational loop, scheduled updates, log rotation and the manual page, is set up by running the script once.

A long list of sources, each with its own switch

The source list is long enough that the README documents each one separately, and the pattern is consistent: a source is disabled by default and enabled with a configuration key, or enabled by default where the maintainer judged it safe.

URLhaus support arrived in January 2020 and is enabled by default. Yara rule support has been automatic since April 2016, with the caveat that using Yara rules requires ClamAV 0.100 or above, and that the rules are deactivated automatically if the ClamAV version is older. The Yara-Rules Project support is deprecated as of version 8.0.0 because the upstream repository is unmaintained and several of its rules fail to load or crash modern ClamAV releases, so it is disabled by default and enabled at your own risk with yararulesproject_enabled="yes".

Two sources arrived in July 2026. ditekshen/detection contributes native ClamAV signatures and is disabled by default, enabled with ditekshen_enabled="yes". twinclams, from Splunk and TwinWave, is also disabled by default and enabled with twinclams_enabled="yes".

Two more need an account rather than just a switch. interServer free database support dates from December 2020 and needs no key. malware.expert is a non-free database, also from December 2020, and it needs a serial key that arrives by email and goes into the config as malwareexpert_serial_key, replacing YOUR-SERIAL-KEY with the key from the email. MalwarePatrol, from May 2015, works the same way, with a receipt number from a free account that goes into the config.

So the configuration surface is heterogeneous, and that is the honest shape of the problem. A free mirror, a deprecated project, a commercial feed and two new community databases all need different handling.

Configuration layering, and why you should not edit master.conf

The configuration model is layered, and the documentation explains the order in which the files are read.

Default configs are loaded in the following order if they exist: master.conf, then os.conf, then os.*.conf, then user.conf or your specified config. The precedence follows: user.conf will always override os.conf and master.conf, and os.conf will override master.conf. The instruction is not to alter master.conf, but to create a user.conf instead, and a minimum of one config is required. Specifying a config on the command line with -c or --config overrides the loading of the default configs.

That ordering is a good design and it is worth understanding the reason for it. master.conf is the shipped default, os.conf is the operating system variant, and user.conf is where your changes go. A single configuration file in the middle of that stack would be overwritten by the next upgrade, and the package maintainers section of the README says to use the included os.*.conf sample config file as a base for the os.conf, which disables automatic updates, update notifications and the uninstallation feature.

That last part matters for distributors. A packager who wants the signature databases present but the self-updating behaviour off needs a way to say so, and the os.*.conf mechanism is that way.

For checking that the work actually took effect, the documentation gives one command, `clamscan --debug 2>&1 /dev/null | grep "loaded"`, which prints the database paths ClamAV has loaded.

And for SELinux systems there is a fix, because Clamscan may report a database as integrity tested BAD and skipped. The command is `setsebool -P antivirus_can_scan_system true`.

Two container modes, and what the image is built on

The Docker image is built on top of the official ClamAV image, and the base is a build argument so it can be swapped.

# all-in-one: clamd + freshclam + unofficial signatures
docker run -d -p 3310:3310 -v clamdb:/var/lib/clamav ghcr.io/extremeshok/clamav-unofficial-sigs:latest
# updater sidecar for an existing clamd
docker run -d -e CUS_MODE=updater -v clamdb:/var/lib/clamav ghcr.io/extremeshok/clamav-unofficial-sigs:latest

The two modes are the design to understand. The all-in-one container runs clamd, freshclam and the signature updater together, and the updater sidecar shares the database volume with a clamd that runs elsewhere, which is the mode for an existing deployment that already has a clamd you do not want to replace. The CUS_MODE environment variable selects the second one, and the shared volume named clamdb is what lets the two containers see the same signatures.

The Dockerfile shows how the image is assembled, and it explains the package choices. The base is clamav/clamav:stable, with a comment noting it also works with the official Debian variant. The install step branches on whether the package manager is apk or apt, installing bash and the GNU userland for the update script, gnupg for signature verification, bind-tools for the Sanesecurity mirror resolution, and socat for clamd socket reloads.

That list is the operational requirement in one place. The script needs a real shell and GNU utilities, the signature databases are cryptographically verified, the Sanesecurity mirrors have to be resolved, and the running clamd has to be told to reload when the database changes.

The test matrix, and the upgrade path guard

The automation section is where this project differs from a shell script someone wrote for themselves.

The list is: GitHub Actions, linting with markdownlint-cli and shellcheck, config parse and dry run testing with ClamAV on Ubuntu 22.04 and 24.04 where every OS config is parse tested, Docker image build and smoke test of both container modes including a real signature download, an upgrade path guard where the previous release must be able to parse the current master.conf, and weekly automated liveness checks of the signature source mirrors.

Three of those are worth expanding.

The upgrade path guard is the cleverest one, because it catches the most common way a config-carrying updater breaks. When the script adds a new option to master.conf, an old installed version can fail to parse the new file, and that failure appears on a machine you upgraded months ago. The guard makes the previous release parse the current master.conf in CI, so the break is found before a deployment finds it.

The liveness checks matter because the whole project depends on mirrors. A Sanesecurity mirror that disappears, a URLhaus outage or a source that moves its layout will silently stop delivering, and the script's behaviour on a dead mirror is exactly the thing to watch. Weekly checks turn that into a visible signal.

And the Docker smoke test with a real signature download is the difference between a container that starts and a container that works.

For a shell script, this is an unusually serious test setup, and it is the strongest argument for using this one rather than writing your own.

Where an unofficial signature updater is the wrong answer

There is a real case against, and it comes down to what an unofficial source means for detection coverage.

ClamAV's own signatures are curated, tested and versioned. The databases this script pulls in are not, and the project says so itself: the Yara-Rules Project is deprecated because the upstream repository is unmaintained and several of its rules fail to load or crash modern ClamAV releases, which is why it is off by default and enabled at your own risk. That is a good default, and it is also an admission that some of these sources are of variable quality.

The second limit is availability. Everything here depends on external mirrors, and the weekly liveness checks are the project's own acknowledgement of that. A signature database that is three weeks old is still better than none, but a detection gap of unknown length is a gap, and the only way to know its size is to monitor the source rather than assume it.

The third is that the tool runs as root and manages a scanner's database directory. The README is explicit about it: always run the script once as your superuser to set all the permissions and create the relevant directories. Running a root script that downloads third party archives and installs them into your antivirus signature path is a supply chain decision, not a convenience one.

The alternative is to add the sources you trust one at a time, using the per-source switches, and to keep the default set for the rest. You give up the coverage breadth and the operational convenience of the one-command updater, and in exchange you know which feeds feed your scanner and that you could account for each of them.

Editorial conclusion

clamav-unofficial-sigs fits a ClamAV administrator who wants additional detection coverage from sources ClamAV itself does not ship, and who is prepared to run a shell script as root that pulls databases from many external hosts. It does not fit an environment that requires a reproducible, offline signature source, since the whole design is a scheduled download from mirrors, and it does not fit a team that treats unmaintained upstream rule sets as an acceptable risk without checking them. Before running it, read INSTALL.md and the guide for your platform, keep the local config overrides in a user.conf rather than editing master.conf, and check the weekly liveness status of the mirrors you depend on before you rely on a source for detection.

Frequently asked questions

Official sources

1. extremeshok/clamav-unofficial-sigs on GitHub
2. Issues
3. Project website
4. README
5. Releases