Workshop Open-source et sécurité

Portrait de Tris

Les Labs font leur rentrée avec un workshop dont la thématique sera "Open-source et sécurité : source du mal et/ou ouverture vers le bien ?" Il aura lieu le jeudi 13 septembre 2012 de 17h30 à 19h30 à la Mutinerie.

Le nombre de place étant limité, merci de vous inscrire.

[Edit du 12/09/2012 : Le texte ci-dessous a été rédigé par l'expert Bruno Spiquel, qui animera le workshop]

Lorsque l'intelligence logicielle était captive du matériel, la sécurité informatique était une préoccupation très secondaire voire inexistante.

La séparation du hardware et du software a donnée naissance à la possibilité d'exploiter les failles logicielles. L'open-source a beaucoup facilité cet accès, rendant les failles analysables et exploitables par à peu près n'importe qui.

Pour autant, il semble peu réaliste de revenir en arrière pour enfermer à nouveau le software dans du hardware dans le but de le protéger et l'open-source permet finalement de curer le mal qu'il a lui-même contribué à créer, pour peu que tous se donnent la peine d'entretenir, à leur niveau, leur univers logiciel.

Crédit photo : Tom Merton/Masterfile

Commentaires

Portrait de G.P.

Bonjour,

J'ai quelques questions : à quel public s'adresse cet atelier ? Sera-t-il technique ? Qui organise et introduit le sujet ? Des experts interviendront-ils ? Si oui qui sont-ils ? 

Merci par avance de ces précisions.

G.

Portrait de Tris

Hello :)

> Tout public : tout le monde est le bienvenu.

> Un peu mais le but du jeu est de faire comprendre même à un public non-averti les enjeux de l'open-source, de la sécurité, etc.

> Bruno Spiquel alias Turblog va animer mais la parole reste libre.

> Chacun peut intervenir s'il le souhaite.

Portrait de samir

est il possible de rendre publique la liste des participants, histoire de se faire une idée du "type de public" justement ?

 

Portrait de Tris

Je n'y suis pas spécialement favorable pour être franche :) Je pars plutôt du principe que si les gens ont envie de venir, ils peuvent librement le dire ou non :)

Après, comme je l'ai dit, Bruno Spiquel qui est bien connu de la communauté libriste sera présent :)

Portrait de kerrubin

Bonjour,

Si c'est disponible, y a-t-il un calendrier des workshops ?
Ne serait-ce que les dates ?
Pas forcément lieux ni heures, juste les dates pour ceux qui doivent s'organiser pour pouvoir venir ?

Merci :)

Portrait de Tris

Pas encore car cela va dépendre de beaucoup d'éléments divers :) Tu viens pour la première ? :)

Portrait de kerrubin

Je m'en doute, pour les éléments divers (ou d'hiver ?). Mais des fois que ce soit possible... :)

Pour venir, c'est une bonne question à laquelle je n'ai pas encore de réponse (si ma 1/2 journée est validée), mais ça m'intéresserait !

Portrait de Tris

On commence à 17h30 en tout cas et sache que ça nous fera plaisir que tu viennes :)

Portrait de M.C.

"L'open-source a beaucoup facilité cet accès, rendant les failles analysables et exploitables par à peu près n'importe qui."

Pas besoin des sources pour executer un logiciel malveillant. C'est plutot la libre circulation des logiciels (et des données en général) qui serait plutot a mettre en cause.

Portrait de Tris

A titre tout à fait personnel & ne préjugeant en rien du workshop de jeudi : pas d'accord ! :)

Exécuter un code malveillant n'est pas l'analyser, le décompiler donc ce n'est pas le connaître. L'Open-source permet ce type d'opération et donc permet aussi d'avoir une meilleure maîtrise de ce que tu fais.

Mais si tu veux venir en débattre jeudi, welcome :)

Portrait de Anonyme

Euh Tris, depuis quand l'exploitation de failles de sécurité est du au mouvement Opensource ?

Bien au contraire, quand les sources sont ouvertes, l'intelligence collective permet de corriger rapidement les failles de sécu.

Par contre la décompilation de logiciels privateurs, qui n'a aucun lien avec le mouvement Open Source, permet de trouver des failles, parfois de les exploiter et sont souvent corrigées de façon tardive par les éditeurs.

Vu ton intitulé, il faudrait décalé le workshop d'un journée, le vendredi.

Portrait de Gwenn

Bonjour,

La formulation du workshop me laisse songeur, particulièrement au niveau d'une curieuse séparation entre hardware et software. Aujourd'hui, la vaste majorité des systèmes électroniques est conçue exclusivement sous une forme logicielle, l'implémentation sous forme de matériel n'étant que l'une des options. C'est ainsi qu'un processeur moderne est conçu en tant que logiciel, avec bien évidemment deux implications : 

  • Il est parfaitement possible et courant de publier ce matériel sous une licence open-source, cf OpenCores ou l'Open Hardware Foundation. Il faut également noter l'existence du concept en mécanique via l'impression 3D amateur.
  • Il est tout aussi évident que les failles logicielles existent également dans le matériel, à proportion moindre pour des raisons de sérieux du travail mais avec des conséquences plus drastiques également.

Ce qui nous amène à la considération suivante : dans la mesure où des matériels majeurs comme la PlayStation 3 ou le Pentium V ont vu des failles être relevées par des indépendants, comment peut-on prétendre séparer les préoccupations de sécurité de ces deux types de solution ?

Considérer que le matériel offre une quelconque protection par rapport au logiciel, c'est afficher son ignorance de la conception d'un matériel moderne. Aujourd'hui, toutes les considérations sur le logiciel (sécurité, piratage, brevets, propriété intellectuelle en général) sont immédiatement applicables au matériel, puisque c'est essentiellement une même oeuvre de l'esprit, diffusée différemment (et éventuellement sous forme libre).

Portrait de bruno.spiquel

J'suis content que quelqu'un relève le fond du troll et pas (trop) sa forme :)

C'est précisément tout l'intérêt de l'exercice : produire un document mettant en évidence le fait que le hardware se soit banalisé (le fait qu'il soit possiblement opensource est d'ailleurs à mentionner) et que nous tendons donc vers un monde informatique 100% logiciel.

Reste aussi à disserter sur la relative protection qu'offre l'enfermement dans le hardware.

Portrait de Gwenn

A mon sens, la question est ici mal posée, et c'est justement ce qui me fait réagir. Indépendamment du débat qui s'ensuit sur la nature ouverte ou non, il y a un distinction entre hardware et logiciel qui n'est tout simplement pas valable.

Qu'on s'attaque à un matériel ou à un logiciel, si le composant numérique est faillible une exploitation peut en être faite. Documentez-vous sur la chute du chiffrement de la PlayStation3 : c'est du matériel disponible à tous qui est employé et l'auteur est plutôt un habitué du logiciel, ce qui ne l'a aucunement empêché de casser une protection matérielle.

Comment ? Parce que... C'est la même chose. Il n'y a pas de "relative protection", c'est un mythe qui se fait de plus en plus fragile. On y retrouve exactement les mêmes schémas, en particulier sur la sécurité. Imaginez que des puces sont enfermées dans des blindages pour empêcher leur étude au microscope, obfsuquées matériellement (imaginez des mémoires avec des bits non contigus !) ou encore pourvues d'auto-destruction... 

Portrait de Tris

Je te répondrais bien "c'est pas faux" mais il y en a bien au moins un qui va me demander ce que je n'ai pas compris dans ton commentaire ^^

Plus sérieusement, ça pose la question de rétro-ingénierie dont la légalité dépend du support (logiciel/matériel) mais aussi des brevets/licences qui y sont apposés. Pas simple tout ça...

Portrait de Gwenn

C'est au contraire assez simple : il faut réellement voir les matériels numériques comme des logiciels qu'on a figé dans le silicium. Un exemple ? Le coeur d'un iPhone est écrit dans le même language que certaines parties de votre navigateur Web.

Les conséquences sont en revanche énormes : les processeurs d'aujourd'hui sont vendus sous forme logicielle autant que sous forme matérielle, laissant au client la charge de le produire physiquement avec d'éventuelles modifications ; et on entre dans les mêmes modèles et problèmes que le logiciel : copie, redistribution, open-source, brevets...

Portrait de Tris

D'accord mais quand le logiciel est open-source/libre mais qu'il existe sur le matériel des brevets, tu ne peux pas les démonter.

Exemple concret : il y a quelque chose chez moi que je rêvais de démonter pour trifouiller à l'intérieur, voir les composants, comprendre l'assemblage et boom ! Brevets (prpriété industrielle donc) attachés au matériel => interdit de le démonter sinon ça devient illicite.

Ouin ! :'(

Portrait de Gwenn

Je ne suis pas un expert légal mais à ma connaissance, le reverse-engineering en lui-même n'a rien d'illégal. Ce qui l'est, c'est l'utilisation sans licence d'une technologie brevetée. Le brevet n'a rien de secret, c'est justement le contraire : divulgation publique du secret contre obligation de licence en cas d'utilisation commerciale.

Portrait de Tris

Ben oui & non justement :s

Ca dépend de pas mal de paramètres, je pense que j'en ferais un bref rappel demain pendant le workshop

Portrait de bruno.spiquel

D'ou le mot "relatif" dans l'intitulé :)

Portrait de Antares

C'est bizarre mais je dirais plutot que le fait que le code soit accessible permet justement à une plus grande communauté de le vérifier et de colmater les brêches.

Parce que jusqu'a maintenant il me semble que les systèmes fermés ne sont pas vraiment protégé contre les failles, et que certains les laissent vivre leur vie après avoir été avertis.

"Pas vu, pas pris".

Portrait de Eburon

La description du workshop me semble bien fumeuse... à priori il y a amalgame entre les concepts de sécurité informatique et protection de secrets via DRM liés à des méthodes hardware.

L'open-source en lui-même n'a pas grand chose à voir avec ce débat: dès qu'un logiciel open-source ou non contient un secret (clef de déchiffrage, certificat, ...), il est possible d'extraire ce secret. Cela a déjà été démontré pour les logiciels commerciaux permettant de lire les dvd et blu-rays.

Contrairement aux sujets de sécurité informatique, où l'utilisateur gère ses secrets (clefs/certificats/mots de passe), l'approche DRM tente de protéger une ressource contre l'utilisateur, en tentant de dissimuler des secrets pour que ce dernier ne puisse pas y accéder. Cette approche repose sur un périmètre de-facto compromis et est vouée à l'échec.

Portrait de bruno.spiquel

La fumisterie déclanche le débat. J'en veux pour preuve les quelques contributions fort pertinentes déposées sur la présente page :)

La montée en puissance de l'opensource coincide avec la montée en puissance de la découverte et de l'exploitation de failles de sécurité. Relation de cause à effet ou pas, telle est la question.

Il n'y a, par contre, aucune histoire de DRM dans le workshop. Quand je parle de logiciel captif du materiel, je penses surtout à toutes les applications embarquées qui étaient légion il y a une 20aine d'année et qui se font beaucoup plus rares de nos jours de par la banalisation des CPU-à-tout-faire ou on préfère coller un ATOM et du software dans un distributeur de billet plutôt qu'un ATMEL avec une ROM aux fesses conçue pour assurer la mission du DAB.

Portrait de Gwenn

Parce qu'un processeur Atmel avec une ROM ce n'est pas du logiciel ? C'est une définition bien curieuse, surtout qu'un DAB ne relève que péniblement de l'embarqué. Par ailleurs, si vous croyez que l'embarqué est un domaine en perte de vitesse, c'est se tromper lourdement car il est au contraire en pleine explosion avec l'avènement des systèmes mobiles et connectés.

La montée en puissance des plateformes génériques est par ailleurs une certaine illusion quand on voit le nombre d'entreprise qui ont aujourd'hui leur propre ASIC ARM, à commencer par mes différents employeurs : on a juste de plus en plus de blocs IP génériques communs à différentes entreprises à cause la complexité croissante.

Le fait est que les failles de sécurité touchent indiféremment matériel et logiciel, open-source et propriétaire. Partant de ce simple constat, je ne comprends que très mal l'énoncé du workshop qui relève à mon sens à la fois d'une méconnaissance technique et d'un parti pris.

Portrait de bruno.spiquel

C'est du logiciel que jean-kevin devant son PC n'ira pas regarder (ni même probablement se douter qu'il est là)

Après, si l'énnoncé est mal posé, il suffit de venir le poser mieux que ça en début de réunion, histoire que le document qui en résultera colle à la réalité.

Le but de l'opération étant de produire quelque chose, on m'excusera si je n'ai pas fait tout le boulot de recherche pouvant mener au document final .. Mais si je l'avais fais, je vois mal quelle utilité aurait le workshop :)

Portrait de Gwenn

Et pourtant, c'est du logiciel que les Jean-Kevin manipulent eux aussi, si c'est ainsi que vous nommez les développeurs amateur. L'immense succès des plateformes Raspberry, Beagleboard ou Arduino devrait vous en convaincre (en logiciel embarqué) de même qu'Opencores ou Sparkfun (en matériel). Ce n'est ni rare ni réservé à une élite, on trouve des cours sur le sujet jsuque sur le Site du Zéro.

En ce qui me concerne, je suis d'avis que la formulation actuelle de ce workshop repose sur une double erreur : celle de distinguer matériel et logiciel, et celle de croire que la diffusion des sources a un impact sur la sécurité, alors que les éditeurs de logiciels de sécurité sont unanimes pour affirmer que le seul vrai facteur de découverte et exploitation de failles, c'est le nombre d'utilisateurs...

C'est intéressant de débattre du libre, et certaines questions sont extrêmement importantes notamment sur les brevets ou la PI en général. Et prétendre que le libre est plus sûr que le propriétaire est, au mieux, hasardeux. En revanche, les hypothèses de cette discussion sont foncièrement erronnées, c'est un fait.

Portrait de Eburon

Le but de l'opération étant de produire quelque chose, on m'excusera si je n'ai pas fait tout le boulot de recherche pouvant mener au document final ..

Faire le boulot menant à un intitulé et un cadre de discussion de qualité aurait déjà été intéressant. Quel public essayez-vous de recruter pour ce workshop avec un tel préambule?

D'ailleurs votre réponse précédente ne me rassure pas :

La montée en puissance de l'opensource coïncide avec la montée en puissance de la découverte et de l'exploitation de failles de sécurité. Relation de cause à effet ou pas, telle est la question.

La question que je me pose, c'est pourquoi une telle question? La première partie ressemble à une affirmation gratuite non étayée sous-entendant d'entrée de jeu que le grand suspect des problèmes actuels de sécurité viennent de l'open-source... soit vous faites ce genre de déclaration dans le but de déclencher la polémique facile qui risque bien de ne pas s'élever au dessus du débat de comptoir, soit vous avez réellement cette perception de l'évolution des problématiques de sécurité (et faites fi des statistiques), et là le débat ne va pas non-plus être très intéressant.

Reste qu'au final, je m'étonne de l'entrée en matière et m'interroge sur la finalité de ce workshop dans les processus de l'HADOPI.

Portrait de bruno.spiquel

Concernant le public, recruter des gens qui étaye comme il faut et savent débattre (comme vous, par exemple :)) est une bonne cible, me semble-t-il.

Concernant l'affirmation gratuite et non étayée, puis-je suggérer une 3ème voie ? Permettre aux gens qui n'ont pas pensé le problème d'y être confronté (un peu violament, j'en convient) pour arriver rapidement au vif du sujet. Le fait de poster une invitation déguisée en troll une semaine avant permet de défricher le terrain (merci) pour être dans le sujet pertinent le jour J

Quant aux processus hadopi, nous sommes dans les labs ici, et ce workshop ne fait pas l'objet d'une commande de la haute autorité ni partie d'un plus grand ensemble obscur destiné à dénigrer le LL comme certains le sous-entende. J'ai simplement entendu beaucoup de gens tergiverser sur les hypothèse qui découlent du sujet et j'ai eu envie qu'un document étayé et éclairé soit fait.

Si la conclusion pouvait être "le LL permet l'amélioration du logiciel et donc une sécurité accrue", ça m'arrangerai bien, mais on verra demain soir.

Portrait de mmu_man

Exactement, le DRM sert à protéger des données vis-à-vis de l'utilisateur, et sur sa propre machine en plus. Non seulement c'est éthiquement dangereux mais c'est illusoire. Les DRM sont défectueux par nature : http://www.defectivebydesign.org/

Mais justement, ça concerne tout à fait le logiciel libre, puisque justement le principe même du DRM est incompatible avec la notion même de code source ouvert. J'attends toujours qu'on me montre une preuve formelle (ie. mathématiquement correcte) qu'on peut faire un DRM en logiciel libre... or exclure les utilisateurs de logiciels libres en imposant un DRM c'est tout simplement une discrimination inacceptable.

Portrait de mmu_man

L'intitulé est tout simplement grotesque.

Il suffit de compter les failles dans Windows pour avoir la preuve que le l'opensource (le libre c mieux mais bon) n'est absolument pas une cause de moindre sécurité. Et les virus existaient sous MSDOS ou AmigaOS bien avant que GNU/Linux soit connu du grand public. Bien au contraire de nombreuses études montrent que la possibilité de revue par les pairs permet d'augmenter la sécurité, ce qui est impossible avec les logiciels privateurs qui sont juste des boites noires (mais que les pirates arrivent de toute façon à décompiler). Même le Département de la Défence américain le dit : http://manoharbhattarai.wordpress.com/2010/07/24/why-free-software-is-more-secure/

Un tel intitulé est juste diffamant envers les auteurs de logiciels libres.

Portrait de Tris

Ce qui est grostesque, c'est la réaction disproportionné que tu as. Il n'est absolument pas question de diffamer qui que ce soit, ni le travail de qui que ce soit. Non seulement l'intitulé du workshop n'est pas une injure à la communauté du libre, mais ne l'est également pas le contenu ni même les commentaires.

Et si tu as le moindre doute sur les propos que l'on va tenir pendant le workshop, tu peux aussi venir, plutôt que de nous faire un procès d'intention par écran interposé :)

Portrait de Calibhaan

Je ne trouve pas disproportionné sa réaction.

Personnellement en lisant au premier degré le texte, je tends à penser plusieurs choses

  1. La personne qui écrit ça ne connait absolument pas le sujet
  2. La personne qui écrit ça nous indique que l’obscur est mieux que le transparent
  3. Qu'il est téléphoné que le 'débat' conclura qu'un système à la Apple est ce qu'il y a de mieux.

Pourtant les personnes qui se joignent à des projets d'open source sont extrêmement compétent dans leur domaine et permettent une meilleure sécurité qu'un système obscure développé pas forcement par les pointures des technologies employées...

Tout ça pour dire qu'en lisant la description cela ne donne pas trop envie de venir, car on s'attend à entendre des inepties...

Portrait de kerrubin

D'un autre coté, en s'arrêtant justement à la description et en boudant bêtement pour une question de mots, cela veut dire qu'il n'y aura pas d'avis contraire et que potentiellement, on pourra troller un maximum sur l'open source sans avoir personne pour nous contredire.

Si elle est pas belle, la vie...

Portrait de Winael

@Tris,

Le contenu même de l'intitulé, la manière dont il est rédigé, influence déjà en lui même le débat. On est sur des idées reçues proche d'un sitcom de Disney Channel. Si c'est pour faire réagir la communauté du Libre et de l'OpenSource, c'est pas en faisant du troll de bas étage que les workshop d'Hadopi vont attirer les défenseurs du modèle ouvert. Au contraire c'est encore les braquer.

Si comme indiqué dans la réponse à Korben sur twitter que le but est de prouver que l'opensource est la solution pour la sécurité informatique, alors l'intitulé est totalement à côté de la plaque. Il aurait mieux fallu souligner que publier les sources entraine de facto un climat de confiance, plutôt que d'attribuer le fait d'exploiter des failles de sécu à la mentalité hacker (les bidouilleurs qui partagent et ont le sens de la transparence et du travailler ensemble), qui est juste une ineptie intellectuelle dont seul Disney a le secret. Il serait donc de bon ton, qu'une autorité représentant la position de l'Etat bien que (pseudo) indépendante, fasse preuve d'un peu de sérieux.

Portrait de bruno.spiquel

Cool, t'as écrit la conclusion du doc !

Tu viens écrire le contenu, histoire de remplacer "il suffit de" par un truc un peu plus ... consistant ? :)

Portrait de ouaip

Il faut quand même reconnaître qu'en lisant l'accroche - qui est bel et bien une affirmation n'est-ce pas - on peu se demander si c'est bien un débat qu'il faut pour désamorcer ce genre d'idées pas très intelligentes.

 

"Lorsque l'intelligence logicielle était captive du matériel, la sécurité informatique était une préoccupation très secondaire voire inexistante."

Ceci est une bêtise, déjà.

"L'open-source a beaucoup facilité cet accès, rendant les failles analysables et exploitables par à peu près n'importe qui."

En voilà une plus affligeante encore.

Non vraiment ça donne pas envie.

 

Portrait de Yarglah

"L'open-source a beaucoup facilité cet accès, rendant les failles analysables et exploitables par à peu près n'importe qui."

Ben tiens.... Le revival de la "sécurité par l'obscurité"

Ca donne pas vraiment envie de discuter de quoi que ce soit apres une telle assertion-troll.

 

Portrait de Boudin

 

Je ne comprend pas trop ce débat, il me semble biaisé de base. La sécurité est quelque-chose de conceptuel/théorique. Son implémentation, qu'elle soit hardware ou software n'est qu'une mise en oeuvre. Une sécurité basée sur la non divulgation de son fonctionnement est considéré comme défaillante (c'est même la première chose qu'on apprend à l'école). Si la simple divulgation de celle-ci suffit à la casser, alors ce n'est pas quelque-chose de sécurisé.
 
L'open-source est source d'ouverture, source de liberté, mais absolument pas de mal, je ne vois aucun exemple, historiquement parlant, illustrant ce postulat. Si quelqu'un peut m'éclairer à ce niveau...
 
Le vrai débat c'est qu'un logiciel fermé ne sécurise pas plus qu'un logiciel ouvert. Un logiciel ouvert permet une revue de code par un maximum de personne, donc une meilleur réactivité, une meilleur communication sur les problèmes potentiels, ainsi qu'une obligation de transparence. Quel arguments, autres que juridiques, justifient de ne pas ouvrir les portions de codes en question ?
Portrait de canard_jaune

Bonjour Tris,

Ce texte me perturbe énormement :(

"Lorsque l'intelligence logicielle était captive du matériel, la sécurité informatique était une préoccupation très secondaire voire inexistante."

Le matériel est aussi sensible aux failles que le logiciel, c'est juste la manière de les exploiter qui diffère (en utilisant un FPGA par exemple).

"La séparation du hardware et du software a donnée naissance à la possibilité d'exploiter les failles logicielles."

Les failles informatiques étaient exploitées bien avant cette séparation (ex : cartes téléphoniques, le démodulateur de canal plus...). Cependant la distinction entre faille logicielle et faille matérielle n'avais pas vraiment de sens.

"L'open-source a beaucoup facilité cet accès, rendant les failles analysables et exploitables par à peu près n'importe qui."

Pas vraiment. Il faut un minimum de connaissances pour analyser du code et encore plus pour développer un exploit. Aussi, n'importe qui avec un minimum de connaissances peut lancer un fuzzer sur un logiciel closed-souce pour débusquer des failles de sécurité afin de les exploiter ensuite.

"Pour autant, il semble peu réaliste de revenir en arrière pour enfermer à nouveau le software dans du hardware dans le but de le protéger"

Encore une fois, la protection matérielle ne corrige pas les failles logicielles. Elle change juste la manière de les exploiter.

"et l'open-source permet finalement de curer le mal qu'il a lui-même contribué à créer, "

Vous luttez contre le mauvais « mal » alors. La publication ou non du code source est en marge du besoin de sécurité du logiciel. Le secret a peut-être pour effet de donner une impression de sécurité mais son efficacité n’a jamais été démontré.

Que les sources soient ouverts ou fermés le niveau de sécurité du logiciel dépend principalement de la solidité des choix de conception et d’implémentation (méthodes de sécurité solides, architecture minimisant les risques, lignes directrices de programmation) et surtout de la fréquence et la qualité de la maintenance du logiciel.

Google Chrome est un des exemple connu de logiciel pensé pour la sécurité; même si il contient des failles, son architecture est telle qu'elles sont très difficiles à exploiter, et son rithme de mise à jour soutenu fait que les exploits deviennent vite obsolète. (ceci n'est pas une pub, d'ailleurs j'utilise Firefox pour vous écrire !)

"pour peu que tous se donnent la peine d'entretenir, à leur niveau, leur univers logiciel.

Crédit photo : Tom Merton/Masterfile"

Merci Tom, et merci Tris … je suppose…

 

Portrait de Tris

[Message de service n°1] Au vu de vos commentaires, il semblerait qu'il y ait eu une légère confusion.

Le texte introductif du workshop a été rédigé par Bruno Spiquel, qui est l'expert qui animera ce workshop. 

Dans la mesure où ce sont ses propos et son point de vue, je lui laisse le soin de les expliquer :)

[Message de service n°2] Si le souhait de cette plateforme et de ce workshop est que la parole soit la plus libre possible, elle n'exclue néanmoins pas une certaine forme de respect mutuel. Les commentaires légèrement injurieux ne seront donc pas visibles.

[Message de service n°3] Merci en tout cas à vous tous d'avoir réagi, commenté. Il y a aura un petit compte-rendu synthétique après le workshop.

 

Portrait de Tris

Si tu veux que je puisse valider tes commentaires, essaie d'être un peu plus mesuré s'il te plaît :)

Et modératrice s'il te plaît ;)

 

Portrait de kerrubin

D'ailleurs, question qui me taraude : à quel public est destiné le travail qui va être fournit ?
La réponse peut (peut être) apporter un éclairage différent sur la manière dont a été posé le pitch de base.

 

Et pour tous ceux qui râlent : il reste 12 places disponibles pour faire entendre vos critiques argumentées (et non critiques gratuites) et pour en discuter (de façon saine et mesurée, le combat dans la boue, fusse-t-il intéressant n'est visiblement pas programmé).

Portrait de Tris

Hello et merci :)

En fait c'est destiné à tous le monde. A mon sens - et Bruno donnera son opinion sur le sujet - la question de la sécurité et sa maîtrise à travers des outils libres & open-source concerne tout le monde. Le but du "jeu" sera de faire en sorte que l'ensemble soit techniquement correct MAIS accessible au plus grand nombre.

:)

Portrait de kerrubin

 

Coucou et de rien :)

 

Je me demandais ça parce que :
"L'open-source a beaucoup facilité cet accès, rendant les failles analysables et exploitables par à peu près n'importe qui."
Est une phrase que j'ai déjà entendue (du moins pour le sens) chez des clients.
Et avant que des ayatollahs crient à l'hérésie et appelent au meurtre, il faut savoir que l'informatique n'est pas le métier les-dits clients et donc leurs connaissances limitées (que ce soit voulu ou non).

 

Il y a un défaut d'information dans certaines structures professionnelles (ce qui est sans doute également valable chez les particuliers) et ce n'est visiblement pas les organismes de "sensibilisation à l'open source" qui les aident (ce n'est pas ceux qui gueulent le plus qui assurent la meilleure information).

Portrait de Tris

Pas la peine de t'acharner.

Tant que tu continueras à tenir ces propos que je me refuse à retranscrire, tes commentaires resteront invisibles pour le reste des lecteurs/commentateurs.

La liberté d'expression n'autorise ni les insultes, ni les accusations gratuites et sans fondements. Et tes récriminations personnelles envers certaines entités ne nous concerne pas.

Portrait de bruno.spiquel

Bonsoir à tous,

Merci pour vos (nombreuses) réactions (y compris les non validées). Vous avez bien noté le sujet trollesque et les affirmations à l'emporte pièce. Vous avez bien noté qu'on les entendais dès 1980/90, vous vous doutez qu'on les entends encore.

A qui est destiné le doc ? A ceux qui voudront bien le lire, et, en priorité, comme tout ce qui est fait aux labs, à l'hadopi et aux politiques qui tournent autour. Ceux qui écoutent finalement beaucoup ce qui se dit, surtout ce qui se dit fort. Et ce qui se dit contient justement ces affirmations (et d'autres) qui sont, pour grande partie, fausses.

Le but du document est d'expliquer pourquoi elles sont fausses, dans des mots accessibles et néanmoins précis, et pourquoi le LL est une chance.

Je me permettrais, sauf avis contraires des interessés, de faire demain soir un récapitulatif de ce qui s'est dit ici, ça sera une très bonne base de travail.

Portrait de jean-

Bonjour.

Ayant suivi les échanges au-dessus, et étant curieux de savoir ce qui s'était dit pendant l'atelier, j'ai cherché le document de synthèse, que je n'ai pas trouvé. Avez-vous une date de publication prévue ?

Bien à vous.

Portrait de Tris

Hello :)

En fait, on a laissé aux participants la possibilité de faire des ajouts pendant le week-end s'ils le souhaitaient. Je m'attaque à la synthèse demain et normalement dans la semaine, en Wiki, ça sera publié :)