Journal OpenSSL est mort, vive (le futur) LibreSSL

Posté par (page perso) .
70
22
avr.
2014

Salut les jeunes,

Vous n'êtes pas sans savoir qu'OpenSSL, la librairie plus ou moins standard implémentant les protocoles SSL/TLS, a récemment fait beaucoup parler d'elle pour un bug extrêmement grave. La librairie n'en était pas à son premier coup, elle a déjà fait parler d'elle à plusieurs reprises par le passé par sa piètre qualité (j'ai pas vu moi-même, je ne fais que rapporter ce que j'entends sur la toile).

Et bien les gens de chez OpenBSD en ont eu marre, ont décidé de forker OpenSSL et de nettoyer la librairie de fond en comble pour repartir sur une base saine. Ils ont commité comme des petits fous (on parle de 250 commits à 8), et sont arrivés à un résultat assez intéressant: en virant tout les machins spécifiques à VMS et Windows, ils ont viré la moitié du bloat qu'il y avait, et toutes les applis dans l'arbre OpenBSD continuent de compiler. Pas mal.

Pour suivre les changements, un amateur a monté un tumblr, OpenSSL Valhalla Rampage qui met l'accent sur les messages de commits. On sent la rage des développeurs envers le code plus que médiocre. Dire que tout le monde dépend de ça. Vous pouvez aussi suivre ça au format twitter (ou aller à la source pour voir tous les changements)

Enfin, il y a un site tout joli pour s'informer sur la Fondation. Je vous rappelle qu'OpenBSD a besoin d'argent (comme tout le monde, vous me direz), et je pense que cette page peut aider. Je vous conseille d'aller jeter un coup d'oeil à la page Campagne de financement pour vous rendre compte à quel point tout le monde dépend de ces gens là.

Ah, et surtout, on apprend que le fork devrait s'appeler LibreSSL. Tout ça me rappelle drôlement quelque chose

Note: Ce contenu placé sous CC0

  • # GNU TLS

    Posté par (page perso) . Évalué à 10.

    Il y a aussi l'alternative GNU TLS qui existe depuis des années. Si une personne ici connaît les plus et les moins des deux bibliothèques ?

    • [^] # Re: GNU TLS

      Posté par (page perso) . Évalué à 6.

      J'ai envie de dire qu'il y a aussi polarssl

      Je me considère comme un artiste vu que mes programmes sont des oeuvres d'art :-P

      • [^] # Re: GNU TLS

        Posté par (page perso) . Évalué à 10.

        Enfin tout ça c'est sous licence GPL. Pas tout le monde accepte ce genre de licence (et en particularité OpenBSD).

        Après il est sûr qu'avoir plusieurs alternatives est une bonne chose.

        • [^] # Re: GNU TLS

          Posté par (page perso) . Évalué à 5.

          LGPL pour GnuTLS non ?

          • [^] # Re: GNU TLS

            Posté par . Évalué à 8.

            Il faisait sans doutes référence à PolarSLL qui est sous double licence GPL+propriétaire.
            La licence propriétaire est… comment dire… un poil chère ?
            99€ par mois ou la modique somme 2750€ en une fois. Quand on sait qu'OpenSSL a reçu l'an dernier environ 2000$ de dons…

            GnuTLS, lui, est bien sous LGPLv2.1+.

      • [^] # Re: GNU TLS

        Posté par (page perso) . Évalué à 10. Dernière modification le 22/04/14 à 13:03.

        PolarSSL est trés propre, l'API est bien défini et la documentation pas mauvaise.

        Le gros problème de Polar c'est le système de double licence à la legacy Qt ( Commercial & GPL ).

        Je développe actuellement une lib open source sous LGPL2+ utilisant naturellement TLS/SSL , et PolarSSL est directement exclue comme dépendance car incompatible….

      • [^] # Re: GNU TLS

        Posté par . Évalué à 5.

        Pas sur que tout le monde apprécie cmake ou les MAKEFILEs handmade

    • [^] # Et NSS ?

      Posté par . Évalué à 7.

      Et que vaut également NSS ?

      A priori, c'est l'une des bibliothèque les plus utilisées (au moins coté client) vu que 2 des 3 plus importants navigateurs l'embarque (Chrome et firefox), et les licenses proposées sont assez permissives (MPL, GPL et LGPL). Il y a également une couche de compatibilité avec openSSL pour les décideursdéveloppeurs pressés et une très bonne liste de plateformes supportées.

      PS : Lien intéressant trouvé après écriture du commentaire.

  • # libressl.org

    Posté par (page perso) . Évalué à 9. Dernière modification le 22/04/14 à 07:38.

    Site web http://www.libressl.org/

    Et une petite perle :
    “theo found a file we don’t seem to need, but just in case, i will paste the contents below:
    !/usr/local/bin/perl
    x86 assember”

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: libressl.org

      Posté par . Évalué à 9.

      «  I dunno. It's hard to tell if this file is necessary because its name is so long and descriptive that I fall asleep before reaching the end of it.

      crypto/bn/asm/x86/f: remember, the f stands for 'fail'. »—Nix

    • [^] # Re: libressl.org

      Posté par (page perso) . Évalué à 2. Dernière modification le 23/04/14 à 06:40.

      Rho purée <blink> quoi.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: libressl.org

        Posté par (page perso) . Évalué à 5.

        Tu as loupé le

        This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags

        en bas de page :-)

        • [^] # Re: libressl.org

          Posté par . Évalué à 1. Dernière modification le 25/04/14 à 17:35.

          OMG! Ils sont quand même bien barrés :D

  • # et ca compile ?

    Posté par . Évalué à 6.

    en virant tout les machins spécifiques à VMS et Windows, ils ont viré la moitié du bloat qu'il y avait, et toutes les applis dans l'arbre OpenBSD continuent de compiler. Pas mal.

    et ca continue de compiler pour VMS et Windows ?
    ;)

    • [^] # Re: et ca compile ?

      Posté par (page perso) . Évalué à 10.

      There’s tons of work that needs to be done first

      That said, they clearly don’t plan on supporting VMS, Windows, OS 9, etc. All of that compatibility adds tons of complexity. Traditionally portable OpenBSD projects, like OpenSSH, OpenNTPD, OpenBGPD, OpenSMTPD are implemented exclusively for OpenBSD first, and then ported.

      If this gets ported, there will probably be a compatibility layer written in that provides missing functions (strlcat(3) and strlcpy(3) on Linux) that gets linked in.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: et ca compile ?

        Posté par (page perso) . Évalué à 10.

        Quoi, ce groupe mené par un leader "éclairé" écrit encore du code propre à une platforme pour laisser les autres dans la panade en forçant l'usage d'API qui sont en dehors de la norme POSIX et d'UNIX, c'est quoi ce bordel, combien de temps est ce qu'on va tolérer les débordements de sys…. Ah, on me signale dans l'oreillette que c'est pas Lennart, donc c'est parfaitement acceptable de faire ça, pardon pour l'intervention.

        ( pour clarifier, je ne critique pas le fait que openbsd le fasse, c'est leur droit, mais je note juste le double standard à ce sujet, et en fait, juste pour lancer le débat qu'autre chose )

        • [^] # Re: et ca compile ?

          Posté par . Évalué à 7.

          La différence majeur c'est que du coté d'OpenBSD, une équipe sera mise en place pour développer les couches de compatibilité.

          • [^] # Re: et ca compile ?

            Posté par . Évalué à 4.

            Mise en place par des personnes externes (en gros, les distributions).
            Ah ben en fait c'est pareil.

            • [^] # Re: et ca compile ?

              Posté par . Évalué à 4.

              Je ne m'y retrouve plus dans tout ce troll systemd accepte les commits ayant pour objectif la portabilité ou c'est « vous avez le droit de forker » ?

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: et ca compile ?

                Posté par (page perso) . Évalué à 7.

                C'est « vous avez le droit de forker », comme pour OpenSSH où il y a un dépôt hébergé à part pour la version portable.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: et ca compile ?

                  Posté par (page perso) . Évalué à 7.

                  À la différence que "vous avez le droit de forker" est faciliter par l'usage de git de base. Et pas du bla bla sur "si on laisse les gens forker, plus personne ne va tourner sur la version HEAD donc on va garder CVS" comme le dit Theo.

            • [^] # Re: et ca compile ?

              Posté par . Évalué à 9.

              Non. Absolument pas.

              La couche portable de OpenSSH est maintenu par les développeurs d’OpenSSH. Le code et le site web de la version portable sont sur le site d’OpenSSH.

              Mais merci quand même pour cette désinformation, et ce fanboyisme là où ça n’a rien à y faire.

              • [^] # Re: et ca compile ?

                Posté par (page perso) . Évalué à -1.

                Le code et le site web de la version portable sont sur le site d’OpenSSH.

                Non, le site d'OpenSSH, c'est openssh.org, le code de la version portable est sur www.mindrot.org

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: et ca compile ?

                Posté par (page perso) . Évalué à -10. Dernière modification le 22/04/14 à 18:13.

                Je cherche, point de "Windows" sur la page, point de "Visual C++" sur la page. De souvenir, ça ne compile pas sous Visual C++ (du moins directement) ou autre compilo Windows. Il y a Cygwin, mais c'est un méchant hack pour contourner les développeurs n'ayant rien à faire de la portabilité.

                De l'autre côté, le source officiel de OpenSSL dit :
                Visual C++
                Borland C
                GNU C (Cygwin or MinGW)
                Et même un lien pour les binaires.

                Donc j'attend avec impatience que tu me dises la marche à suivre pour compiler OpenSSH sous un compilo sous Windows sans passer par une triche genre Cygwin (Cygwin fait le boulot de portabilité, pas OpenSSH).
                Ah oui, "portable" qui ne prend pas en compte Windows mais juste des Linux/Unix (POSIX compliant sinon tu te démerde, c'est ce qu'on te dis, super la portabilité), c'est un peu se foutre du monde… C'est un choix, certes, mais qu'on vienne pas me parler de volonté d'être portable. J'arrive à utiliser SSH (client) sous Windows, mais il faut quand même pas mal batailler (notament sur Unicode pas bien pris en compte sous Windows), ce n'est pas grace aux développeurs d'OpenSSH mais a d'autres personnes.

                Saloperie de réalité sur la portablité et l'interêt que des gens y trouvent.
                En attendant, je préfère la mentalité OpenSSL, plus ouverte sur les gens.

                • [^] # Re: et ca compile ?

                  Posté par (page perso) . Évalué à 10.

                  En attendant, je préfère la mentalité OpenSSL, plus ouverte sur les gens.

                  Elle est surtout très ouverte sur les exploits…

                • [^] # Re: et ca compile ?

                  Posté par . Évalué à 7.

                  Tu confond pas un peu portable et porté ?

                  OMG OpenSSL est pas dispo pour RTOS, quelle bande de raclures de bidets pas portables !

                • [^] # Re: et ca compile ?

                  Posté par (page perso) . Évalué à 10.

                  Donc j'attend avec impatience que tu me dises la marche à suivre pour compiler OpenSSH sous un compilo sous Windows sans passer par une triche genre Cygwin

                  Il suffit de porter OpenSSH sous Windows.

                  Ah oui, "portable" qui ne prend pas en compte Windows mais juste des Linux/Unix (POSIX compliant sinon tu te démerde, c'est ce qu'on te dis, super la portabilité

                  Portable ne veut pas dire universel. Portable ne veut pas dire porté. Portable veut dire qui peut être porté.

                  Cygwin fait le boulot de portabilité, pas OpenSSH

                  Utiliser un bibliothèque pour simplifier le job c'est vraiment trop con

                  • [^] # Re: et ca compile ?

                    Posté par (page perso) . Évalué à 2.

                    Portable ne veut pas dire universel. Portable ne veut pas dire porté. Portable veut dire qui peut être porté.

                    C'est un peu bizarre comme definition, ça veut dire que tous les logiciels sont portables sur tout, ça ne sert pas à grand chose

                    • [^] # Re: et ca compile ?

                      Posté par . Évalué à 10.

                      Non mais regarde par exemple le noyau linux à l'époque des 2.x (x ≤ 4): le portage avait plus ou moins nécessité une réécriture complète de certaines portions du noyau pour chaque nouvelle architecture visée. Alors qu'à partir du noyau 2.6, comme un gros effort de nettoyage de code, de factorisation, etc., avait été apporté, le plus gros avantage avait finalement été (au moins au début) la meilleure portabilité du code, ce qui permettait de modifier le noyau en un endroit et de ne devoir dupliquer certaines modifications que bien plus rarement.

                      Autre exemple : le code de NetBSD (et en fait, OpenBSD itou de ce que j'ai pu voir) est considéré comme extrêmement portable, car même les drivers sont écrit en C ISO (+POSIX je suppose), avec une quantité de code assembleur extrêmement limité, ceci grâce à l'utilisation de wrappers (fonctions d'adaptations) « légers » qui parlent le « langage » de l'OS (bref, qui pigent ses API), et qui évitent voir interdisent l'utilisation de code ASM directement.

                      Imaginons un code de ce genre :

                      /* Ce code est sans doute mal synchronisé; je l'utilise juste pour l'exemple. */
                      extern volatile int g_lock;
                      
                      /* Tentative de prise de verrou */
                      #if defined(HAS_COMPARE_AND_SWAP)
                      while (compare_and_swap(g_lock,0,1) != 1)
                          ; // do nothing: busy waiting -- bad programmer, no cookie !
                      #elif defined(HAS_TEST_AND_SET)
                      while (test_and_set(g_lock) == 1)
                          ; // do nothing: busy waiting -- bad programmer, no cookie !
                      #endif
                      
                      /* plus loin dans le code ... */
                      
                      /* Libération du verrou */
                      #if defined(HAS_COMPARE_AND_SWAP) || defined(HAS_TEST_AND_SET)
                      g_lock = 0;
                      #endif

                      Il est évident que ce truc n'est pas portable. Le code de verrouillage/déverrouillage devrait être encapsulé dans des fonctions spécifiques (par exemple, mutex_lock() et mutex_unlock()1), et encore mieux, il faudrait « fabriquer » un compare_and_swap à partir d'un test_and_set si C&S n'existe pas sur l'archi cible, comme ça le code ne pourrait jamais casser, même si en pratique il risquerait de perdre en perf (car du coup pour fabriquer un C&S à partir d'un T&S, tu dois utiliser une variable tierce pour modifier le mot, faire le test, et renvoyer l'ancienne version).

                      Note que mon exemple est complètement artificiel, vu que gcc et ses potes (au moins llvm et icc, mais sans doute les autres compilos aussi) ont déjà des intrinsics pour générer le bon code. Cela dit, l'OS devrait enrober ces opérations malgré tout pour assurer la portabilité du code au-delà de l'usage d'un compilateur en particulier.


                      1. Et je ne parle même pas de l'utilisation d'une variable globale… 

                • [^] # Re: et ca compile ?

                  Posté par (page perso) . Évalué à 10. Dernière modification le 22/04/14 à 21:49.

                  Mais bien sur Zenichou! Les vilains extrémistes qui ne supportent pas Windows.
                  Ou peut-être qu'ils supportent ce qui supporte POSIX proprement: ce qui veut dire un peu prés tous les OS sauf Windows ?

                  Car c'est pas comme si le pool allocator ( responsable du bug heartbleed ) avait été implémenté juste pour Windows qui a une version préhistorique de malloc, mais si en fait.

                  C'est c'est pas comme si tout le système de structures BIO_* d'OpenSSL moches, buggé et lourdingue étaient là juste pour avoir une IO abstraction layer pour les plateformes non-POSIX : mais si en fait !

                  C'est pas comme si la gestion des connexion asynchrones est à chier dans OpenSSL, uniquement car TOUS les OS supportent un pattern Async I/O reactor style poll(), epoll(), kqueue() Excepté Windows qui prône un pattern proactor, mais si en fait !

                  C'est pas comme si TOUS les OS modernes ont un support correct pour pthread SAUF Windows donc OpenSSL se trimballe encore un système de "lock callback" à implémenter en manuel ou il segfault misérablement en multi-threadé, mais en fait, c'est le cas aussi !

                  Tu devrais sans doute leur proposer ton savoir faire en terme de portabilité depuis ton Visual Studio puisque c'est si facile de supporter Windows.

                  • [^] # Re: et ca compile ?

                    Posté par . Évalué à 3.

                    Car c'est pas comme si le pool allocator ( responsable du bug heartbleed ) avait été implémenté juste pour Windows qui a une version préhistorique de malloc, mais si en fait.

                    J'adorerais vraiment que tu me donnes les details qui font que ce pool allocator est prehistorique.

                    Pour le reste, c'est quand meme marrant que plein de projets arrivent a gerer tout ce que tu cites de maniere bien plus propre qu'OpenSSL…

                    • [^] # Re: et ca compile ?

                      Posté par . Évalué à 10. Dernière modification le 23/04/14 à 02:08.

                      Pour le reste, c'est quand meme marrant que plein de projets arrivent a gerer tout ce que tu cites de maniere bien plus propre qu'OpenSSL…

                      Tant mieux, il sera donc très simple de faire le portage Windows de LibreSSL.

                      En plus, les failles potentielles rajoutées par sa prise en charge n’affecteront pas les autres OS. Double win.

                  • [^] # Re: et ca compile ?

                    Posté par . Évalué à 6.

                    À vrai dire ils utilisent des fonctions non standard comme funopen, donc non, ils ne supportent pas tout ce qui supporte POSIX proprement. Ils supportent OpenBSD et rien d'autre.

                    Et non, ça n'est pas si facile de supporter Visual Studio, ou OpenVMS, ou autre OS non POSIX. OpenSSL le faisait pourtant, et c'est certainement une des raisons pour laquelle presque tout est basé sur OpenSSL. Mais j'imagine que c'est plus facile pour les développeurs d'OpenBSD de chier publiquement sur les couches de compatibilité d'OpenSSL (voire même de se moquer de certaines features comme le support d'OpenVMS) que d'essayer d'implémenter la même chose proprement.

                    • [^] # Re: et ca compile ?

                      Posté par . Évalué à 1. Dernière modification le 24/04/14 à 15:42.

                      funopen est une fonction standard dans la famille des BSD, existant notamment sous FreeBSD ou BSD 4.4.

                      Ils supportent OpenBSD et rien d'autre.

                      C’est bien possible qu’ils ne supportent que leur OS, dans un sens ou dans l’autre. Cet usage non standard de vocabulaire frenglish n’est pas supportable.

                      • [^] # Re: et ca compile ?

                        Posté par . Évalué à 5.

                        Qu'ils utilisent des fonctions de leur OS est tout à fait compréhensible, mais il ne faut pas « justifier » ce fait en disant « de toute manière les systèmes BSD ont cette fonctionnalité ».

                        Par contre, du peu que j'ai pu voir du code des différents BSD, il y a généralement un gros effort d'encapsulation qui rend le code non seulement lisible, mais (relativement) facilement portable. Dans le cas de funopen, il est possible de reproduire la fonctionnalité, mais sans doute avec une efficacité moindre (puisque funopen peut « jouer » avec les différents flux, alors que faire la même chose directement avec des descripteurs de fichiers et read/write nécessite de maintenir les flux de lecture/écriture complètement séparés).

                        C'est un peu comme strlcpy et strlcat. La fonction n'est pas du C standard (même pas POSIX) et donc pas forcément disponible sur le système cible, mais proposer une implémentation de secours n'est quand même pas si compliqué (bon, funopen demande un peu plus de cogiter).

                        • [^] # Re: et ca compile ?

                          Posté par (page perso) . Évalué à -3. Dernière modification le 24/04/14 à 17:11.

                          mais (relativement) facilement portable.

                          Pas du tout, par design.
                          Prenons donc funopen
                          Il est ou? Dans un fichier appelé stdio.h!
                          ce fichier est utilisé par la bibliothèque standard, non modifiable facilement car appartient à la lib standard utilisée.

                          Si tu veux porter, il faut soit modifier le source pour ajouter ton include perso, soit hacker ta lib standard, super…
                          Il auraient voul aider la portabilité qu'ils auraient largement éviter de polluer les includes de la lib standard, ils auraient pris un autre nom pour leur include, en respectant le côté standard des includes standards.
                          Je sais pas pour vous, mais moi quand je lis "include "stdio.h"", je m'attend à ce que seulles des fonction standardisées soient utilisées.

                          Ils la jouent perso à fond, libre à eux, mais pas la peine de dire qu'ils font des efforts pour pas emmerder les autres, c'est faux (en plus, l'auteur de la doc n'est pas du tout à une contradiction près "Standard C Library" et "function may not be portable to systems other than BSD" dans la meme page, juste bien trompeur, qu'on rigole bien, je ne sais ce qui est le pire celui qui écrit ça ou celui qui gobe qu'il y a une volonté de faire attention aux autres)

                          • [^] # Re: et ca compile ?

                            Posté par . Évalué à 5.

                            Prenons donc funopen
                            Il est ou? Dans un fichier appelé stdio.h!

                            C'est vrai. En même temps, contrairement aux headers sous Linux qui me font devenir chèvre à faire des milliards d'#include partout pour trouver la définition d'un type ou la déclaration d'une fonction, les BSD ont une hiérarchie des headers simple qui fait qu'on trouve facilement ce qu'on cherche (enfin en tout cas c'est mon expérience).

                            De plus je me souviens du temps où la libc sous Linux était le plus souvent la glibc, et du coup elle aussi embarquait un peu 12000 fonctions dans des headers « standards ».

                            Si tu veux porter, il faut soit modifier le source pour ajouter ton include perso,

                            Oui, c'est ce que je voulais dire : pour funopen par exemple, il faut clairement pouvoir reproduire la fonctionnalité, ce qui implique écrire une version perso. Idem pour strlcpy ou strlcat. Pour ces dernières, depuis la publication de C11, il existe les fonctions « bornées » (suffixées par _s, genre strcpy_s), qui devraient rendre l'écriture triviale (si le compilateur les implémente).

                            • [^] # Re: et ca compile ?

                              Posté par (page perso) . Évalué à 3.

                              C'est vrai. En même temps, contrairement aux headers sous Linux
                              qui me font devenir chèvre à faire des milliards d'#include
                              partout pour trouver la définition d'un type ou la déclaration
                              d'une fonction, les BSD ont une hiérarchie des headers simple
                              qui fait qu'on trouve facilement ce qu'on cherche (enfin en tout
                              cas c'est mon expérience).

                              L'un comme les autres ont des pages de man pour les fonctions. Car bon, les headers, c'est bien joli, mais ça donne pas les infos potables.

                              (ensuite, c'est en effet chiant pour les types)

                          • [^] # Re: et ca compile ?

                            Posté par (page perso) . Évalué à 9. Dernière modification le 24/04/14 à 18:07.

                            #if not defined(__OpenBSD__)
                            #include "compat.h"
                            #endif
                            

                            Pas besoin de modifier stdio.h. Ensuite, pas la peine d'accuser OpenBSD, comme indiqué très clairement dans la man page, c'est très largement du prior art, i.e 4.4 BSD. Et sinon, magnifique la page de man de MacOSX … :D

                            Je sais pas pour vous, mais moi quand je lis "include "stdio.h"", je m'attend à ce que seulles des fonction standardisées soient utilisées.

                            Sérieusement? Tu vis dans un monde de bisounours ou tu es mauvais en C au choix :). Déjà quel standard ? C89, C99, Posix (quelle version ?) Quelques exemples pour ta culture:

                            • sous Windows, stdio.h définit _snprintf, fonction bien connu des standards.
                            • Sous GNU/Linux, tu peux trouver fcloseall. Y'en a évidemment d'autres.
                            • Sous Android, tu retrouve funopen (les salauds ils ont piqué une libc BSD :)).

                            Pour le reste, je te laisse troller dans ton coin :)

                            • [^] # Re: et ca compile ?

                              Posté par (page perso) . Évalué à -3.

                              if not defined(OpenBSD)

                              include "compat.h"

                              endif

                              Pas besoin de modifier stdio.h.

                              Très fort.
                              tu tronque ma phrase pour oublier que j'ai dit "il faut soit modifier le source pour ajouter ton include perso, "

                              C'et fou comme on peut noyer le poisson quand on veut pas regarder les choses en face : tu arrives à sortir une modification du source (donc hack pourri à coup de define, le truc reproché à OpenSLL!) pour avoir raison, pas grave si ça permet pas d'avoir un source correct (upstream) ni si c'est ce qui est reproché à OpenSLL.

                              Déjà quel standard ? C89, C99, Posix (quelle version ?)

                              Le standard support par la lib. "std" c'est la lib standard, rien à voir avec Posix, pour la version le bohneur est que c'est très très compatible entre les versions.

                              Je trolle peut-être, mais te voila a ignorer des phrases que je sors pour me critiquer, preuve que tu n'as pas grand chose à dire.

                              sous Windows, stdio.h définit _snprintf, fonction bien connu des standards.

                              Microsoft n'est pas parfait, mais déjà est plus respectueux : _ devant un nom de fonction sert à préciser que c'est non standard. les xBSD l'ont un peu oublié…

                              Je n'ai pas dit que les autres étaient parfait, jsute que eux ne le sont pas (non plus, si tu préfère), mais bizarrement quand MS le fait c'est des pourris, quand BSD le fait c'est des gentils. Deux poids, deux mesures, grand classique.

                              Bon, de toutes façons le but n'est pas d'être cohérant, mais de dire que du bien d'un truc qu'on a déjà choisi que ça serait bien. J'arriverai à jour à comprendre qu'on ne peut pas montrer des petits problèmes à des gens qui veulent ne pas voir de problèmes.

                              • [^] # Re: et ca compile ?

                                Posté par (page perso) . Évalué à 2.

                                Le standard support par la lib. "std" c'est la lib standard, rien à voir avec Posix, pour la version le bohneur est que c'est très très compatible entre les versions.

                                Arrête de t'énerver, ton orthographe s'en ressent fortement. Et je suis encore très déçu de te dire que stdio.h et la libc contiennent des fonctions standardisées POSIX et pas juste C, par exemple fdopen (elle est même présente chez Microsoft). Ça peut te choquer mais c'est comme ça.

                                En l’occurrence, et pour être très précis, tu dis

                                Il auraient voul aider la portabilité qu'ils auraient largement éviter de polluer les includes de la lib standard, ils auraient pris un autre nom pour leur include, en respectant le côté standard des includes standards.

                                Je note juste que c'est une pratique commune, qu'on peut dénoncer si ça te fait plaisir, mais ce n'est justement pas mieux / pire que chez les autres. Je n'ai pas parlé de pourris, je n'ai pas dit de mal de Microsoft, j'ai donné un exemple dans chaque système majeur, je peux pas être plus "égalitaire".

                                Bon, de toutes façons le but n'est pas d'être cohérent, mais de dire que du bien d'un truc qu'on a déjà choisi que ça serait bien. J'arriverai à jour à comprendre qu'on ne peut pas montrer des petits problèmes à des gens qui veulent ne pas voir de problèmes.

                                C'est une excellente remarque, surtout appliquée de manière réflective. Et va voir un psy pour ton délire de persécution … (c'est gratuit, en avance pour demain).

                                • [^] # Re: et ca compile ?

                                  Posté par (page perso) . Évalué à 0.

                                  Je note juste que c'est une pratique commune, qu'on peut dénoncer si ça te fait plaisir, mais ce n'est justement pas mieux / pire que chez les autres.

                                  Tu remarqueras que c'est le problème. Quand les autres le font, c'est scandaleux, ils ne respectent pas le standard, ils vont tuer les bébé phoques. Et quand OpenBSD le fait, c'est tout à fait normal, il faut arrêter de les martyriser, les pauvres, ils ont toute la misère du monde à débogguer.

                                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: et ca compile ?

                              Posté par . Évalué à 2.

                              Et sinon, magnifique la page de man de MacOSX … :D

                              Tsss:
                              https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man3/funopen.3.html

                              Depending on the time of day, the French go either way.

                              • [^] # Re: et ca compile ?

                                Posté par (page perso) . Évalué à 1.

                                Le troll n'était pas sur la beauté intrinsèque de la page man, mais qu'il bashait OpenBSD, en citant une page de man de MacOSX, système qu'il défend régulièrement par ailleurs. Bref, ça m'a fait bien fait rire, mais il m'en faut peu.

                                • [^] # Re: et ca compile ?

                                  Posté par . Évalué à 4.

                                  C’est pas tant OS X qu’il défend (si ma mémoire est bonne il n’est pas trop fan), c’est le store, et les utilisateurs qui lui rapportent plus de fric que les utilisateurs Windows.
                                  La page a dû lui cramer la rétine l’empêchant de lire la source du man

                                  Depending on the time of day, the French go either way.

                        • [^] # Re: et ca compile ?

                          Posté par (page perso) . Évalué à 2.

                          C'est un peu comme strlcpy et strlcat. La fonction n'est pas du C standard (même pas POSIX) et donc pas forcément disponible sur le système cible, mais proposer une implémentation de secours n'est quand même pas si compliqué (bon, funopen demande un peu plus de cogiter).

                          Pour strlcpy et strlcat c'est même totalement trivial : il suffit de prendre le code source de la fonction dans OpenBSD (disponible ici http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/) car c'est du pure C standard (15 pauvres lignes de code) !

                          J'ai déjà utilisé ces fonctions dans un logiciel que j'ai développé et j'avais simplement inclues les 2 fonctions dans mon programme.

                • [^] # Re: et ca compile ?

                  Posté par . Évalué à 6.

                  Tu cherches windows dans une liste de "(…) the following Unix operating systems" et tu t'étonnes de ne pas l'y trouver ?
                  Dingue que windows ne soit pas une liste de système unix! En plus de troller tu es un idiot, ça commence à faire beaucoup pour une seule personne.

          • [^] # Re: et ca compile ?

            Posté par (page perso) . Évalué à 3.

            Le travail est pas non plus exactement le même, porter une lib C est un daemon qui dépend de fonctions non présente dans les autres kernels, c'est pas exactement la même chose. J'attends de voir une équipe qui va porter openbgpd qui sont bien plus dépendant du kernel d'openbsd qu'openssh ou libressl puisse l'être. Ou le portage de pf/altq sur linux.

            • [^] # Re: et ca compile ?

              Posté par (page perso) . Évalué à 3.

              pf/altq étant dans le kernel c'est encore moins comparable au reste. Cela dit, il y a bien des gens qui se sont amusés à porter/réimplémenter CARP : http://www.pureftpd.org/project/ucarp

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: et ca compile ?

                Posté par (page perso) . Évalué à 2.

                On m'a dit que altq n'est plus dans le kernel depuis 3j. Et il y a des gens qui ont portés pf sur netbsd. Donc bon, c'est faisable.
                Tout comme des gens ont fait des portages de l'API doors de solaris, ou des gens qui ont fait tourner zfs sur freebsd et linux via fuse. C'est juste un boulot énorme.

                Quand à carp, oui, c'est réimplementable, tout comme des gens ont refait une implémentations de certains API de systemd, suffit de suivre le protocole.

                Mais c'est vrai que je trouve difficilement des choses aussi étroitement lié à un kernel, en dehors du kernel et utilisant beaucoup d'api spécifique du kernel.

        • [^] # Re: et ca compile ?

          Posté par . Évalué à 6.

          Je te rejoins là-dessus, ce qui me fait peur, c'est le fait de virer du code parce que "on l'utilise pas" et notamment tout ce qui se rapporte à FIPS… C'est juste "un peu" utilisé dans l'industrie…

          • [^] # Re: et ca compile ?

            Posté par . Évalué à 2.

            La véritable explication n'a rien à voir avec "parce qu'on ne l'utilise pas":
            http://marc.info/?l=openbsd-misc&m=139819485423701&w=2

            • [^] # Re: et ca compile ?

              Posté par . Évalué à 2.

              C'est pire, c'est nuisible selon les propres convictions bien personnelles de Ted. A aucun moment, il n'a pensé que cela pouvait être intéressant dans certains domaines de la sécurité (et désolé d'avoir réussi à péter la sécu openssl sur certains produits non FIPS, hein…). En gros "ce qui est inutile/nuisible suivant mes propres convictions est inutile/nuisible pour tous". (Bon, perso, je m'en fous, j'utilise pas le code FIPS)

        • [^] # Re: et ca compile ?

          Posté par . Évalué à 5.

          Je trouve qu'il y a quand même une différence majeure que tu oublies de mentionner.

          systemd/udev/udisks sont des libs/daemons qui introduisent de nouvelles API. Ce n'est pas uniquement une meilleure implémentation d'une API existente. Si c'était le cas, cela ne poserait aucun roblème, si ce n'est que l'implémentation sous linux pourraient être meilleure.

          Dans le cas d'un fork openssl, aucune nouvelle API n'est introduite. Il semble même que ça soit un point important de faire en sorte que tout les logiciels présents sous openBSD continuent de compiler avec le fork. Il ne s'agit là que de différence d'implémentation qui n'impactent pas les logiciels tiers, tout comme openBSD a une libc spécifique qui n'est pas portable, une libthread spécifique, etc.
          Dans le cas de lennart, soit on a une implémentation de ses API, qui sont en général peu portable, soit pleins d'applis marchent pas. Dans ce cas là, on a juste une autre implémentation de libssl dont le but est d'être plus propre.

          • [^] # Re: et ca compile ?

            Posté par (page perso) . Évalué à 1.

            Sous Debian stable, j'ai installé systemd et tous les services ont continué de démarré. Je ne vois pas quel API de plus il aurait fallu respecté.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: et ca compile ?

              Posté par . Évalué à 5.

              Tu aurais du essayer d'installer gnome 3 sous freebsd.

              • [^] # Re: et ca compile ?

                Posté par (page perso) . Évalué à 2.

                Je croyais qu'on était entre gens sérieux et qu'on parlait donc de DE sérieux.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: et ca compile ?

                  Posté par . Évalué à 7.

                  Je croyais qu'on était des gens sérieux et que donc on ne trollait pas.

                  • [^] # Re: et ca compile ?

                    Posté par (page perso) . Évalué à 0. Dernière modification le 23/04/14 à 22:24.

                    Ah mais ce n'est pas moi qui ait parlé de Gnome en premier.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: et ca compile ?

                      Posté par . Évalué à 5.

                      parlons donc de xfce et de udisks.

                      • [^] # Re: et ca compile ?

                        Posté par (page perso) . Évalué à -1.

                        Bonne idée, c'est quoi le rapport avec systemd (le sujet du message auquel tu réponds initialement) ?

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: et ca compile ?

                          Posté par . Évalué à 4. Dernière modification le 23/04/14 à 22:45.

                          Peut être pourrais tu prendre la peine de relire :

                          systemd/udev/udisks sont des libs/daemons qui introduisent de nouvelles API

                          Udisks utilise udev et udev est dans systemd.
                          Même si udev précède largement systemd, il en est désormais un module. Et il est nécessaire pour pleins de choses, Xorg et le hotplug, wayland, udisks, etc. Pour ce qui est de la portabilité, le simple fait que certains fonctions publiques de udisks au demeurant très générique contiennent linux dans leur nom est très révélateur. Pour ce qui est de systemd, on reste pour l'instant assez préservé en dehors de gnome, mais je ne doute pas que cela changera, via logind par exemple.

                          • [^] # Re: et ca compile ?

                            Posté par (page perso) . Évalué à 1.

                            Et donc Linux fournit des interfaces qui sont utilisée parce qu'elle facilite la vie des utilisateurs et développeurs. Qu'est-ce qu'il faudrait faire ? Ne pas les utiliser et continuer à se compliquer la vie ?

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: et ca compile ?

                              Posté par . Évalué à 3. Dernière modification le 23/04/14 à 23:00.

                              Au moins éviter d'avoir le culot d'accuser les gens qui élèvent le respect des protocoles et des API standards et la portabilité à un niveau élevé de nuire à la portabilité des logiciels quand on est responsable des logiciels sus-cités.

                              Au mieux, concevoir les fameuses API qui facilitent la vie des utilisateurs et des dévelopeurs de manière à ce qu'elles soient suffisament abstraites et documentées pour être ré-implémentées différement autre part. Ce qui est très très très très loin d'être le cas de udisks et pas vraiment non plus de udev. Le pire c'est que la doc de udisks prétend que l'API est portable.

  • # Donc utile?

    Posté par (page perso) . Évalué à -10. Dernière modification le 22/04/14 à 08:01.

    en virant tout les machins spécifiques à VMS et Windows,

    Supper.
    Autant je comprend pour VMS (pas forcément très utilisé), autant virer ce qu'il y a sur 90% des PC desktop, c'est hum… Ah oui : faire l'intégriste, se couper de ses utilisateurs potentiels.

    en virant tout les machins spécifiques à VMS et Windows,

    Aucune envie de donner à des personnes qui me disent merde à moi et à plein d'utilisateurs.

    tu as oublié FIPS qu'ils ont viré aussi. Manifestement, avoir des utilsiateurs n'est pas leur priorité (après, rien de nouveau, ils codent OpenBSD qui a un nombre d'utilisateurs…)

    Je vous conseille d'aller jeter un coup d'oeil à la page Campagne de financement pour vous rendre compte à quel point tout le monde dépend de ces gens là.

    Des sous, OK, je ne vois rien d'autre (quel monde?), mais bon, 150 k$, c'est aussi ce que nombre de projets KickStarter font en quelque jours ;-).
    A voir si ça peut tenir sur le long terme, sans demande d'aide financière (et si à force devirer plein de choses rapidement, c'est d'une utilisé et de deux pas trop troué)

    • [^] # Re: Donc utile?

      Posté par . Évalué à 10.

      On vire ce qui n'est pas l'essence même du travail (en gros tout ce qui est spécifique à certaines architectures) pour voir la base du code, et la rendre meilleure.

      C'est un principe des plus simples. Cela permet d'éviter de se perdre dans des détails, ce qui empêche une bonne lisibilité du code et donc de trouver les failles.

      Une fois qu'il y aura du code relativement générique, on pourra y rajouter du code spécifique pour les différents OS.
      Fonctionner différemment c'est juste retourner dans les travers d'openssl.

    • [^] # Re: Donc utile?

      Posté par . Évalué à 10.

      Autant je comprend pour VMS (pas forcément très utilisé), autant virer ce qu'il y a sur 90% des PC desktop, c'est hum… Ah oui : faire l'intégriste, se couper de ses utilisateurs potentiels.

      Windows est peut-être utilisé sur 90 % des PC, mais OpenSSL n'est pas utilisé sur 90 % des PC.
      Si on regarde la faille Heartbleed, on voit bien que ça touchait les serveurs Apache ou ngix tournant sur Linux ou *BSD.
      Donc au final si ils virent tout le merdier spécifique à Windows, tant mieux. Franchement faire tourner un serveur Web Apache de prod sur Windows c'est pas sérieux…

      • [^] # Re: Donc utile?

        Posté par (page perso) . Évalué à 10.

        Donc au final si ils virent tout le merdier spécifique à Windows, tant mieux. Franchement faire tourner un serveur Web Apache de prod sur Windows c'est pas sérieux…

        Il paraîtrait que OpenSSL peut aussi être utilisé par des logiciels clients, même sous Windows…

    • [^] # Re: Donc utile?

      Posté par . Évalué à 10.

      Aucune envie de donner à des personnes qui me disent merde à moi et à plein d'utilisateurs.

      Tu parles quand même des personnes qui te disent merde et qui te fournissent aussi à toi et quelques milli(er|ons) de users OpenSSH, que tu utilises un petit peu, je pense. J'aimerais en connaître plus, des personnes qui me disent merde de cette manière. Avant de troller, laisse les faire leur travail, et d'ici quelques temps, tu pourras juger. Tu n'es pas obligé de donner des sous (perso je fais en sorte de donner régulièrement via les posters et les cd, je fais parti des utilisateurs de l'OS sur desktop + serveur), mais vu leur passif, on peut avoir confiance (ou au moins leur laisser le bénéfice du doute).

    • [^] # Re: Donc utile?

      Posté par (page perso) . Évalué à 10.

      Beau troll mais tu as oublié un truc :

      • Tu parles de gens qui maintiennent des outils Unix compliant (bref ils n'ont pas les capacité de maintenir du code spécifique windows car ils n'y connaissent sûrement rien)
      • Ces gens là écrivent un petit soft qui s'appelle OpenSSH dont une version portable existe (branche soutenu par pleins de gens externe à OpenBSD) et qui compile sur toutes les plateformes dont windows
      • Virer du bloab spécifique pour une plateforme qui se trouve en plein milieu du code n'est pas absurde. Ça permet d'autant plus de le mettre dans des fichiers spécifiques (genre windows.h, linux.h, vms.h) et donc améliorer la qualité des portages et leur maintenabilité.
      • A ma connaissance les outils d'OpenBSD compile très bien sous linux et même sous cygwin. Je ne dirai pas autant des outils linux (qui a dit systemd, pulseaudio ou udev dont l'auteur dit clairement emmerder tout le monde et faire du redhat compatible only ?)

      Bref tu prends une phrase, tu ne l'analyse pas, et tu trolls sans réfléchir.

      Mais bon forcement quand on est pas un habitué des audit de code permanent, des relectures croisé de code obligatoires et des méthodologies qui ne feraient pas de mal aux pisseurs de code de SSII : c'est sûr qu'on peut être choqué par ce genre de chose :)

      • [^] # Re: Donc utile?

        Posté par . Évalué à 9.

        linux compatible only, pas redhat, là c'est toi qui trolles.

    • [^] # Re: Donc utile?

      Posté par . Évalué à 10.

      mode Zenitram ON

      Donc tu voudrais qu'il bosse gratuitement pour toi ? Ha ben non, il faut payer, aucune raison qu'ils bossent pour toi gratuitement. C'est ça le libre, tu comprends rien au libre, tu crois que les autres vont faire des choses pour toi gratuitement ?

      mode Zenitram OFF

      Je l'ai bien fait ?

      • [^] # Re: Donc utile?

        Posté par (page perso) . Évalué à 10. Dernière modification le 22/04/14 à 13:36.

        Je l'ai bien fait ?

        Tellement que j'ai moinsé à vue!

        http://devnewton.bci.im

      • [^] # Re: Donc utile?

        Posté par (page perso) . Évalué à 4.

        tu as oublié une phrase ou deux sur les branleurs incompétents qui font joujou là ou les autres bossent mais la base y est :)

    • [^] # Re: Donc utile?

      Posté par (page perso) . Évalué à 10.

      J'ai oublie de mettre ça dans le 'nal, mais c'est intéressant: le commentaire de miod@ sur "quel nom choisir"

      Il explique très clairement que le nom de cette nouvelle librairie n'avait aucune importance, que la roadmap était assez standard:

      • Enlever tout ce qui dépasse
      • Ajouter des features
      • Faire une release stable pour OpenBSD
      • En faire un projet a part, qui pourra être porté sur d'autres environnements, et en profiter pour trouver un nom
      • Le tout en s'assurant de ne rien casser

      Donc oui, ils ont prévu de ne supporter qu'OpenBSD dans un premier temps, ce qui est normal puisqu'ils font ça d'abord et avant tout pour eux, mais que dans la tradition OpenBSD ils feront du code suffisamment portable pour que n'importe qui puisse adapter ça a sa plateforme. Ils te disent pas juste merde, ils te disent "merde pour le moment, reviens dans 6 mois. Oh et la page de dons c'est par la".

      Bon, au final ils ont fait les choses a l'envers (ils ont trouvé un nom), j’espère qu'ils se travestiront pas plus que ça.

      • [^] # Re: Donc utile?

        Posté par . Évalué à 1.

        J'ai oublie de mettre ça dans le 'nal, mais c'est intéressant: le commentaire de miod@ sur "quel nom choisir"

        Son mail est bizarre. D'un coté il dit que choisir un nom c'est pas important, de l'autre, ils choisissent le pire nom possible (LibreSSL) et il est un des premiers à le promouvoir (il rajoutait souvent le hashtag #LibreSSL avant que le nom ne soit officiel).

        • [^] # Re: Donc utile?

          Posté par (page perso) . Évalué à 9.

          Oh mon dieu une conspiration!

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Donc utile?

            Posté par . Évalué à 1.

            Je ne comprends pas ton commentaire.

            J'ai pas parlé de conspiration, je disais juste que ses écrits et ses actes étaient différents sur ce point (et uniquement sur ce point).

        • [^] # Re: Donc utile?

          Posté par (page perso) . Évalué à 3.

          Dans la stratégie OpenBSD, j'aurais personnellement pris le nom d'OpenTLS… Zut, c'est déjà pris mais cela semble mort : http://www.opentls.org/

        • [^] # Re: Donc utile?

          Posté par . Évalué à 5.

          C'est pas bizarre, c'est juste qu'il est mort de rire à troller comme un goret.

          Faut quand même voir leur site en Comic Sans MS avec marqué en bas "This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags"

          • [^] # Re: Donc utile?

            Posté par (page perso) . Évalué à 10.

            N’empêche, merci les gars, là sur le Firefox sur Linux que j’ai sous la main le blink ne clignote pas et je n’ai pas les polices Microsoft installées donc en fait la page est super propre…

            À cause de vos remarques j’ai cherché un Windows pour tester… et merci du signalement, j’aurai raté ça, c’est grand. :)

            ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Donc utile?

          Posté par . Évalué à 10.

          Choisir un nom n'était pas important parce que cela avait été fait très tôt, ainsi que la réservation des noms de domaine. D'où un certain désintérêt pour la question.

          Après, quand on s'acharne à nettoyer ce code-(ifdef-)spaghetti plein de toiles d'araignées et de morceaux de code emmurés que personne n'ose enlever, et que la principale préoccupation de spectateurs est «mais quel nom allez-vous utiliser ?», au bout d'un moment, la seule réaction qui te vient, c'est «vos gueules, y'en a qui bossent ici». D'où mon coup de gueule, qui permettait au passage de faire passer un peu de la ligne officielle du parti.

          Miod, pour le compte du ``Buena Vista SSL club''

        • [^] # Re: Donc utile?

          Posté par . Évalué à 1.

          le pire possible ? vraiment ? et L'àç(Q"é)fqùrùJDzamflraùmgEeagogẑÜùSSL c'est pas pire peut-être ?

          sachant que la licence openSSL interdit de réutiliser le nom openSSL et que openTLS existe déjà…

          • [^] # Re: Donc utile?

            Posté par . Évalué à 3. Dernière modification le 24/04/14 à 11:56.

            L'àç(Q"é)fqùrùJDzamflraùmgEeagogẑÜùSSL c'est pas pire peut-être ?

            Utiliser juste un caractère d'espacement c'est pire (mais j'aurais préféré LibreTLS).

            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Donc utile?

      Posté par . Évalué à 1.

      VMS est plus utilisé que tu le crois et les utilisateurs windows ne sont pas des utilisateurs potentiels d'openBSD. Si tu crois que les devs d'openBSD vont travailler gratuitement pour sécuriser les logiciels propriétaires de microsoft, je pense que tu n'as pas compris ce qu'est openBSD (tout le contraire de windows).

      FIPS est viré aussi et c'est tout aussi justifié que de ne pas supporter windows: http://marc.info/?l=openbsd-misc&m=139819485423701&w=2

  • # Et les algorithmes GOST ?

    Posté par (page perso) . Évalué à 10.

    en virant tout les machins spécifiques à VMS et Windows, ils ont viré la moitié du bloat qu'il y avait

    Ils ont aussi viré les algorithmes d’origine russe… Ceux-ci ont pourtant leurs RFCs et devraient avoir droit de cité au même titre que les algorithmes occidentaux.

    La NSA n’arrivait pas à les casser, c’est ça ?

    • [^] # Re: Et les algorithmes GOST ?

      Posté par . Évalué à 2. Dernière modification le 22/04/14 à 13:32.

      Car tu crois que le KGB n'a pas les même pratique que la NSA ? Et que du coup les algo russes peuvent ne pas avoir de faiblesse caché ?
      Bon après s'ils ont le même niveau de fiabilité que ceux de la NSA il est vrai qu'ils ont aussi le droit de cité

      • [^] # Re: Et les algorithmes GOST ?

        Posté par (page perso) . Évalué à 9.

        Donc il faut se concentrer sur les algos apatrides ?

        Ça va être chaud, non ?

      • [^] # Re: Et les algorithmes GOST ?

        Posté par . Évalué à 10.

        Du coup suffit de chiffrer ses messages avec un algo nsa et de rechiffrer le résultat avec un algo kgb et on est tranquille \o/

        • [^] # Re: Et les algorithmes GOST ?

          Posté par . Évalué à 7.

          Le KGB et la NSA sont tellement passées maîtres dans l'infiltration et l'espionnage que je pense qu'on peut les considérer comme une seule et même entité.

      • [^] # Re: Et les algorithmes GOST ?

        Posté par . Évalué à 4.

        Après le DES (1978), la NSA a quand même promu des algos sûrs (AES, qui peut servir à chiffrer des données classifiées US, tout de même !) mais s'est concentrée sur les systèmes à clef publique, les générateurs d'aléa et la génération des clefs (DSA, bonjour !).

        • [^] # Re: Et les algorithmes GOST ?

          Posté par . Évalué à 1.

          Après le DES (1978), la NSA a quand même promu des algos sûrs

          Mais elle a aussi introduit des backdoors dans certains algos : http://en.wikipedia.org/wiki/RSA_BSAFE

          • [^] # Re: Et les algorithmes GOST ?

            Posté par . Évalué à 2.

            Le lien que tu pointes est une bibliothèque et le problème était qu'elle utilisait le standard troué de génération de nombres aléatoires.

        • [^] # Re: Et les algorithmes GOST ?

          Posté par (page perso) . Évalué à 1.

          C'est amusant, je ne me souviens pas avoir vu passer de preuve qu'il n'y a pas de backdoor dans AES.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Et les algorithmes GOST ?

            Posté par . Évalué à 10.

            Je pige pas bien. AES, comme à peu près tous les algos de crypto publics, a été et est encore testé dans ses retranchements en permanence. Lorsque le « challenge » pour choisir l'algo qui allait être choisi pour AES a été émis, la compétition était clairement ouverte à tous les « non-guignols » (i.e. à ceux qui savent établir un protocole de crypto symmétrique).

            Donc s'il n'existe pas de preuve formelle qu'il n'y a pas de backdoor dans AES, il y a par contre un historique de ~15 ans de recherche, où l'on a essayé de casser de l'AES à tour de bras.

            C'est un peu comme si tu disais qu'on n'a pas prouvé que RSA n'avait pas de backdoor. C'est vrai, mais on a démontré tout un tas de cas où le protocole casse si l'on choisit mal les clés privées ou publiques. Et du coup on a « patché » le protocole en conséquence.

  • # Analyse de dépôt GitHub

    Posté par . Évalué à 8.

    Un type a produit différentes analyses (nombre de ligne de code, principaux contributeurs, fréquences des commits, etc.) sur le code et l'activité des développeurs.
    http://nbviewer.ipython.org/gist/dloss/11089724

  • # précédent audit

    Posté par . Évalué à 5.

    Et ils n'avaient pas vu tout ce "merdier" (je reprends leurs mots) lors du précédent audit entrepris suite aux révélations d'une porte dérobée dans un des algorithmes de chiffrement?

    Toujours est-il qu'un nettoyage de printemps est bienvenu.

    • [^] # Re: précédent audit

      Posté par (page perso) . Évalué à 10.

      Et ils n'avaient pas vu tout ce "merdier" (je reprends leurs mots) lors du précédent audit entrepris suite aux révélations d'une porte dérobée dans un des algorithmes de chiffrement?

      A quoi est-ce que tu fais allusion exactement ? Si c'est l'affaire Gregory Perry alors il s'agissait d'accusations au sujet d'une backdoor dans la pile IPSec.
      Rien à voir avec OpenSSL donc.

  • # réaction du côté d'OpenSSL

    Posté par . Évalué à 6.

    Et comment les dev de OpenSSL réagissent à tout ça ? J'imagine que ça doit pas être franchement la joie…

    • [^] # Re: réaction du côté d'OpenSSL

      Posté par (page perso) . Évalué à 2.

      Et comment les dev de OpenSSL réagissent à tout ça ?

      http://www.pcinpact.com/news/87143-openssl-cumule-23-000-dons-en-dix-jours-et-accepte-bitcoins.htm

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: réaction du côté d'OpenSSL

      Posté par (page perso) . Évalué à 10.

      Eux, je ne sais pas, mais moi franchement, à leur place, je dirais « eh bien allez vous faire foutre. Ça fait quinze ans que le code est là, qu’il est libre, et que vous n’aviez pas de problèmes à vous en servir. Si vous trouviez le code horrible vous pouviez vous en mêler plus tôt, ou aller trouver du code plus joli ailleurs. »

      Sérieusement, je trouve assez écœurant de voir tout le monde se réveiller et tomber sur OpenSSL comme si c’était de la merde et que tout le monde savait que c’était de la merde, alors que c’est de la merde que tout le monde était bien content d’utiliser sans rien faire pendant des années.

      « La gratitude est la maladie des chiens. »

      • [^] # Re: réaction du côté d'OpenSSL

        Posté par . Évalué à 8.

        Sauf qu'ils ont des griefs contre OpenSSL depuis une dizaine d'année et ne se servent que d'une partie d'OpenSSL parce qu'il préfèrent réécrire l'autre partie dans leur logiciel.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: réaction du côté d'OpenSSL

          Posté par . Évalué à 2.

          C'est quoi la partie conservée et la partie ré-écrite ? Qui fait ça ?

          • [^] # Re: réaction du côté d'OpenSSL

            Posté par . Évalué à 3.

            L'exemple déjà donné c'est la lecture d'ASN.1. Les développeurs d'OpenBSD n'utilisent pas celle d'OpenSSL et ont écris leur propre parseur.

            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: réaction du côté d'OpenSSL

        Posté par . Évalué à 3.

        C'est peut-être parce que l'implémentation d'openSSL c'est de la merde et que tout le monde le sait plus ou moins depuis une dizaine d'années et heartbleed a été la goutte de trop qui a amené les seuls qui prennent au sérieux la sécurité à finalement faire ce qui aurait dû être fait depuis longtemps.

        • [^] # Re: réaction du côté d'OpenSSL

          Posté par (page perso) . Évalué à 1.

          S'ils prenaient la sécurité au sérieux, ça fait longtemps qu'ils auraient dû faire ce travail. Non, là, ils veulent juste surfer sur la vague médiatique de la faille pour récupérer de l'argent, en humiliant au passage des développeurs de logiciels libres.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: réaction du côté d'OpenSSL

            Posté par (page perso) . Évalué à 5.

            Il me semble que c'est un projet avec des ressources limitées (tant en argent qu'en main d'œuvre), donc ils ne peuvent pas tout faire, mais par exemple ils avaient déjà commencé à dépendre moins d'OpenSSL grâce à signify pour les packages signés.

            Et si l'effet médiatique leur permettait de récupérer un peu d'argent, je pense que ce serait plutôt une bonne chose vu le peu que récupère ce projet par rapport au caractère assez critique des logiciels qu'ils développent, et qui sont si utilisés (surtout OpenSSH, mais pas seulement).

            Et ce n'est pas spécialement les développeurs d'OpenSSL qui doivent se sentir humiliés, mais plutôt toutes les grandes entreprises qui en dépendent et qui n'ont jamais donné d'argent, tout comme pour OpenSSH d'ailleurs. Espérons qu'elles apprendront un peu la leçon, et qu'avoir à révoquer tous leurs certificats leur aura fait comprendre qu'un logiciel libre ne se développe pas tout seul, et que ça vaut le coup de payer un peu (surtout que ce qui serait beaucoup pour un projet libre est trois fois rien pour ces grandes entreprises).

            • [^] # Re: réaction du côté d'OpenSSL

              Posté par . Évalué à 3.

              Et ce n'est pas spécialement les développeurs d'OpenSSL qui doivent se sentir humiliés, mais plutôt toutes les grandes entreprises qui en dépendent et qui n'ont jamais donné d'argent, tout comme pour OpenSSH d'ailleurs. Espérons qu'elles apprendront un peu la leçon, et qu'avoir à révoquer tous leurs certificats leur aura fait comprendre qu'un logiciel libre ne se développe pas tout seul, et que ça vaut le coup de payer un peu (surtout que ce qui serait beaucoup pour un projet libre est trois fois rien pour ces grandes entreprises).

              Ben aiet, c'est parti (pour OpenSSL, pas pour le truc des gars d'OpenBSD) :

              http://mashable.com/2014/04/24/facebook-google-microsoft-join-forces-to-prevent-another-heartbleed/

              • [^] # Re: réaction du côté d'OpenSSL

                Posté par (page perso) . Évalué à 5.

                Cool, 5 entreprises PRISM compliant pour auditer une bibliothéque critique. Ayez confiance, ayez confiance, braves petits :)

                • [^] # Re: réaction du côté d'OpenSSL

                  Posté par (page perso) . Évalué à 6.

                  Ben oui, les entreprises non américaines n'ont pas l'air de trouver ce genre de bibliothèque critique.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: réaction du côté d'OpenSSL

                  Posté par . Évalué à 2.

                  Restons factuels, hein. Ajd, personne ne l'audite cette bibliothèque. C'est mieux que rien.

                • [^] # Re: réaction du côté d'OpenSSL

                  Posté par . Évalué à 2.

                  http://www.linuxfoundation.org/programs/core-infrastructure-initiative

                  Il y a 12 boîtes (dont au moins une non-américaine, Fujitsu :-)).

                • [^] # Re: réaction du côté d'OpenSSL

                  Posté par (page perso) . Évalué à 4.

                  Cool, 5 entreprises PRISM compliant pour auditer une bibliothéque critique. Ayez confiance, ayez confiance, braves petits :)

                  Non, pour donner de l'argent qui va servir à paier des developeurs / audits. Et je doute qu'il y aura des conditions du genre "on vous donne de l'argent, mais vous laissez une backdoor", et si c'était le cas les projets sont de toute facon libres de refuser l'argent. Et si on leur fait pas confiance pour refuser ce genre de clause, on peut aussi imaginer qu'ils sont deja payés en secret par la NSA qui n'a pas besoin de passer par la linux foundation pour paier des developeurs.

  • # Police (personne ne bouge)

    Posté par (page perso) . Évalué à 7.

    Et sinon le choix de la police Comic Sans MS faut le prendre comment ? :D

  • # Rappel journal précédent

    Posté par (page perso) . Évalué à 4.

    J'ai lu en diagonale les commentaires mais je n'ai pas vu de commentaire pour rappeler le précédent journal sur ce sujet : https://linuxfr.org/users/anaseto/journaux/journal-bookmark-vers-un-fork-d-openssl

    À consulter pour ses 81 commentaires.

  • # Revue de presse

    Posté par . Évalué à 5.

    Hé oui, on peut faire une revue de presse sur un journal maintenant, plus besoin d'avoir une dépêche :)

    http://www.numerama.com/magazine/29166-libressl-par-openbsd-veut-remplacer-openssl.html

  • # ...

    Posté par . Évalué à 6.

    Ils ont commité comme des petits fous (on parle de 250 commits à 8), et sont arrivés à un résultat assez intéressant: en virant tout les machins spécifiques à VMS et Windows, ils ont viré la moitié du bloat qu'il y avait, et toutes les applis dans l'arbre OpenBSD continuent de compiler. Pas mal.

    Faire plein de commit et que le code continue a compiler, pas mal de monde sait le faire.

    Par contre être sur que l'on introduit pas de subtile régression ou trou de sécu c'est beaucoup plus dur. Surtout dans les algos de crypto où il peut avoir des attaques temporelles : http://fr.wikipedia.org/wiki/Attaque_temporelle.

    Enfin c'est bien beau de faire un fork mais si personne ne l'utilise, il ne sera jamais audité et aura potentiellement plein de trou.
    Il y a plein de lib ssl (gnutls, …) ou de lib de crypto, mais c'est pas pour rien que les failles sont divulguées sur les plus utilisées.

    • [^] # Re: ...

      Posté par . Évalué à 4.

      Enfin c'est bien beau de faire un fork mais si personne ne l'utilise, il ne sera jamais audité et aura potentiellement plein de trou.

      […]Henson apparently failed to notice a bug in Seggelmann's implementation,[21] and introduced the flawed code into OpenSSL's source code repository on December 31, 2011. The vulnerable code was adopted into widespread use with the release of OpenSSL version 1.0.1 on March 14, 2012. Heartbeat support was enabled by default, causing affected versions to be vulnerable by default.

      http://en.wikipedia.org/wiki/Heartbleed#Appearance

      Depending on the time of day, the French go either way.

      • [^] # Re: ...

        Posté par . Évalué à 1.

        Sauf erreur de ma part, j'ai entendu dire que c'est parce que personne n'utilisait Heartbeat que la faille n'avait jamais été détecté. (et c'est aussi pour cela que le code HB a été supprimé par la suite)

        • [^] # Re: ...

          Posté par (page perso) . Évalué à 4.

          En même temps c'est pas détectable: je crois que personne ne logue la requête de heartbeat, et personne ne logue les réponses; impossible de savoir que la fonctionnalité (ou la faille, selon le point de vue) a été utilisée.

          • [^] # Re: ...

            Posté par . Évalué à 1.

            Les propos sont - si mes souvenirs sont exactes - de l'auteur de HB. Donc je pense qu'il a peut-être un peu plus de connaissance que nous sur l'utilisation de la chose qu'il a implémenté dans OpenSSL.

        • [^] # Re: ...

          Posté par . Évalué à 3.

          "Personne ne l'utilise" n'empêche pas un attaquant de l'utiliser. C'est bien le problème.

          • [^] # Re: ...

            Posté par . Évalué à 2.

            En quoi c'est contradictoire avec ce que je viens de dire ?

    • [^] # Re: ...

      Posté par . Évalué à 8.

      il ne sera jamais audité et aura potentiellement plein de trou.

      Mouais, enfin j'ai l'impression que l'actualité a démontré qu'un code très utilisé n'est jamais audité non plus et a potentiellement plein de trous également.

      • [^] # Re: ...

        Posté par (page perso) . Évalué à 7.

        C'est pas parce qu'il est audité qu'on trouve 100% des failles. Les erreurs, ça arrive à tout le monde.

      • [^] # Re: ...

        Posté par (page perso) . Évalué à 8.

        Bien sûr que c'est audité. Comment tu crois que la faille a été trouvée ?

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: ...

          Posté par . Évalué à 1.

          Ouais enfin auditer un code deux ans après le commit, c'est comme s'il ne l'avait pas été.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: ...

            Posté par (page perso) . Évalué à 2.

            Donc sinon toi perso tu mets combien de temps entre le commit et le dernier audit qui a détecté tous les bugs ?

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: ...

              Posté par . Évalué à 1.

              Moi, je ne suis pas développeur.

              Mais j'imagine que si j'étais celui d'une bibliothèque de sécurité utilisée par une majorité de serveurs sur le web, l'audit de toute nouvelle fonction me paraîtrait très prioritaire.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: ...

                Posté par (page perso) . Évalué à 3.

                Prioritaire sur quoi ?
                Tu es développeur pas payé d'une bibliothèque de sécurité très importante qui est utilisée gratis par tout le monde et au lieu de regarder tes pieds depuis la chaise longue, il te faut courber l'échine au-dessus du clavier pour auditer le commit d'un autre. Et c'est urgent, sinon panpan culcul.

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                • [^] # Re: ...

                  Posté par . Évalué à 2. Dernière modification le 24/04/14 à 19:16.

                  Tu ne me feras pas croire qu'aucun développeur d'OpenSSL n'est payé pour travailler dessus.

                  En tout cas si ce n'est pas le cas, et si personne ne gère les priorités parce que c'est un travail volontaire, alors je crois qu'il faut définitivement éviter OpenSSL.

                  Au passage, se targuer de développper un outil de sécurité soit-disant robuste et de niveau commercial (c'est pas moi qui le dit, c'est sur la page d'accueil) et ne pas auditer le code au fil des commits, c'est quand même assez moyen.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: ...

                    Posté par (page perso) . Évalué à 5.

                    De ce que je comprend, les développeurs OpenSSL sont payés pour ajouter des fonctionnalités mais généralement pas pour auditer. Les gens qui auditent OpenSSL sont généralement des individuels ou organisations tierces qui espèrent soit s'assurer de la sécurité du bazard pour leur utilisation ou trouver des failles qu'ils peuvent revendre. Ces gens ne sont pas nécessairement des développeurs et ils n'ont pas forcément d'intérêt à publier les résultats de leurs recherches.

                    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                  • [^] # Re: ...

                    Posté par (page perso) . Évalué à 7.

                    Tu ne me feras pas croire qu'aucun développeur d'OpenSSL n'est payé pour travailler dessus.

                    Il n'y a que 24h dans une journée. A moins d'etre Chuck Norris, c'est pas par ce que t'es payé que t'as le temps de maintenir correctement un truc comme OpenSSL tout seul.

                    Au passage, se targuer de développper un outil de sécurité soit-disant robuste et de niveau commercial (c'est pas moi qui le dit, c'est sur la page d'accueil) et ne pas auditer le code au fil des commits, c'est quand même assez moyen.

                    Bien sur que le code est audité avant d'etre commité. C'est pas "on a recu un patch, on le commit, on verra bien si ca compile, et si oui alors c'est OK". Simplement il suffit pas d'auditer le code tout seul pour voir tous les problèmes tout le temps.

                  • [^] # Re: ...

                    Posté par . Évalué à 3.

                    Au passage, se targuer de développper un outil de sécurité soit-disant robuste et de niveau commercial (c'est pas moi qui le dit, c'est sur la page d'accueil) et ne pas auditer le code au fil des commits, c'est quand même assez moyen.

                    Est ce que tu es en train de dire que du code commercial et toujours audite et toujours de bonne qualité et n'a jamais aucun problème?

                    Les bras m'en tombent…

  • # Implémentation prouvée

    Posté par . Évalué à 9.

    Un procès d'intention serait bien mal venu. J'imagine que les développeurs d'OpenSSL étaient totalement impliqués dans leur travail, avec pour objectif fonctionnel et sécurisé. Et pourtant, on retrouve ce trou béant qui est HeartBleed dans leur code.

    Quelle différence de démarche dans le processus de développement de ce 'LibreSSL' ? Aucune. Des développeurs pleins de bonnes intentions, sans doute des experts en sécurité, qui vont tout faire pour obtenir un logiciel robuste et performant. Et pourtant, on retrouvera sans doute des trous béants dans leur code.

    Il me semble qu'il serait temps de passer à des implémentations prouvées. L'équipe Inria ProSecco a réalisé une implémentation prouvée de TLS. Les failles sont alors automatiquement décelées, ce qui ajoute un degré de sécurité à l'implémentation. Pourquoi ne pas utiliser cette même démarche avec les composants de sécurité clés ?

    • [^] # Re: Implémentation prouvée

      Posté par (page perso) . Évalué à 5.

      Les failles sont alors automatiquement décelées

      Je suppute une petite exagération dans ce propos.

      • [^] # Re: Implémentation prouvée

        Posté par . Évalué à 3.

        Une exagération très légère… Si le langage choisi (F7 pour le travail de Prosecco) est bien fait, toutes les failles d'implémentation devraient être décelées.

        Quand on travaille sur des points aussi critiques de sécurité, il me semble normal de prouver la conception du protocole ET son implémentation. Biensûr, c'est encore à l'état de recherches, mais ils ont une implémentation qui fonctionne, et qui est prouvée, ce qui est une belle avancée. Il y a eu beaucoup d'articles traitant de Heartbleed et des solutions à lui apporter, mais on ne mentionne jamais les implémentations prouvées, qui sont, selon moi, la seule solution d'avenir…

        Pour ceux que ça intéresse, j'ai retrouvé le nom de leur implém': c'est miTLS.

        Alfredo Pironti en parle ici: http://alfredo.pironti.eu/research/projects/mitls et il y a même un site dédié ici: http://www.mitls.org/wsgi

        • [^] # Re: Implémentation prouvée

          Posté par (page perso) . Évalué à 10.

          Une exagération très légère… Si le langage choisi (F7 pour le travail de Prosecco) est bien fait, toutes les failles d'implémentation devraient être décelées.

          Non, c'est clairement exagéré. Toutes celles pour lesquelles on a écrit des "preuves". Une approche formelle ne garantie rien "magiquement". Par exemple, dans mitls, il n'y a pas de modélisation explicite du temps, donc on ne peut rien prouver sur les "timings attacks" (ce qui ne veut pas dire pour autant que leur implémentation est incorrecte de ce point de vue là).

          L'autre question évidemment est la possibilité d'embedder ça dans les différents logiciels, je ne suis pas trop sûr de l'interoparibilité de F7

        • [^] # Re: Implémentation prouvée

          Posté par (page perso) . Évalué à -7. Dernière modification le 22/04/14 à 15:08.

          Une exagération très légère… Si le langage choisi (F7 pour le travail de Prosecco) est bien fait, toutes les failles d'implémentation devraient être décelées.

          J'avoue avoir du mal à imaginer une détection automatique d'une erreur du type "je renvoie A alors que je devais renvoyer Q de même type et taille que A, juste que mon doigt a dérapé un peu zut Q contient des données critiques" mais tu vas sûrement m'expliquer… Ou alors tu exagères et c'est juste un faux sentiment de sécurité.

          • [^] # Re: Implémentation prouvée

            Posté par . Évalué à 1.

            Je ne suis pas un expert de ce sujet, mais Blanchet et Pironti, que j'ai croisés à quelques séminaires, sont très convaincants. Biensûr il n'existera jamais de preuve absolue qu'une implémentation est sécurisée, mais ils franchissent déjà une grosse marche dans la sécurité ! Je trouve juste aberrant de voir un groupe de codeurs, aussi bien intentionns soient-ils, reprendre le même chemin que celui qui a conduit à OpenSSL et HeartBleed…

            Si cela t'intéresse, tu peux consulter leurs pages, leurs papiers, où ils expliquent tout ceci bien mieux que moi. :=)

          • [^] # Re: Implémentation prouvée

            Posté par . Évalué à 6. Dernière modification le 22/04/14 à 15:51.

            On garantie que le programme est conforme aux spécifications. Il faut que les spécifications soient correctes, mais ça, aucun programme ne peut les vérifier ; c'est le boulot des humains.

            Mais si dans la spécification d'une fonction il y a marqué qu'elle retourne A, alors un code qui la fait renvoyer Q est incorrect. Si dans sa spécification il y a marqué qu'elle retourne quelque chose du même type que A ou Q, alors la spécification n'est pas assez précise. Bref, dans ta specs tu aura les contraintes sur l'objet retourné, contraintes que satisferont A mais pas Q.

            Par exemple, différentes spécification pour la fonction factorielle :
            * fact :: int -> int alors fact = \x :: int -> -42 * x est une implémentation correcte
            * fact :: uint -> uint est un peu mieux typé, mais il est toujours possible de mal l'implémenté.
            * fact :: {a::uint} -> {b::uint et pour tout x entre 1 et a, x divise b} est un peu plus précis, mais toujours pas assez. Une implémentation correcte de cette spécification peut aussi bien retourner a! que a!×a! ou le produit des nombres premiers entre 1 et a + 42.
            * fact :: {a::uint} -> {b::uint et b = produit sur uint de 1 à a} ça c'est la définition de la fonction factorielle, une implémentation sera correcte.
            * fact :: {a::uint} -> {b::uint tel que b est le nombre de permutations possibles d'une liste de a objets distincs} est correcte aussi.

            Please do not feed the trolls

            • [^] # Re: Implémentation prouvée

              Posté par (page perso) . Évalué à -10.

              Il faut que les spécifications soient correctes, mais ça, aucun programme ne peut les vérifier ; c'est le boulot des humains.

              Donc on ne fait que déporter le problème, on ne le supprime pas.
              Pas très utile.

              • [^] # Re: Implémentation prouvée

                Posté par (page perso) . Évalué à 10.

                Captain Obvious à la rescousse! Tu espérais quoi, un truc qui prouvait la correction par l'opération d'un esprit supérieur ?

                C'est sûr qu'on peut faire la même confiance dans un code C spaghetti de 100K lignes et dans 500 lignes de spécifications dans un langage formel quelconque (chiffres complétement au pifomètre).

            • [^] # Re: Implémentation prouvée

              Posté par . Évalué à 1.

              J'ai pourtant tout le temps entendu l'inverse, il est possible de prouver mathématiquement le fonctionnement d'un algorithme mais dans la pratique c'est très long et fastidieux. En revanche, l'implémentation est impossible à suivre à moins de se concentrer sur une seule implémentation qui n'est jamais modifiée pour effectuer un travail exhaustif. Du coup, je m'en vais lire les articles donnés en lien, ça me semble intéressant.

              • [^] # Re: Implémentation prouvée

                Posté par . Évalué à 5.

                On ne peut pas prouver que tous les algorithmes sont corrects. Il faut les contraindre à accepter tout un tas de paramètres pour rendre l'espace de recherche pour la preuve acceptable. Et puis aussi, si ce que tu avances est vrai, on pourrait prédire quand un algo se termine dans le cas général, ce qui n'est pas possible (le problème de l'arrêt est indécidable).

              • [^] # Re: Implémentation prouvée

                Posté par . Évalué à 2.

                Encore faut-il:
                1- arriver a écrire la spec
                2- que l’écriture de la spec soit correcte

                Pour avoir essaye d’écrire du code avec la méthode B, je peux te garantir que c'est pas demain la veille que tous les logiciels seront écrits avec des méthodes formelles.

    • [^] # Re: Implémentation prouvée

      Posté par . Évalué à 10.

      Quelle différence de démarche dans le processus de développement de ce 'LibreSSL' ?

      C'est des dev OpenBSD, l’élite des développeurs système. Ils ne peuvent pas se planter !

      Plus sérieusement, forker OpenSSL, pourquoi pas. Je connais pas trop l'histoire du projet et sa gestion, du coup difficile d'avoir une opinion. Par contre l'humiliation publique via le tumblr je trouve ça absolument dégueulasse. Ça fait un peu trop coup de pub opportuniste…

      • [^] # Re: Implémentation prouvée

        Posté par . Évalué à 6.

        Par contre l'humiliation publique via le tumblr je trouve ça absolument dégueulasse. Ça fait un peu trop coup de pub opportuniste…

        À priori ça vient pas des devs OpenBSD en même temps.

        • [^] # Re: Implémentation prouvée

          Posté par . Évalué à 1.

          Effectivement, mea culpa. Mais ça reste vilain.

        • [^] # Re: Implémentation prouvée

          Posté par . Évalué à 10.

          Le tumblr ne vient pas des développeurs, mais par contre les messages de commit, si. Comme l'un n'est qu'une reprise de l'autre, j'ai tendance à les penser légèrement responsables.

          De manière générale, ce fork me laisse un petit goût amer dans la bouche. C'est peut-être le côté "je me la pète grave", y compris dans les messages de commits. Et peut-être aussi la volonté clairement affichée que leurs améliorations ne reviennent pas chez OpenSSL (avec le changement de conventions de codage au passage sous prétexte de "lisibilité du code").

          En fait, je suis surpris que de tels "pros" aient pu utiliser pendant des années OpenSSL. Ils avaient jamais mis le nez dans le code d'un logiciel de cette importance pour leur sécurité ?

  • # Libraire != bibliothèque

    Posté par . Évalué à 10.

    My 2 cents…

  • # Un petit peu d'histoire...

    Posté par . Évalué à 10.

    http://www.tedunangst.com/flak/post/origins-of-libressl donne un peu plus d'infos sur le pourquoi du comment des raisons du fork. Au passage, il y'a plein d'autres posts sur le sujet sur le blog de tedu@

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.