« À travers cet article, je ne veux pas vous décourager d'utiliser Linux sur desktop. Je souhaite simplement qu'une partie de ses utilisateurs cessent de propager des paroles partisannes dénuées de technique… »
Voici le propos dénué de technique et parfaitement partisan qui me tient lieu d'opinion sur le sujet :
En utilisant des logiciels libres, on utilise généralement des codes développés avec une certaine bienveillance. Il arrive nécessairement que des gens introduisent des failles volontairement, surtout sur des composants critiques ; et on pense nécessairement aux activités de tous les services de renseignements qui peuvent avoir intérêt à introduire des faiblesses cryptographiques, ou des chemins de traverse pour détourner des données.
L'utilisateur de code privateur n'est lui globalement pas respecté — à raison selon moi. On le voit à la quantité de codes diffusant des publicités, demandant des droits surdimensionnées au regard des tâches à accomplir, appelant régulièrement la maison mère sans que cela soit dans l'intérêt évident du client… À tous égards généralement, l'utilisateur de code privateur est pris pour une poire et c'est un pléonasme. Après tout, il se déleste volontairement de sa liberté, alors pourquoi mériterait-il la moindre sécurité (cf. Tocqueville, De la démocratie en Amérique) ? Probablement n'a-t-il pas la compétence nécessaire…
Ma petite expérience personnelle appuyant ce raisonnement purement politique (car je n'ai aucune compétence technique en matière de sécurité) : à l'époque où j'utilisais windos — la version 98 — connecter une machine neuve à internet était problématique. Elle se retrouvait vérolée avant d'avoir eu le temps de télécharger le pare-feu qui aurait permis de la protéger. Il fallait donc télécharger le dit logiciel, et l'installer hors-ligne avant de pouvoir brancher le modem. Sur Linux, aucun problème de ce type. Inutile de configurer iptables ou tcp-wrapper. Aucun logiciel n'était disposé à communiquer tout et n'importe quoi avec l'extérieur. Tout simplement l'absence de malveillance.
Conclusion : assurément d'un point de vue purement technique il reste des progrès à faire concernant la sécurité. Nonobstant les considérations politiques et éco-systémiques (celles énoncées ci-avant et bien d'autres) pondèrent cela de manière très sensible. L'article n'est d'ailleurs pas totalement hermétique à ces considérations mentionnant que le peu d'utilisateurs incompétents de GNU/Linux joue certainement un rôle dans la réputation [bien fondée] de ces systèmes.
Remarquons aussi que, même pour un non-techniciens absolu, les informations de cet article de propagande politique semblent surannées. Notamment les remarques sur X. Il serait intéressant de voir comment l'auteur se débrouillera pour récupérer les mots de passe d'un autre utilisateur sur une distribution moderne via ce canal… À j'oubliais, tout passe par des logiciels nécessairement malveillants… Un client une victime mirosoft typique en somme.
Le soucis un peu, c'est que les méthodes de mitigation sous Linux ne sont pas très simples, donc non activées par défaut.
Après, l'article est exagéré pour une utilisation desktop typique (au sens, typique pour un windosien auquel on compare) : souvent le seul logiciel qui communique avec des méchants probables est le navigateur (beaucoup l'utilisent même pour le mail), donc en termes de mitigations, ce qui est vraiment prioritaire, c'est d'empêcher le navigateur de pouvoir faire trop de choses.
Sous OpenBSD, avec unveil on s'assure que le navigateur ne peut accéder qu'à ~/Downloads et son cache, ce qui limite pas mal les dégâts, et pledge évite de donner accès à trop d'appels systèmes. Avec Linux, on n'a pas de moyen super simple de faire pareil. Un truc facile quand même, c'est de lancer le navigateur avec un autre utilisateur qui ne peut pas lire le home de l'utilisateur principal (je fais ça lorsque j'utilise Linux, c'est mieux que rien et ça coûte pas cher).
Posté par Denis BRAUSSEN .
Évalué à 5.
Dernière modification le 10 février 2021 à 21:38.
ce qui est vraiment prioritaire, c'est d'empêcher le navigateur de pouvoir faire trop de choses.
Sous OpenBSD, avec unveil on s'assure que le navigateur ne peut accéder qu'à ~/Downloads et son cache, ce qui limite pas mal les dégâts
Sous linux il y a firejail qui peut faire tourner firefox (entre autres) dans une jail. En paramétrant un peu on peut également avoir un répertoire de "downloads" persistent. En plus c'est facile à mettre en œuvre.
Je cite:
Firejail est un programme SUID qui réduit le risque de failles de sécurité en limitant l'environnement d'exécution des applications non fiables en utilisant les espaces de noms Linux et seccomp-bpf. Il permet à un processus et à tous ses descendants d'avoir leur propre vue privée des ressources du noyau globalement partagées, telles que la pile réseau, la table de processus, la "table de montage" (mount table).
C'est vrai que firejail est assez simple d'utilisation pour les logiciels pré-configurés, même si la technologie derrière est plus complexe (un niveau d'indirection en plus, puisqu'il faut un processus pour en surveiller un autre). Cela dit, à ma connaissance, aucune distribution (du moins connue) ne remplace par défaut firefox par firejail firefox.
Posté par vv222 (site web personnel) .
Évalué à 3.
Dernière modification le 12 février 2021 à 19:24.
en termes de mitigations, ce qui est vraiment prioritaire, c'est d'empêcher le navigateur de pouvoir faire trop de choses.
C’est dommage que depuis des années tout avance exactement dans le sens contraire…
Le navigateur est devenu un nouvel OS dans l’OS. Et à mon avis c’est très con.
Les deux plus gros obstacles à la sécurité sous Linux sont Google et Mozilla.
Ce serait quoi une solution du coup ? Les navigateurs utilisent des solutions comme seccomp, ce n'est pas suffisant et bloquer au niveau système les accès ne convient pas plus (tu dis pas que ça ne va pas assez loin ou que ce n'est pas parfait, mais que ce n'est pas la bonne direction). Je ne vois pas ce qu'elle autre option est possible ('fin j'ai une idée, mais je préfère éviter de faire des suppositions).
Mettre fin au "tout Web", au profit des applications natives.
Le navigateur Web est devenue une telle faille de sécurité ambulante uniquement parce que tout passe par lui, s'il ne servait qu'à "afficher des pages Web" on n'aurait pas besoin de toutes ces bidouilles pour tenter de reboucher la passoire.
Je ne souhaite pas qu'on chercher à réparer les navigateurs Web, ça me semble une cause perdue, mais qu'on réduise leur impact global dans notre utilisation des outils informatiques. En bonus ça donnerait une bonne claque au pouvoir démesuré des GAFAM et autres vendeurs loueurs de nuages.
En bonus ça donnerait une bonne claque au pouvoir démesuré des GAFAM et autres vendeurs loueurs de nuages.
Je vois pas le rapport. Il n'y a plus de serveur sans navigateur ? Les GAFAM ne vont pas proposer d'applications natives (ce qu'ils font déjà quand c'est utile) ?
Ce que je pense (et est sûrement discutable) est que ces GAFAM sont indélogeables dans tout ce qui touche aux services en ligne, ils ont trop d’avance et d’emprise dans ce domaine. Par contre il y a peut-être une chance pour d’autres acteurs du côté des applications natives, il suffit de voir VLC dans le domaine de la lecture de vidéo, ou GIMP et Krita pour la manipulation d’images, ou encore Blender dans la 3D…
Je suis incapable de citer un acteur similaire dans les services en ligne qui ne soit pas directement un GAFAM, une succursale d’un GAFAM, ou dépendant de l’infrastructure d’un GAFAM.
Par contre il y a peut-être une chance pour d’autres acteurs du côté des applications natives, il suffit de voir VLC dans le domaine de la lecture de vidéo, ou GIMP et Krita pour la manipulation d’images, ou encore Blender dans la 3D…
Et tu peux en citer un qui a moins de 15 ans ? Ça n'est pas du troll quel logiciel libre (qui est une application de bureau) de moins de 15 ans est arrivé à avoir ce genre de succès ?
Je suis incapable de citer un acteur similaire dans les services en ligne qui ne soit pas directement un GAFAM, une succursale d’un GAFAM, ou dépendant de l’infrastructure d’un GAFAM.
En vrai je pense que le problème sous-jacent c'est que l'écosystème libre n'a pas envi de comprendre qu'un service ne peux être libre au sens où on l'entend pour un logiciel et que ça a bien plus d'impact qu'on ne veux bien le croire.
Mais remplacer un client web par un client en C++ ne changera rien à ça.
En résumé : j'ai essayé de faire un paquet flatpak, mais c'était si mal documenté et buggé, que j'ai fini par me tourner vers Appimage.
Je ne suis pas anti flatpak, mais avant de le réessayer, j'aimerais être sûr qu'il gère les projets java/maven et qu'un même paquet fonctionne sur deux distribs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
C’est dommage que depuis des années tout avance exactement dans le sens contraire…
La mise en place de seccomp, pousser pour l'utilisation de langage memory safe, mettre en place des bac à sable comme webassembly,… qui non content d'aider à la sécurité des navigateurs, aident pour l'ensemble des écosystèmes (même webassembly est utilisé dans des environnements cloud pour faire du faas à bas coût ou dans postgres).
Je présume que tu parle du fait de proposer des API pour interagir avec le matériel ?
Je présume que tu parle du fait de proposer des API pour interagir avec le matériel ?
Non ;) (enfin, si, ça fait partie de ce que je dénonce, mais ce n'en est qu'un point de détail)
Je parle de la dérive en cours depuis bien plus longtemps que ça de tout faire via le navigateur Web. Sorti de quelques "geeks", c'est même la seule application native à tourner sur le système.
C'est fini GNU/Linux, on est maintenant sur Firefox/GNU/Linux ou Chrome/GNU/Linux. Et c'est dans ce Firefox ou ce Chrome que tournent toutes nos applications.
Ton lecteur vidéo, ton MUA, etc mettent quoi en place pour la sécurité ?
Je ne suis pas convaincu que :
les autres logiciels soient mieux sécurisés
que des modèles d'attaques multilogiciels ne soient en soit plus sécurisé ça diminue le couplage, mais ça tue aussi la cohésion (hors de certains systèmes comme aiku, des environnements pure KDE, pure Gnome, pure cocoa, mais ça représente très peu d'utilisateurs dans le monde). Contrôler la sécurité d'un logiciel est largement plus simple et les seccomp(j'ai pas de nom générique pour ce genre de méthode) et bac à sable sont extrêmement efficace pour ça. Tu contrôle un unique point d'entrée. Plutôt qu'une multitudes. Chacune se veut plus simple, mais ce n'est pas dis et il faut que chacun se comporte d'une façon. En plus multiplier les logiciels pour chaque usage… Ça laisse la porte à ce que chaque service vienne avec le logiciel. Tu veux regarder twitch ? Install twitch ! Tu veux utiliser google drive ? Ils ont un logiciel pour ça !… Android me semble être un bon exemple du fait que ça n'est pas ouf comme sécurité malgré le fait d'utiliser des bac à sable.
On peut se plaindre des usages, mais je ne vois pas aujourd'hui d'alternatives qui apporte ne serais-ce que quelque chose d'après près aussi efficace (au sens qualité logiciel) ou pratique.
Ton lecteur vidéo, ton MUA, etc mettent quoi en place pour la sécurité ?
Facile : mon lecteur vidéo ne sert qu'à lire des vidéos, mon client mail ne sert qu'à lire et envoyer des mails. La surface d'attaque et plus globalement les possibilités de failles sont immensément réduites par rapport à un navigateur Web qui se prend pour un OS complet.
VLC n'a pas besoin de savoir traiter une pièce-jointe malicieuse, pas plus que Thunderbird n'a besoin de bloquer une éventuelle vidéo piégée.
Tu pense que les usages ce sont figés en 2010 ? Twitch par exemple tu le gère comment (un flux vidéo + un chat qui doivent être un minimum synchronisé) ? Les traitements de texte à plusieurs tu as quelque chose de standard pour le faire ?
Tout doit passer par l'IETF puis être implémenter ? Tu vois comment ça fonctionne avec XMPP ?
des services, régulièrement des GAFAM, innovent
des gens intéressaient par xmpp proposent des xep
entre le moment où la fonctionnalité est apparue et que ça ai infusée suffisamment pour être utilisable, il faut au moins 5 ans et le réseau n'a jamais atteins suffisamment d'utilisateurs pour que ça ai de toute manière une importance…
Euh, pourquoi ce serait à moi de proposer une alternative à Twitch ? Ou à un système de traitement de texte synchronisé ? (pour ma part ces deux machins peuvent disparaître sans aucune alternative, sans pour autant me manquer)
Et surtout, pourquoi je devrais avoir une réponse à chacune de ces questions avant d’être autorisé à critiquer le système actuel ? Je ne suis ni à l’origine d’un de ces services, ni consommateur de ceux-ci, et surtout je ne vais pas me lancer dans de longues études d’architecture logicielle pour obtenir un quelconque "certificat d’expertise" qui m’autoriserait à critiquer les solutions en place.
Il ne s'agit là que de quelques exemples pour montrer que ta démarche ne peux fonctionner.
Soit tu contrains les gens à un périmètre limiter d'usages (mail, gemini, téléchargement p2p et xmpp).
Soit il va falloir accepter qu'il ne se passe pas quelques mois sans que de nouveaux usages apparaissent.
Je ne t'ai pas interdit de t'exprimer, je tente de pointer du doigt la limite du monde que tu décrit. Tout comme tu remet en cause les démarches de sécurité des navigateurs.
Loin de unveil, mais on est dans l'idée avec AppArmor ou SELinux non ? Mais c'est vrai que ce n'est pas super simple pour l'utilisateur qui sort un peu du cadre prévu par la distro.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Tu rejoins mon opinion profonde.
Au dela des points techniques, il y a une philosophie et une éthique.
Personnellement j'accepte des logiciels imparfaits, ou de ne pas utiliser du matériel Apple parce que je soutiens ce combat politique, ce qui se fait parfois au détriment de la technique: disponibilité, fonctionnalités, sécurité, drivers…
A chacun ses combats.
Tout en soulignant qu' Ubuntu est bien accepté par des néophytes, et que malgré tout, le plan technique est de mon point de vue globalement satisfaisant.
En utilisant des logiciels libres, on utilise généralement des codes développés avec une certaine bienveillance.
Ca me parait un peu rapide comme assertion et non étayée, mais pourquoi pas. Et même si c'est vrai, en quoi est-ce un gage de sécurité accrue?
Il arrive nécessairement que des gens introduisent des failles volontairement
encore une fois non étayé, mais mettons que oui. En quoi la bienveillance empêche un repo quelconque de recevoir une PR avec une backdoor très subtile? et de merger ce code?
À tous égards généralement, l'utilisateur de code privateur est pris pour une poire
je dirais oui.
Après tout, il se déleste volontairement de sa liberté, alors pourquoi mériterait-il la moindre sécurité
Les parasites aiment garder l'hôte vivant. Si les systèmes privateurs avaient une sécurité proche de 0, alors ils ne pourraient pas fonctionner. Voir ton anecodte sur un windows98 ou la machine est vérolée avant d'avoir fait quoi que ce soit. Les systèmes privateurs mettent un accent énorme sur la sécurité (pour conserver précieusement les données récoltées par eux-mêmes, certes.)
Sur Linux, aucun problème de ce type. Inutile de configurer iptables ou tcp-wrapper. Aucun logiciel n'était disposé à communiquer tout et n'importe quoi avec l'extérieur. Tout simplement l'absence de malveillance.
Bin, non, puisque comme le dit l'article de medium, c'est le user qui tape "pip install machin" et que tu peux sans difficultés mettre de la vérole dans "machin".
L'article n'est d'ailleurs pas totalement hermétique à ces considérations mentionnant que le peu d'utilisateurs incompétents de GNU/Linux joue certainement un rôle dans la réputation [bien fondée] de ces systèmes.
Dernièrement on apprenait que sudo a trainé une faille de sécurité pendant 10 ans (!!!!). Utilisateurs incompétents? Code review? Croyance infondée que c'est le voisin qui surveille le code de l'autre? Naïveté? Je sais pas, mais il semble qu'il y ait beaucoup de pieds d'argile chez le colosse linux.
Pour compléter, il ne faut pas toujours manger au même râtelier.
Même s'il y a des "chanceux" qui peuvent ne vivre que du libre, je crois que pour une majorité (je n'ai pas de chiffre à l'appui), c'est du code propriétaire, et s'il reste du temps et de l'énergie, du libre.
Perso, j'essaye de fournir une qualité de code constante, peut importe libre ou pas libre au final.
à l'époque où j'utilisais windos — la version 98 — connecter une machine neuve à internet était problématique.
Oui, enfin c'etait il y a 22 ans, la sécurité de Windows à quand même bien évoluée depuis. La comparaison n'est pas vraiment pertinente. Surtout que Windows est (et était) aussi bien plus ciblé que Linux.
Notamment les remarques sur X. Il serait intéressant de voir comment l'auteur se débrouillera pour récupérer les mots de passe d'un autre utilisateur sur une distribution moderne via ce canal…
Une distribution récente comme Ubuntu 20.04 ? Car oui Ubuntu 20.04 utilise encore X. Plus toutes les autres distribution qui même avec Wayland utilisent encore un serveur X pour les applications qui ne sont pas compatibles Wayland.
Tout simplement l'absence de malveillance.
Justement, la bienveillance ne suffit pas. On a beaucoup d'exemples d'applications "bienveillantes" qui se mettent à avoir un comportement malveillant, après un piratage du projet, de ses canaux de distribution ou un changement de mainteneur par exemple. Et on ne parle pas d'une attaque un peu plus ciblée, qui viserai une entreprise par exemple.
Et le problème c'est que -par défaut- peu de chose protège le système dans ces cas la.
Clairement les systèmes Linux peuvent beaucoup améliorer leur niveau de sécurité.
Mais certains points de l'article me paraissent discutables:
Désactivation de Secure Boot: plusieurs distros permettent d'utiliser Secure Boot, telles que Fedora, Debian, etc. Même si Secure Boot peut théoriquement être contournée à cause d'une faille récente dans Grub.
X11 est un trou de sécurité: certainement, et c'est pour ça que Wayland existe, et qu'il est activé par défaut sous Fedora.
CVE non corrigée sous Debian pour Chromium: je ne pense pas que ça soit un exemple représentatif de la réactivité de Debian pour corriger des CVE. Chromium est un cas particulier car sa maintenance est difficile, d'ailleurs le wiki Debian recommande de ne pas l'utiliser pour cette raison. Debian est probablement une des distributions non rolling release les plus rapides et productives pour corriger des CVE.
Sandboxing Flatpak inutile: en quoi est-il inutile ? Intéressant pour un article qui prétend se baser sur des faits de balancer une affirmation sans arguments.
Utilisation de langages non memory safe: je sais qu'il y a une certaine hype autour de Rust (à bon escient) mais tous les OS couramment répandus sont aussi écrits C à ma connaissance.
Globalement c'est vrai qu'aujourd'hui que pas mal de distros Linux n'ont pas vraiment d'avantage technologique majeur au niveau sécurité sur Windows ou MacOS. Certaines distros sont plus "durcies" que d'autre par défaut (Fedora avec SELinux par exemple).
Ces trois systèmes ont régulièrement des failles plus ou moins majeures qui sont découvertes et publiées.
Mais justement Linux est devenu tellement important au niveau infra que beaucoup d'acteurs s'impliquent pour améliorer la situation à ce niveau, ce qui est rendu possible par le modèle ouvert de Linux.
Je ne pense pas que ni Windows ni MacOS aient autant de personnes impliquées dans l'exploration et la correction de problèmes de sécurité que Linux.
Mais clairement utiliser Linux n'est pas suffisant au niveau sécurité, il faut avoir toute une politique autour pour l'utiliser de manière sûre.
X11 est encore utilisé par défaut sur Ubuntu 20.04, et même pour les distributions utilisant par défaut Wayland, il y a toujours le serveur X11 utilisé pour les applications ne supportant par encore Wayland, qui peut poser le même genre de problèmes, même si limités à un scope plus restreint, mais qui inclut quand même Chromium et Firefox.
Flatpack à 2 problèmes principaux. Le premier c'est que les permissions de la sandbox sont définies par l'application et sont beaucoup trop ouvertes pour la majorité des paquets (par exemple accès à tout /home, voir à tout /). Le second c'est le délais de mise à jours des frameworks. En plus il y a d'autres points qui pourraient être améliorés, comme le profil seccomp ou l'accès à X11. Cet article en parle, avec en plus d'autres problèmes de sécurité sur Linux.
Mais justement Linux est devenu tellement important au niveau infra que beaucoup d'acteurs s'impliquent pour améliorer la situation à ce niveau, ce qui est rendu possible par le modèle ouvert de Linux.
Je ne pense pas que ni Windows ni MacOS aient autant de personnes impliquées dans l'exploration et la correction de problèmes de sécurité que Linux.
C'est probablement valable pour le noyau et d'autres briques systèmes, mais je suis pas sûr pour le desktop. Déjà que certains programmes ou librairies comme OpenSSL ou Curl ont montrés qu'être extrêmement populaire ne signifie pas un apport de moyen humain et ou financier, je doute que Gnome/KDE/Wayland/… et les différentes distributions pour l’intégration aient plus de moyen que les équipes sécurités Windows ou Android
X11 est encore utilisé par défaut sur Ubuntu 20.04, et même pour les distributions utilisant par défaut Wayland, il y a toujours le serveur X11 utilisé pour les applications ne supportant par encore Wayland, qui peut poser le même genre de problèmes, même si limités à un scope plus restreint, mais qui inclut quand même Chromium et Firefox.
XWayland ne permet pas de se comporter comme X11, à savoir avoir une vue globale sur l'écran et les entrées. C'est quand même une sacrée différence.
Notons que Firefox prend en charge Wayland.
Flatpack à 2 problèmes principaux. Le premier c'est que les permissions de la sandbox sont définies par l'application et sont beaucoup trop ouvertes pour la majorité des paquets (par exemple accès à tout /home, voir à tout /).
L'utilisateur peut comme sur Android révoquer les accès finement de chaque application. L'application Flatseals permet de le faire graphiquement.
Idéalement il faudrait comme sur Android pouvoir voir et changer ça lors de l'installation de l'application, mais en tout cas cela reste paramétrable par l'utilisateur.
Le second c'est le délais de mise à jours des frameworks.
Problématique pas différente des distro, c'est une question éventuellement d'avoir suffisamment de bras mais pas de technos.
XWayland ne permet pas de se comporter comme X11, à savoir avoir une vue globale sur l'écran et les entrées. C'est quand même une sacrée différence.
Effectivement il n'y a pas la vue globale, mais toutes les applications qui utilisent XWayland partagent le même serveur X, donc elle peuvent s'espionner entre elles. Et c'est encore plus problématique quand les applications sont par exemple Chromium, Firefox et KeepassXC. Je viens de tester, une application lancée sur XWayland arrive à récuperer les entrées clavier de KeepassXC
Notons que Firefox prend en charge Wayland.
Oui, effectivement, j'aurais du être plus précis. Firefox supporte Wayland, mais ne l'active pas par défaut, et je crois que seule Fedora l'ai fait.
L'utilisateur peut comme sur Android révoquer les accès finement de chaque application. L'application Flatseals permet de le faire graphiquement.
C'est plutôt bien, mais dommage que ce ne soit pas dans les fonctions par défaut du projet.
Mes derniers tests de Flatpack remontent à presque 2 ans, et à l’époque une application pouvait mettre à jour ses permissions sans avertir l'utilisateur. Est-ce encore le cas ? Que se passe t'il avec Flatseal ?
Problématique pas différente des distro, c'est une question éventuellement d'avoir suffisamment de bras mais pas de technos
La problématique est la même, mais ça ajoute une source de failles. Les distributions majeures font quand même du très bon boulot et sont réactives. Mais la on ajoute les frameworks Flatpak et en plus les applications Flatpak et les librairies bundled. Il y a plusieurs articles qui pointait le problème il y a quelques années, avec dans plusieurs cas des delais de plusieurs mois entre le fix d'une faille critique et son arrivé dans le paquet Flatpak. La situation à peut-etre évolué.
Je serais moins critique que l'auteur de l'article sur Flatpak, mais globalement, dans sa configuration par défaut, ça ne résout que très peu de problèmes de sécurité, mais c'est aussi un axe d’amélioration.
Posté par Anonyme .
Évalué à 9.
Dernière modification le 10 février 2021 à 16:58.
Le second c'est le délais de mise à jours des frameworks.
Problématique pas différente des distro, c'est une question éventuellement d'avoir suffisamment de bras mais pas de technos.
Je suis mainteneur de plusieurs paquets dans Debian et je package aussi une application sur Flathub1 (qui pue, qu’est pas libre).
La grosse différence entre les deux environnement c’est que dans Debian, à chaque fois qu’il y a eu un problème sur un de mes paquets, quelqu’un de plus compétent que moi a fait le taff de corriger (ou au moins a fait une PR). Quand j’ai empaqueté prometheus-exporter-exporter, ça c’est fait en discutant en quasi direct avec l’équipe Prometheus, quand je vois passer des bugs sur des dépendances qui cassent mes paquets, je sais qu’ils vont corrigé sans que j’ai à bouger le petit doigt, etc.
Sur Flathub, la seule interaction que j’ai eu avec des mainteneurs c’était quand j’ai ouvert la PR pour ajouter l’application dans le dépôt.
Donc ouais, les problématiques sont probablement les mêmes, mais les communautés sont loin d’être équivalentes. J’ai 1000 fois plus confiance en une communauté organisée de mainteneurs qu’en une suite d’individus, chacun s’occupant seulement de son petit bout de terrain et sans aucune interaction les uns avec les autres.
Qu’on se comprenne, j’aime bien Flatpak et j’utilise des applications venant de Flathub, mais je préférai toujours le paquet Debian au flatpak de FlatHub. D’ailleurs, les applications que j’utilise c’est principalement du non-libre, ou qui ne sont pas dans Debian (exemple, Slack et Zoom au bureau, Signal-Desktop en perso).
J’ai absolument aucune idée de ce que je fais, j’ai un bot qui ouvre des PR quand l’application est mise à jour upstream donc je les merge, mais mon taff s’arrête là. ↩
Wayland et Flatpak sont deux gros bonds en avant à ce sujet et c'est plutôt bien. Le problème de fond et qui pourra se résoudre à (très) long terme c'est l'abandon de langage non-sûr comme C/C++ pour les briques bas niveaux et remplacés par Rust. Ça arrive déjà et avec des mauvaises surprises
Est-ce vraiment une surprise ? Si on code dans un langage non porté sur la plupart des plateformes, faut-il vraiment s'étonner d'obtenir un code qui ne soit compatible qu'avec la plateforme ultra dominante (et apparemment aussi la plus trouée en matière de sécurité matérielle) ?
Il ne faut pas croire que Rust va résoudre tous les problèmes de sécurité par magie. Certainement ça permet de réduire une certaine classe d'erreurs, mais refaire X11 en Rust par exemple n'apporterait pas grand chose niveau sécu.
Java (puis tout un tas de langages) ont remplacés C et C++. C'est juste qu'ils ne l'ont pas fait sur tous les usages de C et C++. Je suis d'accord que sur l'usage de C et C++ actuel java ne semble pas le plus pertinent, mais en 95 quand java est sorti ce n'était pas le cas.
Ce qui aurait été vraiment intéressant c'est un "safe C". Un C compatible à 90% avec l'existant, mais sans les pièges. Mais c'est sans doute plus fun de créer un langage vraiment nouveau.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Et pas possible d'avoir un "safe C" comme tu le décrit. Changer la sémantique de la mémoire, retirer les pointeurs nus, retirer les malloc()/free(), ajouter toutes les sémantiques pour les remplacer (type somme pour vraiment faire bien par exemple ?).
Le sous-ensemble de C++ compatible avec C et le sous-ensemble qui ajoute de sécurité mémoire sont grosso modo 2 langages distincts.
Ce qui aurait été vraiment intéressant c'est un "safe C". Un C compatible à 90% avec l'existant, mais sans les pièges. Mais c'est sans doute plus fun de créer un langage vraiment nouveau.
Vu la popularité de C, si c'était vraiment possible de faire un langage à la fois très compatible et très sécurisé, il est très probable que ça aurait déjà fait. Et des gens très pragmatiques (genre Microsoft, Amazon, Google, des gens guidés par le fun de toute évidence) ne s'embêteraient pas à partir sur un nouveau langage s'ils pouvaient économiser énormément de temps et d'argent avec un tel langage.
Ou d'autres communautés qui apprécies beaucoup le C et la sécurité comme les gens d'OpenBSD. Ils font des choses pour améliorer la sécurité du C en remplaçant certaines API principalement d'ailleurs.
Posté par anaseto (site web personnel) .
Évalué à 4.
Dernière modification le 10 février 2021 à 18:54.
En même temps, il parle de briques bas niveau, pour lesquelles Java n'est pas utilisable.
Cela dit, pour le bas niveau, Rust fait beaucoup d'usage d'unsafe (inévitable), ce qui réduit quand même beaucoup ses garanties. Quand on compare Rust et C pour une application haut-niveau, Rust est un clair gagnant, mais alors Java ou Go est souvent possible aussi, sauf besoins en performance particuliers. Pour du très bas niveau, l'intérêt de Rust est paradoxalement moins impressionnant, je trouve.
Après, il y a aussi la question des bugs dans le compilo. Par exemple, Java utilise un JIT, et un particulièrement complexe, donc le potentiel de bugs problématiques dans le compilo qui conduisent à des problèmes de sécurité est a priori non négligeable. Rust a un compilateur assez complexe aussi, malgré l'absence de JIT, donc le risque n'est pas exclu non plus.
En même temps, il parle de briques bas niveau, pour lesquelles Java n'est pas utilisable.
C'est probablement discutable, maintenant que tu peux compiler java en natif. C'est bien plus récent que rust et donc avec un écosystème bien moins mature et complet.
Après je ne sais pas s'il est pertinent pour autant, mais ce n'est plus impossible.
Après, il y a aussi la question des bugs dans le compilo.
J'aurais plus mis en cause la machine virtuelle que le compilateur perso.
J'aurais plus mis en cause la machine virtuelle que le compilateur perso.
La machine virtuelle fait du JIT, donc combine le gros de la complexité d'un compilateur et celui d'une machine virtuelle traditionnelle (genre Perl), mais en pire (il y a des processus de décision assez complexes pour décider quoi compiler en natif à la volée et quand ce n'est pas possible ou non rentable).
Pour la compilation native, je connais pas bien les détails, mais j'imagine que ça met un sous-ensemble de la JVM (a priori plus simple) et le programme dans un même exécutable.
La machine virtuelle fait du JIT, donc combine le gros de la complexité d'un compilateur et celui d'une machine virtuelle traditionnelle (genre Perl), mais en pire (il y a des processus de décision assez complexes pour décider quoi compiler en natif à la volée et quand ce n'est pas possible ou non rentable).
C'est une façon de voir les choses. Par contre je ne sais pas ce qui est plus complexe entre interpréter un byte-code et compiler un byte-code vers du natif et exécuter ce natif (ce que font les JIT).
Pour la compilation native, je connais pas bien les détails, mais j'imagine que ça met un sous-ensemble de la JVM (a priori plus simple) et le programme dans un même exécutable.
Globalement tu as la bibliothèque standard de java, le garbage collector et ton code.
Si c'est le garbage collector qui te fais peur pour certains usages, il faut savoir que java a toujours pu traiter des données hors de la heap, c'est à dire non géré par le gc. Tu ne peux pas totalement le retirer évidement.
Par contre évidement tu n'a plus les même garanties sur la mémoire. Je ne crois pas qu'on puisse avoir toutes les garanties sur la mémoire à coût 0 sauf à prouver son programme ou à en générer le code par des automates qui vérifies certaines propriétés (mais ce qui revient au même tu dois démontrer à ton automate que tu gère correctement ta mémoire).
Peut être que la solution jadis envisagée par sun de prouver la JVM puis de l'implémenter en hardware permettrait d'avoir à la fois de grandes garanties tout en ayant une performance très correcte.
C'est une façon de voir les choses. Par contre je ne sais pas ce qui est plus complexe entre interpréter un byte-code et compiler un byte-code vers du natif et exécuter ce natif (ce que font les JIT).
Les JIT font souvent les deux : ils analysent les bouts de bytecode fréquemment exécutés et les compilent, tout en interprétant les bouts de bytecode moins fréquents. Autrement le temps de compilation pourrait devenir trop long.
La version native essaie d'apporter plus de compilation que celle que peut raisonnablement faire le JIT sans trop impiéter sur le temps de démarrage. Elle ne compile a priori pas tout pour autant non plus, tout n'étant pas compilable en natif statiquement en Java (en tous cas, c'était ainsi la dernière fois que j'ai lu des trucs sur GraalVM), donc il reste des bouts de bytecode qui sont interprétés et potentiellement même compilés JIT à l'exécution si estimé rentable (si l'analyse de performances est activé dans les options).
La version native essaie d'apporter plus de compilation que celle que peut raisonnablement faire le JIT sans trop impiéter sur le temps de démarrage. Elle ne compile a priori pas tout pour autant non plus, tout n'étant pas compilable en natif statiquement en Java (en tous cas, c'était ainsi la dernière fois que j'ai lu des trucs sur GraalVM), donc il reste des bouts de bytecode qui sont interprétés et potentiellement même compilés JIT à l'exécution si estimé rentable (si l'analyse de performances est activé dans les options).
Non elle apporte une compilation totale. Tu n'a plus aucun jit avec graalvm (on parle de graalvm native-image, ils ont un projet où graal se comporte comme une jvm quelconque). Ce qui ne peux être compilé n'est pas accepté avec ça. C'est quelque chose d'acté, ils ne supporteront jamais complètement java. La hype autour du projet pousse les projet à se conformer à ce sous-ensemble d'ailleurs.
L'objectif de graal, l'idée derrière le projet c'est d'arrêter d'utiliser du jit. C'est l'essence du projet dès le départ.
J'ai vérifié, tu as raison pour l'AoT, visiblement ça ne compile simplement pas pour les programmes qui n'utilisent pas le bon sous-ensemble du langage ; du moins, le site de graal dit que dans ce cas, ça utilise une image fallback qui fait appel à la JVM, je sais pas si c'est uniquement du byte code, mais probablement.
Je me demande du coup si les deux projets graal partagent vraiment beaucoup de code, ou surtout le nom, vu comment la représentation interne de programmes de graal (version normale avec JIT) est justement particulièrement conçue à la base pour le JIT et la gestion simultanée de parties compilées et byte code interprété.
Les développeurs s’en prennent plein la tronche pour quelque chose qui a été fait et annoncé il y a plus de 6 mois. Les gens agissent comme s’ils (les mainteneurs) étaient redevables de quoi que ce soit à qui que ce soit.
Je suis franchement pas étonné de voir Drew De Vault dans les personnes venus râler, et ça me fait encore plus me demander pourquoi on lui accorde tellement d’importance.
Posté par ff9097 .
Évalué à 2.
Dernière modification le 10 février 2021 à 17:27.
Je n'ai pas creusé mais je pense que ça aurait mérité une version majeure (4.0) pour ce genre d'impact qui a peut-être été sous-estimé. Ça n'excuse pas les réactions
Si chaque release est une version majeure, alors les gens vont juste arrêter de mettre des contraintes et c’est retour à la case départ.
Au passage, ils ne respectent pas SemVer, c’est les utilisateurs qui sont partit du principe que c’était le cas.
Mais, bref, admettons que ça soit le cas, ça donne le droit de venir commenter en se comportant comme un connard, en apportant absolument rien de constructif et en insinuant que les développeur sont nuls parce qu’ils choisissent un langage qu’on aime pas (Drew De Vault a régulièrement fait savoir qu’il avait une dent contre Rust) ?
On a déjà vue pire (dans ce fil j’ai pas vu d’insulte directe, comme on peut voir ailleurs), mais franchement, faire preuve d’empathie, se renseigner sur le contexte avant de poster, supposer que les intentions sont bonnes, c’est trop demander ?
De quand date la dernière puce commercialisée en architecture alpha (pour prendre l'exemple de l'une des architectures mentionnées) ? Six mois, du coup, ne peuvent-ils paraître un peu court pour se retourner ?
Si flatpack n est pas sécurisé qu'en est il des exe Windows qui n ont aucune restrictions que celle de l antivirus…
Si X11 n est pas sécurisé, parlons de RDP sous windows dont l ensemble des failles représente à elle seule la principale faille du télétravail.
Le noyau Linux est des plus sécurisés au monde seul des composants autour le sont un peu moins. Mais surtout on parle plus facilement des failles sous Linux car elles intéressent plus les lecteurs geeks. Mais dans la réalité il y en a au moins autant ailleurs. Le pire étant l embarqué qui est très rarement mis à jour…
AppLocker est la fonctionnalité en entreprise pour n'exécuter que des executables en liste blanche.
Windows 10 contient un antivirus, antimalware et d'autres fonctionnalités (core isolation avec une sécurité basé sur la virtualisation), ca a bien changé depuis Windows 7 et Defender
Rdp est à comparé à VNC pas à X11, si tu veux comparé X11 à quelque chose, ce n'est pas à ça. DWM si tu veux.
Le noyau linux est sécurisé, ca c'est clair, mais la distribution en elle-même, ca dépend de ces choix. Mais il y a clairement du travail pour en faire autre chose qu'un serveur sans utilisateur.
Si tu lis un peu MISC, tu verras que les exploits sur Windows sont assez haut niveaux. Enfin pas accessible pour des linuxiens puristes qui n'ont jamais étudiê un OS API.
Un antivirus sur les postes de travail Linux me paraît de plus en plus nécessaire.
J'ai essayé dernièrement de configurer ClamAV (l'antivirus libre pour ceux qui ne connaissent pas) sur des postes de travail. Ça me semble malheureusement impossible de trouver une configuration efficace et pas trop gourmande en ressources :
par défaut il ne scanne les fichiers qu'à la demande, ce qui me semble insuffisant
il est possible de configurer et utiliser l'utilitaire clamonacc fournit avec ClamAV, mais il scanne les fichiers à chaque ouverture, visiblement sans aucun cache : ça me semble un gaspillage de ressources absurde
il est possible d'utiliser le système de fichiers FUSE clamfs, mais le fonctionnement ne me semble pas adapté pour du desktop : les fichiers doivent transiter par un répertoire spécial pour être scannés avant d'être déplacé dans le répertoire "normal", il faudrait donc forcer tous les téléchargements (Firefox, client de messagerie…) à passer par ce répertoire spécial. Du point de vue utilisateur ça me semble une vraie régression de ne plus pouvoir enregistrer un téléchargement directement où on le souhaite.
J'envisage deux solutions qui ne me semblent actuellement pas implémentées :
- le plus simple peut-être, une extension pour Firefox et Thunderbird qui scanne automatiquement tous les fichiers téléchargés / pièces jointes
- avoir une configuration de clamonacc pour scanner les fichiers à l'écriture seulement (pas à chaque lecture)
Je suis preneur de tous vos avis / retours d'expérience sur ce sujet !
# Manqué
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
Voici le propos dénué de technique et parfaitement partisan qui me tient lieu d'opinion sur le sujet :
En utilisant des logiciels libres, on utilise généralement des codes développés avec une certaine bienveillance. Il arrive nécessairement que des gens introduisent des failles volontairement, surtout sur des composants critiques ; et on pense nécessairement aux activités de tous les services de renseignements qui peuvent avoir intérêt à introduire des faiblesses cryptographiques, ou des chemins de traverse pour détourner des données.
L'utilisateur de code privateur n'est lui globalement pas respecté — à raison selon moi. On le voit à la quantité de codes diffusant des publicités, demandant des droits surdimensionnées au regard des tâches à accomplir, appelant régulièrement la maison mère sans que cela soit dans l'intérêt évident du client… À tous égards généralement, l'utilisateur de code privateur est pris pour une poire et c'est un pléonasme. Après tout, il se déleste volontairement de sa liberté, alors pourquoi mériterait-il la moindre sécurité (cf. Tocqueville, De la démocratie en Amérique) ? Probablement n'a-t-il pas la compétence nécessaire…
Ma petite expérience personnelle appuyant ce raisonnement purement politique (car je n'ai aucune compétence technique en matière de sécurité) : à l'époque où j'utilisais windos — la version 98 — connecter une machine neuve à internet était problématique. Elle se retrouvait vérolée avant d'avoir eu le temps de télécharger le pare-feu qui aurait permis de la protéger. Il fallait donc télécharger le dit logiciel, et l'installer hors-ligne avant de pouvoir brancher le modem. Sur Linux, aucun problème de ce type. Inutile de configurer iptables ou tcp-wrapper. Aucun logiciel n'était disposé à communiquer tout et n'importe quoi avec l'extérieur. Tout simplement l'absence de malveillance.
Conclusion : assurément d'un point de vue purement technique il reste des progrès à faire concernant la sécurité. Nonobstant les considérations politiques et éco-systémiques (celles énoncées ci-avant et bien d'autres) pondèrent cela de manière très sensible. L'article n'est d'ailleurs pas totalement hermétique à ces considérations mentionnant que le peu d'utilisateurs incompétents de GNU/Linux joue certainement un rôle dans la réputation [bien fondée] de ces systèmes.
Remarquons aussi que, même pour un non-techniciens absolu, les informations de cet article de propagande politique semblent surannées. Notamment les remarques sur X. Il serait intéressant de voir comment l'auteur se débrouillera pour récupérer les mots de passe d'un autre utilisateur sur une distribution moderne via ce canal… À j'oubliais, tout passe par des logiciels nécessairement malveillants…
Un clientune victime mirosoft typique en somme.J'ai marché dedans ? ----> []
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Manqué
Posté par anaseto (site web personnel) . Évalué à 8.
Le soucis un peu, c'est que les méthodes de mitigation sous Linux ne sont pas très simples, donc non activées par défaut.
Après, l'article est exagéré pour une utilisation desktop typique (au sens, typique pour un windosien auquel on compare) : souvent le seul logiciel qui communique avec des méchants probables est le navigateur (beaucoup l'utilisent même pour le mail), donc en termes de mitigations, ce qui est vraiment prioritaire, c'est d'empêcher le navigateur de pouvoir faire trop de choses.
Sous OpenBSD, avec unveil on s'assure que le navigateur ne peut accéder qu'à
~/Downloadset son cache, ce qui limite pas mal les dégâts, et pledge évite de donner accès à trop d'appels systèmes. Avec Linux, on n'a pas de moyen super simple de faire pareil. Un truc facile quand même, c'est de lancer le navigateur avec un autre utilisateur qui ne peut pas lire le home de l'utilisateur principal (je fais ça lorsque j'utilise Linux, c'est mieux que rien et ça coûte pas cher).[^] # Re: Manqué
Posté par Denis BRAUSSEN . Évalué à 5. Dernière modification le 10 février 2021 à 21:38.
Sous linux il y a firejail qui peut faire tourner firefox (entre autres) dans une jail. En paramétrant un peu on peut également avoir un répertoire de "downloads" persistent. En plus c'est facile à mettre en œuvre.
Je cite:
Firejail est un programme SUID qui réduit le risque de failles de sécurité en limitant l'environnement d'exécution des applications non fiables en utilisant les espaces de noms Linux et seccomp-bpf. Il permet à un processus et à tous ses descendants d'avoir leur propre vue privée des ressources du noyau globalement partagées, telles que la pile réseau, la table de processus, la "table de montage" (mount table).
[^] # Re: Manqué
Posté par anaseto (site web personnel) . Évalué à 3.
C'est vrai que firejail est assez simple d'utilisation pour les logiciels pré-configurés, même si la technologie derrière est plus complexe (un niveau d'indirection en plus, puisqu'il faut un processus pour en surveiller un autre). Cela dit, à ma connaissance, aucune distribution (du moins connue) ne remplace par défaut
firefoxparfirejail firefox.[^] # Re: Manqué
Posté par vv222 (site web personnel) . Évalué à 3. Dernière modification le 12 février 2021 à 19:24.
C’est dommage que depuis des années tout avance exactement dans le sens contraire…
Le navigateur est devenu un nouvel OS dans l’OS. Et à mon avis c’est très con.
Les deux plus gros obstacles à la sécurité sous Linux sont Google et Mozilla.
[^] # Re: Manqué
Posté par ff9097 . Évalué à 0.
La solution a déjà été mentionné : flatpak
[^] # Re: Manqué
Posté par vv222 (site web personnel) . Évalué à 3.
Ce n'est pas une solution, mais un emplâtre sur une jambe de bois.
[^] # Re: Manqué
Posté par Donk . Évalué à 0.
Il faut utiliser les paquets snap
[^] # Re: Manqué
Posté par barmic 🦦 . Évalué à 3.
Ce serait quoi une solution du coup ? Les navigateurs utilisent des solutions comme seccomp, ce n'est pas suffisant et bloquer au niveau système les accès ne convient pas plus (tu dis pas que ça ne va pas assez loin ou que ce n'est pas parfait, mais que ce n'est pas la bonne direction). Je ne vois pas ce qu'elle autre option est possible ('fin j'ai une idée, mais je préfère éviter de faire des suppositions).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manqué
Posté par vv222 (site web personnel) . Évalué à 2.
Mettre fin au "tout Web", au profit des applications natives.
Le navigateur Web est devenue une telle faille de sécurité ambulante uniquement parce que tout passe par lui, s'il ne servait qu'à "afficher des pages Web" on n'aurait pas besoin de toutes ces bidouilles pour tenter de reboucher la passoire.
Je ne souhaite pas qu'on chercher à réparer les navigateurs Web, ça me semble une cause perdue, mais qu'on réduise leur impact global dans notre utilisation des outils informatiques. En bonus ça donnerait une bonne claque au pouvoir démesuré des GAFAM et autres
vendeursloueurs de nuages.[^] # Re: Manqué
Posté par barmic 🦦 . Évalué à 3.
Je vois pas le rapport. Il n'y a plus de serveur sans navigateur ? Les GAFAM ne vont pas proposer d'applications natives (ce qu'ils font déjà quand c'est utile) ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manqué
Posté par vv222 (site web personnel) . Évalué à 2.
Ce n’est pas tout à fait ce que je dis.
Ce que je pense (et est sûrement discutable) est que ces GAFAM sont indélogeables dans tout ce qui touche aux services en ligne, ils ont trop d’avance et d’emprise dans ce domaine. Par contre il y a peut-être une chance pour d’autres acteurs du côté des applications natives, il suffit de voir VLC dans le domaine de la lecture de vidéo, ou GIMP et Krita pour la manipulation d’images, ou encore Blender dans la 3D…
Je suis incapable de citer un acteur similaire dans les services en ligne qui ne soit pas directement un GAFAM, une succursale d’un GAFAM, ou dépendant de l’infrastructure d’un GAFAM.
[^] # Re: Manqué
Posté par barmic 🦦 . Évalué à 3.
Et tu peux en citer un qui a moins de 15 ans ? Ça n'est pas du troll quel logiciel libre (qui est une application de bureau) de moins de 15 ans est arrivé à avoir ce genre de succès ?
En vrai je pense que le problème sous-jacent c'est que l'écosystème libre n'a pas envi de comprendre qu'un service ne peux être libre au sens où on l'entend pour un logiciel et que ça a bien plus d'impact qu'on ne veux bien le croire.
Mais remplacer un client web par un client en C++ ne changera rien à ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manqué
Posté par ff9097 . Évalué à 2.
Comme sur mobile quoi. Ça se plaint aussi sur mobile du tout applications
[^] # Re: Manqué
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
flatpak fonctionne maintenant? https://linuxfr.org/nodes/118350/comments/1788497
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Manqué
Posté par ff9097 . Évalué à -2.
Ça a toujours fonctionné, il faut arrêter la mauvaise foi même si c'est ta spécialité
[^] # Re: Manqué
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Tu peux relire mes commentaires sur ce journal.
En résumé : j'ai essayé de faire un paquet flatpak, mais c'était si mal documenté et buggé, que j'ai fini par me tourner vers Appimage.
Je ne suis pas anti flatpak, mais avant de le réessayer, j'aimerais être sûr qu'il gère les projets java/maven et qu'un même paquet fonctionne sur deux distribs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Manqué
Posté par barmic 🦦 . Évalué à 4.
La mise en place de seccomp, pousser pour l'utilisation de langage memory safe, mettre en place des bac à sable comme webassembly,… qui non content d'aider à la sécurité des navigateurs, aident pour l'ensemble des écosystèmes (même webassembly est utilisé dans des environnements cloud pour faire du faas à bas coût ou dans postgres).
Je présume que tu parle du fait de proposer des API pour interagir avec le matériel ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manqué
Posté par vv222 (site web personnel) . Évalué à 2.
Non ;) (enfin, si, ça fait partie de ce que je dénonce, mais ce n'en est qu'un point de détail)
Je parle de la dérive en cours depuis bien plus longtemps que ça de tout faire via le navigateur Web. Sorti de quelques "geeks", c'est même la seule application native à tourner sur le système.
C'est fini GNU/Linux, on est maintenant sur Firefox/GNU/Linux ou Chrome/GNU/Linux. Et c'est dans ce Firefox ou ce Chrome que tournent toutes nos applications.
[^] # Re: Manqué
Posté par barmic 🦦 . Évalué à 3.
Ton lecteur vidéo, ton MUA, etc mettent quoi en place pour la sécurité ?
Je ne suis pas convaincu que :
On peut se plaindre des usages, mais je ne vois pas aujourd'hui d'alternatives qui apporte ne serais-ce que quelque chose d'après près aussi efficace (au sens qualité logiciel) ou pratique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manqué
Posté par vv222 (site web personnel) . Évalué à 2.
Facile : mon lecteur vidéo ne sert qu'à lire des vidéos, mon client mail ne sert qu'à lire et envoyer des mails. La surface d'attaque et plus globalement les possibilités de failles sont immensément réduites par rapport à un navigateur Web qui se prend pour un OS complet.
VLC n'a pas besoin de savoir traiter une pièce-jointe malicieuse, pas plus que Thunderbird n'a besoin de bloquer une éventuelle vidéo piégée.
[^] # Re: Manqué
Posté par barmic 🦦 . Évalué à 2.
Tu pense que les usages ce sont figés en 2010 ? Twitch par exemple tu le gère comment (un flux vidéo + un chat qui doivent être un minimum synchronisé) ? Les traitements de texte à plusieurs tu as quelque chose de standard pour le faire ?
Tout doit passer par l'IETF puis être implémenter ? Tu vois comment ça fonctionne avec XMPP ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manqué
Posté par vv222 (site web personnel) . Évalué à 2.
Euh, pourquoi ce serait à moi de proposer une alternative à Twitch ? Ou à un système de traitement de texte synchronisé ? (pour ma part ces deux machins peuvent disparaître sans aucune alternative, sans pour autant me manquer)
Et surtout, pourquoi je devrais avoir une réponse à chacune de ces questions avant d’être autorisé à critiquer le système actuel ? Je ne suis ni à l’origine d’un de ces services, ni consommateur de ceux-ci, et surtout je ne vais pas me lancer dans de longues études d’architecture logicielle pour obtenir un quelconque "certificat d’expertise" qui m’autoriserait à critiquer les solutions en place.
[^] # Re: Manqué
Posté par barmic 🦦 . Évalué à 3.
Il ne s'agit là que de quelques exemples pour montrer que ta démarche ne peux fonctionner.
Je ne t'ai pas interdit de t'exprimer, je tente de pointer du doigt la limite du monde que tu décrit. Tout comme tu remet en cause les démarches de sécurité des navigateurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Manqué
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Loin de unveil, mais on est dans l'idée avec AppArmor ou SELinux non ? Mais c'est vrai que ce n'est pas super simple pour l'utilisateur qui sort un peu du cadre prévu par la distro.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Manqué
Posté par Graveen . Évalué à 1.
Tu rejoins mon opinion profonde.
Au dela des points techniques, il y a une philosophie et une éthique.
Personnellement j'accepte des logiciels imparfaits, ou de ne pas utiliser du matériel Apple parce que je soutiens ce combat politique, ce qui se fait parfois au détriment de la technique: disponibilité, fonctionnalités, sécurité, drivers…
A chacun ses combats.
Tout en soulignant qu' Ubuntu est bien accepté par des néophytes, et que malgré tout, le plan technique est de mon point de vue globalement satisfaisant.
[^] # Re: Manqué
Posté par octane . Évalué à 3.
Ca me parait un peu rapide comme assertion et non étayée, mais pourquoi pas. Et même si c'est vrai, en quoi est-ce un gage de sécurité accrue?
encore une fois non étayé, mais mettons que oui. En quoi la bienveillance empêche un repo quelconque de recevoir une PR avec une backdoor très subtile? et de merger ce code?
je dirais oui.
Les parasites aiment garder l'hôte vivant. Si les systèmes privateurs avaient une sécurité proche de 0, alors ils ne pourraient pas fonctionner. Voir ton anecodte sur un windows98 ou la machine est vérolée avant d'avoir fait quoi que ce soit. Les systèmes privateurs mettent un accent énorme sur la sécurité (pour conserver précieusement les données récoltées par eux-mêmes, certes.)
Bin, non, puisque comme le dit l'article de medium, c'est le user qui tape "pip install machin" et que tu peux sans difficultés mettre de la vérole dans "machin".
Dernièrement on apprenait que sudo a trainé une faille de sécurité pendant 10 ans (!!!!). Utilisateurs incompétents? Code review? Croyance infondée que c'est le voisin qui surveille le code de l'autre? Naïveté? Je sais pas, mais il semble qu'il y ait beaucoup de pieds d'argile chez le colosse linux.
[^] # Re: Manqué
Posté par _kaos_ . Évalué à 3.
Salut,
Pour compléter, il ne faut pas toujours manger au même râtelier.
Même s'il y a des "chanceux" qui peuvent ne vivre que du libre, je crois que pour une majorité (je n'ai pas de chiffre à l'appui), c'est du code propriétaire, et s'il reste du temps et de l'énergie, du libre.
Perso, j'essaye de fournir une qualité de code constante, peut importe libre ou pas libre au final.
Matricule 23415
[^] # Re: Manqué
Posté par xenom . Évalué à 4.
Oui, enfin c'etait il y a 22 ans, la sécurité de Windows à quand même bien évoluée depuis. La comparaison n'est pas vraiment pertinente. Surtout que Windows est (et était) aussi bien plus ciblé que Linux.
Une distribution récente comme Ubuntu 20.04 ? Car oui Ubuntu 20.04 utilise encore X. Plus toutes les autres distribution qui même avec Wayland utilisent encore un serveur X pour les applications qui ne sont pas compatibles Wayland.
Justement, la bienveillance ne suffit pas. On a beaucoup d'exemples d'applications "bienveillantes" qui se mettent à avoir un comportement malveillant, après un piratage du projet, de ses canaux de distribution ou un changement de mainteneur par exemple. Et on ne parle pas d'une attaque un peu plus ciblée, qui viserai une entreprise par exemple.
Et le problème c'est que -par défaut- peu de chose protège le système dans ces cas la.
# Quelques remarques
Posté par paulez (site web personnel) . Évalué à 10.
Clairement les systèmes Linux peuvent beaucoup améliorer leur niveau de sécurité.
Mais certains points de l'article me paraissent discutables:
Globalement c'est vrai qu'aujourd'hui que pas mal de distros Linux n'ont pas vraiment d'avantage technologique majeur au niveau sécurité sur Windows ou MacOS. Certaines distros sont plus "durcies" que d'autre par défaut (Fedora avec SELinux par exemple).
Ces trois systèmes ont régulièrement des failles plus ou moins majeures qui sont découvertes et publiées.
Mais justement Linux est devenu tellement important au niveau infra que beaucoup d'acteurs s'impliquent pour améliorer la situation à ce niveau, ce qui est rendu possible par le modèle ouvert de Linux.
Je ne pense pas que ni Windows ni MacOS aient autant de personnes impliquées dans l'exploration et la correction de problèmes de sécurité que Linux.
Mais clairement utiliser Linux n'est pas suffisant au niveau sécurité, il faut avoir toute une politique autour pour l'utiliser de manière sûre.
[^] # Re: Quelques remarques
Posté par xenom . Évalué à 3.
X11 est encore utilisé par défaut sur Ubuntu 20.04, et même pour les distributions utilisant par défaut Wayland, il y a toujours le serveur X11 utilisé pour les applications ne supportant par encore Wayland, qui peut poser le même genre de problèmes, même si limités à un scope plus restreint, mais qui inclut quand même Chromium et Firefox.
Flatpack à 2 problèmes principaux. Le premier c'est que les permissions de la sandbox sont définies par l'application et sont beaucoup trop ouvertes pour la majorité des paquets (par exemple accès à tout /home, voir à tout /). Le second c'est le délais de mise à jours des frameworks. En plus il y a d'autres points qui pourraient être améliorés, comme le profil seccomp ou l'accès à X11.
Cet article en parle, avec en plus d'autres problèmes de sécurité sur Linux.
C'est probablement valable pour le noyau et d'autres briques systèmes, mais je suis pas sûr pour le desktop. Déjà que certains programmes ou librairies comme OpenSSL ou Curl ont montrés qu'être extrêmement populaire ne signifie pas un apport de moyen humain et ou financier, je doute que Gnome/KDE/Wayland/… et les différentes distributions pour l’intégration aient plus de moyen que les équipes sécurités Windows ou Android
[^] # Re: Quelques remarques
Posté par Renault (site web personnel) . Évalué à 6.
XWayland ne permet pas de se comporter comme X11, à savoir avoir une vue globale sur l'écran et les entrées. C'est quand même une sacrée différence.
Notons que Firefox prend en charge Wayland.
L'utilisateur peut comme sur Android révoquer les accès finement de chaque application. L'application Flatseals permet de le faire graphiquement.
Idéalement il faudrait comme sur Android pouvoir voir et changer ça lors de l'installation de l'application, mais en tout cas cela reste paramétrable par l'utilisateur.
Problématique pas différente des distro, c'est une question éventuellement d'avoir suffisamment de bras mais pas de technos.
[^] # Re: Quelques remarques
Posté par xenom . Évalué à 3.
Effectivement il n'y a pas la vue globale, mais toutes les applications qui utilisent XWayland partagent le même serveur X, donc elle peuvent s'espionner entre elles. Et c'est encore plus problématique quand les applications sont par exemple Chromium, Firefox et KeepassXC. Je viens de tester, une application lancée sur XWayland arrive à récuperer les entrées clavier de KeepassXC
Oui, effectivement, j'aurais du être plus précis. Firefox supporte Wayland, mais ne l'active pas par défaut, et je crois que seule Fedora l'ai fait.
C'est plutôt bien, mais dommage que ce ne soit pas dans les fonctions par défaut du projet.
Mes derniers tests de Flatpack remontent à presque 2 ans, et à l’époque une application pouvait mettre à jour ses permissions sans avertir l'utilisateur. Est-ce encore le cas ? Que se passe t'il avec Flatseal ?
La problématique est la même, mais ça ajoute une source de failles. Les distributions majeures font quand même du très bon boulot et sont réactives. Mais la on ajoute les frameworks Flatpak et en plus les applications Flatpak et les librairies bundled. Il y a plusieurs articles qui pointait le problème il y a quelques années, avec dans plusieurs cas des delais de plusieurs mois entre le fix d'une faille critique et son arrivé dans le paquet Flatpak. La situation à peut-etre évolué.
Je serais moins critique que l'auteur de l'article sur Flatpak, mais globalement, dans sa configuration par défaut, ça ne résout que très peu de problèmes de sécurité, mais c'est aussi un axe d’amélioration.
[^] # Re: Quelques remarques
Posté par Anonyme . Évalué à 9. Dernière modification le 10 février 2021 à 16:58.
Je suis mainteneur de plusieurs paquets dans Debian et je package aussi une application sur Flathub1 (qui pue, qu’est pas libre).
La grosse différence entre les deux environnement c’est que dans Debian, à chaque fois qu’il y a eu un problème sur un de mes paquets, quelqu’un de plus compétent que moi a fait le taff de corriger (ou au moins a fait une PR). Quand j’ai empaqueté prometheus-exporter-exporter, ça c’est fait en discutant en quasi direct avec l’équipe Prometheus, quand je vois passer des bugs sur des dépendances qui cassent mes paquets, je sais qu’ils vont corrigé sans que j’ai à bouger le petit doigt, etc.
Sur Flathub, la seule interaction que j’ai eu avec des mainteneurs c’était quand j’ai ouvert la PR pour ajouter l’application dans le dépôt.
Donc ouais, les problématiques sont probablement les mêmes, mais les communautés sont loin d’être équivalentes. J’ai 1000 fois plus confiance en une communauté organisée de mainteneurs qu’en une suite d’individus, chacun s’occupant seulement de son petit bout de terrain et sans aucune interaction les uns avec les autres.
Qu’on se comprenne, j’aime bien Flatpak et j’utilise des applications venant de Flathub, mais je préférai toujours le paquet Debian au flatpak de FlatHub. D’ailleurs, les applications que j’utilise c’est principalement du non-libre, ou qui ne sont pas dans Debian (exemple, Slack et Zoom au bureau, Signal-Desktop en perso).
J’ai absolument aucune idée de ce que je fais, j’ai un bot qui ouvre des PR quand l’application est mise à jour upstream donc je les merge, mais mon taff s’arrête là. ↩
[^] # Re: Quelques remarques
Posté par ff9097 . Évalué à 1.
Wayland et Flatpak sont deux gros bonds en avant à ce sujet et c'est plutôt bien. Le problème de fond et qui pourra se résoudre à (très) long terme c'est l'abandon de langage non-sûr comme C/C++ pour les briques bas niveaux et remplacés par Rust. Ça arrive déjà et avec des mauvaises surprises
[^] # Re: Quelques remarques
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Est-ce vraiment une surprise ? Si on code dans un langage non porté sur la plupart des plateformes, faut-il vraiment s'étonner d'obtenir un code qui ne soit compatible qu'avec la plateforme ultra dominante (et apparemment aussi la plus trouée en matière de sécurité matérielle) ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Quelques remarques
Posté par paulez (site web personnel) . Évalué à 3.
Il ne faut pas croire que Rust va résoudre tous les problèmes de sécurité par magie. Certainement ça permet de réduire une certaine classe d'erreurs, mais refaire X11 en Rust par exemple n'apporterait pas grand chose niveau sécu.
[^] # Re: Quelques remarques
Posté par ff9097 . Évalué à 1.
le problème de X11 est déjà réglé c'est Wayland
[^] # Re: Quelques remarques
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 10 février 2021 à 17:08.
La sûreté présumé* de Rust, ce n'est la même chose que la sécurité vis à vis de l'utilisateur.
Dit autrement, un programme Rust malveillant, c'est un violeur qui porte une capote.
*: à prouver. A priori Java doit être plus sûr que Rust.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Quelques remarques
Posté par ff9097 . Évalué à 0.
Java n'a jamais, et ne remplacera jamais C/C++
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 5.
Java (puis tout un tas de langages) ont remplacés C et C++. C'est juste qu'ils ne l'ont pas fait sur tous les usages de C et C++. Je suis d'accord que sur l'usage de C et C++ actuel java ne semble pas le plus pertinent, mais en 95 quand java est sorti ce n'était pas le cas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ce qui aurait été vraiment intéressant c'est un "safe C". Un C compatible à 90% avec l'existant, mais sans les pièges. Mais c'est sans doute plus fun de créer un langage vraiment nouveau.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 3.
Et pas possible d'avoir un "safe C" comme tu le décrit. Changer la sémantique de la mémoire, retirer les pointeurs nus, retirer les
malloc()/free(), ajouter toutes les sémantiques pour les remplacer (type somme pour vraiment faire bien par exemple ?).Le sous-ensemble de C++ compatible avec C et le sous-ensemble qui ajoute de sécurité mémoire sont grosso modo 2 langages distincts.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Il y a eu des tentatives telles que Safe C ou plus connu Objective C.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 2.
Et ils n'apportent pas assez de gain pour que switch soit intéressant alors qu'ils ont tout de même tenté de diminuer le coût de ce switch.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Vu la popularité de C, si c'était vraiment possible de faire un langage à la fois très compatible et très sécurisé, il est très probable que ça aurait déjà fait. Et des gens très pragmatiques (genre Microsoft, Amazon, Google, des gens guidés par le fun de toute évidence) ne s'embêteraient pas à partir sur un nouveau langage s'ils pouvaient économiser énormément de temps et d'argent avec un tel langage.
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 4.
Ou d'autres communautés qui apprécies beaucoup le C et la sécurité comme les gens d'OpenBSD. Ils font des choses pour améliorer la sécurité du C en remplaçant certaines API principalement d'ailleurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par anaseto (site web personnel) . Évalué à 4. Dernière modification le 10 février 2021 à 18:54.
En même temps, il parle de briques bas niveau, pour lesquelles Java n'est pas utilisable.
Cela dit, pour le bas niveau, Rust fait beaucoup d'usage d'unsafe (inévitable), ce qui réduit quand même beaucoup ses garanties. Quand on compare Rust et C pour une application haut-niveau, Rust est un clair gagnant, mais alors Java ou Go est souvent possible aussi, sauf besoins en performance particuliers. Pour du très bas niveau, l'intérêt de Rust est paradoxalement moins impressionnant, je trouve.
Après, il y a aussi la question des bugs dans le compilo. Par exemple, Java utilise un JIT, et un particulièrement complexe, donc le potentiel de bugs problématiques dans le compilo qui conduisent à des problèmes de sécurité est a priori non négligeable. Rust a un compilateur assez complexe aussi, malgré l'absence de JIT, donc le risque n'est pas exclu non plus.
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 2.
C'est probablement discutable, maintenant que tu peux compiler java en natif. C'est bien plus récent que rust et donc avec un écosystème bien moins mature et complet.
Après je ne sais pas s'il est pertinent pour autant, mais ce n'est plus impossible.
J'aurais plus mis en cause la machine virtuelle que le compilateur perso.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par anaseto (site web personnel) . Évalué à 2.
La machine virtuelle fait du JIT, donc combine le gros de la complexité d'un compilateur et celui d'une machine virtuelle traditionnelle (genre Perl), mais en pire (il y a des processus de décision assez complexes pour décider quoi compiler en natif à la volée et quand ce n'est pas possible ou non rentable).
Pour la compilation native, je connais pas bien les détails, mais j'imagine que ça met un sous-ensemble de la JVM (a priori plus simple) et le programme dans un même exécutable.
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 2.
C'est une façon de voir les choses. Par contre je ne sais pas ce qui est plus complexe entre interpréter un byte-code et compiler un byte-code vers du natif et exécuter ce natif (ce que font les JIT).
Globalement tu as la bibliothèque standard de java, le garbage collector et ton code.
Si c'est le garbage collector qui te fais peur pour certains usages, il faut savoir que java a toujours pu traiter des données hors de la heap, c'est à dire non géré par le gc. Tu ne peux pas totalement le retirer évidement.
Par contre évidement tu n'a plus les même garanties sur la mémoire. Je ne crois pas qu'on puisse avoir toutes les garanties sur la mémoire à coût 0 sauf à prouver son programme ou à en générer le code par des automates qui vérifies certaines propriétés (mais ce qui revient au même tu dois démontrer à ton automate que tu gère correctement ta mémoire).
Peut être que la solution jadis envisagée par sun de prouver la JVM puis de l'implémenter en hardware permettrait d'avoir à la fois de grandes garanties tout en ayant une performance très correcte.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par anaseto (site web personnel) . Évalué à 2.
Les JIT font souvent les deux : ils analysent les bouts de bytecode fréquemment exécutés et les compilent, tout en interprétant les bouts de bytecode moins fréquents. Autrement le temps de compilation pourrait devenir trop long.
La version native essaie d'apporter plus de compilation que celle que peut raisonnablement faire le JIT sans trop impiéter sur le temps de démarrage. Elle ne compile a priori pas tout pour autant non plus, tout n'étant pas compilable en natif statiquement en Java (en tous cas, c'était ainsi la dernière fois que j'ai lu des trucs sur GraalVM), donc il reste des bouts de bytecode qui sont interprétés et potentiellement même compilés JIT à l'exécution si estimé rentable (si l'analyse de performances est activé dans les options).
Bref, c'est une machinerie bien complexe.
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 3.
Non elle apporte une compilation totale. Tu n'a plus aucun jit avec graalvm (on parle de graalvm native-image, ils ont un projet où graal se comporte comme une jvm quelconque). Ce qui ne peux être compilé n'est pas accepté avec ça. C'est quelque chose d'acté, ils ne supporteront jamais complètement java. La hype autour du projet pousse les projet à se conformer à ce sous-ensemble d'ailleurs.
L'objectif de graal, l'idée derrière le projet c'est d'arrêter d'utiliser du jit. C'est l'essence du projet dès le départ.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par anaseto (site web personnel) . Évalué à 2.
J'ai vérifié, tu as raison pour l'AoT, visiblement ça ne compile simplement pas pour les programmes qui n'utilisent pas le bon sous-ensemble du langage ; du moins, le site de graal dit que dans ce cas, ça utilise une image fallback qui fait appel à la JVM, je sais pas si c'est uniquement du byte code, mais probablement.
Je me demande du coup si les deux projets graal partagent vraiment beaucoup de code, ou surtout le nom, vu comment la représentation interne de programmes de graal (version normale avec JIT) est justement particulièrement conçue à la base pour le JIT et la gestion simultanée de parties compilées et byte code interprété.
[^] # Re: Quelques remarques
Posté par Anonyme . Évalué à 5.
Ce ticket est tellement déprimant…
Les développeurs s’en prennent plein la tronche pour quelque chose qui a été fait et annoncé il y a plus de 6 mois. Les gens agissent comme s’ils (les mainteneurs) étaient redevables de quoi que ce soit à qui que ce soit.
Je suis franchement pas étonné de voir Drew De Vault dans les personnes venus râler, et ça me fait encore plus me demander pourquoi on lui accorde tellement d’importance.
[^] # Re: Quelques remarques
Posté par ff9097 . Évalué à 2. Dernière modification le 10 février 2021 à 17:27.
Je n'ai pas creusé mais je pense que ça aurait mérité une version majeure (4.0) pour ce genre d'impact qui a peut-être été sous-estimé. Ça n'excuse pas les réactions
[^] # Re: Quelques remarques
Posté par Anonyme . Évalué à 5. Dernière modification le 10 février 2021 à 18:11.
Oui, probablement, mais [un des développeurs explique](https://github.com/pyca/cryptography/issues/5801#issuecomment-776067787= aussi qu’ils font trop de changement qui devraient être considérés comme majeurs pour que ça ait une réelle utilité.
Si chaque release est une version majeure, alors les gens vont juste arrêter de mettre des contraintes et c’est retour à la case départ.
Au passage, ils ne respectent pas SemVer, c’est les utilisateurs qui sont partit du principe que c’était le cas.
Mais, bref, admettons que ça soit le cas, ça donne le droit de venir commenter en se comportant comme un connard, en apportant absolument rien de constructif et en insinuant que les développeur sont nuls parce qu’ils choisissent un langage qu’on aime pas (Drew De Vault a régulièrement fait savoir qu’il avait une dent contre Rust) ?
On a déjà vue pire (dans ce fil j’ai pas vu d’insulte directe, comme on peut voir ailleurs), mais franchement, faire preuve d’empathie, se renseigner sur le contexte avant de poster, supposer que les intentions sont bonnes, c’est trop demander ?
[^] # Re: Quelques remarques
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
De quand date la dernière puce commercialisée en architecture alpha (pour prendre l'exemple de l'une des architectures mentionnées) ? Six mois, du coup, ne peuvent-ils paraître un peu court pour se retourner ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Quelques remarques
Posté par barmic 🦦 . Évalué à 3.
Je pense qu'il voulait dire par là qu'il aurait était préférable d'indiquer au moment de l'annonce le problème plutôt qu'au moment de la publication.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quelques remarques
Posté par abriotde . Évalué à 0.
Si flatpack n est pas sécurisé qu'en est il des exe Windows qui n ont aucune restrictions que celle de l antivirus…
Si X11 n est pas sécurisé, parlons de RDP sous windows dont l ensemble des failles représente à elle seule la principale faille du télétravail.
Le noyau Linux est des plus sécurisés au monde seul des composants autour le sont un peu moins. Mais surtout on parle plus facilement des failles sous Linux car elles intéressent plus les lecteurs geeks. Mais dans la réalité il y en a au moins autant ailleurs. Le pire étant l embarqué qui est très rarement mis à jour…
[^] # Re: Quelques remarques
Posté par Flavien . Évalué à 2.
AppLocker est la fonctionnalité en entreprise pour n'exécuter que des executables en liste blanche.
Windows 10 contient un antivirus, antimalware et d'autres fonctionnalités (core isolation avec une sécurité basé sur la virtualisation), ca a bien changé depuis Windows 7 et Defender
Rdp est à comparé à VNC pas à X11, si tu veux comparé X11 à quelque chose, ce n'est pas à ça. DWM si tu veux.
Le noyau linux est sécurisé, ca c'est clair, mais la distribution en elle-même, ca dépend de ces choix. Mais il y a clairement du travail pour en faire autre chose qu'un serveur sans utilisateur.
Si tu lis un peu MISC, tu verras que les exploits sur Windows sont assez haut niveaux. Enfin pas accessible pour des linuxiens puristes qui n'ont jamais étudiê un OS API.
[^] # Re: Quelques remarques
Posté par Flavien . Évalué à 3.
[^] # Re: Quelques remarques
Posté par Flavien . Évalué à 1.
Comparaison of command shells
# À quand ClamAV utilisable pour du desktop ?
Posté par YvanM (site web personnel) . Évalué à 1.
Un antivirus sur les postes de travail Linux me paraît de plus en plus nécessaire.
J'ai essayé dernièrement de configurer ClamAV (l'antivirus libre pour ceux qui ne connaissent pas) sur des postes de travail. Ça me semble malheureusement impossible de trouver une configuration efficace et pas trop gourmande en ressources :
clamonaccfournit avec ClamAV, mais il scanne les fichiers à chaque ouverture, visiblement sans aucun cache : ça me semble un gaspillage de ressources absurdeclamfs, mais le fonctionnement ne me semble pas adapté pour du desktop : les fichiers doivent transiter par un répertoire spécial pour être scannés avant d'être déplacé dans le répertoire "normal", il faudrait donc forcer tous les téléchargements (Firefox, client de messagerie…) à passer par ce répertoire spécial. Du point de vue utilisateur ça me semble une vraie régression de ne plus pouvoir enregistrer un téléchargement directement où on le souhaite.J'envisage deux solutions qui ne me semblent actuellement pas implémentées :
- le plus simple peut-être, une extension pour Firefox et Thunderbird qui scanne automatiquement tous les fichiers téléchargés / pièces jointes
- avoir une configuration de
clamonaccpour scanner les fichiers à l'écriture seulement (pas à chaque lecture)Je suis preneur de tous vos avis / retours d'expérience sur ce sujet !
[^] # Re: À quand ClamAV utilisable pour du desktop ?
Posté par vv222 (site web personnel) . Évalué à 4.
Je veux bien te croire, mais il va falloir pour ça expliquer comment tu en arrives à ce constat.
[^] # Re: À quand ClamAV utilisable pour du desktop ?
Posté par YvanM (site web personnel) . Évalué à 2.
Je t'invite à lire ma réponse à cette même question sur le forum ainsi que les commentaires qui suivent.
[^] # Re: À quand ClamAV utilisable pour du desktop ?
Posté par vv222 (site web personnel) . Évalué à 2.
Merci pour le pointeur, si j'ai des réactions je les posterai sur ce fil de forum ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.