Ruuutu

https://github.com/juanre7/Ruuutu es público, sin registro para leer o clonar.

Git. Cada commit lleva autor, fecha y mensaje, y el historial completo es público.

El trabajo se publica como commits y pull requests contra main antes de que exista una release. No hay desarrollo fuera del repositorio.

Git.

El campo version de Cargo.toml, replicado en la etiqueta de git y en el recurso VERSIONINFO que build.rs incrusta en el .exe, de modo que la versión es visible desde las propiedades del fichero en Windows.

SemVer (por ejemplo 1.0.1), que es además lo que Cargo exige.

Cada release nace de una etiqueta con el patrón v*, que es lo que dispara el workflow de release.

https://github.com/juanre7/Ruuutu/releases
Cada release publica sus notas en la página de releases de GitHub, generadas a partir de los commits y pull requests incluidos (gh release create --generate-notes).

Ruuutu no ha corregido hasta la fecha ninguna vulnerabilidad públicamente conocida, así que no hay ninguna que las notas debieran nombrar. La política para cuando la haya está escrita en SECURITY.md, sección «Publicación del arreglo»: cada vulnerabilidad corregida se nombra explícitamente, con su identificador, en las notas de la release que la arregla.

https://github.com/juanre7/Ruuutu/issues
Los issues del repositorio. CONTRIBUTING.md explica qué debe incluir un reporte: versión de Ruuutu y de Windows, qué se esperaba, qué pasó, y el fichero implicado si lo hay.

GitHub Issues.

El mantenedor responde a los issues que se abren. No hay ninguno sin atender.

Las propuestas se responden en el propio issue, aceptándolas o explicando por qué quedan fuera del alcance. Ruuutu es deliberadamente minimalista y esa decisión se argumenta caso por caso.

https://github.com/juanre7/Ruuutu/issues
El historial completo de issues, abiertos y cerrados, es público y se puede buscar sin registro.

https://github.com/juanre7/Ruuutu/blob/main/SECURITY.md
SECURITY.md, enlazado desde el README y desde la pestaña Security del repositorio. Explica que no se abra un issue público, por dónde avisar, qué incluir y en cuánto se responde.

https://github.com/juanre7/Ruuutu/security/advisories/new
GitHub Security Advisories, con el aviso privado activado en el repositorio. SECURITY.md ofrece además una dirección de correo como vía alternativa.

No se ha recibido ninguno hasta la fecha. Los plazos comprometidos están publicados en SECURITY.md: acuse de recibo en 72 horas, valoración inicial en 7 días y arreglo publicado, o un plan con fechas, en 90 días.

cargo build --release produce ruuutu.exe. El README lo documenta en «Compilación desde el código fuente», y el workflow de release lo ejecuta en un runner limpio de Windows en cada etiqueta de versión, así que la instrucción está verificada de forma continua.

Cargo, la herramienta estándar de Rust. No hay scripts de compilación propios más allá del build.rs que incrusta el icono y la versión en el ejecutable.

El toolchain de Rust (rustc y cargo) es FLOSS, con licencia MIT y Apache-2.0, y todas las dependencias vienen de crates.io con licencias FLOSS. El destino habitual, x86_64-pc-windows-msvc, enlaza con el linker de Microsoft, pero existe el destino x86_64-pc-windows-gnu, que usa la cadena de MinGW-w64 y es FLOSS de principio a fin.

cargo test --lib --bin ruuutu. Cubre la persistencia de la configuración, la codificación y reescalado de imagen, la geometría de la superposición y el renderizado de iconos y tipografía. La ejecuta el CI en cada push y cada pull request, y también el workflow de release antes de publicar nada.

Un único comando, cargo test --lib --bin ruuutu, documentado en el README y en CONTRIBUTING.md. No hace falta preparar nada antes.

GitHub Actions ejecuta en cada push y cada pull request los tests con medición de cobertura en Windows, la compilación de release, clippy como puerta, el núcleo portable en Linux, CodeQL y una pasada de fuzzing.

CONTRIBUTING.md, sección «Tests: qué se espera»: toda funcionalidad nueva llega con tests y todo arreglo de un fallo llega con un test que falla sin el arreglo. La política indica módulo por módulo dónde el test es obligatorio y dónde la verificación es manual por depender del escritorio.

Los cambios recientes han llegado con sus tests: la separación del núcleo en src/lib.rs mantuvo y amplió la suite unitaria de configuración y almacenamiento, y el trabajo de fuzzing añadió dos targets sobre el parser de configuración y el codificador de imagen.

Está escrita en CONTRIBUTING.md, con una tabla de qué se espera en cada módulo.

clippy se ejecuta con --all-targets --features devtools, de modo que cubre también las herramientas internas de diseño. Los avisos propios de rustc están activos por defecto.

cargo clippy -- -D warnings es una puerta del CI: cualquier aviso tumba el build, así que main nunca tiene avisos pendientes. El workflow documenta además que el toolchain es stable flotante y que un clippy más nuevo puede estrenar lints sobre código ya escrito; cuando ha pasado, el aviso se ha arreglado.

-D warnings convierte cualquier aviso en error, y --all-targets extiende el análisis a tests, benchmarks y binarios auxiliares.

El diseño de Ruuutu aplica los principios de forma verificable: superficie mínima (no abre puertos, no habla con ningún servidor, no tiene actualizador automático), mínimo privilegio (se ejecuta como el usuario, sin elevación, y solo escribe en su carpeta de configuración y en la de capturas), y validación de la entrada no confiable (el fichero de configuración se parsea con degradación a valores por defecto y está sometido a fuzzing continuo). SECURITY.md enumera explícitamente la superficie de ataque del programa.

El proyecto está escrito en Rust, que elimina por construcción las clases de error de memoria más habituales, y los pocos puntos que cruzan a código C (el codificador WebP de libwebp) y a Win32 están identificados y fuzzeados con AddressSanitizer. CodeQL analiza el código en cada pull request cubriendo el OWASP Top 10 para Rust, y Dependabot vigila las dependencias.

Ruuutu no implementa ni utiliza criptografía. No abre ninguna conexión de red, no guarda credenciales y no genera valores aleatorios con relevancia de seguridad.

Ruuutu no implementa ni utiliza criptografía.

Ruuutu no implementa ni utiliza criptografía.

Ruuutu no implementa ni utiliza criptografía, y por tanto no maneja claves.

Ruuutu no implementa ni utiliza criptografía.

Ruuutu no implementa ni utiliza criptografía.

Ruuutu no establece ninguna conexión de red, así que no negocia claves con nadie.

Ruuutu no gestiona autenticación ni almacena contraseñas.

Ruuutu no genera valores aleatorios con relevancia de seguridad.

Las releases se descargan de GitHub por HTTPS. Cada una publica además el SHA256 del ejecutable y una attestation de procedencia firmada con Sigstore, generada dentro del propio workflow de release, que ata ese binario concreto a este repositorio, a este commit y a ese workflow; se comprueba con gh attestation verify. Las dependencias vienen de crates.io por HTTPS con verificación de checksum registrada en Cargo.lock.

Ningún artefacto se entrega sin verificación: el .exe viaja siempre acompañado de su SHA256 y de la attestation de Sigstore, y las dependencias llevan sus checksums en Cargo.lock, que está versionado en el repositorio.

No hay ninguna vulnerabilidad conocida sin corregir en Ruuutu. El escaneo de dependencias señala avisos de RUSTSEC, y todos son notificaciones de crate sin mantenimiento, no fallos explotables: la mayoría corresponde a los bindings de GTK3 que tray-icon arrastra únicamente al compilar para Linux y que por tanto no existen en ruuutu.exe, que es el único artefacto que se distribuye. Los que sí llegan al binario, ttf-parser vía ab_glyph, no tienen versión corregida publicada por estar el crate discontinuado, y no reportan ningún defecto explotable.

No se ha reportado ninguna. SECURITY.md compromete el arreglo publicado, o un plan con fechas, en 90 días desde el reporte.

El repositorio no contiene credenciales. El único secreto que usa el CI es el token opcional de Codecov, guardado como secreto del repositorio en GitHub y referenciado como tal desde el workflow, nunca escrito en un fichero. La firma de las releases es sin clave: usa el token OIDC efímero del workflow a través de Sigstore, así que no existe ninguna clave de firma que pudiera filtrarse.

Dos herramientas, ambas como puerta de integración. CodeQL analiza el código Rust en cada push a main, en cada pull request y en una pasada semanal programada (.github/workflows/codeql.yml); sus resultados van a la pestaña de code scanning del repositorio. Y clippy se ejecuta con --all-targets --features devtools y -D warnings en el CI, de modo que cualquier aviso tumba el build. Como el workflow de release exige que el CI esté en verde, ninguna release sale sin haber pasado por ambas.

El conjunto de consultas de CodeQL para Rust cubre todas las categorías del OWASP Top 10 salvo la de componentes vulnerables y desactualizados, de la que se encarga Dependabot en este repositorio.

No hay hallazgos pendientes. Los avisos de clippy son una puerta dura del CI y no pueden acumularse, y las alertas de CodeQL se atienden en la pestaña de code scanning.

En cada push a main y en cada pull request, más una pasada semanal programada que recoge las reglas nuevas de CodeQL sobre código que ya no se toca.

Fuzzing con cargo-fuzz y libFuzzer sobre dos objetivos elegidos por su riesgo real: el lector de config.json, que es un parser de JSON escrito a mano que trocea un &str por índices de byte, y el codificador de imagen, que es el único punto donde el programa cruza a código C, al entregar a libwebp un puntero y unas dimensiones. Corre en cada push y cada pull request, con una pasada más larga cada semana (.github/workflows/fuzz.yml).

cargo-fuzz compila los objetivos con AddressSanitizer, que es precisamente lo que detectaría una lectura fuera de límites dentro de libwebp. Al margen de eso, el código de la aplicación está en Rust seguro salvo los bloques unsafe estrictamente necesarios para llamar a Win32.

cargo-fuzz compila con -C debug-assertions, así que los desbordamientos aritméticos y las aserciones de la biblioteca estándar están activos durante el fuzzing. Los objetivos añaden además sus propias aserciones sobre invariantes: que to_json y from_json siguen siendo simétricos, que los parámetros del codificador quedan dentro de rango, y que un PNG recién escrito se puede volver a leer con las dimensiones pedidas.

No hay hallazgos pendientes. Un fallo de cualquiera de los dos objetivos tumba el CI, y el caso que lo provoca se guarda como artefacto del workflow para poder reproducirlo, así que un hallazgo no puede quedarse sin atender.