💾 Archived View for it.omarpolo.com › articoli › openbsd-evoluzione-printf.gmi captured on 2022-04-29 at 11:30:53. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

OpenBSD: il caso di %n

Una delle cose che apprezzo di più di OpenBSD (e di riflesso anche degli altri BSD, ma Open è il primo della classe in questo riguardo) è il “coraggio” di cambiare quando qualcosa non va bene, se non addirittura optare per la rimozione in toto.

Una delle novità introdotte di recente e che molto probabilmente sarà presente anche nella prossima release è la deprecazione del supporto per “%n” dalle funzioni stile printf in libc (printf(3), fprintf(3), …).

Si tratta di un modificatore che scrive sul relativo puntatore passato il numero di byte scritti fino a quel momento. Può non sembrare, ma ha delle “serie implicazioni di sicurezza” e pertanto da un po’ di tempo su OpenBSD è stato cambiato in modo che logghi su syslog(3) e chiami abort(3).

(Onestamente non ho idea di quali siano le possibili problematiche, l’unica cosa che mi viene in mente riguarda l’overflow di eventuali ‘int’, che può essere effettivamente grave, ma credo ci sia altro. Anche la manpage di printf(3) di glibc ha una nota nella sezione BUGS che ne sconsiglia l’utilizzo.)

Da quello che visto su ports@ la maggior parte degli usi di %n sembrano essere dovuti alla dimenticanza che printf ritorna il numero totale di byte scritti, e quindi c’è una valanga di diff tipo:

 	int n;
-	printf(“...%n”, ..., &n);
+	n = printf(“...”, ...);

anche se ci sono usi più “fantasiosi”.

L’ispirazione dietro questo post mi è stata data da un commento (sempre su ports@) di Theo:

For the greater community in the coming years, it is still better to write best-possible diffs which remove it in our tree, then hope that upstreams eventually understand, and even later after that, pray for the greater ecosystem to decide that %n can be removed. This will take two decades. But if we don't start with a "technology demonstration that %n is deletable", then we'll never get there.

e di come, anche se questo è un caso piuttosto piccolo, OpenBSD abbia aperto la strada a diverse innovazioni.

In the past OpenBSD pushed risky theoretical ideas into mainstream software practice by proving the ecosystem was ready to change. No OS wants to make a ABI jump until the case for change is proven. Stack protection, ASLR, and W^X principles are now in common use by mainline operating systems... because things like Firefox and Postgresql don't break anymore. OpenBSD built that route.

Dal commentario per la canzone di OpenBSD 5.5: “Wrap in Time”.

$BlogIt: openbsd-evoluzione-printf.gmi,v 1.1 2021/10/20 07:41:40 op Exp $