Costruire un port per OpenBSD

La cosa più importante da fare è comunicare. Chiedi alle persone su ports@openbsd.org se stanno lavorando sullo stesso port. Dillo all'autore del software originale, compresi i problemi che potresti incontrare. Se le informazioni sulla licenza non sembrano corrette, diglielo. Se hai dovuto fare i salti mortali per compilare il port, digli cosa può sistemare. Se stanno sviluppando solo per Linux e sembrano ignorare il resto del mondo Unix, cerca di cambiare il loro punto di vista.

La COMUNICAZIONE fa la differenza fra un port di successo e un port che verrà lentamente abbandonato da tutti.

Per prima cosa leggi le informazioni in questa pagina. Quindi dai un occhio ai documenti indicati, specialmente la checklist per il porting su OpenBSD.

Testa, poi ri-testa e infine testa ancora!

Sottometti il port. Crea un tarball gzippato della directory del port. Puoi metterlo su un server FTP o HTTP pubblico, spedendo il suo indirizzo a ports@openbsd.org o spedisci il port, codificato mime, allo stesso indirizzo. Scegli il metodo migliore per te.

Indice della Documentazione per il Porting

• Informazioni Disponibili sul Porting
• Policy per il Porting su OpenBSD
• Raccomandazioni di Sicurezza
• Dritte Generiche per il Porting
• Altre dritte Utili

Informazioni Disponibili sul Porting

• checklist per il porting su OpenBSD.
• La man page bsd.port.mk(5). Essa documenta il makefile dell'infrastruttura dei port incluso alla fine di ogni makefile dei port. Ci sono ancora alcuni commenti all'inizio del file stesso, ma le informazioni più utili sono ormai documentate.
• Alcune differenze rispetto ai sistemi di port degli altri BSD, per lo più un riassunto delle differenze nell'infrastruttura.
• Usare librerie condivise nei port di OpenBSD. Queste regole sono molto importanti non appena usi le librerie condivise.
• Particolarità di GNU autoconf, come gestirle nel contesto dei port di OpenBSD.
• I file di configurazione, spesso un grosso problema per i nuovi sviluppatori, e gli strumenti specifici che l'albero dei port di OpenBSD possiede per gestirli.
• Portare applicazioni audio su OpenBSD.
• La documentazione del sistema di package di NetBSD. Questo documento descrive la versione di NetBSD del sistema dei port di FreeBSD ed è molto utile.
• Il FreeBSD Porter's Handbook. Questa è la bibbia del porting su FreeBSD.
• La mailing list dei port su OpenBSD, ports@openbsd.org.

Policy per il Porting su OpenBSD

• OpenBSD non usa /usr/local/etc/rc.d.
  /usr/local è spesso condivisa fra più macchine tramite NFS. Per questo motivo i file di configurazione specifici di una macchina non possono essere contenuti in /usr/local, /etc è il deposito centrale per i file di configurazione della macchina. Inoltre, la politica di OpenBSD è di non aggiornare mai automaticamente i file in /etc. I port che hanno bisogno di specifiche impostazioni di boot dovrebbero avvertire l'amministratore di cosa fare anziché installare file alla cieca.
• OpenBSD NON comprime le man page.
• OpenBSD NON richiede -lcrypt.
  La crittografia DES fa parte della libc standard.
• OpenBSD ha un namespace distinto per utenti e gruppi creati dai port. Per ulteriori dettagli, vedi /usr/ports/infrastructure/db/user.list.
• OpenBSD è fortemente orientato alla sicurezza. Dovresti leggere e capire la sezione sulla sicurezza di questa pagina.
• Assicurati di aggiungere il tag CVS $OpenBSD$ al Makefile. Importando un port da un altro sistema assicurati di lasciare anche il loro tag nel Makefile.
• Lo scopo è che tutte le applicazioni portate supportino OpenBSD. Per raggiungere questo scopo devi mandare le patch per OpenBSD allo sviluppatore dell'applicazione.

Raccomandazioni di sicurezza

• Non usare codice alfa o beta nel preparare un port. Usa l'ultima release regolare o patchata.
• Qualunque software da installare come server dovrebbe essere esaminato alla ricerca di buffer overflow, specialmente l'uso insicuro di strcat/strcpy/strcmp/sprintf. In generale, sprintf dovrebbe essere sostituita con snprintf.
• Non usare mai i nomi di file al posto della vera sicurezza. Ci sono numerose race condition dove non hai pieno controllo. Per esempio, un attaccante che ha già privilegi di utente sulle tue macchine potrebbe sostituire i file in /tmp con link simbolici a file più strategici, come /etc/master.passwd.
• Per esempio, sia fopen che freopen creano un nuovo file o ne aprono uno esistente in scrittura. Un attaccante potrebbe creare un link simbolico da /etc/master.passwd a /tmp/addrpool_dump. Appena lo apri, il tuo file delle password viene modificato. Già, anche con un unlink subito prima. Restringi solo il campo delle possibilità. Usa piuttosto open con O_CREAT|O_EXCL e fdopen.
• Un altro problema molto comune è la funzione mktemp. Dai retta agli avvertimenti del linker bsd sul suo utilizzo. Devono essere corretti. Non è facile come code>s/mktemp/mkstemp/g.
  Fai riferimento alla man page mktemp(3) di OpenBSD current per maggiori informazioni. Codice che usa corretamente mkstemp comprende il sorgente di ed o mail. Un raro esempio di codice che usa corretamente mktemp può essere trovato nel port di rsync.
• Solo perché lo puoi leggere non significa che lo devi fare. Un famoso buco di questo tipo era il problema di startx. Come programma setuid, potevi lanciare startx con qualunque file come script. Se il file non era uno shell script valido, si otteneva un messaggio di errore, insieme alla prima riga del file in questione, senza ulteriori verifiche sui permessi. Molto utile per ottenere la prima riga del file shadow delle password, considerando che comincia spesso con la riga di root. Non aprire il file, e poi fai un fstat sul descrittore aperto per verificare se avresti dovuto essere in grado di aprirlo (altrimenti l'attaccante giocherà con /dev/rst0 e riavvolgerà il nastro) -- aprilo con le informazioni uid/gid/grouplist corrette.
• Non usare nulla che forki una shell in programmi setuid prima di abbassare i propri privilegi. Questo comprende popen e system. Usa invece fork, pipe e execve
• Passa i descrittori aperti agli altri programmi anziché i nomi di file per evitare race condition. Anche se un programma non accetta i descrittori di file, puoi sempre usare /dev/fd/0.
• I diritti di accesso sono legati ai descrittori di file. Se hai bisogno di diritti setuid per aprire un file, apri quel file, quindi abbassa i tuoi privilegi. Puoi sempre accedere al descrittore aperto, ma hai meno di cui preoccuparti. Anche dopo aver abbassato i tuoi privilegi, dovresti sempre stare attento a quei descrittori.
• Evita i programmi setuid root per quanto possibile. root può fare praticamente tutto, ma i diritti di root sono necessari molto di rado, tranne forse per creare socket su porte sotto la 1024. E' meglio comunque tenere quei processi sotto il controllo di inetd e aggingere le voci corrispondenti in inetd.conf. Devi conoscere la giusta magia per scrivere demoni corretti. Si può dire che non conviene scrivere programmi setuid se non si sa come si fa.
• Usa setgid anziché setuid. A parte i file specifici necessari ai programmi setgid, la maggior parte dei file non è scrivibile dal gruppo. Di conseguenza, un problema di sicurezza in un programma setgid non comprometterà il sistema: con i soli diritti di gruppo, il peggio che un intruso potrà fare è manomettere una tabella con i punteggi di un gioco o giù di lì. Vedi il port di xkobo per un cambiamento del genere.
• Non fidarti di file scrivibili dal gruppo. Anche se sono stati controllati, i programmi setgid non sono percepiti come potenziali buchi di sicurezza importanti. Quindi i dati che manipolano non dovrebbero essere considerati sensibili.
• Non fidarti dell'ambiente! Questo comprende cose semplici come il tuo PATH (non usare mai code>system con un percorso non assoluto, evita execvp), ma anche molto più sottili come le impostazioni local, il fuso orario, termcap, eccetera. Fai attenzione alla transitività: anche se prendi tutte le precauzioni, i programmi che chiami direttamente non lo faranno necessariamente.Non usare mai system in programmi privilegiati, costruisci la tua riga di comando, un ambiente controllato e chiama execve direttamente. La man page di perlsec è una buona guida per questi problemi.
• Non usare mai script shell setuid. Sono insicuri per definizione. Inseriscili all'interno di codice C che assicuri un ambiente corretto. D'altro canto, OpenBSD contiene script perl sicuri.
• Fai attenzione al dynamic loader. Eseguendo un setuid, occorre usare solo librerie fidate, analizzate con ldconfig. Setgid non basta.
• Le librerie dinamiche sono ostiche. Il C++ pone un problema analogo. In pratica, le librerie possono compiere determinate azioni in base al tuo ambiente prima ancora che il programma principale arrivi a verificare se è setuid. issetugid di OpenBSD affronta questo problema, dal punto di vista dell'autore di librerie. Non provare a portare librerie se non afferri fino in fondo questo problema.

Dritte generiche per il porting

• __OpenBSD__ dovrebbe essere usato di rado, se non mai. Costrutti ome

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

  sono spesso fuori luogo. Non aggiungere __OpenBSD__ alla cieca. Cerca invece di capire cosa sta succedendo, e quale funzionalità è effettivamente richiesta. La pagine di manuale sono spesso utili, dato che includono commenti storici, spiegando quando una certa funzionalità è stata inclusa in BSD. Verificare il valore numerico di BSD a seconda delle release è spesso il modo giusto. Vedi The NetBSD pkgsrc guide per maggiori informazioni.
• Definire BSD è una pessima idea. Cerca di includere sys/param.h. Non solo definisce BSD, ma gli dà anche un valore corretto. Il frammento di codice corretto sarebbe:

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

• Testa le funzionalità, non gli specifici sistemi operativi. Nel lungo periodo, è molto meglio verificare se tcgetattr funziona anziché se sei su BSD 4.3 o successivo, o SystemVR4. Questi tipi di test confondono solo il problema. Un modo di procedere può essere, ad esempio, fare prove su un sistema particolare, impostare un gruppo di define HAVE_TCGETATTR, quindi passare al sistema successivo. Questa tecnica permette di separare i test sulle funzionalità dai sistemi operativi. Nella fretta, un porter può aggiungere l'intero insieme di define -DHAVE_XXX al Makefile. Può anche aggiungere o scrivere in un file di configurazione di verificare quella funzionalità e aggiungerla automaticamente. Come esempio da non seguire, vedi il sorgente di nethack 3.2.2: ipotizza un mare di cose in base al tipo di sistema. La maggior parte di queste ipotesi sono obsolete e non riflettono più la realtà: le funzioni POSIX sono molto più utili delle vecchie differenze fra BSD e SystemV, tanto che ormai alcune funzioni BSD tradizionali sono supportate solo tramite le librerie di compatibilità.
• Evita di includere dei file che includono altri file che... Primo, perché è inefficente. Il tuo progetto finirà per includere un file che include tutto. Inoltre, perché rende difficile risolvere alcuni problemi. Diventa più difficile non includere un certo file a un dato momento.
• Evita strani giochetti con le macro. Annullare una macro definita in un header file è una pessima idea. Anche definire macro per ottenere un comportamento particolare da un file include è una pessima idea: le modalità di compilazione dovrebbero essere globali. Se vuoi un comportamento POSIX, dillo, e inserisci #define POSIX_C_SOURCE in tutto il progetto, non quando ti pare.
• Non scrivere mai prototipi di funzioni di sistema. Tutti i sistemi moderni, compreso OpenBSD, hanno un posto standard per questi prototipi. Posti tipici sono unistd.h, fcntl.h o termios.h. La man page indica spesso dove si trova il prototipo. Potresti aver bisogno di un altro gruppo di macro HAVE_XXX per procurarti il file giusto. Non preoccuparti di includere lo stesso file due volte, i file include hanno guardie che prevengono ogni tipo di stranezze.
  Se qualche sistema richiede la scrittura del prototipo, non importlo anche a tutti gli altri sistemi operativi. I prototipi fai-da-te falliranno perché possono usare tipi equivalenti sul tuo sistema, ma non portabili su altri (unsigned long al posto di size_t). Inoltre, alcuni compilatori, come il gcc di OpenBSD, fanno un lavoro migliore con alcune funzioni usatissime come strlen se si includono i file header corretti.
• Non usare il nome di una funzione standard per nient'altro. Se vuoi creare la tua funzione, dalle un nome proprio e chiamala ovunque. Se vuoi tornare alla funzione di sistema di default, devi solo commentare il tuo codice e definire il nome della tua funzione cole la funzione di sistema. Non fare il contrario. Il codice dovrebbe assomigliare a

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

Altre dritte utili

• Le versioni recenti di bsd.port.mk impostano il percorso degli installer. In particolare, impostano di cercare prima in /usr/bin e /bin che in /usr/local/bin e /usr/X11R6/bin.
• NON generare librerie condivise se ${NO_SHARED_LIBS} è impostato a yes (attenzione, può essere definito solo dopo l'inclusione di bsd.port.mk). Se il tuo port ha un configure GNU, aggiungi semplicemente la riga CONFIGURE_ARGS += ${CONFIGURE_SHARED} al Makefile.
• E' corretto fare affidamento su una funzionalità apparsa di recente in bsd.port.mk, dato che si suppone che chiunque aggiorni l'intero albero dei port, compreso bsd.port.mk. NEED_VERSION è ormai obsoleto.
• E' preferibile usare update-plist per generare e aggiornare le packing-list anziché fare le cose a mano. Puoi commentare le righe che non ti servono. update-plist può identificare la maggior parte dei tipi di file e copiare la maggior parte delle annotazioni extra correttamente.
• Aggiungi USE_SYSTRACE=Yes a /etc/mk.conf per individuare script, Makefiles, etc. non corretti.
• In OpenBSD curses.h/libcurses/libtermlib sono le ``new curses''. Modifica:
  ncurses.h ==> curses.h
  ``old (BSD) curses'' è disponibile definendo _USE_OLD_CURSES_ prima di includere curses.h (di solito in un Makefile) e linkando con -locurses.
• In OpenBSD, l'uso del terminale è passato dal vecchio sgtty BSD alla nuova famiglia POSIX tcgetattr. Evita il vecchio stile nel nuovo codice. Del codice può definire tcgetattr come sinonimo del vecchio sgtty, ma questo è al massimo una via di fuga su OpenBSD. Il codice sorgente di xterm è un ottimo esempio di cosa non fare. Cerca di rendere corrette le funzionalità del tuo sistema: vuoi un tipo che immagazzini lo stato del tuo terminale (possibile typedef), vuoi una funzione che ricavi lo stato corrente e una funzione che imposti il nuovo stato. Le funzioni che modifichino questo stato sono più difficili, dato che variano a seconda del sistema. Inoltre, ricorda che dovrai gestire casi in cui non sei connesso a un terminale e che devi gestire i segnali: non solo di termine, ma anche background (SIGTSTP). Dovresti sempre lasciare il terminale in uno stato corretto. Fai i test con una vecchia shell, come sh, che non resetta in alcun modo il terminale alla fine del programma.
• Le nuove termcap/terminfo e curses, incluse in OpenBSD, comprendono sequenze standard per controllare i colori dei terminali. Dovresti usare queste, se possibile, ripiegando alle sequenze di colore ANSI sugli altri sisitemi. Comunque, alcune descrizioni di terminali non sono ancora state aggiornate e potresti aver bisogno di specificare queste sequenze a mano. E' in questo modo che vim le gestisce. Questo non è strettamente necessario. Tranne per i programmi privilegiati, è generalmente possibile ridefinire una definizione di termcap per mezzo della variabile TERMCAP e farlo funzionare correttamente.
• La semantica dei segnali è complessa, e varia da sistema a sistema. Usa sigaction per essere sicuro di una specifica semantica insieme ad altre chiamate di sistema menzionate nella man page corrispondente.