L’implémentation de WireGuard dans le noyau FreeBSD est presque terminée

L’implémentation de WireGuard dans le noyau FreeBSD est presque terminée

L’implémentation de WireGuard dans le noyau FreeBSD est presque terminée

Le module et protocole VPN connaît un grand succès depuis sa première version, avec notamment des performances supérieures à la concurrence, une surface de code très réduite et des protocoles modernes pour la cryptographie.

Déjà intégré au noyau Linux, il était prévu depuis longtemps qu’il soit présent dans celui de FreeBSD. C’était même l’objet de la demande de Netgate (qui édite pfSense) au développeur Matt Maxy il y a plus d’un an. Un premier commit avait été poussé en février 2020 et le travail avait continué depuis.

Alors que l’on pensait la mission accomplie pour FreeBSD 13 – qui sera là dans deux semaines – une révision du code par Jason Donenfeld (auteur de WireGuard) et plusieurs développeurs FreeBSD et OpenBSD a montré une situation problématique.

L’avis de Donenfeld est particulièrement tranché sur la qualité du code, évoquant « des fonctions de validation renvoyant de vraies vulnérabilités cryptographiques catastrophiques, des pans entiers du protocole non implémentés, des kernel panics, des contournements de sécurité, […] les plus spectaculaires dépassements de mémoire tampon et la litanie complète des choses horribles qui peuvent aller mal quand les gens ne font pas attention à ce qu’ils écrivent en C ».

Le travail a donc été repris et Donenfeld pense désormais avoir une bonne base, en tout cas fonctionnant comme WireGuard est censé le faire. Mais il y a de très fortes chances que ce ne soit pas fini à temps pour FreeBSD 13. Les développeurs recommandent d’attendre la 13.1 pour que la qualité de l’implémentation augmente encore.

Commentaires (15)


ça va attendre un peu:




In the next day or so, I will be committing a removal of all WireGuard
related bits from our ‘main’ branch, including the work that I recently
committed. It will be followed up by a removal of the implementation
from stable/13, and we will seek appropriate approval to remove it
from releng/13.0 as well. Please, do not be concerned by any of this;
this is being done with mutual support from all parties.




https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057082.html


“es plus spectaculaires dépassements de mémoire tampon et la litanie complète des choses horribles qui peuvent aller mal quand les gens ne font pas attention à ce qu’ils écrivent en C “



Ah ouais, il y va franchement le gars :D


il a sorti la sulfateuse le gars…ouch


C’est le problème quand tu vois le code de personnes “développeurs” mais qui le sont pas vraiment pour plein de raisons (pas le temps de se former, formation à la va-vite, flemme, égo, …).



Etant donné le niveau de criticité du programme, même si les termes sont durs, je trouve ça juste.


Arcy

C’est le problème quand tu vois le code de personnes “développeurs” mais qui le sont pas vraiment pour plein de raisons (pas le temps de se former, formation à la va-vite, flemme, égo, …).



Etant donné le niveau de criticité du programme, même si les termes sont durs, je trouve ça juste.


Même moi je ne suis pas aussi dur qd un ‘admin VMware’ utilise les pools de ressource pour trier les VM ou TAG tous les ports de l’ESXi sur tous les VLAN parce que “c’est plus simple et rapide”. j’ai encore bcp à apprendre ^^


Question sans doute stupide, mais ça remet en question l’implementation dans le code pfsense aussi?


Je me pose la même question.



Mais au vu du lien de Oliverpool, tout se qui est actuellement dans la version 12.x de FreeBSD va être supprimé et tout sera revu pour la version 13.




In the next day or so, I will be committing a removal of all WireGuard
related bits from our ‘main’ branch, including the work that I recently
committed. It will be followed up by a removal of the implementation
from stable/13, and we will seek appropriate approval to remove it
from releng/13.0 as well. Please, do not be concerned by any of this;
this is being done with mutual support from all parties.




La version actuelle de PFSense (25) est basée sur la version 12 de FreeBSD…
Est ce que les développeurs de PFSense vont répercuter cette suppression ? Bonne question !
Quoi qu’il en soit au vu de se qui est dit sur la qualité du code de l’implémentation de Wireguard au sein de FreeBSD 12, utiliser Wireguard n’est peut être pas une si bonne idée !



Je comprend pas vraiment ta remarque ou / et les étapes qui ont menées aux propos de Donenfeld .
Théoriquement tout code avant d’arriver dans une version de FreeBSD doit être revu et testé non ?


Donenfeld c’est le Torvalds de FreeBSD ?? ;)


Non juste l’auteur de wiregard et il veut pas qu’on fasse de la merde avec 🙂


Donenfeld n’est ni plus ni moins que l’auteur de Wireguard, et n’est pas particulièrement affilié à FreeBSD. Et il me semble que, même s’il dit les choses assez crûment, ça n’a rien de commun avec les sorties de Torvalds car ici ce n’est que le code qui est critiqué, et non pas la personne.



Je ne veux pas trop me lancer dans de la psychologie de comptoir, mais sa présentation au SSTIC m’a plutôt donné l’impression d’un type tout doux et pas agressif pour un sou.


C’est inquiétant pour la qualité du code actuellement sur Linux. J’espère que les améliorations sont reportées pour Linux…


Si c’est dans le noyau Linux, ça a été revu et testé.


Bah non, puisque celui qui dit que l’implémentation dans FreeBSD c’est de la merde, c’est justement l’auteur original de WireGuard dans Linux.


C’est surtout que netgate a payé un dev qui a fait de la daube… et que l’implementation présente dans pfsense est dangereuse… le dev en question et netgate n’ont pas daigné répondre au créateur du projet, visiblement ils ont un ego surdimensionnés et des pratiques très douteuses :
https://opnsense.org/opnsense-com/



Opnsense a visiblement choisit l’iimplementation en « userland » qui fonctionne sans les failles de secu, en attendant la prise en charge dans le kernel bsd



(quote:1861391:M.Rhal)

bilbonsacquet a dit:


C’est surtout que netgate a payé un dev qui a fait de la daube… et que l’implementation présente dans pfsense est dangereuse… le dev en question et netgate n’ont pas daigné répondre au créateur du projet, visiblement ils ont un ego surdimensionnés et des pratiques très douteuses : https://opnsense.org/opnsense-com/



Opnsense a visiblement choisit l’iimplementation en « userland » qui fonctionne sans les failles de secu, en attendant la prise en charge dans le kernel bsd




Ouais, je pense que je vais plutot tester opensense que pfsense… J’ai des gros doute sur l’implementation qui est dans pfsense actuellement là.


Fermer