Documentación

MacGuard YARA Channel descarga reglas YARA de fuentes públicas, comprueba que funcionan, las firma y las publica junto a un registro público que permite comprobar qué se publicó y cuándo. Esta web es el escaparate de ese proceso, no un antivirus.

Cómo funciona, paso a paso

1. Descarga. Cada día un workflow de GitHub Actions consulta las fuentes (Neo23x0/signature-base y Yara-Rules/rules) y fija el commit exacto de cada una.
2. Validación. Cada fichero de reglas se compila con el compilador oficial yarac. Un fichero roto, mal formado o con dependencias sin resolver se rechaza y queda anotado.
3. Registro. El resultado se añade al registro de transparencia con fecha, hora y nivel (INFO, WARNING o ERROR). Si algo falla, el mensaje explica qué y por qué.
4. Aprobación y firma. Una publicación se lanza a mano sobre un candidato ya validado y requiere aprobación humana. El workflow firma el manifiesto y el punto de control del registro con Sigstore, sin claves guardadas.
5. Publicación. La release y esta web se despliegan en GitHub Pages y en Cloudflare Pages. Antes de desplegar, el propio pipeline verifica la release como lo haría un cliente.

Qué se publica

• manifest.json: lista de ficheros de reglas con su SHA-256, los commits de origen, la raíz Merkle de las reglas (rules_root) y el estado del registro.
• manifest.sigstore.json: firma del manifiesto.
• inclusion-proof.json: prueba de que el rules_root de esta release está dentro del registro firmado.
• latest.json: puntero a la última release para los clientes.
• logs/LOG.md y log.jsonl: el registro legible y el registro en bruto.
• checkpoint.txt y checkpoint.sigstore.json: el último punto de control firmado.

El registro de transparencia

Es un registro de solo añadir. Cada entrada es una línea JSON y todas juntas forman un árbol de Merkle (RFC 6962). Un punto de control firmado fija el tamaño y la raíz del árbol. Si alguien borrara o cambiara entradas antiguas, la raíz dejaría de coincidir con puntos de control anteriores y se detectaría.

Niveles: INFO es un paso normal; WARNING es algo que no impide publicar pero conviene revisar (por ejemplo, un despliegue omitido); ERROR es un fallo, como una regla rechazada o una publicación fallida. Las horas son UTC.

Cómo comprobarlo usted mismo

1. Descargue la release y compruebe la firma con cosign verify-blob, exigiendo la identidad https://github.com/MacGuard/macguard-yara-channel/.github/workflows/publish.yml@refs/heads/main emitida por https://token.actions.githubusercontent.com.
2. Compruebe que el SHA-256 de cada fichero coincide con el manifiesto.
3. Recalcule el rules_root y compruebe que coincide con el del manifiesto.
4. Compruebe la prueba de inclusión contra el punto de control firmado.

El script scripts/verify_release.py del repositorio hace los cuatro pasos.

Qué no hace

• No es un antivirus: publica reglas de terceros, no analiza su equipo.
• No afirma que las fuentes lo avalen ni que sus reglas sean perfectas; solo garantiza que lo publicado se puede comprobar, que se compiló y que queda constancia.
• Las firmas indican quién publicó, no que el contenido sea inocuo.

Documentation

MacGuard YARA Channel downloads YARA rules from public sources, checks that they work, signs them and publishes them together with a public log that shows what was published and when. This site is the front window of that process; it is not an antivirus.

How it works, step by step

1. Download. Every day a GitHub Actions workflow queries the sources (Neo23x0/signature-base and Yara-Rules/rules) and pins the exact commit of each.
2. Validation. Every rule file is compiled with the official yarac compiler. A broken, malformed or unresolved file is rejected and recorded.
3. Log. The result is appended to the transparency log with date, time and level (INFO, WARNING or ERROR). When something fails, the message says what and why.
4. Approval and signing. A publication is started by hand on an already validated candidate and needs human approval. The workflow signs the manifest and the log checkpoint with Sigstore, with no stored keys.
5. Publication. The release and this site are deployed to GitHub Pages and Cloudflare Pages. Before deploying, the pipeline verifies the release the way a client would.

What is published

• manifest.json: the rule files with their SHA-256, the source commits, the Merkle root of the rules (rules_root) and the log state.
• manifest.sigstore.json: the manifest signature.
• inclusion-proof.json: proof that this release's rules_root is inside the signed log.
• latest.json: pointer to the latest release for clients.
• logs/LOG.md and log.jsonl: the readable and the raw log.
• checkpoint.txt and checkpoint.sigstore.json: the latest signed checkpoint.

The transparency log

It is append-only. Each entry is one JSON line and together they form a Merkle tree (RFC 6962). A signed checkpoint fixes the size and root of the tree. If anyone deleted or changed old entries, the root would no longer match earlier checkpoints and that would be detected.

Levels: INFO is a normal step; WARNING is something that does not block publishing but deserves a look (for example a skipped deployment); ERROR is a failure, such as a rejected rule or a failed publication. Times are UTC.

How to verify it yourself

1. Download the release and check the signature with cosign verify-blob, requiring the identity https://github.com/MacGuard/macguard-yara-channel/.github/workflows/publish.yml@refs/heads/main issued by https://token.actions.githubusercontent.com.
2. Check that every file's SHA-256 matches the manifest.
3. Recompute the rules_root and check that it matches the manifest.
4. Check the inclusion proof against the signed checkpoint.

The repository script scripts/verify_release.py performs all four steps.

What it does not do

• It is not an antivirus: it publishes third-party rules and does not scan your computer.
• It does not claim that the sources endorse it or that their rules are perfect; it only guarantees that what is published can be checked, was compiled, and is on record.
• Signatures show who published, not that the content is harmless.