Construction d'un port OpenBSD

La chose la plus importante que vous puissiez faire est communiquer. Demandez aux personnes sur ports@openbsd.org si elles travaillent déjà sur ce port. Parlez en à l'auteur du logiciel, en évoquant aussi les problèmes que vous pourriez rencontrer. Si l'information sur la licence utilisée apparait comme incorrecte, informez le en. Si vous avez du jongler pour faire la construction du port, dites lui ce qu'il pourrait corriger. S'ils développent exclusivement sur Linux et ignorent le reste du monde Unix, essayez de les faire changer de point de vue.

La COMMUNICATION fait la différence entre un port réussi et un port qui sera abandonné progressivement par tout le monde.

Premièrement, regardez les informations de portage sur cette page. Ensuite, consultez les documents référencés, notamment la liste de contrôle de portage OpenBSD.

Testez, et re-testez, et enfin testez encore !

Soumettez le port. Créez un tarball gzippé du répertoire du port. Vous pouvez soit le déposer sur un serveur FTP ou HTTP publique, soit l'envoyer à ports@openbsd.org, soit envoyer le port avec un encodage mime à la même adresse. Choisissez la méthode qui vous convient le plus.

Index de la Documentation de Portage

• Informations de Portage disponibles
• Politique de Portage OpenBSD
• Recommandations de Sécurité
• Conseils de Portage Génériques
• D'autres Conseils Utiles

Informations de portage disponibles

• La liste de contrôle de Portage OpenBSD.
• La page de manuel bsd.port.mk(5). Celle- ci renseigne sur le makefile d'infrastructure des ports qui est inclus à la fin de chaque makefile de port. Il y a toujours quelques commentaires au début même du fichier, mais la plupart des informations utiles sont à présent documentées.
• Quelques différences avec les autres systèmes de port BSD, qui est un résumé des différences d'infrastructures.
• L'utilisation des librairies partagées dans les Ports OpenBSD. Ces règles sont très importantes lorsque vous utilisez les librairies partagées.
• Les spécificités de GNU autoconf, comment les traiter dans le cas des ports OpenBSD.
• Les fichiers de configuration, une partie fréquemment problématique pour les nouveaux développeurs, et les outils uniques avec lesquels l'arbre des ports OpenBSD doit traiter.
• Portage des applications audio sur OpenBSD.
• La documentation du pkgsrc de NetBSD. Ce document dcrit la version NetBSD du systme de ports de FreeBSD et est trs utile.
• Le Guide du Porteur FreeBSD. C'est la bible du portage FreeBSD.
• La liste de diffusion sur les ports OpenBSD, ports@openbsd.org.

Politique de Portage OpenBSD

• OpenBSD N'utilise PAS /usr/local/etc/rc.d.
  /usr/local est parfois partagé entre plusieurs machines grâce à NFS. Pour cette raison, les fichiers de configuration spécifiques à une machine ne peuvent être stockés dans /usr/local, /etc est le dépôt central pour les fichiers de configuration propres à une machine. De plus, la politique d'OpenBSD est de ne jamais mettre à jour les fichiers dans /etc automatiquement. Les ports qui nécessitent des réglages de "boot" spécifiques devraient informer l'administrateur de ce qu'il faut faire plutôt que d'installer aveuglément les fichiers.
• OpenBSD NE compresse PAS les pages de manuel.
• OpenBSD NE nécessite PAS -lcrypt.
  Le chiffrement DES fait partie de la libc standard.
• OpenBSD a un espace de nommage séparé pour les utilisateurs et les groupes créés par les ports. Consultez /usr/ports/infrastructure/db/user.list pour les détails.
• OpenBSD est très fortement orienté sécurité. Vous devriez lire et comprendre la section sécurité de cette page.
• Assurez vous d'ajouter le "tag" CVS $OpenBSD$ dans le Makefile. Si vous importez le port d'un autre système, assurez vous d'enlever également les "tags" précédents dans le Makefile.
• Le but est de rendre toutes les applications portées compatibles avec OpenBSD. Afin d'atteindre cet objectif, vous devez fournir les patches OpenBSD au mainteneur.

Recommandations de Sécurité

• N'utilisez pas de code alpha ou beta lors de la création du port. Utilisez la dernière révision, ou la dernière révision stable.
• Tous les logiciels à installer en tant que serveur devraient être analysés sur la présence de débordements de tampon, et particulièrement les utilisations non sures de strcat/strcpy/strcmp/sprintf. En général, sprintf devrait être remplacé par snprintf.
• N'utilisez jamais de noms de fichiers au lieu de la sécurité réelle. De nombreuses situations de compétition existent sur lesquelles vous n'avez pas le contrôle. Par exemple, un attaquant qui possède déjà des privilèges utilisateur sur votre machine pourrait remplacer les fichiers dans /tmp avec des liens symboliques vers des fichiers plus stratégiques, comme /etc/master.passwd.
• Par exemple, fopen ainsi que freopen créent un nouveau fichier ou en ouvrent un existant en écriture. Un attaquant pourrait créer un lien symbolique depuis /etc/master.passwd vers /tmp/addrpool_dump. Au moment ou vous l'ouvrez, le fichier de mots de passe est modifié. Oui, même avec un unlink juste avant. Vous ne faites que rétressir le champ des possibilités. Utilisez plutôt open avec O_CREAT|O_EXCL et fdopen.
• Un autre problème très courant est la fonction mktemp Ne négligez pas les avertissements de l'éditeur de liens bsd sur son utilisation. Ces derniers doivent être corrigés. Ce n'est pas aussi simple que s/mktemp/mkstemp/g.
  Réferrez vous à la page de manuel mktemp(3) d'OpenBSD -current pour plus d'indications. Le code correct utilisant mkstemp inclus les sources de ed et mail. Un des rares cas d'utilisation correcte de mktemp est le port de rsync.
• Juste parce que vous pourriez vous apercevoir que cela ne fait pas ce à quoi vous vous attendiez. Un problème de cette nature était le problème startx. En tant que programme setuid, vous pouviez lancer startx avec tout script. Si le fichier n'était pas un script shell valide, un message d'erreur suivait, affichant la première ligne du fichier en question, sans aucune vérification supplémentaire. Il était ainsi très facile d'afficher la première ligne du fichier de mots de passe shadow, celle-ci étant souvent l'entrée root. N'ouvrez pas votre fichier, et faites ensuite un fstat sur le descripteur ouvert pour vérifier si vous auriez été en mesure de l'ouvrir (ou l'attaquant jouera avec /dev/rst0 et réembobinera votre bande) -- ouvrez le avec des informations uid/gid/grouplist correctes.
• N'utilisez rien qui "fork" un shell dans un programme setuid avant de renoncer à vos privilèges. Ceci inclus popen et system. Utilisez fork, pipe et execve à la place.
• Transmettez des descripteurs ouverts aux autres programmes plutôt que des noms de fichiers pour éviter les situations de compétition. Même si un programme n'accepte pas les descripteurs, vous pouvez toujours utiliser /dev/fd/0.
• Les droits d'accès sont attachés aux descripteurs de fichiers. Si vous avez besoin des droits setuid pour ouvrir un fichier, ouvrez ce fichier, et abandonnez vos privilèges. Vous pourrez toujours accéder au descripteur ouvert, mais vous aurez moins à vous en inquiéter. C'est à double tranchants : même après avoir abandonné les privilèges, vous devriez continuer à observer ces descripteurs.
• Evitez les programmes setuid root autant que vous pouvez. Root peut tout faire mais les droits root sont rarement nécessaires, sauf peut être pour créer des sockets avec un port inférieur à 1024. Il est recommandé de faire cela via inetd, vous n'avez qu'a ajouter les entrées correspondantes dans inetd.conf. Vous devez connaitre la magie appropriée pour écrire des démons réussis. On peut dire que vous n'avez pas d'intérêt à écrire des programmes setuid si vous ne savez pas comment le faire.
• Utilisez setgid plutôt que setuid. Ormis les fichiers spécifiques nécessaires aux programmes setgid, beaucoup de fichiers ne sont pas inscriptibles par le groupe. Par conséquent, un problème de sécurité dans un programme setgid ne compromettra pas davantage votre système : avec seulement les droits du groupe, le pire qu'un attaquant puisse faire est de hacker la table de scores d'un jeu ou quelquechose du genre. Consultez le port xkobo pour un exemple d'un tel changement.
• Ne faites pas confiance aux fichiers inscriptibles par un groupe. Même s'ils sont audités, les programmes setgid ne sont pas perçus comme autre chose que des trous de sécurité. Même si les données qu'ils manipulent ne sont pas qualifiables de sensibles.
• Ne faites pas confiance à votre environnement ! Cela implique un certain nombre de choses comme votre "PATH" (n'utilisez jamais system avec un nom sans chemin indiqué, évitez execvp), mais aussi des éléments plus subtiles comme votre locale, votre fuseau horaire, votre "termcap" et ainsi de suite. Rendez vous compte de la relativité : même si vous prenez des précautions importantes, les programmes que vous appelez directement ne le sont pas nécessairement. Ne jamais utiliser system dans des programmes privilégiés, construisez votre ligne de commande, un environnement contrôlé, et appelez execve directement. La page de manuel perlsec est un bon guide sur les problèmes de ce genre.
• N'utilisez jamais de scripts shell setuid. Ils sont par essence non sécurisés. Enveloppez les dans du code C qui s'assure d'un environnement propre. De l'autre côté, OpenBSD comporte des scripts perl sécurisés.
• Prenez garde au chargeur dynamique. Si vous lancez un setuid, seules les librairies de confiance qui ont été scannées par ldconfig seront chargées. Setgid n'est pas suffisant.
• Les librairies dynamiques sont rusées. Le C++ pose un problème similaire. Typiquement, les librairies pourraient procéder à un certain nombre d'actions basées sur votre environnement avant que votre programme principal n'ait eu le temps de vérifier l'état setuid. issetugid d'OpenBSD règle ce problème du point de vue de l'auteur de la librairie. N'essayez pas de porter des librairies si vous ne comprenez pas ces problèmes.

Conseils de Portage Génériques

• __OpenBSD__ devrait être utilisé avec parcimonie. Les constructions qui ressemblent à

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

  sont souvent inappropriées. N'y ajoutez pas aveuglément __OpenBSD__ . Essayez plutôt de comprendre ce qui se passe, et quelles sont les fonctionnalités actuellement nécessaires. Les pages de manuel sont souvent utiles, car elles contiennent des commentaires historiques, et traitent du moment ou une fonctionnalité particulière fut intégrée dans BSD. La vérification de la valeur numérique de BSD plutôt que les revisions connues est souvent le bon moyen. Consultez le guide du package NetBSD pour plus d'informations.
• La définition de BSD est une mauvaise idée. Essayez d'inclure sys/param.h. Cela ne définit pas seulement BSD, mais lui donne aussi une valeur propre. Le bon fragment de code devrait ressembler à :

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

• Testez les fonctionnalités, mais pas pour un ou des OS spécifiques. Lors du long lancement, il est mieux de tester ou tcgetattr plutôt que de le faire seulement sous BSD 4.3 ou plus récent, ou SystemVR4. Les tests de ce genre ne font que confondre le problème. Le moyen d'obtenir des résultats est, par exemple, de tester pour un système particulier, configurer un groupe de définitions HAVE_TCGETATTR, et passez au système suivant. Cette technique sépare les fonctionnalités de tests des spécificités des OS. Dans la précipitatation, un autre porteur peut juste ajouter le jeu de définitions - DHAVE_XXX complet au Makefile. L'un d'entre eux peut aussi écrire ou ajouter à un script "configure" la vérification de cette fonctionnalité et son ajout automatique. Pour un exemple qu'il ne faut pas suivre, consultez les sources de nethack 3.2.2 : elles contiennent des chargements basés sur le type du système. La plupart de ces prétentions sont obsolètes et ne reflettent plus la réalité : les fonctions POSIX sont plus utiles que les plus anciennes différences entre BSD et SystemV, au point que certaines fonctions bsd traditionnelles sont à présent seulement supportées dans les librairies de compatibilité.
• Evitez d'inclure des fichiers qui incluent d'autres fichiers qui... Premièrement car c'est inefficace. Votre projet finira par inclure un fichier qui inclus tout. Egalement car cela rend certains problèmes difficiles à corriger. Il devient plus difficile de ne pas inclure un fichier à un point précis.
• Evitez les astuces de macros bizarres. La suppression d'une macro qui était définie par un fichier d'entête est une mauvaise idée. Définir des macros devant avoir des comportements spéciaux depuis un fichier inclus est aussi une mauvaise idée : les modes de compilation devraient être généraux. Si vous désirez un comportement POSIX, dites non, et #define POSIX_C_SOURCE dans le code de tout le projet, et pas seulement quand vous en aurez besoin.
• N'écrivez pas systématiquement les prototypes de fonctions. Tous les systèmes modernes, OpenBSD inclus, ont une place standard pour ces prototypes. Comme celles qui incluent unistd.h, fcntl.h ou termios.h. La page de manuel traite fréquemment du lieu ou le prototype peut être trouvé. Vous devriez avoir besoin d'un autre groupe de macros HAVE_XXX pour vous procurrez le bon fichier. Ne soyez pas inquiet sur le fait d'inclure un même fichier deux fois, les fichiers "d'includes" ont des gardes qui préviennent de désagréments liés à ceci.
  Si des systèmes tordus veulent que vous écriviez les prototypes, ne les imposez pas à tous les autres systèmes. Faites vos propres prototypes posera des problèmes car les types utilisés pourraient être équivalents sur votre système, mais pas portable sur les autres systèmes (entier long non signé plutôt que size_t), ou obtenir des états const incorrects. Aussi, des compilateurs, comme le gcc d'OpenBSD, sont capables de produire un meilleur travail avec des fonctions très fréquentes comme strlen si vous incluez le bon fichier d'entête.
• N'utilisez pas le nom d'une fonction système standard pour quelquechose d'autre. Si vous voulez écrire la votre, donnez lui un nom propre, et appelez cette fonction partout. Si vous désirez revenir à la fonction par défaut du système, vous n'aurez qu'a commenter votre code, et définir votre nom pour cette fonction. Ne le faites pas autrement. Le code devrait ressembler à ceci

   /* 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);
         

D'autres Conseils Utiles

• Les versions récentes de bsd.port.mk positionnent les chemins des installeurs. Spécifiquement, ils positionnent /usr/bin et /bin pour être parcourus avant /usr/local/bin et /usr/X11R6/bin.
• Ne générez PAS de librairies partagées si ${NO_SHARED_LIBS} est positionné à oui (prenez garde, cela peut être définit seulement après l'inclusion de bsd.port.mk). Si votre port a un "configure" GNU, ajoutez simplement CONFIGURE_ARGS += ${CONFIGURE_SHARED} au Makefile.
• Comptez sur une fonctionnalité apparue dans une version récente de bsd.port.mk est OK, car les gens sont supposés mettre à jour leurs arbres de ports complets, incluant bsd.port.mk. NEED_VERSION est à présent obsolète.
• Préférez l'utilisation de update-plist pour générer et mettre à jour les listes de paquetage plutôt que de faire les choses manuellement. Vous pouvez commenter les lignes inutiles. update-plist peut détecter la plupart des mtypes et copier la plupart des annotations additionnelles correctement.
• Ajoutez USE_SYSTRACE=Yes dans /etc/mk.conf afin de détecter les scripts qui se comportent bizarrement, les makefiles etc.
• Dans OpenBSD curses.h/libcurses/libtermlib sont les ``nouvelles curses''. Changement :
  ncurses.h ==> curses.h
  ``anciennes curses (BSD)'' est disponible en définissant _USE_OLD_CURSES_ avant l'inclusion de curses.h (généralement dans un Makefile) et édition de liens avec -locurses.
• Dans OpenBSD, la discipline de terminal a été mise à jour depuis l'ancienne sgtty BSD vers la nouvelle famille POSIX tcgetattr. Evitez l'ancien style dans le nouveau code. Certains codes pourraient définir tcgetattr comme étant un synonyme de l'ancienne sgtty, mais ceci est au mieux un espace de stop sur OpenBSD. Le code source de xterm est un très bon exemple de ce qu'il ne faut pas faire. Essayez de rendre les fonctionnalités de votre système correctes : vous voulez un type qui se souvient de l'état de votre terminal (typedef possible), vous voulez une fonction qui extrait l'état courant, et une fonction qui applique le nouvel état. Les fonctions qui modifient cet état sont plus compliquées, car elles tendent à varier selon le système. Aussi, n'oubliez pas que vous pourriez être amené à des cas ou vous n'êtes pas connecté à un terminal, et ou vous devriez gérer les signaux, pas seulement ceux de terminaison, mais aussi d'arrière plan (SIGTSTP). Vous devriez toujours laisser un terminal avec un état correct. Faites vos tests sur un shell plus ancien, comme sh, qui ne réinitialise pas le terminal lors de la terminaison du programme.
• Le nouveau termcap/terminfo et curses, inclus avec OpenBSD, comporte des séquences standard pour le contrôle des couleurs dans les terminaux. Vous devriez les utiliser si cela est possible, en se retournant sur les séquences de couleurs ANSI standards sur les autres systèmes. Cependant, certaines descriptions de terminaux n'ont pas encore été mises à jour, et vous pourriez avoir à les spécifier manuellement. C'est par exemple le cas de vim. Ce n'est pas strictement nécessaire. Excepté pour les programmes privilégiés, il est généralement possible de redéfinir une définition termcap via la variable TERMCAP et avoir un fonctionnement correct.
• Les sémantiques des signaux sont rusées, et varient d'un système à l'autre. Utilisez sigaction pour être sur d'une sémantique, ainsi qu'avec les autres appels système référencés dans les pages de manuel correspondantes.