Das Erzeugen eines OpenBSD-Portierung

Die wichtigste Sache, die du machen solltest, ist mit anderen zu kommunizieren. Frage die anderen Leute auf ports@openbsd.org, ob sie an derselben Portierung arbeiten. Teile es dem ursprünglichen Programmierer mit, inklusive der Probleme, wenn du welche findest. Wenn die Lizenzbedingungen nicht korrekt sind, sag es ihm. Wenn du große Schwierigkeiten hattest, die Portierung zum Laufen zu kriegen, teile ihm mit, was verbessert werden könnte. Wenn sie nur auf Linux entwickeln und den Rest der Unix-Welt ignorieren, versuche, ihre Sichtweise etwas zu erweitern.

KOMMUNIKATION macht den Unterschied zwischen einer erfolgreichen Portierung und einer Portierung, die langsam von allen alleine gelassen und nicht mehr benutzt wird, aus.

Sieh dir zuerst die Portierungsinformationen auf dieser Seite an. Dann überprüfe all die gelinkten Dokumente, insbesondere die OpenBSD-Porting-Checkliste.

Teste, teste nochmal und schlussendlich teste nochmals!

OpenBSD unterstützt Updates nun vollständig. Dies bedeutet, dass ein paar Sonderfälle berücksichtigt werden müssen.

Liefere die Portierung aus (submit). Erzeuge einen ,gzipped tarball' des Verzeichnisses der Portierung. Du kannst diesen entweder auf einen öffentlichen FTP- oder HTTP-Server legen und die Adresse an ports@openbsd.org mailen oder ,mime encoded' an die selbe Adresse schicken. Wähle einfach eine Methode aus.

Neue Software zu portieren nimmt Zeit in Anspruch. Schwerer ist es allerdings, diese danach weiterhin zu verwalten. Es ist schon in Ordnung, wenn du Software portierst und die Verwaltung Anderen überlässt. Es ist ebenfalls in Ordnung, wenn du Anderen bei der Aktualisierung und Verwaltung anderer Portierungen hilfst, so lange du mit ihnen in Verbindung bleibst, damit nicht die gleiche Arbeit mehrmals gemacht wird.

In der OpenBSD-Kultur zählt »MAINTAINERship« (auf Deutsch Betreuung) nicht als Statussymbol sondern als Verantwortung. Wir verwenden CVS und die Kommentare werden verwendet, um die Person zu vermerken, die die Arbeit gemacht hat. Ein Portierungs-MAINTAINER ist jemand anderes: eine Person, die sich der Funktionalität der Portierungs verpflichtet fühlt und bereit ist, Zeit zu investieren, um diese so gut es geht bereitzustellen.

Index der Portierungsdokumentation

• Verfügbare Portierungsinformation
• OpenBSD-Portierungsrichtlinie
• Sicherheitsemfpehlungen
• Allgemeine Portierungshinweise
• Andere hilfreiche Hinweise

Verfügbare Portierungsinformation

• OpenBSD-Portierungs-Checkliste.
• OpenBSDs Updaterichtlinien für Portierungen.
• Die Handbuchseite bsd.port.mk(5). Sie dokumentiert das Makefile der Portierungs-Infrastruktur, das am Ende jeder individuellen Portierungs-Makefile eingeschlossen wird. Es gibt am Anfang noch ein paar Kommentare innerhalb der Datei selbst, aber die meisten der sinnvollen Informationen sind jetzt dokumentiert.
• Einige Unterschiede zu den anderen BSD-Portierungssystemen, hauptsächlich eine Zusammenfassung der Infrastruktur-Unterschiede.
• Das Benutzen von Shared Librarys in OpenBSD-Portierungen. Die Regeln sind sehr wichtig sobald du Shared Librarys benutzt.
• GNU-autoconf-Spezifikationen, wie man sie im Gebrauch mit OpenBSD-Portierungen handhabt.
• Konfigurationsdateien, ein häufiger Stolperstein für neue Entwickler und die einzigartigen Werkzeuge, die der OpenBSD-Portierungsbaum besitzt, um diese zu verarbeiten.
• Das Portieren von Audio-Applikationen auf OpenBSD.
• Die NetBSD Paketsystem-Dokumentation. Dieses Dokument beschreibt die NetBSD-Version des FreeBSD-Portierungssystems und ist recht hilfreich.
• Das FreeBSD Porter's Handbook. Das ist die FreeBSD-Portierungs-Bibel.
• Die OpenBSD-Portierungs-Mailingliste ports@openbsd.org.

OpenBSD-Portierungsrichtlinie

• OpenBSD benutzt NICHT /usr/local/etc/rc.d.
  /usr/local wird dank NFS oftmals von verschiedenen Maschinen benutzt. Aus diesem Grund können Konfigurationsdateien, die spezifisch für eine bestimmte Maschine sind, auch nicht in /usr/local abgelegt werden, /etc ist die zentrale Lagerstätte für individuelle Maschinen-Konfigurationsdateien. Außerdem ist es eine OpenBSD-Richtlinie, niemals Dateien unter /etc automatisch upzudaten. Portierungen, die ein bestimmtes Systemstart-Setup benötigen, sollten den Administrator anweisen, was zu tun ist, anstatt blind Dateien zu installieren.
• OpenBSD komprimiert KEINE Handbuchseiten.
• OpenBSD benötigt KEIN -lcrypt.
  DES ist Teil der Standard-libc.
• OpenBSD hat einen separaten Namensraum für User und Gruppen, die von Portierungen erzeugt werden. Siehe /usr/ports/infrastructure/db/user.list für genaue Details.
• OpenBSD is stark sicherheitsorientiert. Du solltest die Sicherheitssektion auf dieser Seite lesen und verstehen.
• Stelle sicher, dass der $OpenBSD$-CVS-Tag in das Makefile eingefügt wird. Wenn du eine Portierung von einem anderen System importierst, stelle sicher, dass du auch ihren Tag in dem Makefile belässt.
• Das Ziel ist, dass alle portierten Anwendungen OpenBSD unterstützen. Um dieses Ziel zu erreichen, musst du alle OpenBSD-Korrekturroutinen auch zurück an den ursprünglichen Programmierer zurückliefern.

Sicherheitsempfehlungen

• Benutze keinen Alpha- oder Beta-Code, wenn du eine Portierung vorbereitest. Benutze die letzte reguläre Version oder die zuletzt korrigierte.
• Jegliche Software, die auf einem Server installiert werden soll, sollte auf Pufferüberläufe (buffer overflows) untersucht werden, insbesondere unsichere Benutzung von strcat/strcpy/strcmp/sprintf. Im Allgemeinen sollte sprintf durch snprintf ersetzt werden.
• Benutze niemals Dateinamen statt echter Sicherheit. Es gibt zahlreiche Wettlaufsituationen, in denen du keine saubere Kontrolle mehr hast. Ein Angreifer, der bereits normale Benutzerrechte auf deiner Maschine hat, könnte Dateien in /tmp mit symbolischen Links auf strategischere Dateien setzen, wie etwa /etc/master.passwd.
• Zum Beispiel erzeugen sowohl fopen als auch freopen eine neue Datei oder öffnen eine bereits existierende zum Schreiben. Ein Angreifer könnte einen symbolischen Link von /etc/master.passwd auf /tmp/addrpool_dump setzen. Sofort wenn du ihn öffnest ist deine Passwortdatei verraten. Ja, sogar mit einem unlink direkt davor. Du kannst nur die Anzahl der Möglichkeiten verringern. Benutze stattdessen open mit O_CREAT|O_EXCL und fdopen.
• Ein weiteres sehr bekanntes Problem ist die mktemp-Funktion. Beachte die Warnungen des ,bsd linker's bei ihrer Benutzung. Die müssen gefixt werden. Das ist nicht ganz so einfach wie s/mktemp/mkstemp/g.
  Sieh dir mktemp(3) genauer an, um weitere Informationen zu erhalten. Korrekter Code, der mkstemp benutzt, schließt den Source zu ed oder mail ein. Eine seltenes Beispiel an Code, der mktemp korrekt benutzt, kann in der rsync-Portierung gefunden werden.
• Nur weil du etwas lesen kannst heißt es nicht, dass du das solltest. Eine sehr bekannte Lücke dieser Art war das startx-Problem. Als setuid-Programm konntest du startx mit jeder Datei als Skript starten. Wenn die Datei kein sauberes Shellskript war, folgte eine Fehlermeldung zusammen mit der ersten Zeile der betreffenden Datei, ohne weitere Überprüfung der Rechte. Ziemlich einfach die erste Zeile der shadow-passwd-Datei zu erhalten, besonders wenn man bedenkt, dass die erste Zeile meist den root-Eintrag enthält. Öffne nicht deine Datei, um dann ein fstat auf den ,open descriptor' zu machen, um zu überprüfen, ob du sie hättest öffnen können müssen (oder der Angreifer wird mit /dev/rst0 spielen und dein Band zurückspulen) - öffne es mit korrekt gesetzter uid/gid/grouplist.
• Tue nichts, was eine Shell im Hintergrund von setuid-Programmen forkt bevor du deine Rechte zurücksetzt. Das schließt popen und system ein. Benutze stattdessen fork, pipe und execve.
• Gebe ,open descriptors' anstatt von Dateiname an andere Programme weiter, um Wettlaufsituationen zu vermeiden. Sogar wenn ein Programm keine 'file descriptors' akzeptiert, kannst du immer noch /dev/fd/0 benutzen.
• Zugriffsrechte sind an ,file descriptors' gebunden. Wenn du setuid-Rechte setzen musst, um eine Datei zu öffnen, öffne die Datei, dann lass deine Rechte fallen. Du kannst nach wie vor auf den ,open descriptor' zugreifen, aber du musst dir um ihn weniger Sorgen machen. Das hat aber zwei Seiten: auch nachdem du die Rechte fallen lassen hast, solltest du noch auf die ,descriptors' aufpassen.
• Vermeide root-setuid wo du nur kannst. Grundsätzlich kann root alles tun, aber root-Rechte werden nur sehr selten wirklich benötigt, vielleicht mit Ausnahme vom Erzeugen von Sockets mit einer Nummer kleiner 1024. Es ist beutend besser, das inetd zu überlassen und nur die relevanten Einträge in inetd.conf zu machen. Du musst selbstverständlich die erforderliche Magie zum Schreiben von Daemons kennen, um das zu erreichen. Man könnte sagen, dass du keinerlei Chancen hast, ein gutes setuid-Programm zu schreiben, wenn du nicht weißt, wie man das macht.
• Benutze setgid anstelle von setuid. Abgesehen von diesen bestimmten Dateien, die von setgid-Programmen benötigt werden, sind die meisten Dateien nicht ,group-writable'. Daher werden Sicherheitsprobleme in einem setgid-Programm dein System nicht bedrohen: nur mit Gruppenrechten wird das schlimmste, was ein Angreifer anrichten kann, das Hacken einer Score-Tabelle in einem Spiel oder etwas ähnliches sein. Siehe auch die xkobo-Portierung für ein Beispiel einer solchen Änderung.
• Vertraue keinen ,group-writable' Dateien. Auch wenn sie geprüft wurden, werden setgid immer noch als wichtige potenzielle Sicherheitslöcher betrachtet. Von daher sollten Informationen, die hiervon berührt werden nicht als sensitive Information betrachtet werden.
• Vertraue nicht deiner Umgebung! Das schließt einfache Dinge wie etwa deinen PATH ein (benutze niemals system mit einem unqualifizierten Namen, vermeide execvp), es betrifft aber auch solche feinen Dinge wie locale, timezone, termcap, und so weiter. Sei vorsichtig mit ,transitivity': Auch wenn du alle Vorsichtsmaßregeln triffst, machen das Programme, die du aufrufst, noch lange nicht. Benutze niemals system in privilegierten Programmen, baue eine saubere Kommandozeile, eine kontrollierte Umgebung und rufe execve direkt auf. Die perlsec-Handbuchseite ist ein gutes Tutorium über solche Probleme.
• Benutze niemals setuid-Shellskripte. Sie sind vererbliche Sicherheitslücken. Schließe sie in C-Code ein, der eine saubere Umgebung sicherstellt. Auf der anderen Seite gibt es unter OpenBSD auch die sicheren Perl-Skripte.
• Nimm dich vor dem ,dynamic loader' in Acht. Wenn du ihn mit setuid laufen lässt, wird er nur vertrauenswürdigen Bibliotheken trauen, die mit ldconfig gescannt wurden. Setgid ist nicht genug.
• Dynamische Bibliotheken sind schwierig. C++-Code stellt ein ähnliches Problem dar. Grundsätzlich könnten Bibliotheken einige Dinge basierend auf deiner Umgebung tun, sogar bevor dein Hauptprogramm dazu kommt, seinen setuid-Status zu checken. OpenBSD-issetugid kümmert sich um dieses Problem vom Standpunkt eines-Bibliotheks-Autors aus. Versuche nicht Bibliotheken zu portieren, bis du diesen Punkt wirklich absolut verstanden hast.

Allgemeine Portierungshinweise

• __OpenBSD__ sollte sparsam benutzt werden, wenn überhaupt. Konstruktionen, die wie

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

  aussehen, sind oft unpassend. Füge nicht blindlings __OpenBSD__ hinzu. Versuche stattdessen herauszufinden, was vor sich geht und welche Funktionalität tatsächlich gebraucht wird. Handbuchseiten sind oftmals hilfreich, da sie historische Kommentare enthalten und darstellen, wann eine spezielle Funktionalität in OpenBSD eingefügt wurde. Den numerischen Wert von BSD gegen bekannte Versionen/Zahlen zu prüfen ist meistens der richtige Weg. Der NetBSD pkgsrc guide enthält noch weitere Informationen.
• BSD zu definieren ist eine schlechte Idee. Versuche sys/param.h einzubinden. Das definiert nicht nur BSD, sondern gibt auch einen sauberen Wert. Das richtige Codefragment sollte etwa so aussehen:

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

• Teste, ob Funktionalitäten vorhanden sind, und nicht nach bestimmten Betriebssystemen. Auf lange Sicht ist es besser zu erfahren, ob tcgetattr funktioniert, als zu erfahren, ob man gerade auf 4.3 BSD oder später oder etwa SystemVR4 arbeitet. Diese Art von Test trifft einfach nicht den Punkt. Ein sinnvoller Weg wäre zum Beispiel auf ein bestimmtes System zu testen, eine Runde von HAVE_TCGETATTR zu definieren und dann mit dem nächsten System weiterzumachen. Diese Technik trennt die Funktionalitätstests von denen auf spezielle Betriebssysteme. In großer Eile kann ein anderer Portierer das ganze Set an -DHAVE_XXX-Definitionen zum Makefile hinzufügen. Man könnte das auch selber schreiben oder im configure-Skript testen und es dann automatisch hinzufügen. Als negatives Beispiel, dem man _nicht_ folgen sollte, kann der nethack-3.2.2-Source dienen: er nimmt jede Menge Dinge basierend auf dem Systemtyp an. Die meisten dieser Annahmen sind veraltet und haben nichts mehr mit der Realität zu tun: POSIX sind nützlicher als alte BSD-versus-SystemV-Unterschiede, da einige traditionelle BSD-Funktionen jetzt nur noch durch Kompatibilitäts-Bibliotheken unterstützt werden.
• Vermeide include-Dateien, die andere includes enthalten, die wiederum andere ... Erstens weil es ineffizient ist. Dein Projekt wird mit einer Datei enden, die alles andere ,included'. Und außerdem werden dabei Probleme erzeugt, die schwierig zu beheben sind. Es wird schwieriger an einem bestimmten Punkt nicht eine bestimmte Datei mit einzubinden.
• Vermeide bizarre macro-Tricks. 'Undefining' eines Makros, das von einer Header-Datei definiert wurde, ist eine schlechte Idee. Das Definieren eines Makros, um ein spezielles Verhalten von einer include-Datei zu bekommen, ist auch eine schlechte Idee: Kompiliermodi sollten global sein. Wenn du POSIX-Verhalten willst, teile es mit, indem du #define POSIX_C_SOURCE im ganzen Projekt einsetzt, nicht nur wenn dir danach ist.
• Schreibe niemals ,system function prototypes'. Alle modernen Systeme, inklusive OpenBSD, haben einen Standardplatz für diese ,prototypes'. Wahrscheinliche Plätze sind etwa unistd.h, fcntl.h oder termios.h. Die Handbuchseite zeigt regelmäßig wo die ,prototypes' zu finden sind. Du könntest noch eine Runde HAVE_XXX-Makros benötigen, um die richtige Datei zu beschaffen. Mach dir keine Sorgen darum , dass du eine Datei zweimal 'includen' könntest, include Dateien haben Aufpasser, die solchen Unfug verhindern.
  Falls irgendein kaputtes System von dir verlangt, den ,prototype' zu schreiben, dehne das nicht gleich auf alle anderen Systeme aus. ,Roll-your-own prototypes' werden nicht funktionieren, da sie Typen benutzen könnten, die auf deinem System funktionieren, aber eben nicht auf andere Systeme portierbar sind; (unsigned long anstelle von size_t) benutzen, oder einen const-Status falsch verstehen. Außerdem sind einige Compiler, so wie auch OpenBSDs gcc, in der Lage, bessere Arbeit mit sehr oft verwendeten Funktionen wie strlen zu leisten, wenn man die richtigen header-Dateien einbindet.
• Untersuche das ,build log' sorgfältig auf Compiler-Warnungen.
  • implicit declaration of function foo() bedeutet, dass ein Funktionsprototyp nicht vorhanden ist. Das bedeutet, dass der Compiler annimmt, dass der Typ des Rückgabewert Integer ist. Gibt die Funktion eigentlich einen Pointer zurück, wird dieser auf 64-Bit-Systemen abgeschnitten, was üblicherweiße zu einem Segmentation-Fault führt.
• Benutze nicht den Namen einer Standard-Systemfunktion für irgendetwas anderes. Wenn du deine eigene Funktion schreiben willst, gib ihr einen eigenen Namen und rufe diese Funktion überall auf. Wenn du zur Standard-Systemfunktion zurückkehren willst, musst du nur deinen Code auskommentieren und den Namen wieder auf die Systemfunktion zurückschreiben. Mach es nicht andersherum. Der Code sollte etwa so aussehen:

         /* ,prototype'-Teil */
         #ifdef USE_OWN_GCVT
         char *foo_gcvt(double number, size_t ndigit, char *buf);
         #else
         /* die richtige Datei einbinden */
         #include <stdlib.h>
         /* use system function */
         #define foo_gcvt  gcvt
         #endif
  
         /* ,definition'-Teil */
         #ifdef USE_OWN_GCVT
         char *foo_gcvt(double number, size_t ndigit, char *buf)
            {
            /* proper definition */
            }
  
         /* typische Verwendung */
         s = foo_gcvt(n, 15, b);
         

Andere hilfreiche Hinweise

• Neuere Versionen von bsd.port.mk setzen den Installer-Pfad. Sie sorgen insbesondere dafür, dass /usr/bin und /bin vor /usr/local/bin und /usr/X11R6/bin durchsucht werden.
• Erzeuge KEINE Shared Librarys wenn ${NO_SHARED_LIBS} auf YES gesetzt ist (Vorsicht: es kann nur nach der Einbindung von bsd.port.mk definiert werden). Wenn deine Portierung ein GNU-configure benutzt, füge einfach die Zeile CONFIGURE_ARGS += ${CONFIGURE_SHARED} in das Makefile ein.
• Es ist in Ordnung eine erst neulich hinzugefügte Funktionalität von bsd.port.mk zwingend zu benötigen, da die Leute sowieso ihren Portierungsbaum mitsamt bsd.port.mk updaten sollten. NEED_VERSION ist von nun an hinfällig.
• Bevorzuge update-plist, um Paketlisten zu generieren und zu aktualisieren, anstatt diese Dinge per Hand zu erledigen. Du kannst die unerwünschten Zeilen auskommentieren. update-plist kann die meisten Dateitypen alleine erkennen und die meisten zusätzlichen ,annotations' korrekt kopieren.
• Füge USE_SYSTRACE=Yes in /etc/mk.conf ein, um fehlfunktionierende Skripte, Makefiles etc. zu entdecken.
• In OpenBSD sind curses.h/libcurses/libtermlib die ,neuen curses'. Ändere:
  ncurses.h ==> curses.h
  ,old (BSD) curses' ist durch das Definieren von _USE_OLD_CURSES_ verfügbar und zwar vor dem Einbinden von curses.h (für gewöhnlich in einem Makefile) und dem Linken mit -locurses.
• In OpenBSD wurden die Terminals von den alten BSD-sgtty zur neuen POSIX-tcgetattr-Familie umgestellt. Vermeide den alten Stil in neuem Code. Es kann Code geben, der tcgetattr als Synonym für das ältere sgtty definiert, aber das ist auf OpenBSD höchstens eine kurzfristige Methode. Der xterm-Quelltext ist ein sehr gutes Beispiel, wie man es nicht machen sollte. Versuche deine Systemfunktionalität richtig hinzubekommen: Du willst ja einen Typen, der den Status deines Terminals behält (möglicher typedef), du willst eine Funktion, die den momentanen Status herausfindet, und eine Funktion, die den neuen Status setzt. Funktionen, die diesen Status modifizieren sind schwieriger als es den Anschein hat, da sie dazu tendieren, von System zu System unterschiedlich zu sein. Vergiss auch nicht, dass du Fälle behandeln musst, bei denen du gar nicht an einem Terminal angeschlossen bist, und in denen du ,signals' behandeln musst: nicht nur das Beenden, sondern auch (SIGTSTP) im Hintergrund. Du solltest das Terminal immer in einem sauberen Zustand belassen. Mach die Tests unter einer alten Shell, wie etwa sh, die das Terminal nicht gleich in allen Fällen zurücksetzt, nachdem das Programm beendet wurde.
• Die neueren termcap/terminfo und curses, wie sie Teil von OpenBSD sind, beinhalten Standardsequenzen für das Kontrollieren von Farb-Terminals. Wenn möglich benutze diese, kehre auf anderen Systemen auf die ANSI-Farbsequenzen zurück. Trotzdem sind noch nicht alle Terminalbeschreibungen auf dem neuesten Stand, und du musst möglicherweise in der Lage sein, diese Sequenzen von Hand zu bearbeiten. So macht es vim. Das ist aber nicht unbedingt notwendig. Mit Ausnahme von privilegierten Programmen ist es generell möglich, eine termcap-Definition durch die TERMCAP-Variable zu übersteuern und sie dadurch zu sauberem Arbeiten zu bringen.
• Signal-Semantiken sind schwierig und von System zu System verschieden. Benutze sigaction, um spezifische Semantiken zu bekommen, zusammen mit anderen Systemaufrufen, die in der entsprechenden Handbuchseite aufgeführt werden.