# Machine-Readable Security Data (Errata, OVAL, CSAF)

TuxCare provides machine-readable security data for Endless Lifecycle Support (ELS) for Runtimes in the following formats:

• Errata — qualified security and selected bug-fix errata advisories
• OVAL — Open Vulnerability and Assessment Language patch definitions for use with OpenSCAP and similar tools
• CSAF — Common Security Advisory Framework advisories in OASIS CSAF 2.0 format, covering both Vulnerability Exploitability eXchange (VEX) and Security Advisory profiles
• RSS — release feeds for tracking updates

Every package is also signed so you can verify its authenticity and integrity before installing — see Package Signature Verification (GPG).

Released fixes are also available via tuxcare.com/cve-tracker and security.tuxcare.com.

# PHP

# Python

# Node.js

# Ruby

# How to use OVAL

OVAL can be used with the OpenSCAP tool.

1. Install OpenSCAP

   RPMDEB

   

   yum install openscap openscap-utils scap-security-guide -y

2. Download an OVAL stream. For example, Python on EL 8:

   wget https://security.tuxcare.com/oval/els_alt_python/el8/oval.xml
   

3. Run a scan:

   oscap oval eval --results result.xml --report report.xml oval.xml
   

# How to use CSAF

Common Security Advisory Framework (CSAF) is a machine-readable format, standardized by OASIS. TuxCare publishes CSAF VEX and Security Advisory files in CSAF 2.0 format at security.tuxcare.com.

provider-metadata.json is available at:

• csaf.data.security.tuxcare.com
• tuxcare.com/.well-known/csaf/provider-metadata.json

The CSAF files are published in JSON format — OASIS provides a list of reference tools that support CSAF.

# Package Signature Verification (GPG)

ELS for Runtimes (PHP, Python, Node.js, Ruby, and other runtimes delivered as alt-* packages) is distributed as native RPM, DEB, and APK packages from TuxCare-managed repositories. Every package and the repository metadata that indexes it are signed with TuxCare's OpenPGP key, so that before anything is installed or updated you can confirm two things about each artifact:

• Authenticity — it was signed with TuxCare's private key.
• Integrity — its bytes match exactly what was signed; no tampering or corruption occurred in transit.

Unlike a manual, registry-based flow, verification here is built into the native package manager. The repository setup script you run during installation imports the TuxCare signing key and enables signature checking (gpgcheck=1 on RPM; signed InRelease/index on DEB and APK), so yum/dnf, apt, and apk verify each package automatically on every install and update. A verification that fails is an integrity violation: the package manager refuses to install the artifact. Do not work around a failed check by disabling verification or re-downloading over an insecure channel — investigate the source instead (see Integrity Violation Events).

# Confirm the TuxCare Signing Key Is Installed

The repository setup script installs the key for you. To confirm it is present in the trust store your package manager uses:

RPMDEBAPK

rpm -qi $(rpm -qa 'gpg-pubkey*') | grep -i tuxcare

If the key is missing, re-run the repository setup script from the installation instructions rather than importing a key from an untrusted source.

# Verify a Package

With signature checking enabled, verification happens automatically during install and update. You can also verify explicitly before installing:

• RPM — download the package without installing, then check its signature.
• DEB — apt verifies the signed InRelease index on update, then checks every .deb against the checksums in that signed index.
• APK — apk verifies the signed index and the package checksum automatically on apk add; use apk verify to check a downloaded package.

RPMDEBAPK

yumdownloader alt-php74   # or: dnf download alt-php74
rpm --checksig alt-php74-*.rpm

A successful RPM check reports digests signatures OK; apt-get update completes with no NO_PUBKEY, not signed, or Hash Sum mismatch warnings; and apk verify prints OK. Any other result is an integrity violation — stop and re-obtain the package over a trusted channel.

repo_gpgcheck=1

# Integrity Violation Events

For compliance with regulations such as the EU Cyber Resilience Act (CRA), an administrator must be able to detect and retain evidence when an integrity check fails — not just have the installation blocked at the terminal. This section defines what counts as an integrity violation for ELS for Runtimes and shows how to capture these events in a dedicated log.

# What Counts as an Integrity Violation

An integrity violation is any failure of the package manager to confirm that an artifact is authentic and unmodified. Four event types apply:

1. GPG signature failure — a package is signed with an unknown key, or its signature does not match its contents.

RPMDEBAPK

Package alt-php74-7.4.33-....rpm is not signed
# or:
The GPG keys listed for the '...' repository are already installed but they are not correct for this package.
# or:
GPG check FAILED

2. Repository metadata signature mismatch — the signed repository index cannot be verified against the trusted key (index tampered with, unsigned, or signed by the wrong key).

RPMDEBAPK

# Only detected when repo_gpgcheck=1 (see note above)
repomd.xml signature could not be verified for ...
# or:
GPG verification is enabled, but GPG signature is not available.

3. Checksum error — a package's bytes do not match the checksum recorded in the signed index (corruption or tampering after signing).

RPMDEBAPK

Package does not match intended download.
# or:
[Errno -1] Package ... checksum ... does not match

4. HTTPS/TLS certificate error — the connection to the repository could not be authenticated, so the transport itself is untrusted.

RPMDEBAPK

Curl error (60): SSL peer certificate or SSH remote key was not OK
# or:
SSL certificate problem: unable to get local issuer certificate

# Retaining Integrity Violation Events in a Dedicated Log

By default an integrity violation is only printed to the terminal of whoever ran the command, so an unattended update (cron, automation, or a fetch triggered while nobody is watching) leaves no durable record. To satisfy the CRA requirement, route these events to a dedicated log the administrator can review, separate from standard package-manager output.

The approach is to run the update through a wrapper that scans the package manager's output for the violation signatures above and forwards any match to the system log via logger, tagged so it can be isolated:

#!/bin/sh
# /usr/local/sbin/tuxcare-secure-update
# Run the ELS update and record any integrity violation to syslog.

TAG=tuxcare-integrity
PATTERN='NO_PUBKEY|not signed|GPG check FAILED|is not signed|signature could not be verified|UNTRUSTED signature|BAD signature|BAD archive|Hash Sum mismatch|checksum .* does not match|does not match intended download|certificate verification failed|unable to get local issuer certificate|NOT trusted'

# Detect the package manager once and run only that one, so a genuine
# integrity failure is not masked by a fall-through to a missing tool
# (a missing manager would otherwise overwrite the exit code with 127).
if command -v yum >/dev/null 2>&1; then
  out=$(yum -y update 'alt-*' 2>&1);       status=$?
elif command -v dnf >/dev/null 2>&1; then
  out=$(dnf -y update 'alt-*' 2>&1);       status=$?
elif command -v apt-get >/dev/null 2>&1; then
  out=$(apt-get -y upgrade 2>&1);          status=$?
elif command -v apk >/dev/null 2>&1; then
  out=$(apk upgrade 'alt-*' 2>&1);         status=$?
else
  echo "No supported package manager found" >&2
  exit 1
fi

echo "$out"
echo "$out" | grep -Ei "$PATTERN" \
  | while IFS= read -r line; do
      logger -t "$TAG" -p auth.err "INTEGRITY VIOLATION: $line"
    done

exit "$status"

Then route the tagged messages to a dedicated file. With rsyslog, add /etc/rsyslog.d/60-tuxcare-integrity.conf:

# Send everything tagged tuxcare-integrity to a dedicated log
:syslogtag, contains, "tuxcare-integrity"  /var/log/tuxcare-integrity.log
& stop

Reload rsyslog and secure the log so it is append-only for auditing:

systemctl restart rsyslog
touch /var/log/tuxcare-integrity.log
chmod 0640 /var/log/tuxcare-integrity.log
chattr +a /var/log/tuxcare-integrity.log   # append-only (optional)

On systems using journald, the logger tag is queryable without extra configuration:

journalctl -t tuxcare-integrity

Run the wrapper from your normal update mechanism (interactively, from cron, or from configuration management) instead of calling the package manager directly. Every blocked installation is then captured in /var/log/tuxcare-integrity.log (or the journal), regardless of when or how the update was triggered, giving administrators a durable, reviewable record of integrity violations.