WireGuard in arrivo su FreeBSD con una coda di polemiche
FreeBSD sta per ricevere il proprio modulo WireGuard nel kernel, grazie al contributo di Netgate, coadiuvato da Jason Donenfeld, principale progettista di Wireguard, e da diversi sviluppatori di FreeBSD e OpenBSD. Ad annunciarlo è stato lo stesso Donenfeld attraverso una mailing list ufficiale. L’arrivo di WireGuard è così importante? Cerchiamo di riepilogarne i vantaggi.
Per chi non fosse informato WireGuard è un protocollo recentemente introdotto anche nel kernel Linux che consente di creare una VPN (Virtual Private Network). Stabilisce connessioni più rapidamente rispetto alle VPN tradizionali come OpenVPN ed è anche più affidabile, soprattutto quando si gestiscono un elevato numero di connessioni. L’affidabilità è molto importante per evitare di dover spendere molto tempo a monitorare l’infrastruttura (in ambito aziendale s’intende) e a ripristinare tunnel OpenVPN.
Oltre alle prestazioni e all’affidabilità, WireGuard offre protocolli moderni, la difficoltà di configurazione è bassa, il codice sorgente è più pulito e leggero. Linus Torvalds l’ha dichiarata “un’opera d’arte” rispetto a OpenVPN e IPSec.
WireGuard in arrivo su FreeBSD
L’inclusione di WireGuardnel kernel di FreeBSD è stata a lungo nella roadmap. Nel febbraio 2020, lo sviluppatore di FreeBSD Matt Macy ha effettuato il primissimo commit relativo a WireGuard su FreeBSD. Il lavoro di Macy è stato commissionato direttamente da Netgate, la società dietro pfSense, la distribuzione BSD-based sviluppata per i router. Netgate non si è curata di contattare Donenfeld ponendo le basi per un port pieno di problemi. Dopo quasi un anno di lavoro, il port di Macy è stato integrato nel kernel e schedulato per FreeBSD 13.0, che dovrebbe essere lanciato tra 15 giorni.
Non benissimo…
Sfortunatamente, nei giorni scorsi Jason Donenfeld ha messo mano al lavoro di Macy insieme a diversi sviluppatori di FreeBSD e OpenBSD, giudicandolo non pronto (per usare un eufemismo).
Sono state aggiunte sleep casuali per “correggere” le condizioni di corsa, funzioni di validazione che semplicemente ritornavano true, vulnerabilità catastrofiche, intere parti del protocollo non implementate, kernel panic, bypass di sicurezza, buffer overflow, istruzioni printf casuali nel codice e tutta una serie di cose orribili che riscontriamo quando le persone non stanno attente a cosa scrivono in C.
queste le sue parole.
Come fare per non ritardare il rilascio? Si sono messi a sistemare il codice in tutta fretta perché Netgate, nel frattempo, aveva già annunciato l’arrivo di WireGuard in pfSense 2.5. Chiaramente la mole di lavoro ha reso impossibile l’impresa ma l’atterraggio sul pianeta BSD è stato semplicemente rimandato alla release 13.1.
Questa collaborazione chiaramente non è stata portata avanti nel modo corretto dall’azienda. Donenfeld ha espresso una certa frustrazione per l’incapacità di Netgate di contattarlo direttamente e, una volta scoperto il lavoro in corso d’opera, una percepita mancanza di interesse a lavorare insieme a lui.
Non si sono preoccupati di contattarci. Va bene, ho pensato, mi metterò in contatto io e vedrò se posso aiutare. Sono seguite una serie di comunicazioni scadenti: messaggi senza risposta, revisioni del codice ignorate, quel genere di cose.
Tipico conflitto di interessi riguardante i progetti open source. Il battibecco, poi, è continuato con accuse e polemiche, che ritengo poco utile riportare: per chi fosse interessato qui trovate il thread.
Seguiteci sul nostro canale Telegram, sulla nostra pagina Facebook e su Google News. Nel campo qui sotto è possibile commentare e creare spunti di discussione inerenti le tematiche trattate sul blog.