• # xkcd 2044

    Posté par . Évalué à 10 (+12/-0).

    Titre de l'image

  • # hahahahahaha

    Posté par . Évalué à 1 (+3/-4). Dernière modification le 10/10/18 à 18:47.

  • # HTTP GET and EXECUTE

    Posté par . Évalué à 7 (+5/-0).

    Est-ce que c'est vraiment différent de :

    curl -s https://random.site/shell.sh | sudo bash
    

    J'invente (presque) rien : https://www.rust-lang.org/fr-FR/install.html.

    L'installation décrite ci-dessus, via rustup, est la façon préférable d'installer Rust pour la plupart des développeurs, mais Rust peut aussi être installé via d'autres méthodes.

    Et pourtant, Debian a déjà une version assez récente

    Mais non, il faut vraiment être sur le fil du rasoir.

  • # c'est pas top mais

    Posté par . Évalué à 2 (+1/-0).

    C'est clair que flatpack est moins sécurisé qu'une install classique mais pour certains logiciel mal maintenus et donc ayant des dépendances ancienne flatpack représente une alternative. Comme qui dirait c'est moins pire. Le risque c'est que du coup il y ait moins d'effort qui soit fait pour une intégration système.

  • # La critique est facile

    Posté par (page perso) . Évalué à 2 (+5/-5).

    La critique est facile, on attend que cette personne propose une alternative sans critiques possibles (tiens plus personne… Classique).

    • [^] # Re: La critique est facile

      Posté par . Évalué à 2 (+1/-1).

      c'est exactement ça qui est rigolo : à la fois la pertinence du constat sur les droits demandés en vrai par les packs dispo, contradictoire avec le discours sur flatpack, et à la fois le fait que l'argumentaire est au final assez faible puisqu'il ne peut reprocher au final que ça. Une belle poilade, en somme.

  • # De ce que j'ai compris

    Posté par (page perso) . Évalué à 5 (+3/-0).

    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: De ce que j'ai compris

      Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 11/10/18 à 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

      As a general rule, Filesystem access should be limited as much as possible. This includes using:

      • Using portals as an alternative to blanket filesystem access, wherever possible.
      • Using read-only access wherever possible, using the :ro option.
      • If some home directory access is absolutely required, using XDG directory access only.

      Les packagers ont une responsabilité s'ils ne respectent pas les bonnes pratiques.

  • # flatkill dot org

    Posté par (page perso) . Évalué à 3 (+1/-0).

    Les auteurs de flatkill.org, qui sont-ils ? Quels sont leurs réseaux ?

  • # 2 autres articles

    Posté par (page perso) . Évalué à 2 (+0/-0).

    Robotic Tendencies » Flatpaks, sandboxes and security
    http://ramcq.net/2018/10/15/flatpak-sandbox-security/
    (via planet.gnome.org)

    Snap, Flatpak and AppImage, package formats compared
    https://verummeum.com/blog/2018/10/14/portable-package-formats/
    (via http://www.osnews.com/story/30797/Snap_Flatpak_and_AppImage_package_formats_compared)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.