Sur linuxfr, je me serais attendu, justement, à ce que ce soit développé, ce serait justement l'un des points les plus importants, les raisons et la façon dont cela a été fait. Le pourquoi du comment et toute l'histoire.
BinarySEC est une société spécialisée en sécurité informatique. Elle a été fondée en 2007, initialement nous avions développé un outils de protection des binaires pour prévenir une bonne partie des types de buffer overflow existants. Cependant après quelques mois nous nous sommes aperçu que cela serait complexe à vendre et surtout à maintenir.
Aussi nous avions remarqué que les attaques les plus violentes et les plus répandues passent par HTTP et là malheureusement l'outil de détection de BOF ne servait pas à grand chose.
Alors j'ai décidé à l'époque de penser un nouveau système de protection des sites Internet. Il fallait quelque chose de simple donc en opposition totale avec mod_security etc... J'ai donc pensé un système de corrélation sous forme d'IA faible et cela a permis d'éliminer le risque de faux positifs à hauteur de 90%.
La première implémentation était un module Apache mais rapidement on nous a demandé une solution en proxy (reverse). À l'époque il n'y avait vraiment que nginx comme solution fiable au reverse proxy, exit squid, varnish et... Apache.
Nous avons donc implémenté l'interface serveur sur nginx et nous avons été très satisfait des performances de ce soft. Parallèlement nous auditions nginx et c'est à ce moment que nous nous sommes dit qu'il fallait vraiment revoir cela. Inutile de me demander des résultats précis, je vais juste vous dire que nous avons évité plusieurs buffer overflow en production de justesse et sincèrement pour un produit de sécurité ce n'était pas vraiment acceptable...
Parallèlement on nous a aussi demandé des solutions forward squid based où là encore nous avons eu quelques frayeurs.
Malheureusement à cette époque nodejs & v8 n'était pas encore stable/fiable pour pouvoir effectuer les opérations nécessaires aux applications reverse & forward proxy. Mais j'avais immédiatement détecté que ce serait le moyen le plus safe d'effectuer des opérations de proxy (ou de serveur) dans le futur. Voir même plus. Mais je ne détaillerais ici.
Il faut bien comprendre que tout cela est possible grâce à v8 qui correspond à une vraie révolution en matière d'informatique technique. Sans cela gatejs n'aurait pas d’intérêt... Pour la faire simpliste, v8 compile du JS en assembleur. nodejs en lui même est très simple et correspond pour ma part à un preloader, il est lui même codé à 70% en JS.
Bref, j'ai estimé que pour pouvoir augmenter la sécurité il fallait absolument réduire la verbosité d'un langage. Actuellement j'estime prendre bien moins de risque avec gatejs et je n'ai aucune limite à la réalisation de plugins.
Reste maintenant les risques de sécurité liés à la logique de design mais là encore c'est plus complexe avec le JS simplement parce que ce n'est pas(plus) un simple langage de scripting accessible à monsieur tout le monde, ce n'est pas PHP et il aura du mal à le remplacer du simple fait qu'il faut plus de compétences pour coder en JS. Un expert qui prend en main Javascript a ses sens en ébullitions :) À l'inverse un kiddy aura du mal.
Pour le choix de l'open source, c'est un peu complexe à détailler ici mais il remonte à bien longtemps et il a fallu convaincre des personnes. Je pense que c'est un gage de confiance et d'assurance dans mon secteur. Compliqué pour ma petite société de convaincre à passer sur des solutions closed sources inconnues. J'espere que cela fera évoluer les choses. Je crois vraiment au modèle économique open source. Je crois que c'est l'avenir. Le problème est qu'il n'y a pas d'école et que tout le monde joue un peu l'empirisme. C'est là mon dilemme.
Mais j'ai beau cherché dans le wiki ou dans le README, il n'y a pas de direction pour la façon de contribuer.
On utilise Github massivement, donc fork + pull request. On est pas très au point sur les détails à préciser. Si vous avez des conseils sur la forme je suis preneur !
Donc c'est libre (on a le droit de forké) mais ça reste fermé ?
Non non ! Nous sommes dans le cadre de la GPLv3 et les contributions doivent simplement prendre la voie du workflow de Github et très sincèrement j’espère qu'il y aura d'autres contributeurs
En me relisant, je me rends compte que c'est un peu aigri, mais je ne sais pas le tourner de manière différente, désolé. Je m'intéresse surtout aux raisons qui poussent une entreprise à rendre un projet libre :
Pour répondre de manière fermée je dirais : publicité sur le savoir-faire, rendu à la communauté et manque de personnel
Je pense donner quelques indices plus haut.
Je crois que tout projet open source doit, d'une manière ou d'une autre, avoir une équipe core qu'il rémunère pour assurer la continuité professionnel du projet. Certain utilise le don d'autre le service ou encore la licence duel.
Je crois beaucoup à la licence duel pour le cas de gatejs où un support pro serait proposé ou encore une garantie sur le fonctionnement (exclue de la GPL) mais aussi des développements spécifiques.
[^] # Re: Ouvert, libre et contribution
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 10.
BinarySEC est une société spécialisée en sécurité informatique. Elle a été fondée en 2007, initialement nous avions développé un outils de protection des binaires pour prévenir une bonne partie des types de buffer overflow existants. Cependant après quelques mois nous nous sommes aperçu que cela serait complexe à vendre et surtout à maintenir.
Aussi nous avions remarqué que les attaques les plus violentes et les plus répandues passent par HTTP et là malheureusement l'outil de détection de BOF ne servait pas à grand chose.
Alors j'ai décidé à l'époque de penser un nouveau système de protection des sites Internet. Il fallait quelque chose de simple donc en opposition totale avec mod_security etc... J'ai donc pensé un système de corrélation sous forme d'IA faible et cela a permis d'éliminer le risque de faux positifs à hauteur de 90%.
La première implémentation était un module Apache mais rapidement on nous a demandé une solution en proxy (reverse). À l'époque il n'y avait vraiment que nginx comme solution fiable au reverse proxy, exit squid, varnish et... Apache.
Nous avons donc implémenté l'interface serveur sur nginx et nous avons été très satisfait des performances de ce soft. Parallèlement nous auditions nginx et c'est à ce moment que nous nous sommes dit qu'il fallait vraiment revoir cela. Inutile de me demander des résultats précis, je vais juste vous dire que nous avons évité plusieurs buffer overflow en production de justesse et sincèrement pour un produit de sécurité ce n'était pas vraiment acceptable...
Parallèlement on nous a aussi demandé des solutions forward squid based où là encore nous avons eu quelques frayeurs.
Malheureusement à cette époque nodejs & v8 n'était pas encore stable/fiable pour pouvoir effectuer les opérations nécessaires aux applications reverse & forward proxy. Mais j'avais immédiatement détecté que ce serait le moyen le plus safe d'effectuer des opérations de proxy (ou de serveur) dans le futur. Voir même plus. Mais je ne détaillerais ici.
J'adore ce lien http://bellard.org/jslinux/
Il faut bien comprendre que tout cela est possible grâce à v8 qui correspond à une vraie révolution en matière d'informatique technique. Sans cela gatejs n'aurait pas d’intérêt... Pour la faire simpliste, v8 compile du JS en assembleur. nodejs en lui même est très simple et correspond pour ma part à un preloader, il est lui même codé à 70% en JS.
Bref, j'ai estimé que pour pouvoir augmenter la sécurité il fallait absolument réduire la verbosité d'un langage. Actuellement j'estime prendre bien moins de risque avec gatejs et je n'ai aucune limite à la réalisation de plugins.
Reste maintenant les risques de sécurité liés à la logique de design mais là encore c'est plus complexe avec le JS simplement parce que ce n'est pas(plus) un simple langage de scripting accessible à monsieur tout le monde, ce n'est pas PHP et il aura du mal à le remplacer du simple fait qu'il faut plus de compétences pour coder en JS. Un expert qui prend en main Javascript a ses sens en ébullitions :) À l'inverse un kiddy aura du mal.
Pour le choix de l'open source, c'est un peu complexe à détailler ici mais il remonte à bien longtemps et il a fallu convaincre des personnes. Je pense que c'est un gage de confiance et d'assurance dans mon secteur. Compliqué pour ma petite société de convaincre à passer sur des solutions closed sources inconnues. J'espere que cela fera évoluer les choses. Je crois vraiment au modèle économique open source. Je crois que c'est l'avenir. Le problème est qu'il n'y a pas d'école et que tout le monde joue un peu l'empirisme. C'est là mon dilemme.
On utilise Github massivement, donc fork + pull request. On est pas très au point sur les détails à préciser. Si vous avez des conseils sur la forme je suis preneur !
Non non ! Nous sommes dans le cadre de la GPLv3 et les contributions doivent simplement prendre la voie du workflow de Github et très sincèrement j’espère qu'il y aura d'autres contributeurs
Pour répondre de manière fermée je dirais : publicité sur le savoir-faire, rendu à la communauté et manque de personnel
Je pense donner quelques indices plus haut.
Je crois que tout projet open source doit, d'une manière ou d'une autre, avoir une équipe core qu'il rémunère pour assurer la continuité professionnel du projet. Certain utilise le don d'autre le service ou encore la licence duel.
Je crois beaucoup à la licence duel pour le cas de gatejs où un support pro serait proposé ou encore une garantie sur le fonctionnement (exclue de la GPL) mais aussi des développements spécifiques.