256 pull requests para blindar GenOffice, la suite ofimática con IA
Un colaborador documenta cómo trató los ficheros de Office como entradas hostiles: 256 parches fusionados contra NaN, rutas traversal y CSV en UTF-16 sin BOM.
GenOffice es una suite ofimática de código abierto, alternativa libre a Microsoft Office para macOS, Windows y Linux, que abre y guarda .docx, .xlsx y .pptx nativos, edita PDF, Markdown y HTML y coloca un agente de IA junto a cada documento. Un colaborador ha publicado el recuento de su trabajo de endurecimiento dentro del proyecto: 256 pull requests fusionados entre el #187 y el #689, casi todos con prefijo fix: o test:. El código está en genspark-ai/genoffice.
La cifra es suya. Sale de la búsqueda de pull requests del propio GitHub, que se corta, y el autor admite que el total real es mayor; los "~268 commits" que cita corresponden a su clon local, no al repositorio. Nadie externo ha auditado la lista. Lo que sí es verificable es que cada PR de los que enumera aparece fusionado.
Los ficheros de Office como entrada hostil
El hilo conductor de la serie es que un .docx o un .pptx que llega de fuera no es un documento, es una entrada que nadie validó. El autor enumera lo que se encuentra: atributos entre comillas simples, True en mayúscula, etiquetas de protección emparejadas, CSV en UTF-16 sin BOM, destinos de pptx con barra invertida, referencias de xlsx en minúscula, tamaños de diapositiva rotos, sistemas de fecha de 1904. Su ciclo de trabajo es siempre el mismo: reproducir, acotar o normalizar, añadir test de regresión y dejar el diff pequeño.
Buena parte de esos 256 parches responden a un único patrón, non-finite in, sane out. Ejes de gráfica, tamaños de fuente, geometría de trazos, anchos de conector y de borde, colSpan de tabla, dimensiones de bitmap, buffers SSE, límites de chat y de timeline. Un NaN que entra en el pipeline de render puede tumbar la aplicación o corromper una exportación, y de ahí el recuento.
SSRF, rutas y zip
El bloque de seguridad toca rechazo de identificadores con traversal, comparación canónica de rutas para pestañas, resolución de ficheros en el renderer, normalización de maxRedirects frente a SSRF, comprobaciones de host y fichero en MCP, validación del directorio central de los zip y cierre de sus handles, acotado del spinCount de protección para evitar un DoS por digest y límites en regiones de redacción y profundidad de esquema. Varios de estos parches viven en el motor de DOCX y en el de PPTX, que son los que más superficie exponen.
Hay también un apartado de i18n y accesibilidad que no es cosmético: pruebas de dirección bidi, recuentos de palabras para CJK y sudeste asiático, mapeo de fuentes kana y radicales, navegación por teclado en la previsualización de diagramas y paneles de IA que respetan la dirección del texto.
Entre las funcionalidades que se colaron en la serie hay una para hojas de cálculo que infiere el rango de tabla desde la región actual, un diálogo de rango de impresión en PDF, una barra lateral de esquema para Markdown y un fallback de búsqueda web con Tavily mediante TAVILY_API_KEY. El PR más reciente citado, el #689, valida marcadores JPEG y dimensiones de imagen.
Lo interesante para quien mantiene software no es el número, sino la lista de clases de fallo. Casi todo lo que aparece ahí se reproduce igual en cualquier parser de formatos heredados: valores no finitos que se cuelan hasta el render, rutas que no se canonicalizan antes de comparar y contenedores comprimidos que se abren sin validar antes el índice. Ese es el material reutilizable. El recuento de PRs es la parte que solo le importa a quien los escribió.
