barmic 🦦 a écrit 5976 commentaires

Par contre, d'un point de vue sécurité, il n'y a pas eu que des approches « langage » pour réduire l'impact de ces bugs, il y a eu aussi des évolutions prenant des approches différentes, comme la mitigation de ces bugs au niveau OS.

Tout à fait tu peux même avoir une approche architecturale. Par exemple en séparant le code qui gère les IO du code plus critique ou en utilisant en langage plus sûr pour les IO et un langage plus orienté performance pour le code critique.

Mais il faut se rappeler qu'un buffer overflow, sur un OS prenant la sécurité au sérieux, c'est pas aussi facilement exploitable qu'il y a vingt ans.

Il faut voir ce que l'on appel exploitable. L'exécution de code arbitraire c'est rendu plus complexe par exemple avec les pages mémoires non exécutables, mais le simple fait de faire crasher un service peu déjà être une exploitation grave de la faille. Soit parce que tu ne veux pas que ce service tombe, soit parce que faire tomber ce service consomme une partie de tes ressources et donc le faire tomber en boucle peu consommer toutes tes ressources (tout ton CPU, tout ton espace disque, flooder tes alertes monitoring pour cacher une attaque plus sophistiquée,…).

Après, dans l'idéal, les deux approches sont complémentaires, mais certains langages safe ont tendance à faire leur propre gestion mémoire, souvent orientée performance et non sécurité (faisant l'hypothèse zéro bugs dans le compilo), donc certains bugs mémoire dans le compilo peuvent du coup être plus graves, car certaines mitigations ne s'appliquent plus.

Ça me fait penser (je vais avoir du mal à retrouver des pointeurs là dessus) que l'un des grands gap pour la performance mémoire actuellement semble être qu'on utilise une mémoire trop fiable. Si on change les prérequis mémoire, les constructeurs peuvent faire quelque chose de bien plus performant. Ça ajoute de la charge au code, mais ça reste plus efficace. Je crois que c'est dans un GLMF que j'avais lu ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne prétends pas connaître ton métier, je suis quitte plutôt que d'expliquer ce qui peu être fait, tu explique ce qui ne peut pas. Tu délégue la responsabilité comme si tu n'y pouvais rien du tout.

D'autre part quand je dis que l'industrie n'arrive pas à supprimer les buffer overflow et que tu réponds que ça n'existe qu'en test et pas en prod il est logique que je te montre que factuellement, il en existe un énorme paquet qui posent des problèmes de sécurité.

Si tu es un maître codeur j'en suis très content pour toi. Sincèrement. Est-ce que tu arrive à faire des revues ou du pair programming pour éviter que ça se reproduise ? Moi j'arrive bien à avoir un processus de revue, mais j'ai du mal à m'organiser pour du pair programming par exemple et quand j'en fais c'est pas toujours très bien fais malheureusement

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Non, je cherche ce que je peux faire à mon niveau. Ni toi, ni moi, ni l'ensemble des membres qui se sont un jour connecté à linuxfr ne vont changer l'industrie. Par contre on peut se demander ce que l'on peut faire pour améliorer ce que l'on fait.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il y a des raisons à la dégeulasse-itude ambiante des softs, et ça n'a rien à voir avec les solutions techniques pour éviter ça. Les solutions techniques, elle existent depuis 3 décades, et rien n'a changé.

Avant de chercher toutes les excuses du monde, on pourrait d'abord s'intéresser à ce que l'on peut faire nous.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Dans tout ça des problème de buffer overflow? en dev oui, en prod, pas depuis que je suis sur le projet.

Mais oui, ça n'existe pas. C'est ce qui est intéressant avec ce genre de bug, il faut les chercher pour les trouver.

La mauvaises qualité c'est toujours les autres, le système, l'air ambiant, le chat écrasé que vous avez croisé ce matin,… Vous êtes prompte à trouver des raisons externes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le débat reviens régulièrement. Si j'ai bien compris X11 fait ça extrêmement mal d'un point de vu efficacité (les implémentations DRI ne font plus de transparence réseau) et d'un point de vu sécurité. L'idée a était de laisser à ceux qui font ça bien le soin de le faire (VNC, rdp ou spice).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L'autre problème plus subtil est que c'est une mauvaise idée de se dire "pas besoin de programmeurs compétents pour ça, le langage s'occupe de tout".

En même temps personne ne dit ça. Ce qui est dit c'est qu'il est déjà suffisamment complexe d'éviter le bugs pour s'outiller pour en limiter. Pour ça il est possible :

• d'ajouter de la sémantique dans le langage pour que le compilateur puisse déterminer l'absence de classe de bugs complètes
• d'avoir des API plus sûres qui t'empêche de ne pas respecter leur contrat ou qui vérifient leur contrat

Tu as trouvé un bug médiatisé avec Ada ? Combien de bug par an arrivent à cause d'un buffer overflow ? Choses qu'on sait supprimer depuis plusieurs dizaines d'années. En tant que développeur je ne suis pas fier que l'industrie à la quelle je fais parti n'arrive pas à éradiquer ce genre de choses. Le buffer overflow c'est surtout pour du C ou C++, mais le déréférencement de valeur nulle on en a presque partout et on a même des langages qui viennent d'arriver qui continuent d'avoir ce problème ou qui se satisfont de le corriger en partie. Alors qu'on sait supprimer cette forme d'erreur.

Quand on peut avoir un code qui prouve l'inexistence de certains bug ça vaudrait le coup qu'on arrête de faire les flemmards en se trouvant des excuses.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le C++ je sais pas mais toi tu es très difficile à lire. J'ai relu plusieurs fois ton texte. Je pense avoir compris le sens général, mais je suis persuadé qu'il y a des phrases dont il manque des parties ou qui ont été refacto en cours de route. Essai de faire des phrases plus courtes tu sera plus compréhensible.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Perso j'arrête ici, pas possible de continuer avec autant de mauvaise foi. Je ne sais pas qui trouve tes messages pertinents, mais c'est triste.

Ceux qui se sont intéressé aux problèmes et qui ne s'évertuent pas à faire du prosélytisme.

Même la FSF est consciente de cela. Un code est véritablement protégé quand il utilise une licence open source et que les droits sur le code sont partagés. Zenitram le répète à longueur de journée : utiliser la GPL quand on est une entreprise permet de limiter la concurrence car un concurrent qui réutiliserais ton travail est soumis au copyleft est pas toi.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La licence ne s'applique pas à celui qui a les droits du code. Tu peux imaginer. Sortir des phrases de leur contexte mais non, elle ne s'applique pas à celui qui possède les droits sur le code.

C'est bien pour ça que tu as des CLA qui existent. Elles permettent à celui qui possède les droits sur le code de changer de manière incompatible la licence du code ce qui serait impossible si la licence s'appliquait à celui qui possède les droits sur le code.

Tu pourra trouver tout un tas de sources sur les problèmes que posent les CLA entre autre le fait de partager les droits sur le code permet d'obliger chaque détenteurs du droit sur le code à suivre la licence car il ne possède pas les droits sur tout le code.

Le you de la licence c'est celui qui reçoit. Il est dit dès le préambule que le développeur qui choisi cette licence donne des droits pas qu'il s'engage à quoi que ce soit.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comme cité dans le commentaire au quel tu répond on parle on parle au sens strictement juridique. Il n'y a pas de définition juridique de libre au sens que tu l'entends.

Si un éditeur publie un exécutable en proclamant que c'est un logiciel libre mais sans publier le code source, tu penses vraiment que la licence ne contraint pas l'éditeur ?

Alors « libre » n'a pas de sens juridique. S'il dit que son logiciel est sous licence GPL et qu'il ne l'est pas tu peux éventuellement le traiter de menteur, mais pas de violer la licence.

Pour le cas présent c'est éventuellement une question de licence inapplicable. Ça n'est pas illégale. Ça ne fonctionne pas, mais ce n'est pas délictueux. Le fais de choisir une licence n'est pas contraignant.

Je veux bien que tu montre quel passage de la GPL oblige le détenteur des droits, parce que je vais avoir du mal à te montrer l'endroit où ça n'est pas et qu'affirmer toi comme moi des choses opposées n'amène pas à grand chose.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

D'un point de vue strictement juridique, il me semble que livrer les sources sans les build est tout à fait confirme à la GPL.

Comme déjà indiqué plus haut par d'autres, c'est un mensonge malheureusement trop colporté. Ça serait bien de corriger ce poste qui semble être positivement noté…

Il me semble que le détail que tu ne prends pas en compte. C'est que quand tu es unique détenteur des droits sur le code, tu fais bien ce que tu veux et le fais de décider les publier tes sources sous licence GPL ne te contraint pas toi. Elle s'applique à ceux qui reçoivent le code et qui n'ont d'autres droits sur celui-ci que ce tu veux bien leur donner. C'est bien pour ça qu'il est possible de faire de publier sous double licence.

Référence nécessaire : jamais entendu parler. Des problèmes pour enlever les noms de marque, oui, ou pour se dépatouiller des différences avec upstream que Red Hat ne livre parfois pas (i.e. ils filent un gros tarball avec tous les patchs appliqués, ce qui est conforme avec la GPL), peut-être mais pouvoir builder les logiciels est indispensable.

RH n'est pas propriétaire du code, ils n'ont donc pas le choix.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si gimp n'a pas inclu ce format dans gtk ou je ne sais quelle bibliothèque généraliste qu'est-ce qui les pousserait à l'implémenter dans un translator ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Quel temps selon toi prendrait-il à un développeur Junior ( un petit nouveau dans une team, sans expérience en dev fonctionnel ) pour apprendre Elm from scratch et être productif.

Combien de temps je ne saurais dire, mais ça va assez vite. Une partie de ce que tu perds en palier initial, tu le gagne en mur que tu ne prends pas un peux plus tard.

Par contre de mon point de vu (je ne suis pas très friand de html+css), c'est l'écosystème plus faible que chez angular qui va réduire la productivité.

Là où avec angular les compatibilité de langages et la manière de faire du framework permettent d'encapsuler n'importe quoi dans un composant et de s'en servir sans à se soucier de l'implémentation (et donc à le combiner avec n'importe quel autre composant en principe). Avec elm on va plutôt faire ça en dehors de l'application elm et interagir avec via des envoie/réception de messages. Ça permet de continuer de garantir toutes les propriétés qu'elm veut donner à ses utilisateurs. Par contre manipuler le DOM via elm et via autre chose en même temps ne se mélange pas aussi bien. Personnellement j'ai très peu besoin de choses que je ne trouve pas en elm directement et si j'ai besoin de quelque chose d'autres je le met dans une branche bien distincte du DOM.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Reason n’est ni plus ni moins qu’une option dans le compilateur.

Du coup il ne vient pas avec un framework comme elm. C'est dommage parce que c'est une grande part de ce qui fait la force d'elm je trouve. Après il peut être implémenté à coté. Mais je n'en vois aucune trace dans la page de documentation du site officiel.

Ce que je trouve génial avec elm c'est que c'est un langage intéressant avec un framework qui se combinent parfaitement.

Tiens c'est surprenant le lien en dessous indique que reason n'est pas fonctionnellement pur je pensais qu'Ocaml l'était.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Moi je m'en sers et j'en suis très satisfait. Je n'ai effectivement jamais rencontré d'erreurs au runtime avec lui et le compilateur est très gentil. Je n'ai pas vraiment pratiqué de langages fonctionnels purs avant elm et je ne maîtrisais pas bien la syntaxe d'haskel.

Il paraît que Facebook a une alternative dérivée d'ocaml.

Elm vient avec un framework, mais je le rapprocherai plus de redux que de react. Dernier point important c'est qu'il n'y a pas de bibliothèque de composants directement utilisable.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Flatpak installé a tout cassé

Ça n'est pas possible si j'ai bien compris. Tout au plus il peut avoir quelques logiciels qui interagissent avec ce flatpak qui vont fonctionner bizarrement.

Encore une fois, faut voir ce que vous voulez

Moi perso je ne veux rien, je laisse les gens qui font faire. Je ne vois pas pourquoi avoir une ambition quelconque si c'était le cas au lieu de répondre à des commentaires sur un sites d'aigris je contribuerais. Ta question n'a pas de sens pour des gens qui ne sont pas aux commandes d'une distribution. Nous, quidam de linuxfr, nous pouvons vociférer autant que l'on veut ça n'a pas vocation à être « volonté de la communauté linux ».

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le fait de ne pas du tout contribuer, même pas un commentaire succinct de remerciement ou une contrib au wiki, c'est quand même assez suspect […]

Ah bon ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est surprenant d'utiliser screen comme ça. Moi je préfère utiliser juste Emacs. Tant que je n'ai pas besoin de sessions persistantes (et encore je ne suis pas sûr que ça n'existe pas dans emacs), je préfère amplement tout faire via emacs. C'est plus logique et nettement mieux intégré.

Si je ne trouve pas de sessions persistantes dans emacs, j'utiliserai screen (ou tmux) uniquement pour ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Non, les gestionnaires de paquets ne sont pas des solutions à l'arrache (dire ca c'est un peu insulter les devs des distributions en fait)

Je n'insulte personne, j'affirme qu'un gestionnaire de paquets avec gestion des dépendances ça n'a rien de triviale. On revois éternellement de nouvelles personnes arriver en expliquant que ce qu'ils font c'est plus simples alors qu'ils ont surtout réimplémenter les bugs corrigés il y a longtemps chez leurs prédécesseurs. Critiquer leur travaux ce n'est pas les insulter ou alors je pourrais te répondre que ces gens qui pensent réimplémenter des gestionnaires de paquets en quelques semaines insultent leurs prédécesseurs.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'ai jamais vu de chartes des paquets d'une distribution linux. Si tu en as une sous la main, ça m'intéresse. On peut considérer la définition du logiciel libre selon Debian, mais ça me paraît assez loin de ce dont tu parle.

Tu amalgame une techno avec son usage. FP peut travailler sans dépôt, c'est potentiellement gênant effectivement. Ça fait perdurer des usages dangereux comme on l'a déjà aujourd'hui (en particulier via curl ... | sh). Mais il donne la possibilité de faire de la distribution logiciel hors distribution linux. Tu peux voir la fondation Apache créer le sien par exemple pareil pour gnu. Les innombrables projets qui créent leur propre dépôt debian (mongo, docker, chrome,…) peuvent faire un travail plus universel et ne pas laisser sur le carreau les utilisateurs de distributions trop exotiques. Enfin ça peut être utile pour des choses comme debian-multimédia.

La multitude de gestionnaire de paquets elle est d'abord du fait des distributions linux qui chacune se sent obligée de montrer qu'elle est différente. Ensuite là il y a une solution concerté qui a une chance et vocation à remplacer toutes les méthodes à l'arrache que l'on a aujourd'hui.

FP ne fait pas le café, il ne fait pas revenir l'être aimé, il est juste une proposition pour passer d'une situation pourrie à un peu moins mieux.

Et mon dieu, c'est clair qu'il n'est pas parfait…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La boîte qui ne me laisse pas admin de ma machine, elle ne va pas me voir longtemps…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Cette comptine ne fonctionne que pour les formats, les standards et tout ce qui revient à des interactions. Tu ressemble à l'existant, tu en fais plus et une dis que tu es suffisamment gros tu as la main mise sur le domaine.

Tu ne peux pas faire ça avec un éditeur de texte.

Surtout qu'une bonne partie de l'intelligence du truc a été volontairement architecturée pour être utilisable ailleurs et est utilisé ailleurs (par eclipse par exemple). Et ça résous un casse tête pour les créateurs de langage.

Donc au lieu d'affirmer que les gens ont des problèmes de mémoire, je veux bien que tu nous montre que tu n'as pas de problème de compréhension de ce que tu met en lien ;)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne suis pas d'accord. Je ne considère vraiment pas le web comme étant une fonctionnalité essentielle à un IDE python. C'est tellement pas essentiel que je l'utilise depuis 5 ans en version community sans frustration. J'ai essayé la version ultimate, j'en ai même une licence avec la boîte où je travaille, mais la version community me convient amplement.

Par contre j'ai arrêté les EAP de la version 2019.4 qui n'étaient pas très stables.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai pas tout compris, mais, si tu pense que le C est immunisé à ce genre de choses, il faudra en parler aux développeur du noyau linux : https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll