Cómo crear un porte para OpenBSD

Lo más importante que debe hacer es comunicarlo. Pregunte en ports@openbsd.org por si alguien ya estuviera trabajando en lo mismo. Comuníqueselo al autor original del programa, e incluya los problemas que pueda encontrar. Si aparece algún error en la información sobre la licencia hágaselo saber. Si tuvo que evitar bucles para crear el porte, dígale qué es lo que debe solucionar. Si sólo están desarrollando para Linux y da la impresión de que les trae sin cuidado el resto del mundo Unix, intente hacer que cambien de opinión.

La COMUNICACIÓN es lo que marca la diferencia entre un porte con éxito y un porte que tarde o temprano será abandonado por todos.

Antes que nada eche un vistazo a la información sobre portes en esta página y luego lea los documentos a los que se hace referencia, especialmente a la lista de comprobación de portes de OpenBSD.

¡Haga pruebas una y otra vez!   y, finalmente... ¡vuelva a repasarlas!

Envíe el porte. Haga un archivo comprimido con tar y gzip del directorio del porte. Lo puede poner en un servidor público de FTP o HTTP y enviar la dirección de éste a ports@openbsd.org, o enviarlo directamente a esta dirección con codificado MIME. Elija el método que más le convenga.

Índice de documentación para portar programas

• Información disponible para portar programas
• Política sobre portes de OpenBSD
• Recomendaciones de seguridad
• Consejos generales para portar
• Otros consejos de ayuda

Información disponible

• Lista de comprobación de portes de OpenBSD.
• La página del manual de bsd.port.mk(5). Contiene la información sobre la infraestructura de los portes que se incluye al final de los ficheros Makefile de cada porte. Todavía hay algunos comentarios al inicio del mismo fichero, pero la mayor parte de la información útil está documentada.
• Algunas diferencias con otros sistemas de portes de BSD, sobre todo un sumario de las diferencias de infraestructura.
• Cómo usar las bibliotecas compartidas en el sistema de portes de OpenBSD. Las reglas que contiene son muy importantes si se usan bibliotecas compartidas, en especial si pkg_update funciona algún día...
• Cómo portar aplicaciones de audio a OpenBSD
• La documentación NetBSD Package System describe la versión de NetBSD del sistema de portes de FreeBSD, y es muy útil.
• La Guía de Portadores de FreeBSD. Es la biblia para los portes en FreeBSD.
• La lista de correo para los portes de OpenBSD ports@OpenBSD.org.

Política sobre portes de OpenBSD

• Debido a que /usr/local es un sistema de archivo con frecuencia compartido entre varias máquinas mediante NFS, OpenBSD NO usa /usr/local/etc/rc.d. Por este motivo los ficheros de configuración específicos de cada máquina no se pueden guardar en /usr/local, y por tanto /etc es el repositorio central para los ficheros de configuración específicos de cada máquina. Más aún, la política de OpenBSD es la de no actualizar nunca de forma automática los ficheros en /etc. Los portes que necesitan algún tipo de configuración de arranque deben avisar al administrador del sistema de lo que éste debe hacer en lugar de instalar ficheros a ciegas.
• Las páginas de manual en OpenBSD NO están comprimidas.
• OpenBSD NO requiere -lcrypt.
  El cifrado con DES es parte del libc típico.
• OpenBSD tiene un espacio de nombre separado para los usuarios y grupos creados por los portes. Vése /usr/ports/infrastructure/db/user.list para más detalles.
• OpenBSD tiene una fuerte orientación hacia la seguridad. Se aconseja leer y asimilar la sección sobre seguridad en esta página.
• Asegúrese de que añade la marca de CVS $OpenBSD$ al fichero de Makefile. Si importa un porte desde otro sistema, asegúrese de que también conserva la marca en el archivo Makefile.
• El objetivo a alcanzar es que todas las aplicaciones portadas tengan soporte en OpenBSD. Para conseguirlo debe informar ampliamente sobre cualquier parche para OpenBSD al mantenedor de la aplicación.

Recomendaciones de seguridad

• NO use código en estado alpha o beta cuando esté creando un porte. Use la revisión o versión más actual.
• Cualquier programa que vaya a ser instalado como servidor debería ser escaneado en busca de desbordamientos en la memoria intermedia (buffer overflows), especialmente en el caso de utilización insegura de strcat/strcpy/strcmp/sprintf. Como regla general, sprintf se debe substituir siempre con snprintf.
• No use nunca nombres de ficheros en lugar de seguridad real. Existen numerosas condiciones de carrera para las que no se tiene un debido control. Por ejemplo, un atacante que ya haya obtenido privilegios de usuario en sus máquinas puede substituir ficheros en /tmp con enlaces simbólicos a ficheros más estratégicos, como /etc/master.passwd.
• También, un ejemplo a tener en cuenta es que tanto fopen como freopen generan un nuevo fichero o abren ficheros ya existentes con permisos para escritura. Un atacante puede crear un enlace simbólico desde /etc/master.passwd a /tmp/addrpool_dump. En cuanto Vd. lo abra, el fichero de su contraseña será filtrado. Sí, incluso con un unlink antes, que tan sólo minimizaría el riesgo. Use open con O_CREATIO_EXCL y fdopen en lugar de lo anterior.
• Otro problema muy común es el de la función mktemp. Haga caso a los avisos del enlazador de bsd sobre su uso. Se deben solucionar. Esto no es tan sencillo como s/mktemp/mkstemp/g.
  Para más indicaciones sobre este respecto vaya a la página de manual de mktemp(3) en OpenBSD-current. Un ejemplo de código correcto que use mkstemp puede ser el de los fuentes de ed o mail. Se puede encontrar un tipo poco usual de código que use correctamente mktemp en el porte rsync.
• Que lo pueda leer no implica que lo deba leer. Un agujero muy conocido de esta naturaleza era el del problema con startx. Al ser un programa setuid, se podía ejecutar con cualquier fichero como guión (script). Si el fichero no era un guión válido del intérprete de órdenes ("shell"), le seguía un mensaje de error junto con la primera línea de error del fichero, sin comprobar más permisos. Considerando que los ficheros shadow passwd a menudo comienzan con una entrada de root, obtener esta primera línea era bastante útil para un atacante. No abra un fichero y a continuación ejecute fstat en el descriptor abierto para comprobar lo podría haber abierto (o el atacante jugará con /dev/rst0 y rebobinará su cinta); ábralo con el uid/gid/grouplist correcto.
• No use nada que cree un proceso hijo de una shell en programas setuid antes de haber eliminado sus privilegios. Esto incluye popen y system. En su lugar use fork, pipe y execve.
• Pase descriptores abiertos en lugar de nombres de archivos a otros programas para evitar condiciones de carrera. Aun en el caso de que un programa no acepte descriptores de ficheros, puede usar /dev/fd/0.
• Los derechos de acceso van adjuntos a los descriptores de ficheros. Si necesita derechos setuid para abrir un fichero, abra ese fichero y elimine sus privilegios. Esto es un arma de doble filo: incluso después de haber eliminado sus privilegios, deberá observar esos descriptores.
• Evite root setuid siempre que pueda. En principio puede hacer cualquier cosa, pero los derechos de root se necesitan en raras ocasiones, tal vez excepto para crear portes de "socket" con un número por debajo de 1024. En este caso tal vez sea mejor controlarlo con inetd y simplemente añadir las entradas relevantes a inetd.conf. Debe conocer el "magic" apropiado requerido para poder codificar "dæmons". Se podría decir que no se tienen programas setuid comerciales si no se sabe cómo hacerlo.
• Use setgid en lugar de setuid. Aparte de los ficheros específicos que necesitan los programas setgid, la mayoría de ficheros no tienen permisos de escritura para grupo. Por tanto, un problema de seguridad en un programa setgid no comprometerá tanto su sistema; con sólo derechos de grupo, lo peor que podrá hacer un atacante es cambiar la tabla de puntuación de un juego o algo parecido. Vea el porte xkobo como un ejemplo de un cambio de este tipo.
• No confíe en ficheros con permisos de escritura para grupo. Aunque hayan pasado una auditoría, los programas setgid no se perciben como un agujero de seguridad en potencia. Por lo tanto, cualquier cosa que pueda ser falsificada no debería ser considerarada como información reservada.
• ¡No confíe en su entorno! Esto incluye cosas tan sencillas como su PATH (nunca use system con un nombre no cualificado y evite execvp), pero tampoco de entornos menos obvios como su locale, timezone, termcap y otros. Nunca use system en programas privilegiados; en su lugar cree su propia orden de línea, un entorno controlado, y una llamada directa a execve. La página de manual de perlsec es una buena tutorial sobre estos problemas.
• Nunca use guiones de ejecución del intérprete de órdenes ("shell scripts") setuid. Éstos son inseguros por definición. Envuélvalos dentro de código C que asegure un entorno apropiado. Por otra parte, las características de OpenBSD incluyen guiones de perl seguros.
• Tenga cuidado con el cargador dinámico. Si está ejecutando setuid sólo ejecutará bibliotecas que hayan sido escaneadas con ldconfig. Setgid no basta.
• Las bibliotecas dinámicas son complicadas. El código C++ presenta un problema parecido. Básicamente, las bibliotecas pueden tomar alguna acción basándose en su entorno antes incluso de que su programa principal haya podido comprobar su estado setuid. OpenBSD issetugid trata este problema desde el punto de vista del escritor de bibliotecas. No intente portar bibliotecas a menos que conozca este tema a la perfección.

Consejos generales

• __OpenBSD__ se debería usar con cuentagotas o mejor no usarlo en absoluto. Construcciones como

          #if defined(__NetBSD__) || defined(__FreeBSD__)
      

  son a menudo inapropiadas. No añada __OpenBSD__ a éstas a ciegas. En lugar de esto, intente imaginar qué es lo que está ocurriendo y qué es lo que se necesita. Las páginas de manual son de gran utilidad para estos casos, ya que incluyen comentarios de tipo historial en los que se menciona cuándo una característica particular se integró en BSD. Contrastar el valor numérico de BSD con el de las versiones conocidas es por lo general la forma correcta de hacerlo. Véase the NetBSD package guide para obtener más información al respecto.
• Definir BSD no es una buena idea, al contrario. Intente incluir sys/parm.h. Esto no sólo define BSD, sino que también le da un valor apropiado. El fragmento de código correcto debería ser así:

          #if (defined(__unix__) || defined(unix)) && !defined(USG)
          #include <sys/param.h>
  	#endif
      

• Base sus comprobaciones en las características, no en sistemas operativos específicos. A la larga es mucho mejor comprobar si tcgetattr funciona que si está funcionando en BSD 4.3 o posterior, o en SystemVR4. Este tipo de pruebas sólo confunden. La manera de hacerlas es, por ejemplo, comprobándolo para un sistema en particular, configurar los ficheros define con HAVE_TCGETATTR, y a continuación proceder con el sistema siguiente. Esta técnica separa las comprobaciones de características de los sistemas operativos específicos. De forma rápida, otro portado puede así simplemente añadir todas las definiciones -DHAVE_XXX en el fichero Makefile. También es posible escribirlo o añadirlo a un guión de configuración para comprobar esa característica y añadirla de modo automático. Como un ejemplo de lo que no se debe hacer, compruebe los fuentes de nethack 3.2.2: asume un montón de cosas basadas en el tipo del sistema. La mayoría de éstas están obsoletas y ya no reflejan la realidad: las funciones POSIX son más útiles que las viejas diferencias entre BSD y SystemV, hasta el punto que algunas funciones bsd tradicionales sólo conservan el soporte mediante bibliotecas de compatibilidad.
• Evite incluir ficheros que incluyan otras inclusiones que... Primero, porque no es eficiente. Su proyecto acabará incluyendo un fichero que incluya todo. También, porque hace que algunos problemas sean difíciles de solucionar. Se hace más difícil no incluir un fichero particular en un momento dado.
• Evite macros estrafalarias. No definir una macro que fue definida por un fichero de cabecera es una mala idea. Definir macros para obtener un comportamiento específico de un fichero include también es una mala idea: los modos de compilación deberían ser globales. Si quiere obtener un comportamiento POSIX dígalo, y añada #define POSIX_C_SOURCE en todo el proyecto, no sólo cuando lo crea conveniente.
• Nunca escriba prototipos de funciones de sistema. Todos los sistemas modernos, incluido OpenBSD, tienen una localización típica para estos prototipos. Dichas localizaciones es probable que sean unistd.h, fcntl.h, o termios.h entre otras. La página de manual suele indicar dónde se puede encontrar el prototipo. Es posible que necesite otras cuantas macros de HAVE_XXX para conseguir el fichero correcto. No se preocupe por incluir el mismo fichero dos veces, los ficheros include tienen métodos de prevención contra esto.
  Si algún sistema defectuoso necesita que escriba el prototipo, no lo imponga en otros sistemas. El uso de prototipos propios no funcionará porque pueden usar tipos que son equivalentes en su sistema, pero no son portables a otros sistemas (unsigned long en lugar de size_t), o resultarán en estados incorrectos de const. Además, algunos compiladores como el gcc propio de OpenBSD, pueden hacer un trabajo mejor como algunas funciones muy frecuentes como strlen si incluye el fichero de cabecera correcto.
• No use el nombre de una función de sistema típica para nada más. Si quiere escribir su propia función, déle su propio nombre, y llame a esa función en todas partes. Si desea volver a la función de sistema por definición, sólo tiene que comentar su código y definir su propio nombre en la función del sistema. No lo haga de otro modo. El código debería ser del siguiente modo

         /* prototype part */
         #ifdef USE_OWN_GCVT
         char *foo_gcvt(double number, size_t ndigit, char *buf);
         #else
         /* include correct file */
         #include <stdlib.h>
         /* use system function */
         #define foo_gcvt  gcvt
         #endif
  
         /* definition part */
         #ifdef USE_OWN_GCVT
         char *foo_gcvt(double number, size_t ndigit, char *buf)
            {
            /* proper definition */
            }
  
         /* typical use */
         s = foo_gcvt(n, 15, b);
         

Otros consejos

• Las versiones recientes de bsd.port.mk definen el camino de los instaladores. En particular, definen que se busque en /usr/bin y /bin antes que /usr/local/bin y /usr/X11R6/bin.
• NO genere bibliotecas compartidas si ${NO_SHARED_LIBS} es igual a "YES" (cuidado, sólo se puede definir después de incluir bsd.port.mk). Si su porte tiene un GNU configure, añada la línea CONFIGURE_ARGS += ${CONFIGURE_SHARED} al fichero Makefile.
• El uso de una funcionalidad que haya aparecido en una versión reciente de bsd.port.mk es aceptable, ya que se supone que los usuarios deben actualizar sus árboles de portes al completo, incluido bsd.port.mk. Ahora NEED_VERSION está obsoleto.
• Prefiera el uso de update-plist para generar y actualizar las listas de empacamiento en vez de hacerlo manualmente. Puede comentar las lineas que no desee. update-plist puede detectar la mayoría de los tipos de archivos y copiar la mayoría de las anotaciones adicionales correctamente.
• En OpenBSD curses.h/libcurses/libtermlib es el «nuevo curses». Cambio:
  ncurses.h ==> curses.h
  El «viejo (BSD) curses» está disponible definiendo _USE_OLD_CURSES_ antes de incluir curses.h (por lo general en un fichero Makefile) y enlazándolo con -locurses.
• En OpenBSD el terminal se ha actualizado del viejo sgtty de BSD al nuevo tcgetattr de POSIX. Evite el viejo estilo en código nuevo. Algo de código es posible que defina tcgetattr como sinónimo del viejo sgtty, pero esto es como mucho una medida temporal en OpenBSD. El código fuente de xterm es un buen ejemplo de lo que no hay que hacer. Intente obtener la funcionalidad de su sistema correctamente: lo que quiere es un tipo que recuerde el estado de su terminal (probablemente typedef), una función que extraiga el estado actual, y una función que configure un nuevo estado. Las funciones que modifican este estado son más difíciles, ya que tienden a variar según el sistema. Tampoco olvide que tendrá que manejar casos en los que no esté conectado a un terminal, y en los que se necesita poder manejar señales: no sólo de terminación, sino también de fondo (SIGTSTP). Debería dejar siempre el terminal en un buen estado. Lleve a cabo verificaciones en intérpretes de órdenes ("shells") más viejos como sh, que no reconfiguren el terminal de ningún modo al terminar un programa.
• Los termcap/terminfo y curses más modernos, como los que se incluyen con OpenBSD, incluyen secuencias típicas para el control de terminales de color. Si es posible debería usar éstas, volviendo a las secuencias de color típicas de ANSI en otros sistemas. Sin embargo, las descripciones de algunos terminales todavía no se han actualizado, y es posible que necesite poder especificar estas secuencias de modo manual. Éste es el modo en que lo hace vim. Esto no es estrictamente necesario. Excepto en casos de programas privilegiados, por lo general es posible anular una definición termcap mediante la variable TERMCAP y hacer que funcione correctamente.
• La semántica de señales es complicada, y varía de un sistema a otro. Use sigaction para asegurarse semánticas específicas, junto con otras llmadas al sistema cuya referencia puede encontrar en las páginas de manual.