Commentaires : Non, un logiciel open source n'est pas forcément plus sécurisé

Débat sur l'actu
21

le propriétaire n’est pas plus sûre.

Le problème est toujours la vision libriste que les utilisateurs peuvent vérifier.
Désolé mais je ne suis pas dev et le code n’est pas mon truc. De même quand vous allez acheter une voiture, vous n’ allez pas être capable de voir des choses que je vois par mon métier de concepteur meca.
Au bout d’un moment, on fait un mini confiance, et je suis sûre que pleins de projets open sources ne sont pas relus par d’autres dev. Tout comme on sait que des boites type facebook et quasi toutes les app de smartphones prennent des données.

L’open source dsl mais tous les collègues informaticiens sur mes sites l’argument de sécurité est aussi dans leurs mots. Sauf que la part de distrib linux face a windows (hors server) est très faible donc pas forcément rentable de les chercher pour les pirates. Et à voir l’argent et temps dépensé par des grosses boite de secu et espionnage pour surveiller et découvrir les failles windows par rapport à des os open sources

22

Au bout d’un moment, on fait un mini confiance, et je suis sûre que pleins de projets open sources ne sont pas relus par d’autres dev. Tout comme on sait que des boites type facebook et quasi toutes les app de smartphones prennent des données.

Les développeur sont souvent surpris du contraire. Au point de se demander quelle est la motivation de certains de passer autant de temps à relire le code des autres. Mais le fait est que le monde de l’open source est très actif et il suffit d’aller voir sur des sites comme Github, gitlab (et d’autres) pour comprendre que ce n’est pas un mythe.

Mais il existe des raisons concrètes à cela, l’open source est un monde ou la valeur d’un développeur se juge aussi à ses interventions sur des projets. Autrement dit, celui qui trouve des failles dans des logiciels, c’est très bon pour son CV s’il veut bosser dans la sécurité.

On se rapproche un peu du système qui prévalait dans le compagnonnage des temps ancien, ou la valeur d’une personne se jugeait à ce qu’il avait fait.

Ajoutons que de nombreuses entreprises, mais aussi des agences de sécurité gouvernementales ont intérêt à contribuer pour diverses raisons.

L’open source dsl mais tous les collègues informaticiens sur mes sites l’argument de sécurité est aussi dans leurs mots. Sauf que la part de distrib linux face a windows (hors server) est très faible donc pas forcément rentable de les chercher pour les pirates. Et à voir l’argent et temps dépensé par des grosses boite de secu et espionnage pour surveiller et découvrir les failles windows par rapport à des os open sources

Le grand public se trompe en pensant que l’informatique n’est faite que de ce qu’il voit.

C’est oublier que dans l’informatique moderne, beaucoup de logiciels tournent « dans le cloud » et qu’une grande partie des données de valeur sont justement sur des serveurs.

Si un hacker parvient à pirater le PC de madame michu, il aura peut être accès à son compte. Mais s’il parvient à pirater les serveurs de la banque, il aura accès à tous les comptes.

Des serveurs qui sont donc des cibles extrêmement prisés(et attaqués) par les hackers, car ils contiennent bien plus de données précieuses que le PC de tata michu.

Et les parts de marché de Linux sur les serveurs sont très élevées, c’est dire à quel point le libre n’a vraiment rien à prouver sur le plan de la sécurité.

Le problème est toujours la vision libriste que les utilisateurs peuvent vérifier.
Désolé mais je ne suis pas dev et le code n’est pas mon truc. De même quand vous allez acheter une voiture, vous n’ allez pas être capable de voir des choses que je vois par mon métier de concepteur meca.

Je fais partie d’un club de mécanique. Et s’il y a un domaine qui gagnerait beaucoup à s’enrichir des retours communautaires, c’est bien celui la conception automobile.

Quand vous voyez des voitures ou il faut démonter la face avant pour changer une simple ampoule, vous comprenez qu’il y aurait beaucoup de choses à améliorer. Ce qu’une communauté ne manquerait pas de faire.

Mais ne vous inquiétez pas, la culture libre commence à s’attaquer à la conception des objets matériels.

1 « J'aime »
23

Les applications serveur pour Windows ACCEPTABLE, c’est rare, parce que Windows c’est pour les utilisateurs finaux.
Et encore, dans ma boite c’est au choix, Windows 10 ou CENTOS-Like, linux fait un ravage. :slight_smile:

Windows a fait des efforts de fout avec PowerShell, mais rien de mieux de gerer un Linux avec un SSH avec ANSIBLE par dessus pour l’exemple, La ou Windows ça passe sur des outils Microsft, fragile niveau config, peu orchestrable dans une infra, même avec des GPO.

Un Windows Serveur, ça marche pour provider des services Microsoft dans un environnement fermer des réseaux mondiaux, pour l’utilisateur final.

1 « J'aime »
24

La question que je me pose depuis le début, c’est est-ce qu’il faut avoir un doctorat issu d’un laboratoire certifié CNRS en cyber-sécurité pour pouvoir être développeur ? Bien sûr que non.

Après, tout se corrige. C’est même une gloire que de dire que l’on a pu colmater telle ou telle faille ou que l’on a pu bloquer tel ou tel groupe de hackers et de le faire publier.

Que ferait-on sans les hackers ? :smiley:

25

Oui
Bien sur
Tout à fait
Evidemment

Là je suis pas d’accord. Dans l’absolu, çà serait bien mais dans la pratique çà ne fonctionne pas comme çà. C’est le principe même des dépendances.
Ma petite expérience de 24 ans de Linux me fait dire que si çà marchait si bien et que tous les acteurs mettaient à jour leur logiciel, on n’aurait pas inventé les SNAP, FLATPAK pour intégrer les dépendances.

Car oui, à un instant T, çà fonctionne et si un seul logiciel traine à se mettre à jour et c’est toute ta distribution Linux qui ne peux plus se mettre à jour.

26

Combien de personnes sur la terre tout entière souhaite bosser dans la sécurité ?

Logiciel libre ou propriétaire, c’est pareil de ce point de vue.

Depuis que le numérique existe, Oui bien sur. Elles font confiance à Windows, Office, Exchange et toute la panoplie de microsoft.
Certaines administration sont à utiliser Libre Office ou OpenOffice mais disposent des fois de Word et Excel parceque çà fonctionne mieux. hihi

Oui et non. L’histoire des premiers serveurs linux et du grand déploiement de ce système n’est pas vraiment lié à une meilleure sécurité mais plutôt à une meilleure disponibilité des ressources, une simplicité de mise en oeuvre et la possibilité pour certains serveurs de ne jamais avoir besoin de redémarrer (serveurs d’impression par exemple).
Chose que Windows serveur ne sait pas faire. Au bout de centaines d’heures de fonctionnement, il faut redémarrer sinon le système sature, rame, et pour les mises à jour ou l’installation d’un nouveau logiciel, il fallait redémarrer systématiquement.
Linux ne demande à redémarrer que si le noyau est touché et un redémarrage est très très rapide.

Heureusement que çà existe le libre. Aujourd’hui, on commence à trouver toute sorte de plans et fichiers 3D pour recréer soi même des pièces en impression 3D.
C’est le balbutiement de cette technologie. On va attendre quelques années pour que çà évolue avec une obligation de fournir les plans.

27

Très actif le monde de l open source c est relatif, ça fait plus de 10ans que gimp évolue pas,alors que pleins de solutions proprio sont arrivés avec des outils comme du détourage auto,…
En audio alors là les projets sont morts a tel point qu il y a plus de gens qui code pour reaper qu un adour ou autres, en quelques années des soft proprio sont déjà loin devant que des soft open sources bien plus vieux.
Et on peut le faire pour pas mal de chose.
Si il n y a pas une organisation type Mozilla, canonical, oracle… Les soft open sources n évolue peu

28

Pas complètement.

Celui qui a travaillé sur des logiciels propriétaires, il peut le mettre sur son CV, mais non seulement on devra le croire sur parole, mais en plus on ne pourra pas voir dans quelle mesure il a contribué au logiciel et comment est son code.

Alors que celui qui a contribué à l’open source, on peut aller regarder comment est son code, l’importance et la complexité de ses contributions, et même éventuellement voir comment il interagit avec les autres contributeurs (via les discussions publiques sur les issues et les PR).

1 « J'aime »
29

@benbart
Etude très complète mais pour résumer en 2 mots, j’ai toujours pensé que le principe même de l’Open Source et de la réutilisation de briques d’origine multiples, était plutôt la source d’insécurité et d’instabilité de logiciels. C’est comme le communisme: une très belle idée dans le principe mais source de grosses dérives dans les faits.

30

Euh, c’est acté que la « la réutilisation de briques d’origine multiples » est tout aussi vrai dans le propriétaire que dans le libre…

1 « J'aime »
31

« Apres une journée de boulot, ils ont peut-être autre chose à faire ».
L’Open source peut être maintenu par des particuliers après le boulot c’est vrai, mais également par des entreprises (style React avec FaceBook, Golang avec Google etc …) ou des freelances qui vivent avec des sponsors.
L’Open source ne veut pas forcément dire gratuit et si l’on utilise de tels projets il est souvent possible de rémunérer le développement.

Pour revenir au sujet, je pense qu’il est tout simplement impossible d’affirmer que l’Opensource et d’avantage ou moins sécurisé.

Dépendre d’une techno propriétaire qui finit par disparaître (Flash, Silverlight?) ou dépendre de projets open source qui ne sont plus maintenus, dans tous les cas c’est assez problématique. Il est vrai qu’il sera toujours possible de faire un fork dans l’Open Source.
Avoir un poste de travail qui n’est pas mis à jour par choix ou par nécessité, qu’il soit sous un OS propriétaire ou pas, le problème est le même …

Dans tous les cas, pouvoir partager quand c’est possible son savoir, ses idées. Je trouve l’idée louable et c’est très formateur :slight_smile:

32

Hello « World »

C’est l’instruction la plus sécure que je connaisse. Il n’y a pas de failles… :stuck_out_tongue:

33

Je dirai même qu’aujourd’hui l’écrasante majorité du code open source est écrit par des gens rémunérés pour. Et heureusement d’ailleurs… Le bénévolat, c’est bien joli, mais ça ne remplis pas l’assiette.

Sur tous les projets open source sur lesquels j’ai travaillé et du coup eu l’occasion de faire un peu attention à qui sont les principaux mainteneurs, j’ai pu constater que ces principaux mainteneurs étaient rémunérés par leur employeur pour faire ce travail.

On connait bien sûr des exemples emblématiques, comme ceux que tu as cités, où une entreprise est carrément directement derrière le projet open source, qu’elle a créé. Mais même sur des projets qui ne sont pas créés à la base par une entreprise, on retrouve au final la même chose. Par exemple, Go a été fondé par Google, donc tout le monde sait que Google est le principal contributeur/financeur de Go, mais, c’est moins connu, Google a aussi énormément fait pour Python, qui est un projet indépendant de Google : le fondateur et gros contributeur Guido van Rossum a été embauché par Google et a travaillé sur Python pendant des années pour travailler sur Python.

Et sur certains projets, on peut trouver des stats de temps en temps, qui confirment bien ça. Par exemple sur le noyau Linux version 5.10, il y a peine 5.9% des commits (4% des lignes de code) qui ont été réalisés par des gens identifiés comme non affiliés à une entreprise (et 6.6% des commits / 5.3% du code par des gens dont on ignore s’ils sont affiliés ou non à une entreprise).

34

tout à fait vrai et peu rassurant

35

Carrément !!!

Dans les fait les gros projets open source ne sont jamais gratuit, d’une manière ou d’une autre tu participes au financement, aux tests, en numéraire, en spécification, en compétences diverses. C’est très souvent en temps humain !!!

A l’inverse faire toutes ces tâches sur des logiciels payants… pour certain pourquoi pas mais d’autres c’est anormal !

36

Elles sont juste moins dans le viseur des pirates…

37

Là je suis pas d’accord. Dans l’absolu, çà serait bien mais dans la pratique çà ne fonctionne pas comme çà. C’est le principe même des dépendances.
Car oui, à un instant T, çà fonctionne et si un seul logiciel traine à se mettre à jour et c’est toute ta distribution Linux qui ne peux plus se mettre à jour.

Non, car il y a deux choses différentes qu’il ne faut pas confondre. La première, c’est l’évolution fonctionnelle des logiciels vers des versions plus récentes. La seconde, c’est la correction des failles de sécurité (ce dont nous parlons ici).

Si vous mettez à jour une dépendance vers une version plus récente, vous avez effectivement de chances de rencontrer les problèmes que vous mentionnez.

Mais si vous gardez le code de la dépendance dans sa version actuelle en lui appliquant juste un patch de sécurité colmatant la faille, vous n’en rencontrerez pas.

Sur les distributions de type « rolling release », on préfère la première option, en essayant de tenir à jour le maximum de logiciel dans leur dernière version. Dans les distributions stables, on préfère appliquer la seconde.

Ma petite expérience de 24 ans de Linux me fait dire que si çà marchait si bien et que tous les acteurs mettaient à jour leur logiciel, on n’aurait pas inventé les SNAP, FLATPAK pour intégrer les dépendances.

Alors il faut comprendre qu’au départ, tout viens d’une très grande force du logiciel libre : les distributions Linux possède tous les codes sources des logiciels, ce qui rends possible une chose que seul le monde libre peut faire : de compiler un maximum de logiciels avec une version unique des dépendances.

A la clé, une optimisation magistrale : l’occupation disque est réduite, ainsi que l’occupation en mémoire vive puisqu’on évite d’avoir plusieurs versions d’une même bibliothèque simultanément en mémoire. C’est l’une des choses qui rendent les distributions linux si légères.

Mais cet avantage amène aussi quelques inconvénients. Ajouté au grand nombre de distributions (et de versions des distributions), cela complique l’installation de logiciels récents, parce qu’une version récente d’un logiciel peut parfois demander une dépendance plus récente.

Bien sûr, il y a des backports et autres dépots gérés par les développeurs. Mais c’est lourd, cela demande du travail et multiplié par le nombre de distributions et de versions existantes, c’est difficile à gérer.

Alors il est vrai que pour 95% des logiciels d’un système, ça ne pose pas problème, car les utilisateurs se moquent totalement d’avoir la dernière version en date. Et que ça fait parfois même parti des requis pour la stabilité.

Mais pour une petite partie des logiciels, c’est un problème. Il existe des logiciels dont il est important d’utiliser la dernière version, par exemple parce qu’elle offre des évolutions fonctionnelles intéressantes.

C’est aussi un problème pour les logiciels propriétaires, parce que c’est le développeur qui doit se taper le boulot pour tourner sur toutes les versions de toutes les distributions.

D’ou l’invention des logiciels encapsulés pour apporter plus de souplesse, de liberté et une possibilité supplémentaire à l’utilisateur.

Mais il faut bien comprendre ce que cela apporte et pourquoi cela n’a pas vocation à remplacer les formats de paquets classiques pour tous les logiciels.

38

Très actif le monde de l open source c est relatif, ça fait plus de 10ans que gimp évolue pas,alors que pleins de solutions proprio sont arrivés avec des outils comme du détourage auto,…
En audio alors là les projets sont morts a tel point qu il y a plus de gens qui code pour reaper qu un adour ou autres, en quelques années des soft proprio sont déjà loin devant que des soft open sources bien plus vieux.

Pourtant, un petit tour sur le Git de Gimp permet de voir qu’il y a quasiment des commits tous les jours.

Et un petit tour sur celui d’Ardour montre que le dernier commit date d’il y a… 4 heures.

Bref, on est loin de logiciels a l’abandon comme votre commentaire le laisserait croire.

Après, que certains projets libre n’aient pas autant de moyens de se tirer la bourre sur des fonctionnalités marketing que les plus gros softs du marché ou que les développeurs ont parfois d’autres priorités dans leur liste d’évolution, c’est un autre problème et un autre sujet.

Mais il faut rappeler encore une fois qu’on parle ici de sécurité, pas d’évolutions fonctionnelles, car ce n’est pas du tout la même chose.

39

L’encapsulation est aussi et surtout un moyen de faire de l’isolation et de… contourner certaines restrictions imposées par les licences…

Car pour simplement régler le problème des dépendances, il y a deux solutions simples qui couvrent l’écrasante majorité des besoins :

  • la compilation avec des bibliothèques statiques (embarquement des bibliothèques dans le binaire),
  • intégrer dans le binaire un chemin de recherche des bibliothèques personnalisé et livrer les bonnes versions des bibliothèques dans ce chemin (et ça peut aussi se faire dynamiquement à l’exécution, avec la variable d’environnement LD_LIBRARY_PATH).

La première solution est la plus pratique à l’usage, mais elle peut par contre poser des problèmes de licence quand la licence de la bibliothèque est « contaminante » (tu peux pas linker statiquement une bibliothèque GPL dans une application BSD ou Apache par exemple).

Ce qui ne veut pas pour autant dire que le logiciel évolue d’un point de vue utilisateur. 90% de ces commits sont liées à la localisation du logiciel ou des modifications techniques sans réel impact sur les principales fonctionnalités.

Si tu veux juger de l’évolution fonctionnelle d’un logiciel, il faut plutôt regarder les issues de type « Feature » fermées récemment. Et là c’est plus la même chose… À peine 3-4 par mois, dont le tiers fermées sans être implémentées, et beaucoup pour des choses absolument mineures et qui pourtant ont mis trèèèès longtemps à être implémentées (par exemple, pouvoir faire une recherche par nom dans les calques, quasiment deux ans…) ou non implémentées (15 ans (!!!) pour décider de na pas mettre un warning quand on utilise le pinceau avec l’opacité à 0%…).

Oui, c’est un autre problème. Mais le problème c’est qu’il y aura toujours un libriste fanatique pour te dire que le logiciel libre fait tout aussi bien si ce n’est mieux que son concurrent propriétaire. Ce qui est factuellement complètement faux dans le cas de certains logiciels propriétaires très populaires (Photoshop et Office en tête). Et ça, c’est globalement pas bon du tout pour l’image du logiciel libre.

40

L’encapsulation est aussi et surtout un moyen de faire de l’isolation.

La raison d’être de l’encapsulation est de simplifier le déploiement des logiciels.

On peut faire de l’isolation indépendamment de l’encapsulation, mais l’encapsulation permet de simplifier la mise en oeuvre.

La première solution est la plus pratique à l’usage, mais elle peut par contre poser des problèmes de licence quand la licence de la bibliothèque est « contaminante » (tu peux pas linker statiquement une bibliothèque GPL dans une application BSD ou Apache par exemple).

Le fait qu’une licence soit contaminante ne veut pas dire pour autant que la liaison est interdite avec du code sous licence libre permissives. (Voir la liste des licences libres compatibles avec la GPL.). Juste que c’est contaminant, donc que le résultat n’est pas combinable avec une licence incompatible ou propriétaire.

Par contre, il faut savoir que du code sous licence GPL reste contaminant, quand bien même on utilise une liaison dynamique. Pour éviter cela, les bibliothèques doivent être sous une variante de la licence GPL, la licence LGPL qui est spécialement conçue à cet effet.

Explications sur le site GNU.org :

La GPL a-t-elle des exigences différentes concernant les modules liés à une création qu’elle régit, selon que la liaison est statique ou dynamique ?
Non. Lier une création régie par la GPL avec d’autres modules, que ce soit de manière statique ou dynamique, revient à faire une création combinée basée sur la création régie par la GPL. Donc les termes et conditions de la licence publique générale GNU s’appliquent à l’ensemble de la combinaison.