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

Benoit Bayle

03 juillet 2022 à 12h30

open source logiciel fotolia_cropped_2738x2739

On entend la phrase magique depuis un bon moment déjà : « un logiciel open source sera par définition plus sécurisé qu'un logiciel propriétaire ». Et si cette maxime pouvait se vérifier il y a une dizaine d'années, ce n'est malheureusement plus forcément le cas aujourd'hui.

Il y a encore quelques années, les logiciels libres (free software) ou open source présentaient bel et bien un avantage structurel en matière de sécurité informatique pour une raison simple : ils permettent la capacité de modifier le code afin de garantir la possibilité d'obtenir un correctif en cas d'exposition à une vulnérabilité dans sa sécurité. Cependant, en une dizaine d'années, la créativité des pirates et la prolifération des cibles potentielles ont modifié cet état de fait, et aujourd'hui, les logiciels open source ne bénéficient d'aucune garantie de sécurité.

La chaîne d'approvisionnement logicielle se fait de plus en plus complexe

Aujourd'hui, les composants et bibliothèques open source tiers sont présents dans l'immense majorité des programmes informatiques et des applications. Ils permettent notamment aux développeurs d'ajouter diverses fonctionnalités à ces logiciels. Cependant, il serait illusoire de considérer la pratique sans risque : en effet, Snyk et la Fondation Linux ont pu publier un rapport nommé The State of Open Source Security il y a quelques jours qui présente une dépendance et des vulnérabilités indéniables. Ce rapport, alimenté par une enquête auprès de plus de 550 développeurs et professionnels de la cybersécurité au premier trimestre 2022, permet ainsi de prendre la pleine mesure des failles liées à l'utilisation de l'open source.

Ainsi, un projet moyen de développement applicatif rencontre 49 vulnérabilités en moyenne, tandis que 80 dépendances directes à du code open source ont été relevées. D'autre part, 49 % des organisations interrogées dans le cadre de cette enquête affirment ne pas avoir de politique de sécurité open source. Le problème principal vient du fait que de nombreux développeurs logiciels assemblent du code ajoutant des composants open source déjà existants à leur code unique, ce qui crée à terme de nombreux problèmes de sécurité.

Sur le même sujet :

Qu'est-ce que Log4Shell, la vulnérabilité qui enflamme Internet ?

Des failles de plus en plus nombreuses, et de plus en plus difficiles à régler

La durée nécessaire pour corriger les failles dans le domaine open source a plus que doublé en l'espace de seulement trois ans. S'il fallait 49 jours en moyenne en 2018, il faut désormais compter sur 110 jours en 2021 pour corriger une faille liée au code open source. Par ailleurs, il est désormais beaucoup plus difficile de maintenir de la visibilité sur l'ensemble des composants open source qui forment un logiciel, et ces dépendances créent de véritables risques de sécurité qui se vérifient ces dernières années. Les principaux intéressés sont d'ailleurs plus de 25 % à indiquer être inquiets quant à l'impact de cette dépendance open source sur la sécurité de leur service.

Pour tenter d'endiguer le problème, qui grandit chaque jour, Snyk et la Fondation Linux recommandent ainsi aux entreprises de définir et de déployer une véritable politique de sécurité open source, mais aussi d'utiliser l'automatisation afin d'adapter la réponse aux potentielles attaques.

Sur le même sujet :
147,9 millions de dollars : le prix pour des logiciels open source sécurisés

Source : Snyk, Fondation Linux

Benoit Bayle

Geekonoclaste permanent, je m'intéresse autant aux jeux vidéo (avec une petite faiblesse particulière pour les JRPG) qu'à l'high-tech. Je cherche à la fois l'originalité et l'inventivité, que ce soit...

Lire d'autres articles

Commentaires (45)

jvachez

C’est même tout le contraire, le code source aide grandement à détecter des failles de sécurité. Et comme les gens trainent souvent à appliquer les mises à jour c’est encore plus simple.

dredd

Et donc à les colmater aussi. C’est plus complexe que ça quoi. Sacré JVachez. Monsieur « il n’y a pas d’antivirus sur Linux donc vous êtes à la merci des virus »

Werehog

wackyseb

Même pas besoin de reverse ingeniering avec l’open source. On a direct accès au code source pour trouver les failles et les exploiter. Et en plus des tas de personnes ne mettent jamais à jour leurs logiciels. Au moins en code fermé, c’est plus compliqué de trouver la faille. Apres Il n’y a pas de solution miracle. Ce que l’homme fait, un autre homme saura le défaire. Il faut juste un peu de patience.

stratos

je ne suis pas dev, mais la diversité des projets, il y a juste à voir la quantité de distrib linux n’aide pas forcément à maintenir tout ça a jour et colmater tout ca. Il y a un noyau commun entre différentes distrib mais le reste change. le gros problème de l’open source que je vois de l’extérieur, c’est chacun son projet , il y a quelque gros projet open source type firefox,vlc., notepad… mais sinon c’est très diverse. Et les soft open source, ok on a accès au code, mais vu le nombre de soft je ne pense pas qu’il y a toujours des dev ext au projet pour relire tout le code à chaque modification. Apres une journée de boulot, ils ont peut-être autre chose à faire.

MattS32

Werehog: Bon par contre le carnaval des dépendances parce que c’est gratuit donc on se sert sans compter, c’est effectivement un problème. Il commence à y avoir des mesures pour ça, comme le SBOM. L’idée est de fournir avec tous les logiciels une liste précise de toutes les dépendances, pour pouvoir rapidement détecter ce qui est impacté par une faille. Ça commence à devenir obligatoire sur certains marchés, par exemple pour tous les logiciels utilisés par une agence du gouvernement fédéral américain.

Jissou06

Bon par contre le carnaval des dépendances parce que c’est gratuit donc on se sert sans compte Tout à fait. Mais ce n"est pas spécifique à l’openSource Nombre de projet d’ampleur ClosedSource utilisent des bibliothèques, dépendances OpenSource (nodeJs et autres) et ne sont pas sécurisés non plus. Au moins le monde (fondation Linux…) ont le mérite de soulever le problème pour mieux y repondre

Francis7

« Use it at your own risk ! » and « Have a lot of fun! ». Your SuSE Team. Cela ne m’a jamais causé de souci. Alors que des copains me voyaient comme un extra-terrestre dans les années 90. En tant que particulier, ce sont des considérations qui nous dépassent. J’ai toujours adoré Linux, hors formation initiale. Mais dans le milieu pro, ils doivent être vachement occupés. Même Microsoft se fait pirater ses serveurs et stations de travail sous Linux.

benbart

{Un admin Système linux parle} En effet, un code libre n’a jamais était plus sécurisé, c’est loin d’être nouveau. Et ça na JAMAIS était le faire valoir du libre. A la base le logiciel libre, ça na pas été fait pour la sécurité, mais tel qu’un projet de société ! Le paradigme qui se dégage d’un projet libre, c’est auditer, modifier, diffuser du code, la ou un logiciel aux sources fermé ça l’interdit … C’est dans ce sens qu’il faut le lire … donc c’est extrêmement biaisé de se croire protéger quand on utilise un outils libre… Par ailleurs, des failles dans des logiciels proprio’ c’est très souvent opaque au niveau de la transparence et de la résolution des problème, et bien souvent ça enlève beaucoup de moyens à un SI de contourner un problème ou une faille. Au taff, on traite de plus en plus de CVE, et la le logiciel libre est intéressent, c’est qu’on peux directement savoir s’il ont est sujet aux CVE en question, et il y a très souvent des correctifs qui viennent rapidement, et on peux payer un service de maintient du le logiciel libre, parce qu’un logiciel libre n’est pas toujours 100% gratuit et philanthropique, voire bénévole. (Red Hat, Oracle, blah blah blah) Par contre, jean-kevin qui git clone tout les trois jour un projet libre bling-bling plus maintenu après les trois semaines de hype, la en effet il y a un soucis de sécurité … Donc, non le libre ne favorise pas la sécurité, mais ça viens avec des outils d’audit et une lecture sceptique sur le code libre, la ou un projet propriétaire t’enlève tout outils d’audit et autres ou patchage ou modification du programme. Petite subtilité, Quant on parle de CVE, c’est qu’elles sont publié, et souvent ça viens par vague sur une techno’ en particulier, et souvent à la suite de l’audit dans une boite ou autres. ( CF. log4j et plus largement Java il y a quelques mois ). Dernière petite chose et non des moindre, histoire d’abolir le chiisme entre proprio’ et libristes, c’est la qualité du code qui fait le développeur, c’est pas ses outils ! il en va de même pour l’administrateur système. ( ps : les problèmes de distribution de packages/logiciels corrompu ( NPM/PHP par exemple ) sont pas lier aux sources ouverte/fermé, mais c’est un soucis générale, lier à tous les environnements ) A mon humble avis : Ils y a maintenant des galaxies de projets libre, et les temps d’audit on drastiquement diminué, car ça na pas de taux horaire favorable à un employeur. Il y a déjà un soucis sur ce point. C’est le farewest dans le libre, parce que c’est libre, je vois de plus en plus de développeurs qui utilisent des outils sans les comprendre dans leur ensemble, de même pour les administrateurs, je m’inclue dedans car, j’ai pas encore suffisamment d’expérience sur tel ou tel framework, je me suis donc orienté vers outils avec le minimum de middleware, un enfer à géré sur Foreman/Satellite/Katello pour l’exemple. Il serait intéressant de : Factoriser au max les outils, évitant les dépendances « contrib » de faible confiance. Conventionner(ou normer) les interactions entre les outils. Afficher clairement les dépendances dans les README, en 2022 ça n’est toujours pas le cas, je suis toujours obliger de vérifier la qualité du maintient d’un outils à chaque fois … c’est fatigant, et par moment je le fait même plus quand il est 15h59 un vendredi… Vérifier les taux de tickets et merge resquest appliqué, ça justifie de la qualité du maintient d’un outils en quantité au minimum. LIRE, LIRE et encore RTFM !!!

benbart

L’offuscation ça na jamais marché ! La preuve il y toujours autant de logiciels pirates

wackyseb

Rien à voir !! On parle des failles de sécurité pour prendre le contrôle à distance du PC. Et non pas du piratage des logiciels.

benbart

En effet, ça n’a directement strictement rien a voir, c’était imagé. Généralement c’est du code décompilé et recompiler avec quelques corrections, moyennent de la rétro-ingénierie. Et je pense qu’on est d’accord que la rétro-ingénierie, ça existe. Alors c’est pas forcement pour toutes les mains, et c’est justement l’argument historique du libre. Par ailleurs, je maintient à l’époque actuel que les sources ouverte ont tout de même la valeur ajouter d’aider à l’audit du code, voir de sa correction et publication via un commit. Ca laisse à chacun les moyens technique de s’approprier une problématique.

juju251

wackyseb: On parle des failles de sécurité pour prendre le contrôle à distance du PC. Et non pas du piratage des logiciels. C’est vrai que ça fonctionne tellement bien qu’il n’y a presque jamais de failles dans Windows ou dans Exchange Server, par exemple … Désolé, hein, mais c’est n’importe quoi de croire que parce qu’un logiciel est propriétaire on est mieux protégé qu’avec un logiciel libre juste parce que son code source est inaccessible … … Ceci dit, il y a déjà moyen d’en savoir pas mal sur Windows avec son SDK, donc inaccessible, pas tant … En vrai, le plus important là-dedans c’est avant tout la vitesse de réaction pour corriger les failles, ainsi que la reconnaissance de l’existence du problème. Ils ne vont pas être bien d’accord chez Microsoft, mais bon … Dernière chose, combien de projets proprio se basent (même en petite partie) sur du code en open source (quelque soit la licence) ?

wackyseb

Oui pour sûr. Avoir les sources quand on sait quoi en faire ça permet d’aider la communauté ou de faire un fork avec des améliorations. Par contre pour la sécurité, je reste mitigé. D’un côté on peut avoir pleins de gens qui debug et tout autant qui cherchent la faille « facilement »

wackyseb

Oui tu as parfaitement raison pour Windows. Une passoire à bug en tout genre. Le code est tellement lourd qu’il faut s’y retrouver et que les interactions entre les différentes parties ne doivent pas être simple à gérer windows.developpez.com Windows 10, c'est un code source de plus de 0,5 To, plus d'un demi-million de... Le système d’exploitation (OS pour Operating System) est un ensemble d’applications (de logiciels) qui permettent d’utiliser les ressources physiques (le matériel) de l’ordinateur. Il permet également d’utiliser d’autres logiciels en correspondance... Pour ce qui est du libre, je suis moi même libriste. J’avais fait ma propre distribution Linux basé sur LinuxMint pour le plaisir et c’est super compliqué à maintenir. J’ai eu un nombre incalculable de bugs. Puis j’ai aidé certains projets avec mes humbles connaissances. Je ne compte plus les failles en tout genre, les prises de contrôle lors des debug. Et tu as parfaitement raison aussi. Beaucoup de logiciels même propriétaire utilisent des bibliothèques du libre comme Ffmpeg par exemple

KlingonBrain

Comme d’habitude, du grand bullshitage anti open source dans les commentaires à coup de grand n’importe quoi et d’argumentaires bâties à partir d’idées reçues, je propose de revenir à des faits simples et vérifiables. -Demandez vous dans quel dépôt logiciel contient le moins de malwares et autres spywares piquant vos données personnelles ? Les dépots des distributions Linux sont réputés très sains en la matière, demandez vous si c’est un simple hasard. -Quel modèle offre le plus de transparence en permettant AUX UTILISATEURS et à la communauté de vérifier par eux même que l’éditeur dit la vérité quand il prétends respecter vos données personnelles et ne pas contenir de malware ? -Tapez « sécurité par l’obscurité » dans un moteur de recherche pour comprendre ce que pensent des vraies pointures de l’informatique de cette illusion dangereuse qui consiste à croire qu’on serait plus en sécurité en découvrant moins de failles. Sachant que tant qu’une faille existe, elle peut être connue de quelqu’un et exploitée. -Comme si les logiciels « closed source » n’étaient jamais victimes de « leaks » de leurs code source. Au moins dans le monde open source, il n’y a pas que les hackers du dark web qui peuvent le lire facilement Ps : je ne répondrait pas aux trolls, commentaires ininteressants, attaques personnelles, etc…

KlingonBrain

Même pas besoin de reverse ingeniering avec l’open source. On a direct accès au code source pour trouver les failles et les exploiter. Mais aussi pour les corriger Au moins en code fermé, c’est plus compliqué de trouver la faille. Allez voir ce que pensent des experts de ce modèle appelé « sécurité par l’obscurité ». Ce n’est pas parce que vous ignorez l’existence d’une faille que d’autres ne la connaissent pas. Une bonne sécurité, c’est de corriger les failles, pas de les ignorer ou de les cacher. Et en plus des tas de personnes ne mettent jamais à jour leurs logiciels. Le libre propose les systèmes de mise à jour parmi les plus efficients du monde. Mais aussi des choses que ne permet pas le modèle propriétaire, comme de recompiler tous les logiciels dépendant d’une bibliothèque affectée sans attendre le bon vouloir des éditeurs.

KlingonBrain

Il n’y a pas forcément du tout blanc ou du tout noir avec l’open source. La seule chose qui importe c’est la réactivité. Il y a de très mauvais projets open source et de très bons logiciels fermés. Il faut juste que les failles puissent être signalées facilement et corrigées rapidement. Bon par contre le carnaval des dépendances parce que c’est gratuit donc on se sert sans compter, c’est effectivement un problème. C’est juste la conséquence logique de la médiocrité technique qui s’installe dans les entreprises. Les plus jeunes brassent à la pelle des techno qu’ils ne maîtrisent pas, ni même les grands principes de sécurité (entre autres) que cela implique… Alors oui, et pour répondre au sujet de l’article, le fait est qu’on accuse le logiciel libre de quelque chose… qui est le fait de mauvaises pratiques d’entreprises et de codeurs incompétents, ou trop pressés pour des raisons de rentabilité. Ce sont des codeurs qui prennent le monde de l’open source juste comme un simple réservoir de code gratuit dans lequel ils viennent piocher sans rien vérifier, ni la provenance, ni la sécurité du dépôt, ni la réputation de l’auteur, ni même le respect de la licence. Bref, ils prennent n’importe quel code sur le web, en faisant n’importe quoi et sans rien vérifier pour aller plus vite que plus vite, et après, ils viennent pleurer parce qu’ils ont des problèmes. Ensuite, des décideurs encore plus incompétents viennent pleurer que c’est la faute de l’open source. Il est facile de comprendre que s’ils faisaient exactement la même chose avec du code propriétaire, des bibliothèques fermées trouvées gratuitement sur n’importe quel site, ils iraient encore plus rapidement et sûrement à la catastrophe. Quand on fait n’importe quoi, on obtient n’importe quoi. L’open source, n’est pas non plus une baguette magique prétendant sauver l’incompétence profonde des entreprises qui ne pensent qu’au fric et à la rentabilité des problèmes logiques et prévisibles engendrés par le manque de conscience professionnelle, pur produit d’un système crevant de son avidité financière.

benbart

On dirait un Montpelliérain qui parle ! Je t’offre la bière, et on refera le monde

stratos

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

KlingonBrain

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.

benbart

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. 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.

Francis7

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 ?

wackyseb

Oui Bien sur Tout à fait Evidemment KlingonBrain: Mais aussi des choses que ne permet pas le modèle propriétaire, comme de recompiler tous les logiciels dépendant d’une bibliothèque affectée sans attendre le bon vouloir des éditeurs. 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.

wackyseb

KlingonBrain: 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é. Combien de personnes sur la terre tout entière souhaite bosser dans la sécurité ? KlingonBrain: 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. Logiciel libre ou propriétaire, c’est pareil de ce point de vue. KlingonBrain: Ajoutons que de nombreuses entreprises, mais aussi des agences de sécurité gouvernementales ont intérêt à contribuer pour diverses raisons. 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 KlingonBrain: 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é. 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. KlingonBrain: Mais ne vous inquiétez pas, la culture libre commence à s’attaquer à la conception des objets matériels. 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.

Loposo

MattS32

wackyseb: Logiciel libre ou propriétaire, c’est pareil de ce point de vue. 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).

jo1244

@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.

vidarusny

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…

sshenron

« 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

SPH

Hello « World » C’est l’instruction la plus sécure que je connaisse. Il n’y a pas de failles…

MattS32

sshenron: 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. 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).

jo1244

tout à fait vrai et peu rassurant

vidarusny

sshenron: 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. 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 !

EricARF

Elles sont juste moins dans le viseur des pirates…

KlingonBrain

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.

KlingonBrain

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. GitLab Commits · master · GNOME / GIMP · GitLab The GNU Image Manipulation Program Et un petit tour sur celui d’Ardour montre que le dernier commit date d’il y a… 4 heures. github.com/Ardour/ardour transcode debug should not print (null) array termination committed 04:05PM - 04 Jul 22 UTC x42 +2 -2 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.

MattS32

KlingonBrain: D’ou l’invention des logiciels encapsulés pour apporter plus de souplesse, de liberté et une possibilité supplémentaire à l’utilisateur. 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). KlingonBrain: Pourtant, un petit tour sur le Git de Gimp permet de voir qu’il y a quasiment des commits tous les jours. 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%…). KlingonBrain: 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. 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.

KlingonBrain

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.

KlingonBrain

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. Et il y aura toujours un « propriétariste fanatique » qui viendra te dire que le propriétaire fait mieux sous prétexte qu’il connait un logiciel qui à 3 fonctions en plus. Rappelons qu’un logiciel, ça ne se résume pas juste à des fonctionnalités à un instant T. Il y a aussi le prix, les conditions d’utilisations, la garantie de survie à long terme et la possibilité de le modifier (ou de le faire modifier) même si tu as un besoin professionnel particulier (souplesse). Tout ramener au seul critère de la surenchère fonctionnelle, c’est oublier que beaucoup de gens se contentent d’un « paint »… parce c’est juste ce dont ils ont besoin. Le fait qu’une formule 1 soit capable de rouler plus vie qu’une Clio n’en fait pas pour autant le meilleur choix pour le quotidien. Quand on parle de performances des suite bureautique… alors que dans les entreprises les gens n’en maîtrisent même pas 10% des fonctionnalités. Mais bon, c’est le droit de chacun de faire ses choix, comme de payer année après années pour des licences hors de prix et de se plier aux mille et uns caprices des contrats des éditeurs (et leur constante évolution) et de se convaincre que ceux qui ont fait d’autre choix ont forcément tort. 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%…). Pour ma part, je ne vois pas ou est le problème. Gimp a toujours été connu pour son évolution régulière, soutenue, mais lente. Ce qui n’a rien à voir avec un logiciel dont la maintenance et la sécurité serait à l’abandon. L’équipe de développement est connue pour être modeste … et tout projet logiciel doit faire le mieux avec les resources dont il dispose. Tout chef de projet vous dira qu’on ne peut pas dire oui à toutes les demandes de fonctionnalités. Finalement, le problème n’existe que dans la tête de ceux qui veulent absolument faire de Gimp le concurrent de Photoshop au lieu de se demander à combien de personnes Gimp rends service de façon quotidienne. Ils oublient de se demander si le problème qu’ils soulèvent en est réellement un pour les 95% d’utilisateurs du soft et non pas juste pour la minorité de pro du graphisme dont les besoins de productivité, d’intéropérabilité ou de processus rendront quoi qu’on fasse assez difficile de se passer de Photoshop.

KlingonBrain

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. Tout à fait exact. Mais ceux qui veulent troller sur le libre adorent les clichés, comme cette bonne vieille image d’amateurisme. Mais il y a une idée reçue effectivement répandue, celle de penser que le propos du libre serait la gratuité. Or la gratuité n’est pas la raison d’être réelle du logiciel libre (free speech, not free beer). Même si cela arrive fréquemment que les logiciels soient gratuits, il arrive aussi que non.

max6

De ce fait il n’y a pas besoin de reverse ingeniering avec l’open source. On a AUSSI directe aussi direc accès aux sources pour trouver le failles et les combler. Cela fonctionne dans les deux sens. Ce qui n’empêche pas qu’en plus des tas de personnes ne mettent jamais à jour leurs logiciels. Alors qu’en code fermé, c’est plus compliqué de trouver la faille et de convaincre l’entreprise de la combler quand elle n’attaque pas le découvreur parce qu’il a fait du reverse engineering (encore que ce soit rare de nos jours les entreprises n’aiment pas la mauvaise publicité).

MattS32

KlingonBrain: Par contre, il faut savoir que du code sous licence GPL reste contaminant, quand bien même on utilise une liaison dynamique. Oui effectivement, j’ai confondu avec la LGPL. KlingonBrain: Pour ma part, je ne vois pas ou est le problème. Ben perso je vois un sacré problème… Quand je demande une fonctionnalité sur un logiciel, qu’on me réponde oui rapidement ou non rapidement, ça me va. Qu’on laisse la question en suspens pendant 15 ans avant de finalement prendre une décision, ça me va pas du tout (y compris si la décision est finalement d’implémenter le truc…). Ça ne fait pas sérieux. Et ça dessert du coup le logiciel. Et ce n’est pas bon non plus pour la communauté d’ailleurs. Parce qu’accumuler les issues ouvertes depuis des années sans y répondre, sans décider, sans prioriser, ça rend plus compliqué le suivi, les contributions (celui qui veut contribuer se retrouve avec une masse énorme d’issues, il va se noyer et ne saura pas laquelle prendre… 3470 issues ouvertes sur Gimp actuellement, la plus ancienne a 22 ans, et c’est un bug…)… Pareil pour les PR, y a plusieurs dizaines de PR qui sont en attente depuis plus de 6 mois, plus de 4 ans pour les plus anciennes… Laisser trainer des PR aussi longtemps, ça décourage les contributeurs et ça leur impose un travail supplémentaire, parce qu’il faut réadapter ce qui a été fat aux évolutions du main pendant tout ce temps… Bon après, à la décharge de Gimp, faut dire que c’est sans doute un logiciel libre qui ne bénéficie pas d’énormément de financement par des entreprises… Pour les besoins professionnels, il est beaucoup trop loin de ce que font les solutions propriétaires, pour un coût qui reste modeste pour une entreprise par rapport à un investissement dans le logiciel libre (un an de Photoshop pour un utilisateur, c’est le coût d’une journée de dev à peine…), tandis que les nombreux indépendants qui bossent avec Photoshop n’ont pour la plupart pas les compétences pour s’investir dans le développement de Gimp. max6: quand elle n’attaque pas le découvreur parce qu’il a fait du reverse engineering (encore que ce soit rare de nos jours les entreprises n’aiment pas la mauvaise publicité). C’est surtout qu’elles n’ont aucune base légale pour les attaquer. La plupart des pays autorisent le reverse engineering quand il est à des fins de recherche ou d’interopérabilité. KlingonBrain: En oubliant de se demander si ça en est réellement un pour les 95% d’utilisateurs qui n’auront jamais besoin de plus que ce qu’offre Gimp. Oui et non. Parce que justement les fonctionnalités que tu prétends être « marketing » dans Photoshop, ce sont des fonctionnalités qui parfois plaisent énormément au grand public, parce qu’elles rendent accessibles et rapides des opérations qui avant nécessitaient beaucoup d’expérience ou beaucoup de temps, si ce n’est les deux à la fois… Par exemple les capacités actuelles de Photoshop pour reconstituer ce qui manque quand on retire un panneau disgracieux ou des câbles électriques sur une photo, c’est juste bluffant… Idem pour sa capacité à recomposer un panorama à partir d’une série de photo prise en tout auto (donc avec un appareil qui va adopter des réglages différents d’une photo à l’autre, complexifiant grandement la recomposition), avec une jointure totalement invisible, une balance des blancs uniformisée, etc… Idem quand il s’agit d’étirer la photo 4/3 de ta copine devant ce magnifique coucher de Soleil sur la plage lors des dernières vacances, que tu veux mettre en fond d’écran 16/9, mais sans déformer la copine en question, ni le disque parfait du Soleil… En fait, en un certain sens Photoshop est plus grand public que Gimp. Parce que ces fonctions « marketing » rendent accessible à tous des opérations que seul un professionnel aguerri savait faire il y a quelques années… Certes, c’est pas donné, mais à 12€ par mois, c’est tout de même devenu accessible pour pas mal de monde…

ld9474

benbart: Afficher clairement les dépendances dans les README, en 2022 ça n’est toujours pas le cas, je suis toujours obliger de vérifier la qualité du maintient d’un outils à chaque fois … c’est fatigant, et par moment je le fait même plus quand il est 15h59 un vendredi… Bonjour, étonnant une telle demande . 1 - pas de doc d’architecture livré avec la solution? Cette documentation devrait faire mention des éléments tiers utilisés 2 - Si on utilise des gestionnaires de paquet (et pas que) il y a forcément un fichier qui recense les dépendances: package.json, fichier projet etc… 3 - il existe des solutions qui font l’analyse des risques. J’en utilise une qui s’appelle White Source (le nom a semble t il changé en Mend Bolt). Couplée à de l’intégration continue vous avez un paquet d’information. Voici un exemple de résultat avec un build sur Azure DevOps (ca doit très bien marcher aussi avec des github actions ou sur gitlab) image2000×743 87.3 KB

benbart

Salut, Déjà merci beaucoup pour ce soft bien sympas (Mend Bolt). Et pour reprendre ces points, je reprends votre plan : Pour les gros projets open-source ( pas forcément Free Software ) tu type Red Hat, Oracle, etc. Le travail est bien fait, voir très bien, même s’il y a quelques lacunes sur certains supports et documentations par moment, mais c’est rare. Il y a également des projet à sources ouverte très bénévole et soutenue par différentes entités de l’open/free-sources (XFree pour l’exemple), autant il y a beaucoup de projets de grandes qualités, mais il peu y avoir un manque de réactivé et de maintient. La limite de l’argument, c’est que l’on peu patch sois-même les soucis et faire un commit/merge request, mais un Admin Sys (au sein d’un SI) n’a pas forcément le temps de faire la passerelle avec les DEVs de la communauté du projet qui maintient le soft, en plus d’un manque de MaJ de la documentation pour quelques projets ( et personne leur en veux ). Mais j’en veux à « Kévin_RGB » qui découvre une API et qui s’amuse, qui fout le tout sur github et l’abandonne 6 semaines plus tard, manque de commu’, il y a plus de ticket/merge request traité. Autant, j’aime bien Kévin-RGB, parce qu’il s’approprie des outils, qu’il créer et qu’il s’éclate avec, mais j’ai de plus en plus de mal à cerner les bons des mauvais projets (je suis pas dev, même si j’ai des connaissances dans certains langages. ), bon la c’est dans un cadre amateur et non pro ( quoi que … ). Donc j’ai rien contre le libre, je crois à son projet de société, mais je pense qu’il manque de plus en plus de « bonnes pratiques » dans le maintiens des projets libre avec l’ouverture des repos gratuits (github, framagit …), un pharmakon, non pas qu’il faut « traité », l’analogie s’arrête la. A savoir qu’il y a une autre limite à mon raisonnement, l’admin sys est payé par un patron heureux de voir sa SI qui remonte pas de problème. Je faisais référence sans doute aux projets github, non disponible dans les repos, j’ai rarement eux de soucis avec du « main free », quelques aléas avec du « contrib », me forcent à recompiler un soft avec la bonne version du bon soft ssl pour l’exemple, non pas que ça soit désagréable, mais ça peu être dur de trouver solutions par moments. Tiens, me plaindre sur les internets ma apporté une solution. merci pour le soft, ça m’en bouche un coin, j’en chercherai d’autre pour comparer. Je crois que je vais commencer à me plaindre plus souvent sur les internets Bonne soirée/journée

benbart

ça c’est propre à vos idées politique, je n’ai pas à en juger. Mais je pense que vous pensez au collectivisme et au libre-partage et non au communisme. Le libre/open-souce impose un libre-partage(pas tous égaux) et est certes collectiviste ( comme notre société, même si ça sent le sapin actuellement ), mais n’implique pas une ode au capitalisme ou au communisme, Les GAFAM très capitalistes investissent et participent en masse dans le Free/open software. J’aurai donc du mal à comprendre la pertinence de votre affirmation. Mais je rappel un point(mais c’est peut être un abus de langage de votre part) : L’Open Source n’est pas la même chose que le Free Software. Je ne vais pas rentré dans les détailles car c’est traité par ailleurs dans les commentaires. Par ailleurs, OUI, il va avoir une monter de l’insécurité si le SI n’a pas de RSSI intelligent, vu le prix que ça coute un RSSI, vous voulez le voir compétant. Il n’est jamais recommander d’ajouter du code qui viens des zinternets sans une étude au préalable(support, maintient, CVE passé et en cours . . . blah blah blah), et un audit du code pour les soft critiques. Le risque peu venir du monde développeur ou administrateur, même culpabilité pour les deux. Pour l’instabilité des systèmes, j’ai rarement vu ça sur une distribution Linux(Free Software), allez voir chez microsoft(propriétaire) pour les instabilités d’un système. (bon, c’est un peu facile, car microsoft a fait des gros effort, mais manque d’outils structurel comme les repos.) Sur des softs, la réactivité n’est pas directement rapport aux Free/Open, mais de la bonne volonté de sa communauté à patcher le soft, la ou le proprio’, c’est à la bonne volonté du compte bancaire et des décisions de la cravate. RSSI = Responsable de la sécurité des systèmes d’information SI = Système d’information = Ensemble de machines et d’humainz s’agitant autour des services informatique = Serveur + Administrateur système + Logiciel + Refroidissement + Contrôle d’acces + trop de trucs. DéfinitionSSSS de logiciel libre : fr.wikipedia.org Logiciel libre Pages pour les contributeurs déconnectés en savoir plus Navigation Contribuer Outils Définition de L’open Software : fr.wikipedia.org Open source Pages pour les contributeurs déconnectés en savoir plus Navigation Contribuer Outils

jo1244

J’ai bien dit communisme, régime de l’ex URSS et d’un certain nombre de pays en Europe, Asie et ailleurs. Pour le reste de votre prose, qui n’est pas toujours compréhensible, je ne partage pas vos idées. Windows (à partir de W98) me parait le système le plus stable et le plus fiable pour la micro-informatique; c’est évidemment autre chose pour les serveurs et autres grosses applications. Une expérience récente avec Lubuntu me confirme que l’OS et l’UI manquent beaucoup de cohérence, ce qui est normal compte tenu de l’absence d’un chef d’orchestre. Mais qu’il existe des systèmes comme Ubuntu est évidemment une très bonne chose car cela permet de donner une nouvelle vie (comme media center par exemple) à une vieille bécane.

benbart

En effet, il est possible de faire tourner sur Windows Server des bonnes fermes de virtualisation pour faire tourner des serveurs linux, et des très bon logiciels 3D, les deux propriétaire empêchant à tout le monde d’en profiter, comme font de nombreuse entreprises qui souhaite établir en confiance en l’ouvrant. Dans les marchés économique ça aide beaucoup. Malgré ça, les logiciels libres QEMU/KVM(pour la virtualisation) et Blenders(pour la 3D) font un poids notable et sont récompensé dans l’industrie. Sur les OS Libre, en effet, en fonction de l’éditeur(quand il y en a un) et de sa communauté, l’UI est en deçà de ce qu’il se fait dans le monde propriétaire. Enfin même de façon générale, c’est pas le fer de lance du Logiciel Libre, et un poils plus rarement dans l’open source. mais ça tend à vraiment s’améliorer. Donc en effet, nous n’avons pas la même vision. vous associez communisme au logiciel libre/ouvert, la ou même les plus capitalistes des pays du monde investissent en masse. je l’interprète comme ça. Bon, je m’arrête la. Je vous souhaite une bonne soirée.

jo1244

Je suis ok pour arrêter la discussion. Juste un point: je n’associe pas communisme au logiciel non-propriétaire, j’avais écrit à peu près « C’est une belle idée » mais comme pour le communisme l’application de cette idée est loin d’être aussi rose.

KlingonBrain

Ben perso je vois un sacré problème… Quand je demande une fonctionnalité sur un logiciel, qu’on me réponde oui rapidement ou non rapidement, ça me va. Qu’on laisse la question en suspens pendant 15 ans avant de finalement prendre une décision, ça me va pas du tout Pourquoi ne pas tenter de faire une telle demande chez Adobe ou Microsoft, histoire de voir ce qu’ils répondent ? Il faut réaliser que logiciel libre, ça ne signifie pas que les programmeurs doivent devenir des subordonnés de tout le monde. Que l’éditeur d’un logiciel soit libre ou propriétaire, on ne demande pas une fonctionnalité, on fait une suggestion, nuance. J’explique plus bas pourquoi ce que vous demandez est impossible et le fait que les suggestions sont un reservoir d’idée, ni plus, ni moins. Cela dit, pour ceux que les décisions des programmeurs ne satisfont pas(c’est leur droit), le logiciel libre permet justement de ne pas être enchainé à leur bon vouloir. On peut obtenir tout ce qu’on veut en le programmant soi même ou bien en payant une société de service pour le faire. Et il existe même des moyens de le financer de manière communautaire en lançant un crowdfunding L’avantage du libre par rapport au propriétaire, c’est que le code source étant accessible, c’est possible. Ça ne fait pas sérieux. Et ça dessert du coup le logiciel. Cela n’à voir avec un manque de sérieux. Dans le monde propriétaire, l’éditeur ne vous répondrait même pas. Au mieux, vous auriez droit à une réponse évasive d’un employé d’un call center qui n’en sait probablement rien. Les éditeurs permettent rarement au public de parler aux programmeurs et encore moins de connaitre les développement futurs. Mais il existe aussi d’autres raisons. Quand il faut planifier les sessions de développement à venir, les développeurs réfléchissent à toutes les idées et priorités qu’ils ont sur la table, et ils en choisissent un certain nombre. Dans ce contexte, on comprends pourquoi il est impossible de dire à une personne qui a suggéré une idée si elle sera adopté. Et si oui, quand elle le sera, dans la prochaine session, la suivante… ou jamais si les orientations changent ou que des priorités viennent bousculer les choses (exemple : une faille à corriger peut venir prendre le pas sur le temps de développement d’une fonctionnalité). Parce qu’un projet à long terme, c’est vivant et que les décisions peuvent dépendre de plusieurs personnes. Donc qu’une suggestion puisse rester en attente est tout à fait logique, puisque cela correspond juste à la réalité des choses. Et ce n’est pas bon non plus pour la communauté d’ailleurs. Parce qu’accumuler les issues ouvertes depuis des années sans y répondre, sans décider, sans prioriser, ça rend plus compliqué le suivi, les contributions (celui qui veut contribuer se retrouve avec une masse énorme d’issues, il va se noyer et ne saura pas laquelle prendre… 3470 issues ouvertes sur Gimp actuellement, la plus ancienne a 22 ans, et c’est un bug…)… Au contraire, c’est plutôt bien organisé, il y a des tags permettant de contextualiser par section et par contexte, ainsi que d’autres critères. On peut constater que la communauté fait un immense travail, en reportant beaucoup de bugs, même secondaires et de petits détails. L’équipe semble corriger beaucoup de bugs de façon régulière, vraissemblablement tout ce qui est bloquant en priorité. Et certainement, comme il est classique dans les petites équipes, les bugs secondaires en batch par section de code de façon plus étalée dans le temps. Cela n’a rien d’inhabituel ou de choquant de voir un bon pourcentage de signalements qui n’aboutissent jamais à une action. Bug non reproductible, demande d’information qui ne reviennent jamais, les raisons sont multiples et variées. Et Les garder réponds à un besoin : voir si d’autres utilisateurs les confirment avant de déclencher des recherches longues et complexes pour rien. Pour terminer, il ne faut pas vouloir chercher à Gimp des problèmes qu’il n’a pas. Je l’utilise très régulièrement depuis des années, c’est un logiciel qui fonctionne bien et qui est plutôt stable à l’usage. Pareil pour les PR, y a plusieurs dizaines de PR qui sont en attente depuis plus de 6 mois, plus de 4 ans pour les plus anciennes… Laisser trainer des PR aussi longtemps, ça décourage les contributeurs et ça leur impose un travail supplémentaire, parce qu’il faut réadapter ce qui a été fat aux évolutions du main pendant tout ce temps… Bien au contraire. Il faut savoir que ce n’est pas parce que les projets libres ont besoin de contributeurs qu’il cherchent pour autant n’importe quel contributeur. Gimp est typiquement le genre de projet géré par de vieux programmeurs chevronnés qui savent très bien ce qu’ils font. Et repérer de potentiels contributeur autant que prioritiser ce qui mérite de l’être. Il est important dans un projet de ne pas gaspiller le temps de travail et la motivation de contributeurs réguliers qui travaillent sur des évolutions importantes pour traiter « Des PR à la noix ». Tout simplement parce qu’il y a aujourd’hui trop de programmeurs qui cherchent à tout prix à inscrire leur nom dans des projets connus pour se constituer un CV, quitte à proposer des PR pour n’importe quoi, des choses peu utiles, peu pertinentes, pas du tout en phase avec les orientations du projet, mais surtout faciles à programmer. Cela peut faire perdre un temps monstrueux et n’apporte absolument rien. D’autant que même traiter un très bon PR d’un programmeur extérieur, ça demande énormément de temps. Parce qu’il faut vérifier de façon extrêmement attentive et rigoureuse, outre sa pertinence et son intérêt, qu’il soit bien programmé, qu’il ne cherche pas à introduire une faille ou un malware, qu’il n’introduise pas de bugs ou de régressions. Dans beaucoup de cas, le programmeur qui propose le PR ne connait pas très bien l’architecture du logiciel, il faudra donc qu’un programmeur régulier du projet retravaille certaines parties. Donc qu’il passe du temps à rentrer dans le contexte visé par le PR. Un programmeur de valeur qui veut vraiment rentrer dans un projet connait très bien ces problèmes et arrive souvent d’emblée à faire comprendre sa valeur. Mais il ne sera pas choqué si au début, il doit faire preuve d’un peu de patience. Bon après, à la décharge de Gimp, faut dire que c’est sans doute un logiciel libre qui ne bénéficie pas d’énormément de financement par des entreprises… Pour les besoins professionnels, il est beaucoup trop loin de ce que font les solutions propriétaires, pour un coût qui reste modeste pour une entreprise par rapport à un investissement dans le logiciel libre (un an de Photoshop pour un utilisateur, c’est le coût d’une journée de dev à peine…), tandis que les nombreux indépendants qui bossent avec Photoshop n’ont pour la plupart pas les compétences pour s’investir dans le développement de Gimp. Gimp est effectivement un projet relativement modeste malgré sa célébrité. Et si mes souvenirs sont bons, il est majoritairement sur base bénévole. Il n’est effectivement pas adapté pour les purs professionnels du graphisme, parce qu’ils ont à la fois un impératif de productivité maximale et d’interopérabilité qui rendraient l’utilisation de Gimp peu adaptée. Et le prix de la licence n’est pas un souci dans ce contexte. Gimp est par contre un outil de choix pour tout ceux qui travaillent de graphisme de façon plus annexe. Et pour qui le payement d’une licence Photoshop ne se rentabilise pas forcément. Sans parler de l’argument de la licence libre, qui est un argument bien réel sur le long terme. Oui et non. Parce que justement les fonctionnalités que tu prétends être « marketing » dans Photoshop, ce sont des fonctionnalités qui parfois plaisent énormément au grand public, parce qu’elles rendent accessibles et rapides des opérations qui avant nécessitaient beaucoup d’expérience ou beaucoup de temps, si ce n’est les deux à la fois… Par exemple les capacités actuelles de Photoshop pour reconstituer ce qui manque quand on retire un panneau disgracieux ou des câbles électriques sur une photo, c’est juste bluffant… Idem pour sa capacité à recomposer un panorama à partir d’une série de photo prise en tout auto (donc avec un appareil qui va adopter des réglages différents d’une photo à l’autre, complexifiant grandement la recomposition), avec une jointure totalement invisible, une balance des blancs uniformisée, etc… Idem quand il s’agit d’étirer la photo 4/3 de ta copine devant ce magnifique coucher de Soleil sur la plage lors des dernières vacances, que tu veux mettre en fond d’écran 16/9, mais sans déformer la copine en question, ni le disque parfait du Soleil… Justement, Gimp ne vise absolument pas ce genre de public. Parce qu’il est déjà beaucoup trop complexe pour le très grand public qui cherche des outils très simples pour faire de la « créa qui en jette » sur les photos de famille. Et il faut réaliser que les professionnels du graphisme travaillent profondément les images créent des compositions et font un certain usage de détourages. Mais a l’inverse, beaucoup de gens n’en font jamais, ou vraiment très peu. Parce qu’une très grande partie de leurs besoins se concentrent dans des actions beaucoup plus simple : recadrages, corrections lumineuses, changements de formats, compression pour le web, etc… Ce à quoi Gimp réponds admirablement bien. En fait, en un certain sens Photoshop est plus grand public que Gimp. Parce que ces fonctions « marketing » rendent accessible à tous des opérations que seul un professionnel aguerri savait faire il y a quelques années… Est ce que quelques fonctions qui rendent certaines opérations plus facile suffisent pour autant à rendre des logiciels professionnels relativement « complexes et bardés de fonctions » accessibles au grand public ? Pour ma part, j’ai quand même un doute, car maîtriser un logiciel graphique ne se limite pas juste à cela. Je me souviendrais toujours d’une époque ou l’on croyait que les langages de programmation visuels allaient rendre les programmeurs professionnels obsolètes parce qu’ils deviendraient accessible à monsieur tout le monde… sauf que 30 ans plus tard, pas de bol, les programmeurs existent toujours et que les utilisateurs ont maintenant une peur bleu du moindre outil de programmation. De plus, pour le côté artistique, il faut avoir en tête qu’aussi intelligentes soient les fonctionnalités, il peut y avoir une différence entre ce qu’elles imaginent et ce que vous avez en tête. Donc que savoir aussi le faire « à la main » restera certainement un plus dans certains cas de figure. Certes, c’est pas donné, mais à 12€ par mois, c’est tout de même devenu accessible pour pas mal de monde… En même temps, je ne suis pas certain que tout le monde ait envie de dépenser 144€ par an juste pour bidouiller quelques photos personnelles. En tout cas, ce n’est pas mon cas. D’autant qu’a tenir ce raisonnement, on pourrait continuer pour pléthore d’autres logiciels … ce qui peut finir par représenter un certain prix au total. Pour finir, je m’arrête ici, je vous souhaite donc une bonne fin de discussion. Je vous remercie pour cet échange intéressant et argumenté, même si nous ne sommes pas d’accord.

MattS32

KlingonBrain: Pourquoi ne pas tenter de faire une telle demande chez Adobe ou Microsoft, histoire de voir ce qu’ils répondent ? Comme je dis, je préfère une réponse négative rapide plutôt que de rester 15 ans dans l’attente… Laisser comme ça une question en suspens ça fait vraiment pas sérieux. Pareil pour les PR. Je ne dis pas qu’il faut accepter toutes les PR, et je comprends bien qu’on ne peut pas toutes les accepter. Mais par contre on ne doit pas laisser trainer des PR pendant des mois. C’est frustrant pour le développeur (et je t’assure que ça l’est BEAUCOUP plus que de se faire rejeter sa PR, j’ai plusieurs années d’expérience de contribution à plein temps à des logiciels open source, et j’ai donc beaucoup de retours d’expérience à ce niveau, en plus de mon expérience perso), ça fait du boulot supplémentaire pour la maintenir, etc… Et c’est d’autant plus problématique quand en plus tu contribues professionnellement et que tu as du monde au-dessus qui te demande des status… KlingonBrain: Donc qu’une suggestion puisse rester en attente est tout à fait logique, puisque cela correspond juste à la réalité des choses. Dans ce cas, pourquoi la fermer soudain au bout de 15 ans ? Si c’est censé être un vivier d’idées, elle ne devrait jamais être fermée… KlingonBrain: Bug non reproductible, demande d’information qui ne reviennent jamais, les raisons sont multiples et variées. Et devraient dans ce cas être explicitées… Si on n’arrive pas à reproduire, on ferme le bug en disant qu’on arrive pas à le reproduire. Si on manque d’informations, on les demande. S’il n’y a pas de réponse, on ferme au bout d’un moment. Garder des trucs ouverts et inactifs pendant des années, ça ne fait qu’entretenir de la complexité et du fouillis et faire perdre du temps à tout le monde. KlingonBrain: Dans le monde propriétaire, l’éditeur ne vous répondrait même pas. Oh que si. Quand tu es un client qui paye, je t’assure que tu as des réponses. Et je dis ça par expérience, aussi bien avec des éditeurs, comme Microsoft (qui a même créé le programme Insiders pour collecter encore plus de demandes, en incitant les membres de ce programme à faire des demandes), IBM et Oracle, qu’en tant qu’éditeur, auprès des clients de boîtes pour qui j’ai travaillé.

wackyseb

C’est pas mon domaine alors je vous crois sur parole. Si c’est mieux pour le recruteur (en espérant que le manager a déjà fait du code ou qu’il sait encore le lire).

wackyseb

Ah bon, un logiciel libre payant ??? Ça existe çà ? Mais si on a les sources, on recompile et c’est gratuit du coup ? J’ai dit une bêtise peut être !!

MattS32

Dans un processus de recrutement un peu sérieux, il n’y a pas que le manager qui est impliqué, il y a aussi des développeurs, qui vont faire passer un entretien technique au candidat et qui sont tout a fait capable d’aller regarder son GitHub et de voir ce qu’il a fait de bien ou de pas bien. J’ai même déjà vu des boîtes qui sur le formulaire en ligne pour postuler ont prévu un champ spécifiquement pour saisir l’URL de son profil GitHub. Et parfois l’implication dans l’open source fait même partie explicitement de la fiche de poste (en général quand le poste va justement impliquer de devoir travailler avec la communauté, c’est préférable de prendre quelqu’un qui a déjà un peu d’expérience et de réputation dans le domaine).

MattS32

wackyseb: Mais si on a les sources, on recompile et c’est gratuit du coup ? J’ai dit une bêtise peut être !! Tout dépend de la licence. Tu peux avoir de l’open source extrêmement restreint (un logiciel open source n’est pas forcément un logiciel libre), où par exemple les sources ne sont là qu’à titre informatif, sans que tu ais le droit de compiler, tout comme à l’extrême inverse, tu as des licences qui t’autorisent à faire absolument tout ce que tu veux, même vendre sans indiquer d’où ça vient. Entre les deux, tu as des modèles de licence qui par exemple t’autorisent à utiliser gratuitement le logiciel, original ou modifié, si tu es un particulier ou un organisme à but non lucratif, mais qui t’imposent par contre de prendre une licence payante en cas d’usage commercial. Ou encore, il peut y avoir une version « Community » gratuite pour tous et une version « Entreprise » payante pour tous mais avec quelques fonctionnalités supplémentaires ou du support (ça c’est vraiment un modèle classique : MySQL, MariaDB, PyCharm, MongoDB, DBeaver, Portainer, Docker et bien d’autres…). J’ai même vu des cas tordus de licence « militante » t’interdisant explicitement d’utiliser le logiciel si tu travailles dans tel ou tel entreprise ^^

wackyseb

Je te crois sur parole car c’est pas mon monde

wackyseb

MattS32: MySQL, MariaDB Je les connais celles-là. Le reste pas du tout Heureusement que personne n’audite les PC en entreprise. Qui n’a jamais installé de l’open-source en lousdé, un shareware avec un keygen, ou un freeware interdit en entreprise sauf à payer une licence. Hihi

ld9474

wackyseb: un shareware avec un keygen, ou un freeware interdit en entreprise sauf à payer une licence Ou la la !! Grosse faute des admins quand même !! Si tu installes ce que tu veux sur ton poste pro c’est que tu as des privilèges un peu trop élevés quand même. Quand tu sais que la plupart des virus se propagent comme ca, en général tu vérouilles d’entrée de jeu.

wackyseb

C’était pour imager. L’antivirus bloque les signatures et certains nom donc le keygen serait supprimé d’office. Mais oui sur nos postes on est admin (enfin presque car il existe superadmin). Et pour l’installation de logiciel, un clic droit et lancer en temps qu’admin. Le service compétent est au courant de cette action mais à l’echelle de plus de 400 milles PC, qui regarde les logs ?

ld9474

Ca craint votre truc

wackyseb

Faut pas s’inquiéter. J’ai jamais rencontré de service informatique compétent. Hihi

Voir tous les messages sur le forum

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

La chaîne d'approvisionnement logicielle se fait de plus en plus complexe

Des failles de plus en plus nombreuses, et de plus en plus difficiles à régler

A découvrir en vidéo

Commentaires (45)

Top app & logiciels

Sur le même sujet