je ne demande pas aux distribs de compiler sans SSE2, les nouvelles machines doivent pouvoir tirer partie des optimisations
en pratique, je n'ai eu des soucis qu'avec 2 composants utilisant réellement SSE2 (flash et libflac), "tout compiler pour quelques machines perdues" est donc hors de propos
Cependant, par expérience, ces machines sont encore utilisables (la mienne en tout cas). J'ai racheté un portable plus récent, mais mon vieux PC fixe est le seul à avoir un lecteur CD. J'ai un autre vieux PC récupéré, à base de CPU intel mais lui c'est la carte graphique qui ne gère pas GNOME 3. Même problème, les pre-requis minimum, sont "flous". En gros pour savoir, faut essayer.
Je suis capable de recompiler les programmes qui posent problème. Mais les distribs ne communiquent pas trop sur les pré-requis matériels, changent plus ou moins silencieusement des flags de compilation importants, tout en conservant la même appellation "i686" qui a toujours fait fonctionner nos vieilles machines.
Quand tu casses la compatibilité binaire d'un logiciel, une bonne pratique est de changer de version majeure. Là tu romps la compatibilité mais tu t'appelles toujours i686, et les gens passent du temps à déboguer parce que ça a toujours fonctionné chez eux par le passé. Cela devrait être possible de déduire quelles architectures matérielles exactement sont gérées à partir des flags de compilation. Il faudrait juste les mettre plus en avant plutôt que promouvoir un "i686" qui n'a plus beaucoup de sens.
Le problème n'est pas que là. Ce qui me dérance c'est plutôt que les distribs décident de ne plus prendre plus en charge SSE2, continuent à faire des paquets i686, mais ne communiquent pas sur le fait que ça ne marchera plus pour certaines personnes. L'utilisateur final ne sait pas non plus à partir de quelle version de distrib exactement ces architectures ne sont plus gérées (ou alors l'information m'a échappé).
Pourtant en pratique, j'ai eu le problème avec très peu d'applications: d'abord le plugin flash (mais lui a l'excuse d'être propriétaire), puis libflac 1 ou 2 ans plus tard.
Ah, c'était dans libflac le problème. Un autre soucis c'est de savoir avec quels flags d'architecture sont compilés les distros, pour pouvoir savoir chaque distrib est vraiment compatible.
On tombe alors dans les distributions pour ordinosaure… C'est du matériel avec 1,5 Go de RAM, capable de faire tourner un GNOME 3. Ça ferait certes une occasion d'essayer une SliTaz, mais c'est pas un 486 non plus…
Je me suis fait la même remarque. J'ai un Athlon XP 3000+ (barton) acheté en 2004 je crois. Je me suis rendu compte de problèmes avec SSE2 quand j'ai tenté de ripper mes CD audio avec sound-juicer (sous Mageia 6, le problème n'est pas que chez Fedora). La seule solution a pour moi été de le recompiler en désactivant la gestion SSE2. Cela peut être un peu pénible, mais c'est le seul logiciel avec lequel j'avais eu ce problème. Je n'avais pas eu le soucis avec Firefox, mais j'utilise moins cet ordi depuis cette année. Après c'est sûr que rebuilder Firefox, c'est pas ce qu'il y a de plus pratique…
En cherchant un peu je suis tombé sur ce thread: https://superuser.com/a/1254953
On y pointe cet outil en Rust, elfx86ets, permettant de détecter le jeu d'instructions utilisé par un binaire (et donc potentiellement trouver les binaires à problème selon son architecture).
Par ailleurs, il a été constaté dans la partie de la base de données dédiée à la gestion des étudiants, des commentaires tels que : diagnostiqué de plusieurs maladies graves […] ou très lourdement endetté […].
Sûrement un coup des syndicalistes :p. Sérieusement, la lecture des manquements vaut effectivement le coup d'oeil. Pour une école qui enseigne l'informatique, ça craint du boudin vu le nombre d'infractions.
La délégation a enfin été informée que les postes de travail des agents de sécurité qui ont accès au dispositif de vidéosurveillance est protégé par un mot de passe composé de 5 caractère alphanumériques.
On peut s'occuper d'un autre problème du même genre maintenant, les motards. Ils se regroupent le dimanche, boivent, font un boucan d'enfer et ce sont de vrais dangers publics sur la route. Interdisons la moto !
Je propose qu'on rajoute juste un peu plus de loups.
Je manipule de moins en moins des fichiers systèmes, alors ceci ne m'évoquait plus grand chose:
root::16431:0:99999:7:::
Il faut commencer par comparer avec la ligne existance avec sudo grep root /etc/shadow. Pour comprendre un peu mieux je rajoute un extrait de man shadow. C'est le 2ème champ vide (plutôt qu'avec un point d'exclamation, en tout cas sur ma vieille Ubuntu) qui ouvre la porte:
mot de passe chiffré
Consultez crypt(3) pour plus d'informations sur le traitement de cette chaîne.
Si le champ du mot de passe contient une chaîne qui ne peut pas être un résultat valable de crypt(3), par exemple si elle contient les caractères ! ou *, alors l'utilisateur ne pourra pas utiliser
son mot de passe UNIX pour se connecter (mais il se peut que l'utilisateur puisse se connecter au système par d'autres moyens).
Ce champ peut être vide. Dans ce cas aucun mot de passe n'est nécessaire pour s'authentifier avec l'identifiant de connexion indiqué. Cependant, certaines applications qui lisent le fichier
/etc/shadow peuvent n'autoriser aucun accès si le mot de passe est vide.
Un champ de mot de passe qui commence avec un point d'exclamation indique que le mot de passe est bloqué. Les caractères restants sur la ligne représentent le champ de mot de passe avant que le
mot de passe n'ait été bloqué.
Galaxy J5 ici, et je compte bien le faire durer aussi longtemps que possible, c'est pas comme si les réserves de terres rares étaient infinies. Je n'utilise que Firefox, donc je trouve aussi la question de savoir si Firefox continuera de tourner avec d'anciennes version d'Android pertinente…
Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.
Non. Tu te prends par la main, tu codes ton appli pour utiliser les libs couramment utilisées par les plus grosses distrib’ du marché et tu livres un soft potable.
Tu te berces d'illusions là.
Les "libs couramment utilisées par les plus grosses distrib’ du marché" ça veut rien dire. Toutes les distribs n'ont pas les mêmes versions de bibliothèques, et faire des cas spécifiques par combinaison de version sans les tester ça, ça ne marche pas.
Exemple en tête: GTK+ qui a changé la gestion du CSS en cours de route sur GTK+ 3. Tu fais comment quand tu as fait le portage de ton appli pour la nouvelle version, mais que toutes les distribs ne l'ont pas ? En général tu te retrouveras avec les distribs qui ont l'ancienne version de dépendance qui diffuseront l'ancienne version de l'appli, et les les distribs qui ont la version récente qui diffuseront la nouvelle version de l'appli.
Tu noteras que l'appli est propre, mais c'est l'écosystème qui fait que la distrib contrôle les dépendances, et pas le développeur de l'appli. Flatpak lui permet de livrer exactement la version qui est connue pour fonctionner avec telle autre version de dépendance, et ça marchera sur toutes les distribs gérant flatpak. Le développeur reprend le contrôle.
Ensuite s'il sort une nouvelle version majeure, bin désolé mais si tu n'as pas une distrib rolling release, la réalité du terrain c'est que ton soft ne sera que dans la version N+1 de la distrib parce que faire un backport ce serait aussi backporter les dépendances dans leur version plus récentes. Si ces dépendances sont partagées avec d'autres applis et non parallèlement installables, la validation devient un cauchemar, donc personne ne fait le backport.
Flatkill a tout de même un avantage: montrer que le boulot n'est pas fini, car faire un package flatpak les yeux fermés en donnant toutes les autorisations à l'appli c'est une hérésie au niveau sécurité, parce que ça ouvre des failles de sécurité.
Des packageurs inconséquents peuvent donc ruiner la réputation d'une application, et ça c'est un vrai problème. J'ai déjà vu des développeurs refuser de mettre le doigt dans flatpak, et refuser les rapports de bug à ce sujet parce que l'appli a été packagée par un tiers.
Qui ici a déjà eu une application malveillante sous GNU ? Quel est du coup l’utilité du cloisonnement ?
À une époque où les gens font du wget http://www.whatever/bidule_inconnu.sh | sudo bash , se protéger contre des menaces potentielles ne me semble pas superflu. En plus, le fait que tu n'ais jamais vu d'application malveillante ne veut pas dire qu'elles n'existent pas, juste que tu n'en as pas vu. Un rootkit qui s'installe par exemple, ça le crie pas sur les toits.
Le besoin de cloisonnement vient du fait que le modèle des distributions est peu flexible, et que des softs produits pour Linux et Windows sont en général plus à jour sous Windows ! Pour Linux, il faut attendre la prochaine version de ta distrib, croiser les doigts et espérer un backport, etc. Ensuite à partir du moment où tu veux exécuter du code tel que fourni par le développeur de l'application et que tu fais sauter l'intermédiaire de sécurité qu'est la distrib, tu te retrouves exposé au bon vouloir de chaque développeur d'appli de mettre à jour les bibliothèques qu'il utilise à chaque faille de sécurité détectée. S'il ne le fait pas, tu es exposé (comme le montre bien http://flatkill.org ) , la seule solution solution est donc de cloisonner, et de bien cloisonner (i.e. réduire les permissions au minimum).
En gros, flatpak ça fonctionne comme Android au niveau permissions. Donc le moyen le plus rapide de fournir un flatpak pour les applications était de demander un maximum de permissions pour que ça fonctionne directement. Mais ensuite les applications ont un boulot d'adaptation pour réduire les droits demandés, et utiliser des portails à la place. Et adapter une application, ça demande du temps de développement.
En revanche, je pense que la bonne question à se poser c'est: doit-on packager des applications sur flathub en sachant que les développeurs de l'application ne soutiennent pas flatpak. Parce que si personne n'est prêt à faire le boulot d'adaptation, cela représente effectivement un risque.
Une des solutions est sans doute de mettre plus en avants les droits réclamés par une application flatpak, pour qu'on sache si ça a été packagé à l'arrache ou si l'application a réellement été adaptée pour flatpak. Une autre partie de la solution est peut être aussi de ne pas packager une application si:
- on a pas l'intention de fournir des patchs pour restreindre les droits qu'elle demande
- ou si on sait que le mainteneur de l'application refusera les patchs pour la gestion de flatpak
Ou bien on peut la packager, mais sans diffuser le paquet flatpack tant que l'application n'a pas été modifiée pour demander des droits un minimum raisonnables.
En gros, le problème est plus dans l'utilisation de flatpak par les packagers. Mais il faudrait sans doute aussi renforcer dans flatpak et gnome-software la visibilité des permissions demandées pour que l'utilisateur comprenne bien ce à quoi il s'expose.
Que veux tu que le numéro de version te suggère ? Il y a un 4ème digit qui n'a pas l'air d'être dans la numérotation upstream, plus un numéro de paquet. Je pense que si tu es capable d'aller chercher des numéros de CVE, tu dois être capable de regarder le changelog d'un paquet non ? Tu peux d'ailleurs le faire graphiquement avec le gestionnaire de paquets de Mageia. Alors ou c'est en anglais, mais franchement, je ne vois pas ce qu'ils font de si différent des autres distribs, et qui mérite de s'indigner.
Ce n'est pas tant que la version proposée soit ancienne qui me choque, c'est que la distribution diffuse une version qui n'est plus maintenue.
Plus maintenue upstream. LibreOffice maintient ses releases pendant seulement 9 mois, ils ne font pas de version LTS. Mageia fait la maintenance, il y a quoi de désinvolte là dedans ?
Moi ce qui me choque, c'est que tu sois "choqué" alors qu'ils font le job de maintenance, et plutôt bien. Tu attendais une dépêche Mageia pour dire "on maintient LibreOffice" (et tout les autres logiciels de la distrib qui ne sont plus maintenus upstream) ? Dans ce cas pourquoi LibreOffice et pas d'autres logiciels aussi en fin de vie ? Pour moi c'est implicite que le distributeur fait la maintenance, c'est ce qu'on demande à une distribution.
Sinon pour le vieux Fujitsu, tu as la distribution Slitaz.
Les saveurs loram permettent de démarrer SliTaz sur des machines ayant très peu de ressources. La saveur loram a besoin de 128 MB et libère le cdrom, la version loram-cdrom peut démarrer avec 24 Mb et un peu de mémoire swap, mais ne libère pas le cdrom.
Donc la loram-cdrom peut peut être tourner (lentement). Mais tu n'y feras jamais tourner LibreOffice.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 9.
Alors soyons clairs:
Cependant, par expérience, ces machines sont encore utilisables (la mienne en tout cas). J'ai racheté un portable plus récent, mais mon vieux PC fixe est le seul à avoir un lecteur CD. J'ai un autre vieux PC récupéré, à base de CPU intel mais lui c'est la carte graphique qui ne gère pas GNOME 3. Même problème, les pre-requis minimum, sont "flous". En gros pour savoir, faut essayer.
Je suis capable de recompiler les programmes qui posent problème. Mais les distribs ne communiquent pas trop sur les pré-requis matériels, changent plus ou moins silencieusement des flags de compilation importants, tout en conservant la même appellation "i686" qui a toujours fait fonctionner nos vieilles machines.
Quand tu casses la compatibilité binaire d'un logiciel, une bonne pratique est de changer de version majeure. Là tu romps la compatibilité mais tu t'appelles toujours i686, et les gens passent du temps à déboguer parce que ça a toujours fonctionné chez eux par le passé. Cela devrait être possible de déduire quelles architectures matérielles exactement sont gérées à partir des flags de compilation. Il faudrait juste les mettre plus en avant plutôt que promouvoir un "i686" qui n'a plus beaucoup de sens.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 4.
Le problème n'est pas que là. Ce qui me dérance c'est plutôt que les distribs décident de ne plus prendre plus en charge SSE2, continuent à faire des paquets i686, mais ne communiquent pas sur le fait que ça ne marchera plus pour certaines personnes. L'utilisateur final ne sait pas non plus à partir de quelle version de distrib exactement ces architectures ne sont plus gérées (ou alors l'information m'a échappé).
Pourtant en pratique, j'ai eu le problème avec très peu d'applications: d'abord le plugin flash (mais lui a l'excuse d'être propriétaire), puis libflac 1 ou 2 ans plus tard.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 1.
Ah, c'était dans libflac le problème. Un autre soucis c'est de savoir avec quels flags d'architecture sont compilés les distros, pour pouvoir savoir chaque distrib est vraiment compatible.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 2. Dernière modification le 31 octobre 2018 à 10:54.
On tombe alors dans les distributions pour ordinosaure… C'est du matériel avec 1,5 Go de RAM, capable de faire tourner un GNOME 3. Ça ferait certes une occasion d'essayer une SliTaz, mais c'est pas un 486 non plus…
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 6.
On ne devrait pas avoir à changer de hardware pour des problèmes purement logiciels… Développement durable, tout ça…
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 4.
Je me suis fait la même remarque. J'ai un Athlon XP 3000+ (barton) acheté en 2004 je crois. Je me suis rendu compte de problèmes avec SSE2 quand j'ai tenté de ripper mes CD audio avec sound-juicer (sous Mageia 6, le problème n'est pas que chez Fedora). La seule solution a pour moi été de le recompiler en désactivant la gestion SSE2. Cela peut être un peu pénible, mais c'est le seul logiciel avec lequel j'avais eu ce problème. Je n'avais pas eu le soucis avec Firefox, mais j'utilise moins cet ordi depuis cette année. Après c'est sûr que rebuilder Firefox, c'est pas ce qu'il y a de plus pratique…
En cherchant un peu je suis tombé sur ce thread: https://superuser.com/a/1254953
On y pointe cet outil en Rust, elfx86ets, permettant de détecter le jeu d'instructions utilisé par un binaire (et donc potentiellement trouver les binaires à problème selon son architecture).
# Les pratiques
Posté par liberforce (site web personnel) . En réponse au lien Mise en demeure de l'association 42. Évalué à 6.
Sûrement un coup des syndicalistes :p. Sérieusement, la lecture des manquements vaut effectivement le coup d'oeil. Pour une école qui enseigne l'informatique, ça craint du boudin vu le nombre d'infractions.
# security FTW
Posté par liberforce (site web personnel) . En réponse au lien Mise en demeure de l'association 42. Évalué à 4.
[^] # Re: Microsoft en rêvait
Posté par liberforce (site web personnel) . En réponse au journal IBM achète Red Hat. Évalué à 10.
De l'importance de la ponctuation…
vs
[^] # Re: prochaine étape la Vuvuzela ?
Posté par liberforce (site web personnel) . En réponse au journal Enfin un maire qui a la tête sur les épaules. Évalué à 9.
Je propose qu'on rajoute juste un peu plus de loups.
[^] # Re: Magnifique !
Posté par liberforce (site web personnel) . En réponse au journal La faille grosse comme une maison. Évalué à 3.
Je manipule de moins en moins des fichiers systèmes, alors ceci ne m'évoquait plus grand chose:
root::16431:0:99999:7:::
Il faut commencer par comparer avec la ligne existance avec
sudo grep root /etc/shadow. Pour comprendre un peu mieux je rajoute un extrait deman shadow. C'est le 2ème champ vide (plutôt qu'avec un point d'exclamation, en tout cas sur ma vieille Ubuntu) qui ouvre la porte:[^] # Re: question
Posté par liberforce (site web personnel) . En réponse à la dépêche Firefox 63. Évalué à 7.
Galaxy J5 ici, et je compte bien le faire durer aussi longtemps que possible, c'est pas comme si les réserves de terres rares étaient infinies. Je n'utilise que Firefox, donc je trouve aussi la question de savoir si Firefox continuera de tourner avec d'anciennes version d'Android pertinente…
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par liberforce (site web personnel) . En réponse au lien "wget http://foo.com/command.sh | bash" considered harmful. Évalué à 5.
Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.
[^] # Re: Non! Microsoft ne libère PAS 60 000 brevets!
Posté par liberforce (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 41 de l’année 2018. Évalué à 10.
La situation sur exFAT notamment est confirmée notamment par Bradley Khun de la Software Freedom Conservancy.
M'enfin le meilleur endroit pour en discuter reste le journal Vers une fin de la guerre des brevets logiciels ?
[^] # Re: C'est ce qui s'appelle
Posté par liberforce (site web personnel) . En réponse au journal Paul Allen bronsonisé. Évalué à 8.
C'est sûr qu'il l'a mauvaise.
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . En réponse au journal Flatpak. Évalué à 10. Dernière modification le 12 octobre 2018 à 12:29.
Tu te berces d'illusions là.
Les "libs couramment utilisées par les plus grosses distrib’ du marché" ça veut rien dire. Toutes les distribs n'ont pas les mêmes versions de bibliothèques, et faire des cas spécifiques par combinaison de version sans les tester ça, ça ne marche pas.
Exemple en tête: GTK+ qui a changé la gestion du CSS en cours de route sur GTK+ 3. Tu fais comment quand tu as fait le portage de ton appli pour la nouvelle version, mais que toutes les distribs ne l'ont pas ? En général tu te retrouveras avec les distribs qui ont l'ancienne version de dépendance qui diffuseront l'ancienne version de l'appli, et les les distribs qui ont la version récente qui diffuseront la nouvelle version de l'appli.
Tu noteras que l'appli est propre, mais c'est l'écosystème qui fait que la distrib contrôle les dépendances, et pas le développeur de l'appli. Flatpak lui permet de livrer exactement la version qui est connue pour fonctionner avec telle autre version de dépendance, et ça marchera sur toutes les distribs gérant flatpak. Le développeur reprend le contrôle.
Ensuite s'il sort une nouvelle version majeure, bin désolé mais si tu n'as pas une distrib rolling release, la réalité du terrain c'est que ton soft ne sera que dans la version N+1 de la distrib parce que faire un backport ce serait aussi backporter les dépendances dans leur version plus récentes. Si ces dépendances sont partagées avec d'autres applis et non parallèlement installables, la validation devient un cauchemar, donc personne ne fait le backport.
[^] # Re: Kill flatkill
Posté par liberforce (site web personnel) . En réponse au journal Flatpak. Évalué à 8.
Flatkill a tout de même un avantage: montrer que le boulot n'est pas fini, car faire un package flatpak les yeux fermés en donnant toutes les autorisations à l'appli c'est une hérésie au niveau sécurité, parce que ça ouvre des failles de sécurité.
Des packageurs inconséquents peuvent donc ruiner la réputation d'une application, et ça c'est un vrai problème. J'ai déjà vu des développeurs refuser de mettre le doigt dans flatpak, et refuser les rapports de bug à ce sujet parce que l'appli a été packagée par un tiers.
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . En réponse au journal Flatpak. Évalué à 6. Dernière modification le 12 octobre 2018 à 11:20.
À une époque où les gens font du
wget http://www.whatever/bidule_inconnu.sh | sudo bash, se protéger contre des menaces potentielles ne me semble pas superflu. En plus, le fait que tu n'ais jamais vu d'application malveillante ne veut pas dire qu'elles n'existent pas, juste que tu n'en as pas vu. Un rootkit qui s'installe par exemple, ça le crie pas sur les toits.Le besoin de cloisonnement vient du fait que le modèle des distributions est peu flexible, et que des softs produits pour Linux et Windows sont en général plus à jour sous Windows ! Pour Linux, il faut attendre la prochaine version de ta distrib, croiser les doigts et espérer un backport, etc. Ensuite à partir du moment où tu veux exécuter du code tel que fourni par le développeur de l'application et que tu fais sauter l'intermédiaire de sécurité qu'est la distrib, tu te retrouves exposé au bon vouloir de chaque développeur d'appli de mettre à jour les bibliothèques qu'il utilise à chaque faille de sécurité détectée. S'il ne le fait pas, tu es exposé (comme le montre bien http://flatkill.org ) , la seule solution solution est donc de cloisonner, et de bien cloisonner (i.e. réduire les permissions au minimum).
[^] # Re: De ce que j'ai compris
Posté par liberforce (site web personnel) . En réponse au lien Flatpak - a security nightmare. Évalué à 2. Dernière modification le 11 octobre 2018 à 11:10.
La doc de flatpack spécifie aussi qu'il faut limiter les permission d'accès au filesystem:
http://docs.flatpak.org/fr/latest/sandbox-permissions.html#filesystem-access
Les packagers ont une responsabilité s'ils ne respectent pas les bonnes pratiques.
# De ce que j'ai compris
Posté par liberforce (site web personnel) . En réponse au lien Flatpak - a security nightmare. Évalué à 5.
En gros, flatpak ça fonctionne comme Android au niveau permissions. Donc le moyen le plus rapide de fournir un flatpak pour les applications était de demander un maximum de permissions pour que ça fonctionne directement. Mais ensuite les applications ont un boulot d'adaptation pour réduire les droits demandés, et utiliser des portails à la place. Et adapter une application, ça demande du temps de développement.
Le système de packages n'est pas parfait non plus:
https://mastodon.social/@federicomena/100873820279835134
En revanche, je pense que la bonne question à se poser c'est: doit-on packager des applications sur flathub en sachant que les développeurs de l'application ne soutiennent pas flatpak. Parce que si personne n'est prêt à faire le boulot d'adaptation, cela représente effectivement un risque.
Une des solutions est sans doute de mettre plus en avants les droits réclamés par une application flatpak, pour qu'on sache si ça a été packagé à l'arrache ou si l'application a réellement été adaptée pour flatpak. Une autre partie de la solution est peut être aussi de ne pas packager une application si:
- on a pas l'intention de fournir des patchs pour restreindre les droits qu'elle demande
- ou si on sait que le mainteneur de l'application refusera les patchs pour la gestion de flatpak
Ou bien on peut la packager, mais sans diffuser le paquet flatpack tant que l'application n'a pas été modifiée pour demander des droits un minimum raisonnables.
En gros, le problème est plus dans l'utilisation de flatpak par les packagers. Mais il faudrait sans doute aussi renforcer dans flatpak et gnome-software la visibilité des permissions demandées pour que l'utilisateur comprenne bien ce à quoi il s'expose.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 6.
Que veux tu que le numéro de version te suggère ? Il y a un 4ème digit qui n'a pas l'air d'être dans la numérotation upstream, plus un numéro de paquet. Je pense que si tu es capable d'aller chercher des numéros de CVE, tu dois être capable de regarder le changelog d'un paquet non ? Tu peux d'ailleurs le faire graphiquement avec le gestionnaire de paquets de Mageia. Alors ou c'est en anglais, mais franchement, je ne vois pas ce qu'ils font de si différent des autres distribs, et qui mérite de s'indigner.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 9.
Plus maintenue upstream. LibreOffice maintient ses releases pendant seulement 9 mois, ils ne font pas de version LTS. Mageia fait la maintenance, il y a quoi de désinvolte là dedans ?
Moi ce qui me choque, c'est que tu sois "choqué" alors qu'ils font le job de maintenance, et plutôt bien. Tu attendais une dépêche Mageia pour dire "on maintient LibreOffice" (et tout les autres logiciels de la distrib qui ne sont plus maintenus upstream) ? Dans ce cas pourquoi LibreOffice et pas d'autres logiciels aussi en fin de vie ? Pour moi c'est implicite que le distributeur fait la maintenance, c'est ce qu'on demande à une distribution.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 3. Dernière modification le 09 octobre 2018 à 16:10.
Pour des versions plus récentes, il y a une version Flatpak de LibreOffice :
https://www.libreoffice.org/download/flatpak/
Je n'ai pas testé cependant.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 7.
Ça a l'air d'être le cas, en partie, et en partie aussi du backport de Fedora 26 :
Source: http://sophie.zarb.org/rpms/1a4c8e652e881959b1c8a95c45559202/changelog
Malgré le "not released yet", ça a bien l'air d'être livré:
https://madb.mageia.org/package/show/release/6/arch/x86_64/name/libreoffice
[^] # Re: j'envysage de trouver une autre machine
Posté par liberforce (site web personnel) . En réponse au message Quel distribution et quelle de pour un pc tournant de base sous windows 98. Évalué à 2. Dernière modification le 09 octobre 2018 à 11:43.
Sinon pour le vieux Fujitsu, tu as la distribution Slitaz.
Donc la loram-cdrom peut peut être tourner (lentement). Mais tu n'y feras jamais tourner LibreOffice.