Abajo les dejo la interesante entrevista realizada por It’s FOSS al cofundador de Hyperbola, Andre Silva por parte de John Paul.
ItsFOSS: En su anuncio, usted declara que el núcleo de Linux está “avanzando rápidamente por un camino inestable”. ¿Podría explicar lo que quiere decir con eso?
Andre: En primer lugar, incluye la adaptación de funciones de DRM como HDCP (High-bandwidth Digital Content Protection). Actualmente hay una opción para desactivarla en el momento de la construcción, sin embargo no hay una política que nos garantice que será opcional para siempre.
Históricamente, algunas características comenzaron como opcionales hasta que alcanzaron la funcionalidad total. Luego se volvieron forzadas y difíciles de parchear. Incluso si esto no sucede en el caso de HDCP, somos cautelosos con estas implementaciones.
Otra de las razones es que el núcleo de Linux ya no se está reforzando en el tema de seguridad adecuadamente. Grsecurity dejó de ofrecer parches públicos hace varios años, y nosotros dependíamos de eso para la seguridad de nuestro sistema. Aunque todavía podíamos usar sus parches para una suscripción muy costosa, la suscripción sería cancelada si elegíamos hacer públicos esos parches.
Tales restricciones van en contra de los principios del FSDG que requieren que nosotros proveamos el código fuente completo, sin blobs, y sin restricciones a nuestros usuarios.
KSPP es un proyecto que fue pensado para subir Grsec* al kernel, pero hasta ahora no se ha acercado a alcanzar el nivel de reforzamiento del kernel Grsec / PaX. Tampoco ha habido muchos desarrollos recientes, lo que nos lleva a creer que ahora es un proyecto inactivo en su mayor parte.
Por último, el interés de permitir módulos Rust en el kernel es un problema para nosotros, debido a las restricciones de la marca Rust que nos impiden aplicar parches en nuestra distribución sin permiso expreso. Aplicamos parches para eliminar el software que no es libre, los archivos sin licencia y las mejoras en la privacidad del usuario en cualquier lugar donde sea aplicable. También esperamos que nuestros usuarios puedan reutilizar nuestro código sin ninguna restricción o permiso adicional.
Esta es también en parte la razón por la que usamos UXP, un motor de navegador completamente libre y un conjunto de herramientas de aplicación para nuestro correo y aplicaciones de navegador.
Debido a estas restricciones, y a la preocupación de que en algún momento pueda convertirse en una dependencia forzada del tiempo de construcción del kernel, necesitábamos otra opción.
ItsFOSS: Usted también dijo en el anuncio que estaría bifurcando el kernel de OpenBSD. ¿Por qué escogió el kernel de OpenBSD sobre el kernel de FreeBSD, el kernel de DragonflyBSD o el kernel de MidnightBSD?
Andre: OpenBSD fue escogido como nuestra base para trabajar porque es un sistema que siempre ha tenido código de calidad y seguridad en mente.
Algunas de sus ideas que nos interesaron mucho fueron las nuevas llamadas al sistema, incluyendo el compromiso y la revelación que añade un reforzamiento adicional al espacio de usuario y la eliminación de la herramienta de aplicación de políticas del sistema systrace.
También son conocidos por Xenocara y LibreSSL, que ya habíamos estado usando después de portarlos a GNU/Linux-libre. Los encontramos bien escritos y generalmente más estables que Xorg/OpenSSL respectivamente.
Ninguna de las otras implementaciones de BSD que conocemos tiene ese nivel de seguridad. También somos conscientes de que LibertyBSD ha estado trabajando en la liberación del kernel de OpenBSD, lo cual nos permitió usar sus parches para comenzar el desarrollo inicial.
ItsFOSS: ¿Por qué bifurcar el kernel en primer lugar? ¿Cómo mantendrán el nuevo kernel actualizado con el nuevo soporte de hardware?
Andre: El kernel es una de las partes más importantes de cualquier sistema operativo, y sentimos que es crítico comenzar con una base firme para seguir adelante.
Para la primera versión planeamos mantener la sincronización con OpenBSD donde sea posible. En versiones futuras podremos adaptar el código de otros BSDs e incluso el kernel de Linux donde sea necesario para mantenernos al día con el soporte de hardware y las características.
Estamos trabajando en coordinación con Libreware Group (nuestro representante para actividades de negocios) y tenemos planes para abrir nuestra fundación pronto.
Esto ayudará a sostener el desarrollo, contratar futuros desarrolladores y animar a nuevos entusiastas para el soporte de hardware y código más reciente. Sabemos que el deblobbing* no es suficiente porque es una mitigación, no una solución para nosotros. Así que, por esa razón, necesitamos mejorar nuestra estructura y pasar a la siguiente etapa de desarrollo de nuestros proyectos.
ItsFOSS: Usted dice que planea reemplazar las partes del kernel y el espacio de usuario de OpenBSD que no son compatibles con la GPL o que no son libres con las que sí lo son. ¿Qué porcentaje del código cae en la zona no GPL?
André: Alrededor del 20% en el kernel y el espacio de usuario de OpenBSD.
La mayoría de las partes licenciadas no compatibles con la GPL están bajo la licencia Original BSD, a veces llamada “licencia BSD de 4 cláusulas” que contiene un grave defecto: la “odiosa cláusula publicitaria BSD”. No es fatal, pero nos causa problemas prácticos porque genera incompatibilidad con nuestro código y con el desarrollo futuro bajo GPLv3 y LGPLv3.
Los archivos no libres en OpenBSD incluyen archivos sin una cabecera de licencia apropiada, o sin una licencia en la carpeta que contiene un componente particular.
Si esos archivos no contienen una licencia para dar a los usuarios las cuatro libertades esenciales o si no han sido explícitamente añadidos en el dominio público, no es software libre. Algunos desarrolladores piensan que el código sin licencia es automáticamente de dominio público. Esto no es cierto bajo la ley de derechos de autor de hoy en día; más bien, todos los trabajos con derechos de autor están protegidos por defecto.
Los bloques de firmware no libre en OpenBSD incluyen varios firmwares de hardware. Estos bloques de firmware también ocurren en el núcleo de Linux y han sido eliminados manualmente por el proyecto Linux-libre durante años después de cada nueva versión del núcleo.
Normalmente tienen la forma de un binario codificado hexadecimal y se proporcionan a los desarrolladores del kernel sin código fuente con el fin de proporcionar soporte para hardware de diseño propietario. Estos blobs pueden contener vulnerabilidades o puertas traseras además de violar su libertad, pero nadie lo sabría ya que el código fuente no está disponible para ellos. Deben ser eliminados para respetar la libertad del usuario.
ItsFOSS: Estuve hablando con alguien acerca de HyperbolaBSD y mencionaron HardenedBSD. ¿Ha considerado HardenedBSD?
André: Habíamos investigado sobre HardenedBSD, pero estaba bifurcado desde FreeBSD. FreeBSD tiene una base de código mucho más grande. Aunque HardenedBSD es probablemente un buen proyecto, requeriría mucho más esfuerzo para nosotros depurar y verificar las licencias de todos los ficheros.
Decidimos usar OpenBSD como base para bifurcar en lugar de FreeBSD debido a su compromiso con la calidad del código, la seguridad y el minimalismo.
ItsFOSS: Usted mencionó UXP* (o Plataforma Unificada XUL). Parece que estais usando el fork de Moonchild de la base de código pre-Servo Mozilla para crear un conjunto de aplicaciones para la web.
Andre: Sí. Nuestra decisión de usar UXP fue por varias razones. Ya estábamos rebautizando Firefox como Iceweasel durante varios años para eliminar DRM, deshabilitar la telemetría y aplicar opciones de privacidad preestablecidas. Sin embargo, se nos hizo cada vez más difícil mantenerlo cuando Mozilla siguió añadiendo anti-funciones, eliminando la personalización del usuario y rompiendo rápidamente nuestros parches de privacidad.
Después de FF52, todas las extensiones de XUL fueron eliminadas en favor de WebExt y Rust se impuso en tiempo de compilación. Mantenemos varias extensiones de XUL para mejorar la privacidad/seguridad del usuario que ya no funcionaban en el nuevo motor. También nos preocupaba que los complementos de WebExt, de funcionalidad limitada, introdujeran problemas de privacidad adicionales. Por ejemplo, cada addon de WebExt instalado contiene un UUID que puede utilizarse para identificar a los usuarios de forma única y precisa (véase Bugzilla 1372288).
Después de algunas investigaciones, descubrimos UXP y que se mantenía regularmente al día con las correcciones de seguridad sin apresurarse a implementar nuevas características. Ya habían desactivado la telemetría en la caja de herramientas y siguen comprometidos a eliminarla toda de la base de código.
Sabíamos que esto estaba bien alineado con nuestros objetivos, pero aún así necesitábamos aplicar algunos parches para ajustar la configuración de privacidad y eliminar el DRM. Por lo tanto, empezamos a crear nuestras propias aplicaciones sobre el conjunto de herramientas.
Esto nos ha permitido ir mucho más allá del rebranding*/deblobbing básico, como hacíamos antes, y crear nuestras propias aplicaciones XUL totalmente personalizadas. Actualmente mantenemos Iceweasel-UXP, Icedove-UXP y Iceape-UXP, además de compartir las mejoras del kit de herramientas con UXP.
ItsFOSS: En una entrada del foro, noté que se mencionaban HyperRC, HyperBLibC y hyperman. ¿Son estas bifurcaciones o reescrituras de las actuales herramientas BSD para ser compatibles con la GPL?
André: Son bifurcaciones de proyectos existentes.
Hyperman es una bifurcación de nuestro actual administrador de paquetes, pacman. Como pacman no funciona actualmente en BSD, y el mínimo soporte que tenía en el pasado fue eliminado en las versiones recientes, se requirió un fork. Hyperman ya tiene una implementación en funcionamiento usando soporte LibreSSL y BSD.
HyperRC será una versión parcheada del init de OpenRC. HyperBLibC será un fork de BSD LibC.
ItsFOSS: Desde el principio de los tiempos, Linux ha defendido la licencia GPL y BSD ha defendido la licencia BSD. Ahora, usted está trabajando para crear un BSD con licencia GPL. ¿Cómo respondería a aquellos en la comunidad BSD que no están de acuerdo con este movimiento?
André: Somos conscientes de que hay desacuerdos entre el mundo de la GPL y el de BSD. Incluso hay desacuerdos sobre llamar a nuestra distribución previa “GNU/Linux” en lugar de simplemente “Linux”, ya que la última definición ignora que el espacio de usuario de GNU se creó en 1984, varios años antes de que el núcleo de Linux fuera creado por Linus Torvalds. Fueron los dos programas diferentes combinados los que hicieron un sistema completo.
Algunas de las principales diferencias con BSD, es que la GPL requiere que nuestro código fuente se haga público, incluyendo las versiones futuras, y que sólo puede ser usado en tándem con archivos con licencias compatibles. Los sistemas BSD no tienen que compartir su código fuente públicamente, y pueden combinarse con varias licencias y software no libre sin restricción.
Dado que somos fuertes partidarios del movimiento de Software Libre y deseamos que nuestro futuro código permanezca siempre en el espacio público, hemos elegido la GPL.
ItsFOSS: Sé que en este punto usted está empezando el proceso, pero ¿tiene alguna idea de quién podría tener una versión utilizable de HyperbolaBSD disponible?
Andre: Esperamos tener una versión alfa lista para el 2021 para las pruebas iniciales.
ItsFOSS: ¿Cuánto tiempo seguirán apoyando la versión actual de Linux de Hyperbola? ¿Será fácil para los usuarios actuales cambiarse a ella?
Andre: Según nuestro anuncio, continuaremos soportando Hyperbola GNU/Linux-libre hasta el 2022 (cuarto trimestre). Esperamos que haya alguna dificultad en la migración debido a los cambios en la ABI*, pero prepararemos un anuncio e información en nuestro wiki una vez que esté listo.
ItsFOSS: Si alguien está interesado en ayudarle a trabajar en HyperbolaBSD, ¿cómo puede hacerlo? ¿Qué tipo de experiencia estarían buscando?
Andre: Cualquiera que esté interesado y sea capaz de aprender es bienvenido. Necesitamos programadores y usuarios de C que estén interesados en mejorar la seguridad y la privacidad en el software. Los desarrolladores necesitan seguir los principios del FSDG para el desarrollo de software libre, así como el principio de la YAGNI* que significa que implementaremos las nuevas características sólo cuando las necesitemos.
Los usuarios pueden bifurcar nuestro repositorio git y enviarnos los parches para su inclusión.
ItsFOSS: ¿Tienen algún plan para soportar ZFS? ¿Qué sistemas de archivos serán compatibles?
Andre: El soporte de ZFS no está planeado actualmente, porque utiliza la Licencia Común de Desarrollo y Distribución, versión 1.0 (CDDL). Esta licencia es incompatible con todas las versiones de la Licencia Pública General de GNU (GPL).
Sería posible escribir nuevo código bajo GPLv3 y liberarlo bajo un nuevo nombre (por ejemplo, HyperZFS), sin embargo no hay una decisión oficial de incluir código de compatibilidad con ZFS en HyperbolaBSD en este momento.
Tenemos planes de portar BTRFS, JFS2, CHFS de NetBSD, HAMMER/HAMMER2 de DragonFlyBSD y JFFS2 del kernel de Linux, todos los cuales tienen licencias compatibles con la GPLv3. A largo plazo, también podemos soportar Ext4, F2FS, ReiserFS y Reiser4, pero necesitarán ser reescritos debido a que están licenciados exclusivamente bajo la GPLv2, la cual no permite el uso con la GPLv3. Todos estos sistemas de archivos requerirán desarrollo y pruebas de estabilidad, por lo que estarán en versiones posteriores de HyperbolaBSD y no para nuestra(s) versión(es) estable(s) inicial(es).
Me gustaría agradecer a Andre por tomarse el tiempo de responder a mis preguntas y por revelar más sobre el futuro de HyperbolaBSD.
Entrevista original en It’s Foss
Publicado bajo permiso de John Paul Wohlschied y André Silva.
Deblobbing*: Entender este término como la limpieza de blobs sin código fuente del kernel de Linux.
ABI: Interfaz binaria del computador + la API.
Grsec: Abreviatura de grsecurity, que es un conjunto de parches para el kernel de Linux que enfatiza las mejoras de seguridad.
Rebranding: Cambio de marca o rediseño.
UXP: Desarrollo del Front-End.
YAGNI: En ingeniería de software la filosofía de desarrollo de programas.
Fuente: maslinux
