Linux? - Page 233

Nil > Je pense que c'est un risque qu'ils ont choisi de prendre. Microsoft a utilisé la même stratégie par le passé : arriver à se positionner comme le standard que tout le monde utilise ou doit égaler, et en profiter pour garder une longueur d'avance sur ses concurrents, quitte à prendre des décisions qui font grincer des dents. Et globalement ça a marché, du moins pendant un certain temps, parce que passer à une solution alternative avait un coût non négligeable.

C'est exactement le problème qui se pose. Former et assainir la chose n'est pas mission impossible mais sors complètement du cadre traditionnel d'un projet OSS

Zerosquare (./6958) :
Ce n'est pas la première fois que ce cas se produit. Il s'était déjà passé la même chose avec Ulrich Drepper qui gérait glibc, qui avait le même genre de comportement que Poettering, et qui travaillait aussi pour RedHat. À tel point que Debian avait fini par en avoir marre et avait switché vers eglibc.

Je trouve qu'Ulrich Drepper faisait un très bon travail de mainteneur de glibc et que c'est vraiment dommage qu'il soit parti (vers Goldman Sachs ). Avec lui, on n'aurait jamais eu cette merde de Flatpak, ces idées existaient déjà à l'époque, et il a expliqué très clairement et fermement pourquoi c'est de la merde. (À mort les applications blob!)

Ce que veut dire Nil si je comprends bien c'est pourquoi Red Hat laisse Poettring tout seul sur le projet, sachant qu'il fait grincer des dents. Et je me pose la même question à vrai dire…

Parce que RedHat en a RAF tout simplement? ca leur rapport encroe plus de controle sur le monde de Systemd-kernel je suis un peu en avance, mais c'est probablement le prochain point de controle

Brunni > ben j'ai répondu plus haut : pour l'instant ils gagnent plus qu'ils ne perdent, donc ils laissent faire.

Merci Brunni, oui, c'est exactement ça. Red Hat a beau être une boite qui fait du LL, ça reste une boite privée (et j'imagine que Poettring est rémunéré directement par RH) qui sait gérer des équipes et des projets. Qu'un truc aussi énorme ne repose sur les épaules que d'une seule personne, ça me paraît dingue...

Il n'est pas le seul à bosser sur systemd, il en est "seulement" le créateur, le mainteneur principal et la figure de proue du projet. Et son côté "rentre-dedans", aussi agaçant qu'il soit, a peut-être aidé à pousser son projet, justement.

Nil (./6967) :
et j'imagine que Poettring est rémunéré directement par RH

Bah oui, évidemment. Il est employé par Red Hat, et l'esclavage a été aboli. Donc forcément ils le paient.

Kevin Kofler (./6963) :
Avec lui, on n'aurait jamais eu cette merde de Flatpak, ces idées existaient déjà à l'époque, et il a expliqué très clairement et fermement pourquoi c'est de la merde. (À mort les applications blob!)

Les distribs n'ont qu'à faire en sorte que packager une application ne soit pas une galère sans nom
Faire des packages corrects (ne serait-ce que pour Debian et Ubuntu, donc du .deb dans les deux cas) prend actuellement un temps proprement phénoménal, donc les développeurs se sont adaptés, c'est tout à fait normal.

Kevin Kofler (./6969) :
Bah oui, évidemment. Il est employé par Red Hat, et l'esclavage a été aboli. Donc forcément ils le paient.

Il pourrait être bénévole ; il pourrait aussi être rémunéré comme freelance, sans faire partie de l'équipe et en ayant de ce fait un lien de subordination faible (ie : il s'occuperait de systemd dans son coin de façon indépendante et RH le rémunèrerait comme extérieur).

Flanker -> tu connais checkinstall ? http://www.asic-linux.com.mx/~izto/checkinstall/
C'est packagé sur Debian et sûrement ailleurs.

Ca te permet de builder et installer un .deb fingueurs in ze noze, même moi j'y arrive c'est dire ^^

Mais la qualité de ces paquetages est absolument à vomir. Il n'y a même pas un vrai paquetage source. C'est peut-être acceptable pour le but déclaré (permettre d'installer un logiciel pour ton usage privé de manière à ce que la désinstallation soit possible plus tard), et même là avec des limitations (ça utilise LD_PRELOAD pour intercepter l'installation de fichiers, donc tout ce qui contourne LD_PRELOAD – binaires statiques, binaires SUID, binaires qui tournent sous un environnement nettoyé etc. – ne sera pas enregistré!), mais absolument pas pour créer des paquetages distribuables.

Folco (./6972) :
Flanker -> tu connais checkinstall ? http://www.asic-linux.com.mx/~izto/checkinstall/
C'est packagé sur Debian et sûrement ailleurs.

Ca te permet de builder et installer un .deb fingueurs in ze noze, même moi j'y arrive c'est dire ^^

Le problème vient des dépendances, qui s'appellent différemment sur chaque distrib, et qui auront des versions différentes. Du coup, c'est une horreur vu que tu dois tester toutes les configurations possibles… ou alors tu fais un gros .deb avec toutes les dépendances incluses, pour être sûr que ça fonctionne.

Bien sûr, je ne distribue rien avec. De toute façon, je ne programme pas pour distribuer, tu sais bien.

Checkinstall ne gère pas du tout les dépendances, à part si tu les spécifies manuellement avec le flag (géré seulement pour les RPMs, pas pour les debs, d'après la documentation) --requires=… (et à part les auto-requires de bibliothèques .so de RPM, je suppose, mais dpkg ne fait pas ça).

Godzil a souhaité poursuivre une discussion dérivée dans un nouveau sujet. La discussion initiale a eu lieu dans le sujet topics/132745-linux/233#post-6969 tandis que la discussion dérivée continue dans le sujet topics/188198-systemd-le-retour-de-la-vengeance où les messages en rapport ont été copiés.

GEdit n'a plus de mainteneur :
https://mail.gnome.org/archives/gedit-list/2017-July/msg00001.html

Un jour, systemd aussi. Un jour.

Lol

Zerosquare (./6978) :
GEdit n'a plus de mainteneur :
https://mail.gnome.org/archives/gedit-list/2017-July/msg00001.html

Geany a pris la relève depuis longtemps déjà. C'est étonnant que gedit a tenu si longtemps.

Oh linux mon beau linux, a quel point est tu bien sécurisé?

A priori il est conseillé de ne pas appliquer certains patchs, mais pas pour la raison auquel vous pensez:

https://yro.slashdot.org/story/17/08/04/2233239/linux-kernel-hardeners-grsecurity-sue-open-sources-bruce-perens

Oh et Linus s'en est donné a coeur joie: https://www.theregister.co.uk/2017/06/26/linus_torvalds_slams_pure_garbage_from_clowns_at_grsecurity/?mt=1502286911319
(et pour le coup je ne peux pas lui donner tord)

quels débiles chez grsec...

GRSecurity → poubelle!

direct ?

Sur un plan technique, il est un fait qu'absolument rien n'arrive à la cheville de PaX+grsecurity, qui contient des protections contre une importante diversité de vraies attaques. KERNEXEC, MEMORY_UDEREF, RAP, CONSTIFY, RANDSTRUCT et REFCOUNT sont les principales défenses, capables d'arrêter à plusieurs endroits les PoCs mentionnés quelques fois par an sur par exemple LWN et qui fonctionnent sans problème sur mainline. Soit ces protections n'existent pas du tout upstream (c'est le cas des 3 premières: les SMEP+SMAP des x86/x86_64 et PXN+PAN des ARM ne sont pas tout à fait équivalents à KERNEXEC et MEMORY_UDEREF, nécessitent du matériel récent encore rare dans le monde réel et/ou tournant rarement des kernels qui gèrent ces features, et sont apparemment plus faciles à désactiver par des exploits), soit elles existent dans une version nettement dégradée (les trois dernières sont opt-in plutôt qu'opt-out, et utilisées dans un sous-ensemble très restreint du kernel).
Linux mainline continuera manifestement pendant encore longtemps (virtuellement toujours ?) à être vulnérable à des classes d'attaques connues, qui n'existent plus depuis 10 à 15 ans pour certaines dans PaX+grsecurity... et existent également de moins en moins sous Windows. Du point de vue de la mise en place de défenses contre des classes d'attaques connues, l'écart entre le entre le core de Windows (kernel + user-space de l'OS seul) et Linux + user-space plus ou moins core (ça veut dire par exemple aussi Samba, pour avoir une enveloppe fonctionnelle comparable à celle de Windows OOTB) grandit en défaveur de Linux + user-space. Dans les deux cas, je ne parle pas des librairies et applications tierces développées il y a longtemps sans règles de sécurité !
Par exemple, Windows 10 est en train d'aller de plus en plus loin dans la mise en place d'une forme de CFG, même si elle n'est pas aussi puissante que RAP; aucune forme de CFG n'existe dans Linux mainline ou dans son user-space (aussi parce que presque toutes les distros utilisent GCC, qui ne propose aucune telle feature). Ca ne veut pas dire qu'il ne reste pas de bugs embarrassants dans le core de Windows, ça veut juste dire que Microsoft travaille beaucoup plus que Google, Redhat et les autres à emmerder les faiseurs d'exploits en empilant les défenses...

Sur un plan non technique... ne tirons pas sur les ambulances, elles se mettent (et on les met) dans la position d'en recevoir bien assez comme ça
Même si certaines des raisons pour lesquelles PaXTeam+spender se comportent ainsi sont faciles à comprendre et difficiles à ne pas admettre. Beaucoup ne font hélas pas l'effort de chercher à en prendre connaissance.

Sur le plan plus légal, il y a déjà eu un précédent plus ou moins similaire :
http://www.h-online.com/open/news/item/Controversy-surrounds-Red-Hat-s-obfuscated-source-code-release-1200554.html

En gros, Red Hat a arrêté de distribuer publiquement les patches du noyau sous forme individuelle, pour les remplacer par un seul gros patch qui reprend tout - ce qui est beaucoup moins pratique pour savoir lesquels ont été appliqués ou modifiés. La raison avancée était qu'ils ne voulaient plus faciliter le boulot d'Oracle, qui vend sa propre distrib dérivée de RHEL. En soi ce n'est pas interdit par la GPL : rien ne dit que les sources doivent être redistribuée sous forme "pratique".

Là où c'est intéressant, c'est qu'il fournissaient aussi à leurs clients (ceux qui payent) le détail des patches individuels, mais interdisaient contractuellement aux clients de redistribuer ces infos, sous peine de résiliation de contrat. Or les patches étant sous GPL, les clients ont le droit de les redistribuer. C'est assez clairement contraire à l'esprit de la licence, mais je ne sais pas si la légalité de la manœuvre a été tranchée.

de mémoire, la GPL demande quand même que ça soit sous une forme un minimum utilisable (mais je dois me tromper, du coup)

Pour le coup, c'est utilisable : si tu appliques le gros patch, tu retrouves bien le même code que si tu avais appliqué tous les patches individuels. Donc ce n'est pas la même chose que s'ils avaient fait passer le code dans un obfuscateur, par exemple.

Mais d'après ce que j'ai compris, le point litigieux principal n'était pas celui-là (même si ça faisait grincer des dents) ; c'était "est-ce que c'est légal de vendre un soft sous GPL avec un contrat qui devient caduc quand tu utilises un des droits que t'accorde la GPL ?"

Le problème est la clause de non modification/amendements de la GPLv2 et supérieure, tu ne peux pas modifier la licence en ajoutant des contraintes.