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 Sytoka Modon (site web personnel) . É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 Sylvain Berfini (site web personnel) . Évalué à 6.
J'ai envie de dire qu'il y a aussi polarssl…
[^] # Re: GNU TLS
Posté par Mr Kapouik (site web personnel) . É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 patrick_g (site web personnel) . Évalué à 5.
LGPL pour GnuTLS non ?
[^] # Re: GNU TLS
Posté par Croconux . É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 Firwen (site web personnel) . Évalué à 10. Dernière modification le 22 avril 2014 à 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 mickabouille . Évalué à 2.
Je croyais que la GPL était compatible avec le LGPL. C'est un problème de version de licence ? genre v2 contre v3 ?
[^] # Re: GNU TLS
Posté par Firwen (site web personnel) . Évalué à 10.
Non,
Comme expliqué avec Brio par les Fedoratiens https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#GPL_Compatibility_Matrix
[^] # Re: GNU TLS
Posté par spider-mario . Évalué à 1.
Disons que le code lui-même peut, mais les exécutables qui en résultent sont nécessairement sous GPL.
(Par exemple, les kdelibs ont toujours été sous LGPL, même quand Qt était encore sous GPL.
Re: How come KDELibs can use LGPL?)
[^] # Re: GNU TLS
Posté par diorcety . Évalué à 5.
Pas sur que tout le monde apprécie cmake ou les MAKEFILEs handmade
[^] # Et NSS ?
Posté par TilK . É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 ZeroHeure . Évalué à 9. Dernière modification le 22 avril 2014 à 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 Anonyme . É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 BohwaZ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 23 avril 2014 à 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 BAud (site web personnel) . Évalué à 5.
Tu as loupé le
en bas de page :-)
[^] # Re: libressl.org
Posté par GouNiNi . Évalué à 1. Dernière modification le 25 avril 2014 à 17:35.
OMG! Ils sont quand même bien barrés :D
# et ca compile ?
Posté par NeoX . Évalué à 6.
et ca continue de compiler pour VMS et Windows ?
;)
[^] # Re: et ca compile ?
Posté par ZeroHeure . Évalué à 10.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . É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 Anonyme . É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 mickabouille . É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 barmic . É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 » ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: et ca compile ?
Posté par claudex . É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 Misc (site web personnel) . É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 neil . É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 claudex . Évalué à -1.
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 Joris Dedieu (site web personnel) . Évalué à 7.
openssh.com en l'occurrence
Oui chez djm (at) openbsd.org
[^] # Re: et ca compile ?
Posté par Almacha (site web personnel) . Évalué à 4.
La version portable se trouve bien sur le site officiel de OpenSSH ici : http://www.openssh.com/portable.html
[^] # Re: et ca compile ?
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 22 avril 2014 à 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 patrick_g (site web personnel) . Évalué à 10.
Elle est surtout très ouverte sur les exploits…
[^] # Re: et ca compile ?
Posté par navaati . É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 Joris Dedieu (site web personnel) . Évalué à 10.
Il suffit de porter OpenSSH sous Windows.
Portable ne veut pas dire universel. Portable ne veut pas dire porté. Portable veut dire qui peut être porté.
Utiliser un bibliothèque pour simplifier le job c'est vraiment trop con
[^] # Re: et ca compile ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
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 lasher . É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 :
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()etmutex_unlock()1), et encore mieux, il faudrait « fabriquer » uncompare_and_swapà partir d'untest_and_setsi 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
gccet ses potes (au moinsllvmeticc, 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.Et je ne parle même pas de l'utilisation d'une variable globale… ↩
[^] # Re: et ca compile ?
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 22 avril 2014 à 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 pasBill pasGates . Évalué à 3.
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 neil . Évalué à 10. Dernière modification le 23 avril 2014 à 02:08.
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 Pierre Bourdon . É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 neil . Évalué à 1. Dernière modification le 24 avril 2014 à 15:42.
funopenest une fonction standard dans la famille des BSD, existant notamment sous FreeBSD ou BSD 4.4.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 lasher . É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 (puisquefunopenpeut « jouer » avec les différents flux, alors que faire la même chose directement avec des descripteurs de fichiers etread/writenécessite de maintenir les flux de lecture/écriture complètement séparés).C'est un peu comme
strlcpyetstrlcat. 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,funopendemande un peu plus de cogiter).[^] # Re: et ca compile ?
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 24 avril 2014 à 17:11.
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 lasher . Évalué à 5.
C'est vrai. En même temps, contrairement aux headers sous Linux qui me font devenir chèvre à faire des milliards d'
#includepartout 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 ».
Oui, c'est ce que je voulais dire : pour
funopenpar exemple, il faut clairement pouvoir reproduire la fonctionnalité, ce qui implique écrire une version perso. Idem pourstrlcpyoustrlcat. Pour ces dernières, depuis la publication de C11, il existe les fonctions « bornées » (suffixées par_s, genrestrcpy_s), qui devraient rendre l'écriture triviale (si le compilateur les implémente).[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . Évalué à 3.
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 zul (site web personnel) . Évalué à 9. Dernière modification le 24 avril 2014 à 18:07.
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
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:
Pour le reste, je te laisse troller dans ton coin :)
[^] # Re: et ca compile ?
Posté par Zenitram (site web personnel) . Évalué à -3.
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.
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.
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 zul (site web personnel) . Évalué à 2.
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
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".
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 claudex . Évalué à 0.
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 Frank-N-Furter . Évalué à 2.
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 zul (site web personnel) . É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 Frank-N-Furter . É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 Almacha (site web personnel) . Évalué à 2.
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 laffer . É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 Misc (site web personnel) . É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 Krunch (site web personnel) . É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 Misc (site web personnel) . É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 Prae . É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 laffer . É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 Prae . É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 Enj0lras . É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 claudex . É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 Enj0lras . Évalué à 5.
Tu aurais du essayer d'installer gnome 3 sous freebsd.
[^] # Re: et ca compile ?
Posté par claudex . É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 Enj0lras . Évalué à 7.
Je croyais qu'on était des gens sérieux et que donc on ne trollait pas.
[^] # Re: et ca compile ?
Posté par claudex . Évalué à 0. Dernière modification le 23 avril 2014 à 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 Enj0lras . Évalué à 5.
parlons donc de xfce et de udisks.
[^] # Re: et ca compile ?
Posté par claudex . É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 Enj0lras . Évalué à 4. Dernière modification le 23 avril 2014 à 22:45.
Peut être pourrais tu prendre la peine de relire :
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 claudex . É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 Enj0lras . Évalué à 3. Dernière modification le 23 avril 2014 à 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 Zenitram (site web personnel) . Évalué à -10. Dernière modification le 22 avril 2014 à 08:01.
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.
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…)
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 karchnu . É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 WhiteCat . Évalué à 10.
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 gouttegd . Évalué à 10.
Il paraîtrait que OpenSSL peut aussi être utilisé par des logiciels clients, même sous Windows…
[^] # Re: Donc utile?
Posté par ulver . Évalué à 10.
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 Mr Kapouik (site web personnel) . Évalué à 10.
Beau troll mais tu as oublié un truc :
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 deasy . Évalué à 9.
linux compatible only, pas redhat, là c'est toi qui trolles.
[^] # Re: Donc utile?
Posté par rewind (Mastodon) . É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 devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 22 avril 2014 à 13:36.
Tellement que j'ai moinsé à vue!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Donc utile?
Posté par Toufou (site web personnel) . É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 rakoo (site web personnel) . É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:
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 Anonyme . Évalué à 1.
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 ZeroHeure . É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 Anonyme . É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 Sytoka Modon (site web personnel) . É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 navaati . É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 Thomas Debesse (site web personnel) . É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 Miod in the middle . É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 laffer . É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 barmic . Évalué à 3. Dernière modification le 24 avril 2014 à 11:56.
Utiliser juste un caractère d'espacement c'est pire (mais j'aurais préféré LibreTLS).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Donc utile?
Posté par laffer . É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
[^] # Re: Donc utile?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Il est vrai que WindowsNT := VMS++ ;-)
# Et les algorithmes GOST ?
Posté par gouttegd . Évalué à 10.
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 Mimoza . Évalué à 2. Dernière modification le 22 avril 2014 à 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 Misc (site web personnel) . Évalué à 9.
Donc il faut se concentrer sur les algos apatrides ?
Ça va être chaud, non ?
[^] # Re: Et les algorithmes GOST ?
Posté par moi1392 . É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 Thomas Douillard . É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 khivapia . É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 M . Évalué à 1.
Mais elle a aussi introduit des backdoors dans certains algos : http://en.wikipedia.org/wiki/RSA_BSAFE
[^] # Re: Et les algorithmes GOST ?
Posté par khivapia . É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 Krunch (site web personnel) . É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 lasher . É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 Nonolapéro . É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 Le Gab . É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 patrick_g (site web personnel) . Évalué à 10.
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.
[^] # Re: précédent audit
Posté par Le Gab . Évalué à 3.
Je pense que tu as raison.
# réaction du côté d'OpenSSL
Posté par Adrien . É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 Tonton Th (Mastodon) . Évalué à 2.
http://www.pcinpact.com/news/87143-openssl-cumule-23-000-dons-en-dix-jours-et-accepte-bitcoins.htm
[^] # Re: réaction du côté d'OpenSSL
Posté par gouttegd . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réaction du côté d'OpenSSL
Posté par steph1978 . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réaction du côté d'OpenSSL
Posté par laffer . É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 claudex . É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 anaseto . É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 oinkoink_daotter . Évalué à 3.
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 zul (site web personnel) . É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 claudex . É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 oinkoink_daotter . É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 Antoine . É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 Anonyme . Évalué à 4.
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 ManuxFr (site web personnel) . Évalué à 7.
Et sinon le choix de la police Comic Sans MS faut le prendre comment ? :D
[^] # Re: Police (personne ne bouge)
Posté par Spack . Évalué à 10.
[^] # Re: Police (personne ne bouge)
Posté par ManuxFr (site web personnel) . Évalué à 3.
Oui j'ai vu juste après…
Tout de même étonnent comme technique de financement !
# Rappel journal précédent
Posté par Maxime (site web personnel) . É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.
[^] # Re: Rappel journal précédent
Posté par Nonolapéro . Évalué à 2. Dernière modification le 22 avril 2014 à 12:06.
Où pour consulter les différents contenus en rapport avec OpenSSL, il faut suivre le tag OpenSSL.
# Revue de presse
Posté par SpaceFox (site web personnel, Mastodon) . É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
La connaissance libre : https://zestedesavoir.com
# ...
Posté par M . Évalué à 6.
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 Frank-N-Furter . Évalué à 4.
http://en.wikipedia.org/wiki/Heartbleed#Appearance
Depending on the time of day, the French go either way.
[^] # Re: ...
Posté par Prae . É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 rakoo (site web personnel) . É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 Prae . É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 Antoine . Évalué à 3.
"Personne ne l'utilise" n'empêche pas un attaquant de l'utiliser. C'est bien le problème.
[^] # Re: ...
Posté par Prae . Évalué à 2.
En quoi c'est contradictoire avec ce que je viens de dire ?
[^] # Re: ...
Posté par arnaudus . Évalué à 8.
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 Misc (site web personnel) . É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 Krunch (site web personnel) . É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 zebra3 . É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 Krunch (site web personnel) . É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 zebra3 . É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 ZeroHeure . É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 zebra3 . Évalué à 2. Dernière modification le 24 avril 2014 à 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 Krunch (site web personnel) . É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 Anonyme . Évalué à 7.
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.
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 djano . Évalué à 3.
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 vanille_cafe . É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 Sygne (site web personnel) . Évalué à 5.
Je suppute une petite exagération dans ce propos.
[^] # Re: Implémentation prouvée
Posté par vanille_cafe . É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 zul (site web personnel) . Évalué à 10.
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 Zenitram (site web personnel) . Évalué à -7. Dernière modification le 22 avril 2014 à 15:08.
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 vanille_cafe . É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 Zylabon . Évalué à 6. Dernière modification le 22 avril 2014 à 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 -> intalorsfact = \x :: int -> -42 * xest une implémentation correcte*
fact :: uint -> uintest 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 Zenitram (site web personnel) . Évalué à -10.
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 zul (site web personnel) . É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 _jordan_ . É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 lasher . É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 djano . É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 LeMagicien Garcimore . Évalué à 10.
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 Moonz . Évalué à 6.
À priori ça vient pas des devs OpenBSD en même temps.
[^] # Re: Implémentation prouvée
Posté par LeMagicien Garcimore . Évalué à 1.
Effectivement, mea culpa. Mais ça reste vilain.
[^] # Re: Implémentation prouvée
Posté par Florent Fourcot . É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é ?
[^] # Re: Implémentation prouvée
Posté par Krunch (site web personnel) . Évalué à 8.
Bah si ils utilisent OpenSSL depuis un moment et ils le connaissent assez bien je pense. J'imagine que cette histoire est juste la goutte qui fait déborder le vase.
https://www.peereboom.us/assl/assl/html/openssl.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Libraire != bibliothèque
Posté par olaf . Évalué à 10.
My 2 cents…
# Un petit peu d'histoire...
Posté par gaston . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.