No hace mucho escribía sobre la diversidad de compresores en OS X. El post me trajo algunos recuerdos del tema.

Descubrí que había algo más que el compress en Unix hace unos 7 u 8 años. Mientras buscaba como hacer un poco más eficiente el proceso de respaldo de las bitácoras de los web servers del Portal Banamex, cuando trabajaba para este banco (que compactadas eran de 2GB por cada web server y cada día crecían más y más, y así el principal problema era el espacio en disco). Mientras que mi idea era hacer uso de un named pipe para no tener que necesitar de más espacio mientras que la bitácora era compactada, me sorprendió encontrar que el HP-UX incluía otros compresores: una implementación del ZIP de Phil Katz y del ZIP de GNU.

La utilería compress y las extesiones «.Z» tienen una larga tradición en Unix, especialmente cuando se trabaja con un Unix de marca. El proceso de compactación hacía uso del compress, así que decidí hacer unas pruebas encontrando que el gzip con la opción -9 nos daba un 80% de mayor capacidad de compresión, que junto con el uso de un named pipe nos daba espacio para mantener un histórico de bitácoras mayor y facilitaba enormemente poder obtener las bitácoras.

Escribo la anécdota no por la reducción de tiempo y espacio señalado sino porque costó trabajo poder hacer que estos cambios se adoptaran. Resultó que por el simple hecho de mencionar o implicar que se haría uso de algo que era «código abierto» bastó para decir desde un inicio que no, argumentando motivos de «seguridad». No fue hasta que se obtuvo un correo de quién se encargaba de los aspectos de administración del sistema operativo HP-UX a nivel de la organización de Citi, señalando que si bien éste y otros sistemas operativos incluían como parte de su distribución utilerías que tenían un origen en el código abierto, el vendedor del HP-UX amparaba la implementación de estas utilerías en su distribución y así quedaban dentro del contrato de soporte que se tenía con HP. Sí, ciertamente esto daba cierta seguridad y respaldo pero, como desarrollador, no había ninguna diferencia. De haber una vulnerabilidad ahí seguiría pero ésta resultaría irrelevante de cualquier modo ya que el sistema estaría protegido por las políticas de seguridad establecidas a su alrededor. Si estas políticas y su protección fallasen, se haga o no uso de las utilerías de compresión de código abierto, las vulnerabilidades que éstas pudiera incluir se explotarían. ¿Por qué no, por ejemplo, si estas utilerías se consideraban inseguras, se eliminaba de la distribución del sistema operativo? Respuesta, porque el mismo sistema las usaban en procesos administrativos internos. Eliminarlas significaba incapacitar al sistema y su garantía. Si estas eran inseguras el sistema era inseguro per se, y así se adquirió.

Un sistema es seguro porque no se use aquello que éste incluye y se sabe o sospeche es inseguro; su seguridad sólo se incrementa eliminado aquello que se sabe es inseguro o así se sospecha. Si sus vulnerabilidades no pueden eliminarse, el sistema es inseguro per se y no debería adquirirse. Si ya se invirtió adquiriéndolo es mejor conocerlo haciendo uso de éste y reforzándolo según se vaya conociéndolo.