djano a écrit 1147 commentaires

Je vois pas le rapport avec ce que je dis dans le commentaire ci-dessus.

La fusée Ariane V s'est plantée parce qu'il ont réutilisé du code dans un contexte différent sans vérifier qu'il pouvait supporter les nouveaux paramètres lies a la puissance supérieure d'Ariane V par rapport a celle d'Ariane IV (la fusée pour laquelle le code avait été originellement écrit).

Par contre c'est tout a fait approprie pour shellshock ou des gens (Apache, dhcpd, …) ont donne un accès très ouvert a bash, hors de sa conception d'origine.

Je vais prendre un en exemple la CVE-2007-1381 dans PHP, où un développeur voulant rendre le code plus « sécure » a remplacé une utilisation parfaitement valide de strncpy par un emploi erroné de strlcpy causant un trou béant de sécurité. Et parce que cette leçon n'est pas suffisante, php refait une erreur similaire 4 ans plus tard en remplaçant un strcat par un strlcat https://bugs.php.net/bug.php?id=55439
Vive les bonne pratiques, hein !

Bah si ç’avait été un programme qui avait automatiquement corrige le code pour le mettre a jour, ce n'aurait jamais été un problème.

Je ne suis pas d'accord avec la politique qui consiste a dire que l'on ne touche a rien parce que ça marche. C'est comme ça que l'on arrive a une base de code morte parce que personne ne veut mettre le nez dedans parce que c'est moche / buggue / etc.
C'est comme ça que l'on arrive a avoir du code legacy que l'on ne peut plus toucher parce que l'on ne sais pas ce que ça fait, ni comment ça le fait.
Le meilleur moyen d’éviter tout cela et de faire évoluer le code continuellement.

C'est pas tant l'expression que le contre sens historique: le logiciel libre existait, puis le proprio est arrive, puis le logiciel libre est re apparu (ou bien a renait de ses cendres).
En particulier, sur l'e-commerce, je pense qu'il n'y a eu que du proprio, puis le logiciel libre est arrive.
Donc, non vraiment pas "depuis toujours".

Bref, c'est juste totalement faux, et ça verse dans du journalisme sensationnaliste de *****.
Je n'ai pas envie de lire ce torchon merci bien.

J'avais surtout pas envie de le lire rien qu'en lisant ca:

Dans le monde «impitoyable» des technologies e-commerce, s’affrontent depuis toujours deux philosophies: celle des solutions technologiques reposant sur le modèle Open Source et celle des éditeurs de solutions propriétaires.

"depuis toujours", vraiment?
La déjà, l'auteur ne connaît clairement rien au sujet sur lequel il écrit.

A ce propos, je ne comprends toujours pas pourquoi la fondation mozilla suit son propre chemin, en réinventant un système sous technologies web qui existe déjà et pour lequel tous gagneraient à une fusion. Proposez-moi un smartphone alliant les mécaniques de LuneOS/WebOS, la communauté et les technologies de firefox, et l'aspect "libre", j'achète tout de suite !!!

Je ne vois pas quel interet aurait Mozilla a se rallier a webOS?
Sur FirefoxOS tout est en HTML + Javascript + CSS, apparemment sur webOS, c'est plutôt Qt et Webkit. Bref ce n'est pas en accord avec leur politique.

FirefoxOS a une dynamique ascendante avec des vrais partenaires qui distribuent leur OS alors qu'HP n'a jamais réussi a trouver quoi faire de webOS, n'a pas su créer une communauté autour et l'a libéré sur le mode du "je m'en débarrasse" pour finalement réussir a le revendre in-extremis a LG.

Autant ta question aurait peut être eu du sens en 2012, autant elle est hors de propos aujourd'hui.
webOS ça sent vraiment le roussi.

Ce n'est pas moi qui l'ai créée, promis :)

Je ne suis pas sur de l'origine.
Avant d'avoir la page wikipedia, je ne connaissais pas non plus.

Est ce cet effet?
http://blogs-images.forbes.com/alexknapp/files/2011/11/citogenesis.png

Pas vraiment.
On utilise souvent le terme "compiler" pour passer a un langage ayant un niveau d'abstraction bien inférieur (C -> ASM, OCaml -> code natif), alors qu'on utilise plus volontiers transpiler lorsque les niveaux d'abstraction du langage source et du langage cible sont équivalents (Python -> Javascript, Java -> Javascript). Ceci dit, on utiliser également le terme compiler la ou l'on utilise le terme transpiler, donc il n'y a pas de terme unique ou inapproprié.

En effet, excellente depeche !
Une telle densite est surprenante pour le passage d'une version 4.00 a une version 4.02.
C'est egalement un beau travail de vulgarisation scientifique :)

Merci de m'avoir fait decouvrir pfff ("Un ensemble d'outils pour réaliser de l'analyse de code dans de nombreux langages" dans la depeche). Le nom est quand meme pas terrible, mais ca a l'air surpuissant. Je suis content de voir que l'auteur de Coccinelle a rebondi sur l'idee et est alle beaucoup plus loin. Il fut un temps, j'avais regarde si quelque chose comme Coccinelle existait pour Java, mais ce projet m'etait passe sous le nez. Sympa de le retrouver :)

J'ai decouvert avec plaisir que tu contribuais a OCaml. Merci pour tes contributions !
Du coup je comprend beaucoup mieux ta connaissance theorique des langages de programmation ;)

Le bogue est peut être l'explication pour laquelle les micro noyaux n'ont pas percé ? ;)

Je comprends bien l'argument "c'est comme ça"

Je ne suis pas de ceux qui considèrent que le monde tel qu'il est est abouti ou que l'on ne peut rien y changer.
J'essaie de faire bouger les choses a ma manière.

C'est pour ça que je trouve ta vision intéressante: elle bouscule les idées en place et essaie d'amener vers autre chose.

J'ai cru comprendre que tu étais dans la recherche.

Je pense que la recherche en informatique devrait publier tous les codes sources ou jeux de données sous licences libres. Cela permettrait facilement de reproduire les expériences et résultats conformément a la méthode scientifique.
Actuellement, j'ai l'impression que certains papiers trichent en disant "voila ce que l'on obtient", alors qu'ils peuvent raconter n'importe quoi ou alors ils ont effectivement obtenus ces résultats mais en passant par d'autres moyens que ceux décrit dans l'article (par exemple, photoshop au lieu de l'application directe de l'algo) par manque de temps, etc.

J'en ai discute avec un chercheur et effectivement, cela soulèverait d'autres problèmes: cela prend du temps de rendre tout disponible, il faut l’héberger, ce n'est pas vraiment le boulot d'un chercheur, etc.

Qu'est ce que tu en penses?

Si je te suis bien, ce que les gens de la securite considerent comme "secure", ce seraient des architecture a micro-noyaux (comme patrick_g l'indique ci-dessous). N'est ce pas?

Maintenant, je blâme régulièrement les utilisateurs/clients (c'est a dire tout le monde, nous, moi) pour la qualité des productions de l'industrie informatique, mais cela s'applique aussi bien a la sécurité: les utilisateurs choisissent les logiciels sur leurs fonctionnalités puis le prix (le moins disant) avant les autres facteurs. Ils ne s’intéressent pas du tout aux facteurs tels que performance, qualité du produit ou sécurité lors de l'achat, mais lorsqu'il y a un problème, c'est un problème totalement inacceptable qui doit être résolu pour hier. Il ne semblent pas comprendre que leurs choix initiaux entraînent presqu'inévitablement le résultat final (bugs, performances horribles, failles béantes de sécurité).

Je ne dis pas que c'est facile.

Le succès de Linux s'explique par un processus de développement ouvert et une architecture modulaire ou l'on ne paye que pour ce que l'on utilise.
Le choix du langage C a attiré beaucoup de contributeurs car c'est un langage très répandu dans la programmation système. Ceci a permis a Linux de développer sa base de développeurs malgré les faiblesses criantes du langage. C'est un choix "social".
L'architecture modulaire a permis de limiter l'impact de fonctionnalités pour ceux qui ne les utilise, d’où la grande adaptabilité du noyau a des machines très différentes: super ordinateurs, PCs de bureau, smartphones, embarque, etc.
Le succès de Linux doit beaucoup a cette combinaison de facteurs.

 

Une architecture micro noyau rend le développement beaucoup plus difficile (algorithmes distribues, débogage infernal, etc.), et potentiellement désastreux pour les performances si l’implémentation n'est pas correcte. Certes la sécurité est accrue, mais dans notre monde actuel, la sécurité passe après les fonctionnalités, perfs, etc.

Utiliser des méthodes formelles rend le développement bien plus compliqué et limite la base des contributeurs. A nouveau cela réduit le succès des projets utilisant ce type de technologies.

 

La sécurité a un coût réel, et notre monde n'a jusque la pas considéré que le coût en valait la chandelle.
J’espère que cela changera aussi bien pour ton dada (la sécurité), que pour le mien (la qualité).

oui, mais s'il sont intéressés par Capsicum c'est que seccomp-bpf ne répond pas totalement a leurs besoins.
Je n'ai pas compris s'ils veulent remplacer l'un par l'autre ou s'ils veulent profiter de sécurités accrues.

Je parlais du souci des perfs, pas de la sécurité intrinsèque.

Oui enfin il ne faut pas se leurrer, toute méthode de sécurité comme Capsicum ou LXC/Docker qui repose sur le noyau Linux est dans la catégorie "pas secure" pour les gens sérieux, puisque la surface d'attaque est l'ensemble du noyau—c'est énorme.

Je ne suis pas sur de comprendre ce que tu veux dire: Je comprend que LXC puisse ne être considéré comme pas secure. Effectivement un programme a accès a l’intégralité du noyau. Par contre je ne comprend pas ce qui pourrait être considéré comme secure. A quels systèmes penses-tu?

Capsicum me semble tout de même un bon moyen de limiter la portée des attaques sur des processus ayant les moindres privilèges. Tout ceci est module bug dans l’implémentation bien entendu, mais c'est le cas de toutes les solutions de sécurité. De toute façon si l’implémentation est foireuse peu de choses peuvent te sauver a moins d’empiler les techniques de sécurité mais alors la bonjour le surcoût de maintenance.

Bref, peux tu étayer ton propos? J'aimerai bien comprendre ce que tu veux dire.

Pas de souci: la compartementalisation arrive a la rescousse ! ;)

Cette approche a rarement perce au niveau applicatif.

Je l'ai vu sur des terminaux types citrix ou tu accèdes a une seule application qui ne communique avec rien sur ta machine.

L'autre approche est de séparer tout ce qui est personnel de tout ce qui est pro dans les smartphones (Samsung Knox) en utilisant 2 VM séparées pour effectivement cloisonner les 2 activités et éviter que le perso n'impacte le pro.

Oui enfin Linus, par défaut il dit non et puis après il discute..
Vu le nombre de fonctionnalités qu'on doit lui demander d'introduire dans Linux, ça me parait d'ailleurs une stratégie tout à fait raisonnable!

Tu as sans doute raison. C'est plutôt sain comme fonctionnement pour trier les gens sérieux et déterminés des gens pas sérieux.
Ça dit aussi: "quel est le cas d'utilisation?"

Je me rappelle que l'épisode Capsicum arrivait immédiatement après celui des innombrables intégrations de modules de sécurité. Linus avait vu rouge a cette occasion et avait tapé du poing sur la table ce qui avait amené a la création du framework LSM pour mutualiser les hooks de sécurité.

Je me souviens de ta premières dépêches sur le sujet et j'avais été très enthousiasmé par cette approche: très simple a utiliser par les programmeurs, ce qui pouvait vraiment aider a diffuser son utilisation et une amélioration globale de la sécurité sur nos OS.

Cependant je me rappelle que Linus avait jeté le bébé avec l'eau du bain en disant qu'il y avait suffisamment de modules de sécurité et qu'il ne voulait pas en intégrer un nouveau. C’était donc une fin de non recevoir absolument indépendante des qualités de la solution qui ne laissait entrevoir aucune possibilité d’intégration dans Linux.
J'avais été très déçu par cette fin en queue de poisson, a la hauteur de l'excitation et des espoirs qu'avait provoque cette technologie.

D’où ma question: Qu'est-ce qui ferait que le résultat sera différent cette fois-ci ?
Pourquoi Linus accepterait-il d’intégrer Capsicum maintenant ?

Je connais OpenAM, Central Authentication Service, FreeIPA…

Par contre je ne les utilise pas alors je me garderai bien de les comparer :)

+1 Les serveurs LDAP font de la réplication multi-maîtres, alors certaines de ces recettes ne leur sont pas applicables.
Je pense que la seule qui reste valable est celle sur la répartition de charge.

A noter que ce n'est pas une bonne idée de faire du round-robin sur des serveurs multi-maîtres en répétant la suite d’opérations Add-Modify-Delete sur une entrée avec le même nom. Cela ne va pas bien se passer. Oui, oui, c'est du vécu avec des clients.

pour d'autres de plateformes ou d'affichage.

Manque-t-il un mot?
Allez je me lance: "pour d'autres types"?

UI

=> inteface utilisateur

En conséquence, une meilleure utilisabilité et un meilleur affichage sur les écrans avec des pixels très petits comme les écrans Retina.

Cette phrase manque cruellement d'un verbe.

Tout a fait, mais ça ne rend pas moins valide ce que j'ai dit.

Pareil ici.

Ou est le rapport avec les logiciels libres?
OK pour la liberté (quoique la liberté avec un logiciel fermé, …), mais qu'en est-il de la licence?