La dernière version d'ubuntu introduit un nouveau système de packaging appelé snap. Les snaps sont globalement des systèmes de fichiers squashfs qui contiennent les binaires d'une application et sont soumis au contrôle de apparmor et seccomp pour garantir l’intégrité du système qui exécutera le snap. Ils sont par la suite distribué par un "store" sous ubuntu ou ils peuvent être installés en ligne de commandes.
Au début on se demande l'intérêt d'une telle approche alors que les paquets debian (.deb) ou RedHat (.rpm) existent depuis plus de 20 ans et semblent remplir leurs tâches.
En m'impliquant dans les projets Open Hardware, je me suis retrouvé confronté à d'autres profils d'ingénieurs qui ont une vision plus basique de la flexibilité d'un système que nous pouvons avoir en tant qu'informaticiens. Disons pour être claire que globalement un ingénieur en mécanique veut installer son logiciel et ses mises à jours en cliquant sur une icône. Dès que l'on suggère une commande du type apt-get install on a un phénomène de révulsion.
L'autre problème auquel nous sommes confrontés en tant que communauté c'est la disparité des bibliothèques et des versions qui peuvent exister entre les systèmes des membres d'une même communauté. Ces disparités peuvent engendrer des problèmes de compatibilité notamment lorsque les logiciels sont en développements actifs.
Je me suis alors lancé dans la création de mon premier snap avec FreeCAD. En prenant un peu de recul on est assez loin du traditionnel hello world! et deux semaines plus tard, je peux dire qu'on en est très loin.
snap fonctionne suivant un système de préparation, staging et création d'image. Il est ultra modulaire, et l'ensemble de la configuration s'effectue via un unique fichier snapcraft.yaml. Il existe pas mal de tutoriel sur le net plus ou moins bien faits, mais intégrer FreeCAD dans un snap relève plutôt du défi.
snap reprend le principe d’intégration continue, et il est donc possible de décrire les étapes de compilation de l'application dans le fichier snapcraft.yaml. Pour être honnête et pour être "développeur" de FreeCAD j'ai omis cette étape. Compiler FreeCAD et l'ensemble de ses dépendances depuis github requiert une prise en main d'un mois environ (et une compile complète 6h sur mon laptop), alors tenter de le faire dans un outils en cours de développement ou en v1 me semblait un peu risqué. J'ai plutôt choisi une approche qui me semblait plus "simple".
J'ai fait l’étape de staging dans une VM vagrant. A partir de cette VM, j'ai compilé les dépendances (libMED, VTK, OCCT, Netgen, CalculiX, puis j'ai copié l'ensemble des binaires nécessaires dans le répertoire de staging de mon snap et ai créé un wrapper de lancement. Au bout d'un mois d'essai ça marche complétement. Alors qu'elles ont été les difficultés ?
Qui dit snap dit pas d’accès au système de fichiers système. Donc au revoir:
- Le système de configuration de GTK
- Les locales
- Les fontes
- Les répertoires temporaires
- L’accès aux fichiers de configuration systèmes
Tout ceci doit être présent dans votre snap et vous devez bien entendu utiliser les variables d’environnement pour relocaliser ces fichiers (un conseil regardez toutes les variables XDG_ …).
Au final mon snap fonctionne, le temps de dev n'a pas été aussi long que ça, et si vous voulez tester c'est la
https://myapps.developer.ubuntu.com/dev/click-apps/share/09951e1397a86ca9243bebcd715373197c702839fe5c5f9b8f1b5db81767306df0eb07698f8a6b3ac0c4/
Ça peut vous donner une idée de ce que l'on peut réussir à faire au travers de SNAP que j'ai trouvé au final super intéressant et surtout qui résout mon problème d’accès à FreeCAD pour les ingénieurs en mécanique sous linux !. Le paquet FreeCAD arrive ainsi au même niveau que le paquet Windows et MacOS ;)
Et pour finir voici le wrapper de lancement qui peut vous servir !
if [ ! -d "SNAP_USER_DATA/.config" ]
then
\mkdir $SNAP_USER_DATA/.config
fi
export CONFIG_DIR=$SNAP_USER_DATA/.config
export I18NPATH=$SNAP/usr/share/i18n
export LOCPATH=$CONFIG_DIR
LANG=en_US
ENC=UTF-8
LOC="$LANG.$ENC"
\rm -rf $CONFIG_DIR/$LOC
if [ ! -e $CONFIG_DIR/$LOC ]; then
($SNAP/usr/bin/localedef --prefix=$CONFIG_DIR -f $ENC -i $LANG $CONFIG_DIR/$LOC)>& /dev/null
fi
export LC_ALL=$LOC
export LANG=$LOC
export LANGUAGE=${LANG%_*}
export LIBGL_DRIVERS_PATH=$SNAP/usr/lib/x86_64-linux-gnu/dri
export GTK_PATH=$SNAP/usr/lib/x86_64-linux-gnu/gtk-2.0/modules
export LD_LIBRARY_PATH=$SNAP/usr/lib:$SNAP/usr/lib/x86_64-linux-gnu/gio/modules:$SNAP/usr/lib/x86_64-linux-gnu/gtk-2.0/modules:$LD_LIBRARY_PATH
export GTK_DATA_PREFIX=$CONFIG_DIR
export GTK_EXE_PREFIX=$SNAP/usr
export GDK_PIXBUF_MODULE_FILE=$SNAP/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
export PYTHONHOME="$SNAP/usr"
export PYTHONPATH="$SNAP/usr"
export XDG_DATA_DIR="$SNAP/usr/share/glib-2.0/schemas"
export GSETTINGS_SCHEMA_DIR="$SNAP/usr/share/glib-2.0/schemas"
export LANG=en_US.UTF-8
export FREECAD_USER_DATA="$SNAP_USER_DATA"
export XDG_CONFIG_HOME="$CONFIG_DIR"
export MATPLOTLIBDATA="$SNAP/usr/share/matplotlib/mpl-data"
export GIO_EXTRA_MODULES="$SNAP/usr/lib/x86_64-linux-gnu/gio/modules"
export XDG_RUNTIME_DIR="$CONFIG_DIR"
export QT_QPA_FONTDIR="$SNAP/usr/share/fonts"
export XDG_DATA_HOME="$SNAP/usr/share/icons"
export XDG_DATA_DIRS="$SNAP/usr/share/mime"
\cp -rf $SNAP/fontconfig $CONFIG_DIR
if [ ! -d "$CONFIG_DIR/.cache/fontconfig" ]
then
($SNAP/usr/bin/fc-cache --really-force --verbose) >& /dev/null
\cp $SNAP/etc/matplotlibrc $CONFIG_DIR/matplotlibrc
fi
export MPLCONFIGDIR="$CONFIG_DIR"
export GTK2_RC_FILES="$SNAP/usr/share/themes/Raleigh/gtk-2.0/gtkrc"
exec "$SNAP/opt/local/FreeCAD-0.17/bin/FreeCAD" -u $CONFIG_DIR/user.cfg -s $CONFIG_DIR/system.cfg $@
# Cliquer sur une icône
Posté par Anonyme . Évalué à 7. Dernière modification le 05 juin 2016 à 22:26.
N’est-ce pas le but de la logithèque Ubuntu ?
Ou alors FreeCAD n’est pas disponible dans la version que tu souhaites, et du coup ça devient un bordel à installer autrement qu’avec une image où tout y est déjà ?
Et comment on installe un snap, justement ?
[^] # Re: Cliquer sur une icône
Posté par vejmarie (site web personnel) . Évalué à 8.
C'est le but de la logitheque ubuntu, mais elle supporte 2 formats, .deb ou snap.
Pour installer un snap:
sudo snap install freecad (par exemple)
J'utilise une version de dev de FreeCAD avec les autres membres du projet RuggedPOD. Les dependances de FreeCAD notamment OCCT sont "outdatees" dans les distros (v6.8 par exemple alors que la biblio est en v7), et du coup ca nous permet de tous tourner avec le meme niveau de version sur l'ensemble de l'application.
[^] # Re: Cliquer sur une icône
Posté par Cyprien (site web personnel) . Évalué à 2.
Merci pour ce retour, je suis assez curieux de voir ce que ca donne…
Je viens de l'installer, pas de problème, ca passe. Par contre, ensuite, comment on fait pour le lancer ?
freecad en ligne de commande ne fonctionne pas… Je suis sur Ubuntu Gnome.
[^] # Re: Cliquer sur une icône
Posté par vejmarie (site web personnel) . Évalué à 2.
/snap/bin/freecad.FreeCAD ;)
[^] # Re: Cliquer sur une icône
Posté par Loïc Minier . Évalué à 2.
Et normalement /snap/bin est même dans le PATH par défaut, donc même "freecad.FreeCAD" devrait marcher. :-)
# Excellent !
Posté par rockn (site web personnel) . Évalué à 1.
C'est super ! C'est justement quelque chose que je voulais faire car j'ai cru comprendre que les snap pouvaient s'installer sur tablette ubuntu touch (sans "casser" le système), et même si j'ai vu par exemple que Gimp et LibreOffice n'était pas vraiment utilisable sur tablette, je pense que FreeCAD sur tablette ferait un très bon viewer 3D.
Une question à propos de ce snap avant que j'installe une VM 16.04 pour tester par moi même :
- C'est une version de FreeCAD avec OCCT 7 ?
[^] # Re: Excellent !
Posté par vejmarie (site web personnel) . Évalué à 3.
Oui OCCT 7, VTK 7 pour le post processing FEM, et CalculiX integre. J'en ai profite pour activer aussi le module Assembly (en cours de dev)
# merci !
Posté par bolikahult . Évalué à 2.
Salut, c'est chouette d'avoir ce genre de retour !
Étant architecte, disons que j'ai un peu le même profil que tes copains mécaniciens, même si je fais quand même de la ligne de commande.
Je me demandais si tu envisageais de faire la même chose avec flatpack (xdg-app) ? J'ai un peu peur qu'avec snap, seul ubuntu puisse profiter d'une installation à la windows.
C'est pas une injonction, hein ! Simplement ça m'intéresse de connaître l'état d'esprit des empaqueteurs sur ce sujet snap/xdg-app…
tchô
[^] # Re: merci !
Posté par vejmarie (site web personnel) . Évalué à 1.
Salut,
Alors pour le moment je n'ai pas prevu de tester d'autres systemes d'empaquetage ;). Mais j'ai plutot l'esprit ouvert alors je vais regarder ce que tu proposes. Ce serait pas mal si snap etait porte sur d'autres distro, je pense que ca doit etre faisable, mais a mon avis on va rentrer dans des gueres de religions ;)
vejmarie
[^] # Re: merci !
Posté par Okki (site web personnel, Mastodon) . Évalué à 4.
Snap c'est uniquement Ubuntu, quand Flatpak tournera partout (y compris sous Ubuntu). Par contre, bien que la technologie soit déjà prête, toutes les logithèques ne le prennent pas encore en charge (ce qui oblige à passer par la ligne de commande). Dans le cas de GNOME Software / Ubuntu Software, il faudra attendre la prochaine version, prévue pour le mois de septembre.
[^] # Re: merci !
Posté par anarnux . Évalué à 1.
A priori si, snap serait deja compatible avec de grosse distro autre qu'ubuntu (debian,archlinux en natif, c'est dire)
http://liliputing.com/2016/06/ubuntus-snap-packages-now-work-many-linux-distros.html
C'est une bonne nouvelle pour les logiciels linux grand public :)
# Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 9. Dernière modification le 06 juin 2016 à 09:46.
J’ai une question à ce sujet, parce que j’ai l’impression que snap va avoir exactement le même problème que docker à ce niveau. Comment se passe les mises-à-jour de sécurité en cas de faille dans une des bibliothèques utilisées par les snap ?
Les « problèmes » de compatibilité étant généralement dus à la mise à disposition d’une unique version des bibliothèques pour toutes les applications, ça facilite aussi grandement le travail en cas de faille, puisqu’il suffit de mettre à jour uniquement la bibliothèque pour protégér l’ensemble du système.
Sur snap, si je lis entre les lignes, ça signifie que les bibliothèques se retrouvent dupliquées, potentiellement en version différente entre chaque application, donc qu’aucune mise-à-jour de sécurité n’est possible et qu’il faut attendre le bon vouloir des mainteneurs d’une application pour être mis à l’abri. Et qu’en plus de ça, en cas de faille de sécurité, c’est l’ensemble des applications de ton système qu’il faut mettre à jour.
Est-ce que je me trompe ?
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Anonyme . Évalué à -1.
Le « problème » des mises à jours de sécurité sur Docker (ainsi que sur snap pour le coup) sont un faux problème tellement il est en réalité plus simple de réaliser ces mises à jours que sur un système traditionnel.
Après avoir reconstruit l'image, il est du coup bien plus simple d'exécuter la suite de test du service que l'on a mis dans un container et de s'assurer de l'absence d'incompatibilité avec la mise à jour que sécurité. Il suffira de relancer de le service avec le nouveau container, et cela sera fait avec la possibilité de rollback de manière bien plus souple que sur une installation traditionnelle en cas de problème.
Personnellement, j’accueille snap avec bienveillance, je pense que c'est vers ce paradigme que doivent se diriger les distributions désormais, fournir une base d'exécution et fournir les applications sous forme de containers embarquant ses propres dépendances et ses suites de tests.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 10. Dernière modification le 06 juin 2016 à 10:29.
Tout le problème est justement là.
Ce n’est pas de la responsabilité de l’utilisateur d’une image docker/snap/vagrant/whatever de reconstruire l’image. Et donc il est à 100% dépendant d’un fix upstream. Fix qui arrivera de toute façon trop tard, s’il arrive un jour.
Un bug OpenSSL, c’est quelques heures avant d’avoir un fix et au mieux 24h pour qu’il soit dispo dans la distribution de ton choix et donc toutes tes applications à l’abri, sans montée de version de l’application elle-même donc sans gros risque de régression.
Avec la containeurisation ambiante, il faudra attendre que toutes tes applications aient été reconstruites et redéployées, avec généralement une montée de version (je vois mal l’upstream se taper un rebuild de 4 ou 5 versions différentes juste pour y changer libssl.so) donc des régressions potentielles.
Si tu es safe en moins d’un mois, je te tire mon chapeau…
Ça rejoint un peu ce qui est dit dans ce post : https://blog.seboss666.info/2015/04/la-situation-deplorable-des-administrateurs-systeme/
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par flagos . Évalué à 2.
Si la dependance est clairement indiquée, la distro peut se charger de refaire le build. Mais bon, je sais pas du tout si les snap fonctionnent comme ca.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 2.
Si si tu as un fichier de définition du snap qui indique de manière claire et facile à parser, les dépendances du snap.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par flagos . Évalué à 2.
Tout a fait. Mais le probleme est evidemment le meme pour les .debs actuellement, il faut que les dépendances soient listes quelque part. Rien n’empêche un développeur d'inclure a la rache son fork d'openSSL.
Un exemple de fichier snap:
https://github.com/ubuntu/snappy-playpen/blob/master/youtube-dl/snapcraft.yaml
Ca a vraiment l'air pas mal et plutot simple comme système de packaging.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 3.
Oui c'est ce que je dis c'est simple. Surtout que c'est un format déjà connu (du yaml) :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 2.
Oula ça c'est toi qui l'affirme. Le bug peu impacter le design, la correction peu avoir des effets de bords mal maitrisé,… Une redbuild d'une image ne demande pas nécessairement de monté de version ou plutôt tu fais comme Debian tu a 2 numéros de version, un pour le logiciel et un pour le packaging :
La responsabilité vient de l'empaqueteur qui lors d'une mise à jour de sécurité d'une dépendance doit mettre à jour la dépendance, faire une vérification de non régression puis fournir le nouveau paquet. Si tu ne veux pas faire les tests de non régressions tu peux toujours ne pas les faire, comme de toute manière la création des images est automatisée, leur création ne prends pas des années.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 7. Dernière modification le 06 juin 2016 à 12:00.
Pour des correctifs de sécurité, non. Ou en tout cas ce n’est pas censé se produire, sauf bug de sécu très intrusif.
Upstream si.
Avec les .deb, la plupart des dépendances sont indiquées en
>=, donc la mise-à-jour de sécurité ne nécessite pas de mise-à-jour de l’application.Par exemple
firefox 46.0.1-1sous Debian déclarelibc6 (>= 2.17), utilisant actuellementlibc6 2.22-9. Un bug critique dans la libc fera que Debian déploieralibc6 2.22-10, ce qui ne nécessitera aucune mise-à-jour de Firefox, la version déclarées étant compatible avec la version installée. Firefox restera donc en version46.0.1-1.Avec snap ou docker, la version de ton image doit être décorrélée de la version de ton application.
En effet, si tu livres une image
firefox 46.0.1-1 + libc6 2.22-9en version1.0.0, une correction sur la libc nécessite de monter de version ton image, puisque tu livreras une imagefirefox 46.0.1-1 + libc6 2.22-10versionnée1.0.1. Et ce sont toutes tes images contenantlibc6 2.22-9qui vont devoir se prendre une montée de version.Côté upstream, j’imagine assez mal le mainteneur maintenir chaque image
firefox XXX + libc6 last-stable-compatible, il y a de fortes chances qu’il s’en tienne à uniquementfirefox last-stable + libc6 last-stable-compatible. Tu peux donc te retrouver avec un saut de version non contrôlé de Firefox (du genre tu es resté àfirefox 44en prod) pour pouvoir gérer un bug critique sur la libc…Un véritable enfer à gérer en perspective…
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par flagos . Évalué à 2.
Si le mainteneur ne veut pas rester sur cette version, il faut se poser la question de savoir si c'est une bonne idée d'y rester. Les bugs de sécurité ne sont pas que dans la libc et dans la lib ssl, ils sont également dans les applis.
Choisir de rester sur une version de firefox qui ne beneficie d'aucun support de la part du mainteneur ne me parait pas être une bonne pratique.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 4. Dernière modification le 06 juin 2016 à 12:35.
Oui et non. S’il y a des problèmes de sécurité non corrigé, il faut évidemment éviter d’utiliser cette application.
On imagine assez bien que si le mainteneur de Firefox considère avoir assez de temps disponibles pour suivre les mises-à-jour de Firefox (globalement 1 ou 2 par mois), il n’a décemment pas assez de temps pour suivre les variations de toutes les dépendances de Firefox :
coreutils debconf debconf-2.0 debianutils file-rc firefox fontconfig fontconfig-config fonts-dejavu-core fonts-freefont fonts-liberation gcc-6-base initscripts init-system-helpers insserv libasound2 libasound2-data libatk1.0-0 libatk1.0-data libaudit1 libaudit-common libavahi-client3 libavahi-common3 libavahi-common-data libbz2-1.0 libc6 libcairo2 libcomerr2 libcups2 libdatrie1 libdbus-1-3 libdbus-glib-1-2 libevent-2.0-5 libexpat1 libffi6 libfontconfig1 libfreetype6 libgcc1 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libglib2.0-0 libgmp10 libgnutls30 libgraphite2-3 libgssapi-krb5-2 libgtk2.0-0 libgtk2.0-common libharfbuzz0b libhogweed4 libhunspell-1.3-0 libice6 libicu55 libidn11 libjbig0 libjpeg62-turbo libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 liblzma5 libncurses5 libncursesw5 libnettle6 libp11-kit0 libpam0g libpam-modules libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpcre3 libpixman-1-0 libpng16-16 libprocps5 libselinux1 libsemanage1 libsemanage-common libsepol1 libsm6 libsqlite3-0 libstartup-notification0 libstdc++6 libsystemd0 libtasn1-6 libthai0 libthai-data libtiff5 libtinfo5 libustr-1.0-1 libuuid1 libx11-6 libx11-data libx11-xcb1 libxau6 libxcb1 libxcb-render0 libxcb-shm0 libxcb-util0 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxi6 libxinerama1 libxml2 libxrandr2 libxrender1 libxt6 lsb-base mount passwd perl-base procps sensible-utils shared-mime-info startpar sysvinit-core sysvinit-utils sysv-rc ttf-bitstream-vera ucf util-linux x11-common zlib1gSi une seule de ces dépendances bougent, en particulier pour raison de sécurité, le mainteneur doit reconstruire une image… Autant te dire que c’est juste impossible à faire…
Et du coup, tu peux vouloir rester sur un Firefox 44, toujours maintenu par le mainteneur de Firefox, mais plus maintenu par le mainteneur du container parce qu’il est dans l’impossibilité de continuer à suivre X versions de Firefox (il passe déjà sa vie à refaire des images pour la dernière version, il ne va pas en passer une 2nde pour une autre…).
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par flagos . Évalué à 1. Dernière modification le 06 juin 2016 à 12:49.
C'est tout a fait possible et il faut évidemment le faire de manière automatisée comme déjà indique au dessus. C'est la valeur ajoutee de snap.
Concrètement, je pense qu'avoir une version support long terme d'un paquet, va simplement consister a spécifier une branche du repo git du projet, en tous cas pour 90% des projets. Je pense pas que cela compromette les week-end du mainteneur. C'est d'ailleurs plutôt heureux, car pour bon nombre de petits projets, les mainteneurs sont bien souvent les développeurs eux mêmes.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 5. Dernière modification le 06 juin 2016 à 13:21.
Pas vraiment en pratique.
Parce que ça signifie (et c’est particulièrement visible chez Docker) des Go de téléchargement chaque jour pour chaque utilisateur final…
Et aussi d’avoir des systèmes de notification si une dépendance bouge (c’est un problème difficile à résoudre et qui nécessite… de recoder un équivalent à APT !).
Si je prend l’exemple de FreeCAD, c’est (sorry pour le spam…) :
coreutils debconf debconf-2.0 debianutils dpkg fontconfig fontconfig-config fonts-dejavu-core fonts-freefont fonts-freefont-ttf fonts-liberation fonts-lyx freecad gcc-6-base install-info iso-codes liba52-0.7.4 libaa1 libasound2 libasound2-data libass5 libasyncns0 libatk1.0-0 libatk1.0-data libaudio2 libaudit1 libaudit-common libavahi-client3 libavahi-common3 libavahi-common-data libavc1394-0 libavcodec57 libavcodec-extra57 libavutil55 libbasicusageenvironment1 libblas3 libblas-common libblas.so.3 libbluray1 libboost-atomic1.58.0 libboost-chrono1.58.0 libboost-date-time1.58.0 libboost-filesystem1.58.0 libboost-program-options1.58.0 libboost-python1.58.0 libboost-regex1.58.0 libboost-signals1.58.0 libboost-system1.58.0 libboost-thread1.58.0 libbsd0 libbz2-1.0 libc6 libcaca0 libcairo2 libcap2 libcap2-bin libcddb2 libcdio13 libchromaprint0 libcoin80v5 libcomerr2 libcroco3 libcrystalhd3 libcups2 libdatrie1 libdb5.3 libdbus-1-3 libdc1394-22 libdca0 libdirectfb-1.2-9 libdrm2 libdvbpsi10 libdvdnav4 libdvdread4 libebml4v5 libegl1-mesa libegl1-x11 libevdev2 libexpat1 libfaad2 libffi6 libflac8 libfontconfig1 libfreeimage3 libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-gdi1.1 libfreerdp-locale1.1 libfreerdp-primitives1.1 libfreerdp-utils1.1 libfreetype6 libfribidi0 libgbm1 libgcc1 libgcrypt20 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libgfortran3 libgl1 libgl1-mesa-glx libgl2ps1 libglapi-mesa libgles1 libgles1-mesa libgles2 libgles2-mesa libglib2.0-0 libglu1 libglu1-mesa libgme0 libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2 libgraphite2-3 libgroupsock8 libgsm1 libgssapi-krb5-2 libgstreamer1.0-0 libgstreamer-plugins-base1.0-0 libgtk2.0-0 libgtk2.0-common libgudev-1.0-0 libharfbuzz0b libhogweed4 libice6 libicu55 libidn11 libilmbase12 libinput10 libinput-bin libiso9660-8 libjasper1 libjbig0 libjpeg62-turbo libjs-jquery libjs-jquery-ui libjson-c3 libjs-sphinxdoc libjs-underscore libjxr0 libk5crypto3 libkate1 libkeyutils1 libkrb5-3 libkrb5support0 liblapack3 liblapack.so.3 liblcms2-2 liblircclient0 liblivemedia52 liblua5.2-0 liblzma5 libmad0 libmatroska6v5 libmng1 libmodplug1 libmp3lame0 libmpcdec6 libmpeg2-4 libmtdev1 libmtp9 libmtp-common libncurses5 libncursesw5 libnettle6 libnuma1 liboce-foundation10 liboce-modeling10 liboce-ocaf10 liboce-ocaf-lite10 liboce-visualization10 libogg0 libopencore-amrnb0 libopencore-amrwb0 libopenexr22 libopenjp2-7 libopenjpeg5 libopus0 liborc-0.4-0 libp11-kit0 libpam0g libpam-modules libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpcre16-3 libpcre3 libphonon4 libpixman-1-0 libpng16-16 libproxy1v5 libproxy-tools libpulse0 libpulse-mainloop-glib0 libpyside1.2 libpython2.7 libpython2.7-minimal libpython2.7-stdlib libpython-stdlib libqt4-dbus libqt4-declarative libqt4-designer libqt4-help libqt4-network libqt4-opengl libqt4-script libqt4-scripttools libqt4-sql libqt4-svg libqt4-test libqt4-xml libqt4-xmlpatterns libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5widgets5 libqt5x11extras5 libqtassistantclient4 libqtcore4 libqtdbus4 libqtgui4 libqtwebkit4 libquadmath0 libraw1394-11 libraw15 libreadline6 libresid-builder0c2a librsvg2-2 librtmp1 libsamplerate0 libschroedinger-1.0-0 libsdl1.2debian libsdl-image1.2 libselinux1 libsemanage1 libsemanage-common libsepol1 libshiboken1.2v5 libshine3 libshout3 libsidplay2 libslang2 libsm6 libsnappy1v5 libsndfile1 libsndio6.1 libsoqt4-20 libsoxr0 libspeex1 libspeexdsp1 libspnav0 libsqlite3-0 libssh2-1 libssh-gcrypt-4 libssl1.0.2 libstdc++6 libswresample2 libsystemd0 libtag1v5 libtag1v5-vanilla libtasn1-6 libtcl8.6 libthai0 libthai-data libtheora0 libtiff5 libtinfo5 libtk8.6 libtwolame0 libudev1 libupnp6 libusageenvironment3 libusb-1.0-0 libustr-1.0-1 libuuid1 libva1 libva-drm1 libva-x11-1 libvcdinfo0 libvlc5 libvlccore8 libvncclient1 libvo-amrwbenc0 libvorbis0a libvorbisenc2 libvpx3 libwacom2 libwacom-common libwavpack1 libwayland-client0 libwayland-server0 libwebp5 libwebpmux1 libwinpr-crt0.1 libwinpr-crypto0.1 libwinpr-dsparse0.1 libwinpr-environment0.1 libwinpr-file0.1 libwinpr-handle0.1 libwinpr-heap0.1 libwinpr-input0.1 libwinpr-interlocked0.1 libwinpr-library0.1 libwinpr-path0.1 libwinpr-pool0.1 libwinpr-registry0.1 libwinpr-rpc0.1 libwinpr-sspi0.1 libwinpr-synch0.1 libwinpr-sysinfo0.1 libwinpr-thread0.1 libwinpr-utils0.1 libwrap0 libx11-6 libx11-data libx11-xcb1 libx264-148 libx265-79 libxau6 libxcb1 libxcb-composite0 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-present0 libxcb-randr0 libxcb-render0 libxcb-render-util0 libxcb-shape0 libxcb-shm0 libxcb-sync1 libxcb-util0 libxcb-xfixes0 libxcb-xkb1 libxcb-xv0 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxerces-c3.1 libxext6 libxfixes3 libxft2 libxi6 libxinerama1 libxkbcommon0 libxkbcommon-x11-0 libxkbfile1 libxml2 libxmu6 libxpm4 libxrandr2 libxrender1 libxshmfence1 libxslt1.1 libxss1 libxt6 libxtst6 libxvidcore4 libxxf86vm1 libzipios++0v5 libzvbi0 libzvbi-common lsb-base mime-support passwd phonon phonon-backend phonon-backend-vlc pyside-tools python python2.7 python2.7:any python2.7-minimal python:any python-collada python-cycler python-dateutil python-lxml python-matplotlib python-matplotlib-data python-numpy python-numpy-abi9 python-pivy python-ply python-pyparsing python-pyside python-pyside.phonon python-pyside.qtcore python-pyside.qtdeclarative python-pyside.qtgui python-pyside.qthelp python-pyside.qtnetwork python-pyside.qtopengl python-pyside.qtscript python-pyside.qtsql python-pyside.qtsvg python-pyside.qttest python-pyside.qtuitools python-pyside.qtwebkit python-pyside.qtxml python-qt4 python-qt4-gl python-six python-tz qdbus qtbase-abi-5-5-1 qtchooser qtcore4-l10n readline-common sensible-utils shared-mime-info sip-api-11.3 ttf-bitstream-vera tzdata ucf vlc vlc-data vlc-nox x11-common xkb-data zlib1gRien que la détection d’un changement de version dans au moins une de ces dépendances pour éviter de reconstruire une image alors qu’il n’y a pas de changement, ça va être un enfer. Le yaml ne gère absolument pas ce cas actuellement et rebuildera à tous les coups sans possibilité de savoir s’il faut incrémenter la version ou non.
Autant te dire que c’est chaque jour que ton snap doit être reconstruit et poussé chez tes utilisateurs… Ils vont légèrement faire la gueule. Surtout que FreeCAD lui n’a absolument pas changé de version.
En plus si tu veux maintenir un snap pour plusieurs versions de FreeCAD, tu te tires juste une énorme balle dans le pied en terme de gestion…
Je ne te suis pas là… Pour l’utilisateur final, ça sera effectivement suivre
my-application.latestoumy-application.esr.Mais pour le mainteneur de l’image, c’est suivre tous les
lib-xxx.{latest,esr}et reconstruire les images en conséquence.[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Malizor . Évalué à 2.
Les mises à jour de Snap se font sous forme de diff, donc il n'y a pas des Go de téléchargement si seul un pauvre .so a changé.
Et si le snap est fait assez proprement (s'il est construit à partir des bibliothèques de la distro de base), la reconstruction du snap en cas de màj d'une bibliothèque est automatisée (ou va l'être, j'admets ne pas savoir si c'est déjà le cas).
Alors oui, si le packageur utilise un fork de la libssl, c'est à lui de gérer derrière. Mais ce problème n'a rien de nouveau.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par flagos . Évalué à 1.
Snap supporte les upgrade delta.
Heu… si l'equivalent des ppa vont tres certainement gérer ca proprement, comme les ppa le font deja pour les .deb en fait. Tu as une source pour affirmer que tout va être rebuilde tous les jours ou tu affirmes juste sans aucune idee de comment ca va marcher en pratique ?
Reconstruire les images, c'est le boulot des ppa d'ubuntu. Le boulot du mainteneur, c'est de vérifier que toutes les dépendances sont bien decrites dans le format du paquet, c'est tout.
D'ailleurs, l'enorme avantage, c'est que ca va eviter les rapports de bugs inutiles de personnes qui ont telle lib en Vx et une autre en Vy, qui ne veulent pas les mettre a jour (on a pas forcement compris pourquoi d'ailleurs). Pour les mainteneurs et pour les developpeurs, il n'y aura qu'une seule version a prendre en compte pour les rapports de bugs, ce qui va sincèrement simplifier les choses.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 5.
Vu la tonne de dépendances remontée par FreeCAD, c’est au doigt mouillé mais je ne dois pas être loin du compte. La probabilité d’avoir une maj de version sur une des dépendances chaque jour est à mon avis proche de 1.
J’ai vérifié sur mon système, les dates où apt m’a fait une mise-à-jour d’une des dépendances :
apt-rdepends freecad -f Depends | grep -v "^ " | xargs -I {} zgrep {} /var/log/dpkg* | awk -F: '{print $2}' | awk '{print $1}' | sort -uSur 365 jours, 2015-06-02 au 2016-06-06 : 226 mises-à-jour.
Et encore, ça ne concerne que les dépendances actuellement installées sur mon système, il m’en manque 52 sur les 432.
Mais je te concède sans soucis le jour sur 3 qui ne connaît pas de mise-à-jour…
Dans tous les cas, ça confirme bien le problème : tu vas devoir livrer chaque jour un paquet Snap FreeCAD sous peine de rendre obsolètes tes utilisateurs…
Et avec un enfer de dépendances différentes chaque jour.
Mon script y va peut-être avec de gros doigts, mais je compte 86 jours avec plus de 10 dépendances modifiés, 7 avec plus de 100 dépendances et même 2 journées avec plus de 400. Qui s’est mis à jour et pourquoi ?
Les PPA n’ont justement pas à gérer ça. Si libssl est mis à jour, FreeCAD n’a pas à être rebuildé. On ne rebuild FreeCAD que si FreeCAD change de version upstream (et on en profite au passage pour upgrader un coup les dépendances si nécessaires).
Alors que le snap va devoir être rebuildé sur chaque changement de version de FreeCAD, mais aussi de n’importe laquelle de ses dépendances, y compris récursives.
C’est effectivement le taff actuel des PPA. Ce n’est pas du tout le même genre ni volume de travail qui attend un mainteneur Snap.
Si tu es mainteneur PPA, tu n’as pas à te soucier de la maintenance de tes dépendances, si tu es mainteneur snap si.
Ça ne changera strictement rien, voire ça sera encore pire.
Tu vas te retrouver avec des bugs sur la version 1.0.0 du snap qui contient un jeu de dépendances potentiellement totalement différente de la version 1.0.1.
Reproductibilité proche du néant, bissect impossible, etc.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 3.
Aller, je m’autocorrige un peu, mon script était un peu violent. La version correcte.
apt-rdepends freecad -f Depends | grep -v "^ " | sort -u | xargs -I {} zgrep "status installed {}:amd64" /var/log/dpkg* | awk -F: '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -rnSur 1 an et avec 52 dépendances non installées sur 432, 178 mise-à-jours, soit 1 jour sur 2.
La plus grosse, le 09/11/2015 (release Debian 8.2.0 je dirais), 254 dépendances modifiées, suivi du 03/02/2016 (Debian 8.4) avec 115 dépendances.
35 jours (soit 1 semaine sur 2 environ) avec plus de 10 mises-à-jour.
Ça ne change pas grand chose au fait que le mainteneur Snap de FreeCAD soit ne va plus avoir de vie sociale pour suivre les correctifs et décider de livrer une nouvelle version ou non, soit va livrer tous les 2 jours un Snap rebuildé « au cas où » à l’arrache à partir de l’état courant des dépôts Debian sans maîtrise de ce qu’il livre réellement.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 2.
Qu'est-ce qui est à l'arrache ? De quelle maîtrise tu parles ?
Pour la reproductibilité des bugs, les conteneurs sont la meilleure solution. Ils permettent au développeur de connaître l'environnement exact dans le quel son logiciel s'exécute et cela lui permet de manipuler facilement des versions différentes. C'est vraiment le grale pour le test :
Je ne vois pas de quel problème tu parles. Tu prends ta version 1.0.1 tu downgrade les dépendances et tu vois ce que ça donne. C'est trivial.
Pour savoir si tu as besoin de reconstruire tu as montré la commande. C'est automatisable encore une fois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 3.
La containerisation est intéressante pour le dev, ça c’est indéniable.
Ça évite de péter son système principal et ça permet de conserver des environnements stables même si on développe sur plusieurs environnements en parallèle (du genre des projets qt4 et qt5).
Ou d’installer aux forceps de vieilles ou trop récentes versions de dépendances.
Ce n’est actuellement pas du tout le cas et c’est un problème compliqué à résoudre.
Tu lances ta commande, tu obtiens un binaire. Est-ce le même qu’hier ? Tu es incapable de le dire. As-tu buildé une v1.0.0 ou une de tes dépendances a-t-elle bougée et tu as alors compilé une v1.0.1 malgré que tu aies indiqué v1.0.0 dans ton fichier de build ?
La seule manière viable de procéder est de générer la liste des dépendances dynamiquement chaque jour, de vérifier si elle a bougé depuis hier (hint : c’est statistiquement le cas) et si c’est le cas, de lancer un nouveau build du snap en incrémentant sa révision, snap qui ne partage potentiellement plus grand chose comme dépendances par rapport à la version d’il y a 1 semaine.
Et alors tu t’éloignes bien loin de la joie annoncée en début de journal de la stabilité et maîtrise de ton système…
Pour l’exemple de FreeCAD, ça donne par exemple plus de 180 versions sur 1 an, dont les dépendances divergent rapidement passées 1 semaine d’écart.
Juste ça en prod, tu oublies. Vraiment.
Les autres manières de procéder impliquent le gel sur un terme plus ou moins long des dépendances et donc d’exposer ses utilisateurs à des failles ou des bugs.
On imagine assez bien un mainteneur n’upgradant ses dépendances qu’avec une nouvelle release upstream de l’application principale, laissant un trou béant entre deux. Et à l’inverse assez mal le mainteneur de FreeCAD se dire « Oh , un heartbleed sauvage apparaît. FreeCAD snap, en avant ! ».
Et c’est totalement compréhensible, il est responsable de la maintenance de FreeCAD. Ni de OpenSSL, ni de la libc, ni de DBus !!!
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par flagos . Évalué à 2.
Au contraire, tu maitrises cette partie. Tant que tu ne fais de pull, ton environnement local sera fige. C'est le contraire d'apt, ou un simple apt upgrade fait que justement, un meme binaire peut avoir des comportements differents suivant les jours. Le cas est rare certes, mais la reproductibilité est clairement une force des containers.
C'est ce que tu as deja en prod. Vraiment.
L'avantage, c'est qu'au moins, tu délivres des configs cohérentes a tes utilisateurs, des configs que tu peux tester et reproduire.
Encore une fois, les ppa pourront detecter ce genre de dependance et relancer une build. Le mainteneur n'aura rien a faire.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 5.
On s’en tape de la reproductibilité si c’est pour monter une armée de botnet en 1 mois. La sécu avant tout SVP…
Non, je n’ai pas ça en prod. Je n’ai pas 180 versions de FreeCAD. Si FreeCAD ne bouge pas, il n’est pas mis à jour.
Et de grosse terrachiés de bugs et failles non corrigés…
Et donc ? Les Snap deviennent un apt dist-upgrade remote ?
Intérêt par rapport à APT si mon FreeCAD est mis-à-jour 1 jour sur 2 avec des dépendances non maîtrisées ? Ça casse complètement l’intérêt que vous vendez de Snap là…
Snap n’est intéressant que si tes utilisateurs passent leur vie à poil sur leurs machines… Comme Docker, Go et plus généralement tout ce qui cherche à figer plus ou moins définitivement l’environnement, ce qui est un énorme problème de sécurité et une véritable bombe à retardement dégoupillée…
On va juste bien rigoler au prochain Heartbleed ou random-42 like tient…
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 1.
Un checksum et c'est vérifié.
Tu n'a pas compris que quand on fait du packaging, on versionne ne le packaging en plus du logiciel. Si tu fais une construction alors tu passe de 1.0.0-n à 1.0.0-$((n+1)).
Oui et c'est facilement automatisable, voir tu peux être notifié des mises à jour d'une de tes dépendances.
Par contre il y a un biais dans ce que tu annonce :)
Si je repars de la sortie de ton
zargset que je fais :On remarque qu'il y a des paquets qui sont mis à jour un grand nombre de fois. Donc non, en une semaine tu peux très bien avoir plusieurs mise à jour d'un même paquet (j'ai très peu de dépendance de freecad). Après ça ne change pas grand chose :)
Et c'est ce que tu as eu en vrai déjà maintenant. Tu peut très bien avoir eu une dépendance qui à modifié le comportement de freecad (plantage, ralentissement, accélération, etc) et c'est une version différente sauf que c'est invisible et complexe à reproduire.
En prod tu es sensé valider les mises à jour de tes dépendances donc tu es obligé de prendre en compte chaque mise à jour même de sécurité pour revalider ton installation. Il n'y a que les sysadmin qui se permettent de faire des mises à jour à l'arrache des dépendances en espérant que ça va passer parce que leur système doit être toujours à jour quitte à ce que les services lancé dessus soient down…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 5.
Si tu as de la compilation reproductible, oui.
Sinon, tu peux avoir 2 checksums différents mais le même binaire quand même (même versions de libs, même version d’application, mais un truc qui a changé entre les 2, par exemple la date de build dans une entête d’archive…).
C’est un problème à part entière et même Debian ne parvient pas encore au 100% reproductible.
C’est exactement mon propos.
Tu vas te retrouver chaque jour avec une v1.0.n+1 dont tu n’as absolument aucune idée si c’est techniquement une vraie v1.0.n+1 (une lib a bougé depuis) ou juste une v1.0.0 rebuildé (aucune modif de lib).
Et donc si tu dois la pousser à tes utilisateurs ou non.
Je ne vois pas le rapport avec ce que j’annonce.
Oui bien sûr que OpenSSL va se prendre une maj de sécu par jour voire plus.
Ce n’est pas une raison pour que le paquet de Firefox ou de FreeCAD le soit justement !!! Et c’est même un comportement que tu ne souhaites absoluement pas avoir…
Actuellement, si OpenSSL publie 5 maj de sécu en 1 semaine, je maj 5 fois OpenSSL. Et c’est tout !!!
Avec Snap, comme ma dépendance foireuse est dans quasi toutes mes applications, ça va soit me laisser à poil jusqu’à ce que le mainteneur du snap décide d’intégrer la version d’OpenSSL corrigée, soit ça va me faire aussi 5 maj de mon appli snap.
En pratique, là où aujourd’hui un fix de sécu se résume à upgrader une seule lib et à oublier cette faille définitivement, snap va être une bouse infecte qui va nécessiter de se poser la question de quelles applications intègrent quelles versions de OpenSSL, de mettre à jour l’ensemble de tes applications impactées, et à devoir surveiller ton système avec une très longue traîne de faille le temps que tous tes mainteneurs snap aient fait leur travail d’intégration.
Sur des fixs de sécurité, c’est quasi impossible, et en tout cas ça ne vaut clairement pas la chandelle du risque de sécurité introduit par snap.
Tu échanges un potentiel risque de régression jamais atteint en pratique ou qu’à la marge, contre un risque avéré de dépréciation progressive des bibliothèques installées sur ta machine et donc soumises à faille de sécurité.
Je met à jour chaque jour à gros coup de apt dist-upgrade, je n’ai connu qu’un seul down de prod (à l’arrivée de systemd).
apt est très robuste de ce côté et Debian suffisamment soigneux avec ses paquets pour éviter le dawa.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 3.
Tu ne veux pas comprendre ce sera donc mon dernier message :
Se référer au point 1
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 9.
Vous en avez pas marre de crier à l'enfer pour tout et n'importe quoi ?!
Que quelque chose ne plaît pas je le comprends et il est possible d'en discuter, mais pousser des cris d’orfraie à chaque fois que quelque chose ne plaît pas c'est fatiguant.
C'est à celui qui te fourni l'application de gérer ton application.
Si ta distribution te fournie le snap, elle pourra aussi facilement que d'habitude te fournir la correction sans travail supplémentaire.
Si tu quelqu'un d'autre, ça va dépendre de la politique de cet autre. À toi de choisir correctement celui qui te fournira ton logiciel, comme c'est déjà sensé être le cas.
Que de changements !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Zenitram (site web personnel) . Évalué à -3.
Euh… Je n'ai même plus temps de voir les commentaires et imaginer une réaction sur ce sujet, voila que tu me piques mes répliques.
tout se perd… Mais prépare-toi, les retours peuvent être violent (surtout vu que tu en as profité pour y mettre un peu de systemd).
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Aeris (site web personnel) . Évalué à 5.
J’avais raté ce gros détail au passage. C’est justement là-dessus que snap et docker rendent les choses infectes.
Actuellement sous Debian, si la libc6 est impactée par une maj de sécurité, c’est au mainteneur de libc6 de faire le correctif et de déployer sa nouvelle version. Il n’y a donc qu’un seul travail à faire pour patcher l’ensemble de ta distribution.
En plus, étant un patch de sécurité, les risques de régression applicatives restent rares, les mainteneurs des applications n’auront à agir qu’en cas de réels problèmes de compatibilités.
Sous snap/docker, cette étape ne suffit plus et il faut que le mainteneur de chaque application corrige ses dépendances, rebuild ses images et les redéploie. La faille de sécurité va avoir une longue traîne avant correction, les images peu/pas maintenue allant rester à poil longtemps.
.deb = 1 mainteneur, toutes les applications fixées.
.snap/.docker = n+1 mainteneurs (1 lib + n container) = n applications fixées
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 2.
Ce que je répète depuis l'annonce il y a plusieurs semaines, le n est entièrement automatisable. Tout comme le 1 est en fait un m qui est lui aussi automatisé (tu as au moins 3 architectures par distribution). Il faut comprendre que lors d'une mise à jour simple le passage de code source au paquet est quasiment automatique et que le reste est automatisable très simplement. La reconstruction totale d'un arbre de paquet n'a rien de monstrueux et c'est quelque chose de très courant déjà aujourd'hui même chez les BSD (=> toutes les distributions sources passent leur temps à faire ce genre de choses).
Donc non ça ne demande que le travail de mise en place initial en plus, le reste est très faible.
Et encore une fois, snap n'est pas fait pour remplacer .deb, il le remplace sur quelques applications précises. Tu n'es pas sensé avoir 20% de tes paquets en snap.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par barmic . Évalué à 1.
Avec Docker oui, avec snap je ne suis pas sûr vu qu'il n'y a pas de gestion de version locale des snap à ce que je sache (mais je peux me tromper).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par Okki (site web personnel, Mastodon) . Évalué à 9.
Je n'ai touché ni à l'un, ni à l'autre, mais vu de loin, j'ai l'impression que c'est justement l'une des grosses différences avec Flatpak. Là où Snap semble absolument tout inclure, Flatpak fait appel à des runtimes. On a par exemple les runtimes Freedesktop, GNOME, KDE… Et il peut y avoir différentes versions d'un même runtime (GNOME 3.18, 3.20)
À l'arrivée, s'il y a des failles dans X11, Wayland, Mesa, DBus, SDL… c'est le runtime Freedesktop qui sera mis à jour, et non pas le Flatpak de l'application.
Alors, bien évidemment, le conteneur pourra également contenir certaines bibliothèques bien spécifiques, mais ça représente tout de même beaucoup moins de risques vis-à-vis d'éventuelles mises à jour incessantes du conteneur. Autre avantage, ça devrait également occuper bien moins de place. À première vue, 200 Mo pour le Snap, contre 14 Mo pour le package Ubuntu. Reste à créer un Flatpak pour pouvoir comparer XD
Maintenant, je ne sais pas vous, mais je trouve ce fichier .yaml super vilain (rien que la palanquée d'export, ça me refroidit). Pour le coup, un survol de la doc de Flatpak me donne l'impression de quelque chose de bien plus propre et mieux pensé.
Sinon, pour rester dans la sécurité, côté Snap ils parlent bien de sandboxing, mais je n'ai rien trouvé dans leur doc vis-à-vis des autorisations. Côté Flatpak, par défaut il n'y a aucun accès aux fichiers, réseau, périphériques, process en dehors de la sandbox, services (X, D-Bus, PulseAudio…). Et pour pouvoir y accéder, il faut le spécifier dans la conf du conteneur. Ensuite, de ce que j'ai compris, il y aura des demandes utilisateur au niveau de l'environnement de bureau. « L'application Tartampion souhaite pouvoir accéder à la webcam. Souhaitez-vous l'autoriser ? ».
Le site Flatpak étant nettement plus complet et mieux foutu que les quelques pages que j'ai pu trouver sur developer.ubuntu.com, ça me donne tout de même l'impression que l'ensemble du projet Flatpak a réellement été mieux pensé. Maintenant, j'ai sans doute raté quelque chose (ça serait tout de même étonnant que ça n'ait pas été pris en compte), et serais donc curieux de connaître l'avis des primo adoptants.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par freem . Évalué à 2.
À priori, ça me semble le seul intérêt (qui n'est pas négligeable) de la technologie comparé à la création de paquets contenant un binaire lié statiquement.
Je me trompe?
# Bof !
Posté par LaBienPensanceMaTuer . Évalué à 8.
Il n'y a que moi que ça choque ?
Transposons:
Régis, mécanicien poid lourd, au micro de Geek Inter "Disons que pour être clair, un ingénieur en informatique veut pouvoir installer un joint de culasse en cliquant sur une icône ou via apt-get. Dès que l'on suggère l'emploi d'une clef de 12, on a un phénomène de révulsion".
Non sérieusement… c'est bien pour ça qu'on a des métiers: ingé dev, ingé système, architecte (dev ou système), ingénieur sécurité, technicien de support, etc…
C'est bien pour ça qu'il y a une vingtaine d'années, des mecs se sont dit "hey, et si on faisait des distributions: on aurait des systèmes cohérents avec des applications installables facilement"… ET ILS L'ONT FAIT !!!!
Il existe des tonnes de distributions, plus ou moins stables, plus ou moins à jour qui t'assurent justement la "non disparité".
Je pense qu'encore une fois, ton article cherche à répondre à un mauvais besoin: comment violer la philosophie d'un des atomes de l'éco-système GNU/Linux: les distributions.
C'est pas assez à jour ? Passe à une autre distrib, recompile et repackage, mais non… fournir des containers n'est pas, de mon point de vue, une solution pérenne.
Ton exemple est peut ête mal choisi, mais définitivement, je trouve tout ça pas terrible :p
[^] # Re: Bof !
Posté par vejmarie (site web personnel) . Évalué à 5.
Le graphe de dependance de FreCAD est assez complexe, et la maintenance a un stade "industriel" du code requiert un minimum de point commun entre chaque utilisateur notamment avec l'ajout de certaines fonctionnalites. Les PPA on la force de pouvoir mettre a jour des paquets anciens, mais ne permettent pas de faciliter l'installation. L'approche avec un coeur "solide" maintenu pas la distro et les dependances peripheriques me semble bonne pour ces raisons. La maintenance d'OCCT et de VTK est anecdotique et si on veut utiliser FreeCAD avec les dernieres fonctions il faut de toutes facons refaire le package.
Je ne pense pas que snap "tuera" les distributions au contraire, par contre je pense que cette techno permettra aux mainteners de distros de se concentrer sur l'essentiel plutot que d'avoir a gerer des tonnes de paquets dans tous les sens.
[^] # Re: Bof !
Posté par Zenitram (site web personnel) . Évalué à -1.
Ben non, ils ne l'ont pas fait (c'est jamais assez à jour)
Ou prend un snap, c'est pareil que ce que tu dis, mais la complexité en moins (et même un peu plus de sécurité).
Ce que tu conseilles pour pallier à ce que tu trouves trop génial (c'est bizarre d'avoir un palliatif si c'est génial, passons) est pire en terme de temps et de sécurité, super…
# Flatpak
Posté par ff9097 . Évalué à 3.
Et encore une fois canonical fait à sa sauce…
[^] # Re: Flatpak
Posté par gnumdk (site web personnel) . Évalué à 1.
Oui, enfin pour le coup Canonical était là avant hein…
[^] # Re: Flatpak
Posté par Okki (site web personnel, Mastodon) . Évalué à 7.
On pourrait formuler ça autrement. Canonical a encore développé un truc tout seul dans son coin rien que pour Ubuntu, quand d'autres ont préféré créer un projet Freedesktop distribution agnostique. C'est la même chose pour Mir vis-à-vis de Wayland, et tout comme ils ont finit par abandonner upstart au profit de systemd ou le Software Center au profit de GNOME Software, je te paris qu'un jour il en sera de même de Mir et Snap.
[^] # Re: Flatpak
Posté par barmic . Évalué à 3.
Upstart fonctionnait sur RedHat.
Personnellement je ne vois pas d'un mauvais œil le fait d'avoir d'autres expérimentations que ce qui sort de freedesktop
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Flatpak
Posté par Renault (site web personnel) . Évalué à 7.
Le risque est que cela divise la communauté et les aspects techniques pour des questions de guerre de clochers.
Les autres distributions et environnements de bureau ont travaillé sur quelque chose dont il semble que Canonical n'a pas exprimé beaucoup d'idées ou de requêtes. C'est dommage de faire son truc dans son coin alors que depuis 2 ans une solution technique était en discussion et ouverte à tous. Si au moins un effort notable pour travailler sur ce projet public avait été tenté, ça aurait eu du sens.
D'autant qu'il y a enfin une vraie synergie à faire de Flatpak un succès.
[^] # Re: Flatpak
Posté par barmic . Évalué à 5.
Ça a toujours était le cas, ça n'a pas tué le monde linux. Linux (et son écosystème) s'est toujours construit comme un bazar plutôt qu'une cathédrale. Je pense qu'il est saint de garder un fonctionnement qui marche.
Rien empêche de commencer par proposer des choses en plus tard élire la « meilleure » solution et/ou faire fusionner les solutions. Industrialiser comme un dogme : tout doit être un standard, une RFC, une spécification,… Ça freine l'expérimentation et ça supprime tout le coté fun tout ça pour le plaisir des distributions commerciales comme RedHat ou Suse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Flatpak
Posté par ff9097 . Évalué à 0.
Ça serait très bien si ça se passe comme ça mais on peut en douter. Quand tu vois qu'il y a toujours les deux formats deb/rpm alors que c'est strictement la même chose.
On peut vouloir améliorer les choses plutôt que de ne rien faire
[^] # Re: Flatpak
Posté par barmic . Évalué à 2.
Je ne suis pas certains qu'il s'agisse d'une amélioration. Il y a pas mal de choses de freedesktop qui ne sont pas plus adopté que ça.
La LSB est assez moyennement respectée de base et c'est probablement parce qu'elle n'a jamais vraiment fais de consensus.
Il y a des choses qui sont faites en sous-mains pour homogénéiser les choses (https://linuxfr.org/news/cudf-ou-la-r%C3%A9solution-de-d%C3%A9pendances-universelle).
Mais tu remarquera que la création du standard non content d'avoir permis de fusionner les solutions n'a pas empêché d'en créer de nouvelle (pkgng, pacman, nix, guix,… et maintenant docker, flatpak ou snap, voir gem, pip, cpan, npm,… il y en a aussi qui sont mort comme click et d'autres).
Il y a un moment ou bon, euh… Comment dire ? On arrive pas à faire de standard, on peut arrêter d'en créer par espoir. Il y a des endroits où pour pleins de raisons, ça ne marche pas. Ce serait super mais non. Il faut faire son deuil.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Flatpak
Posté par claudex . Évalué à 3.
Pour le coup, je ne vois pas ce que ça changerait d'avoir le même. Il faudrait de toute façon empaqueter différemment en fonction des distributions cibles (et si ce n'est pas le cas, c'est trivial d'avoir un process de build qui fait les deux, au pire avec alien).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Flatpak
Posté par freem . Évalué à 2.
Bien d'accord avec toi, mais je tenais à préciser que ce problème de disparité me semble surtout lié aux binaires exécutables.
Pour pas mal de paquets, ça ne devrait pas être le cas, puisque de nos jours, il y a énormément de logiciels écrits en langages interprétés (surtout python).
[^] # Re: Flatpak
Posté par claudex . Évalué à 3.
Il y a quand même la gestion des dépendances à gérer. Par exemple, pour python, le paquet pour avoir pyyaml s'appelle python3-yaml chez Debian et python3-PyYAML chez Fedora. Mais sinon, tous ces langages compilés finissent très souvent par appelé du code compilé (pour l'interface graphique (PyQt), pour le parsage xml (python-lxml)…) et on en revient au même problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Flatpak
Posté par freem . Évalué à 2.
Effectivement, si les paquets changent de nom, c'est pas simple.
Je pensais que les libs natives étaient encapsulées. Si ça avait été le cas, seule la lib python elle-même aurait eu une dépendance sur du natif, pas les applications (ou du moins, pas directement).
[^] # Re: Flatpak
Posté par claudex . Évalué à 3.
Ayant fait un peu de packaging pour du multidistrib, c'est ce qui me prenait le plus de temps (bon, c'était des trucs très simple à packager).
Sauf que la lib python, elle ne fournit pas l'interface à Qt, c'est un truc à part. Si elle est déjà dans la distrib et qu'elle est est dans la bonne version, effectivement, ça ne pose pas de problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Flatpak
Posté par Renault (site web personnel) . Évalué à 3.
Ce n'est pas ça le pire.
Les distributions embarquent des versions différentes de chaque application et donc dépendance. Pour que le tout fonctionne de manière cohérente, il faut souvent gérer un certain nombres de correctifs sur les paquets.
Sans oublier que le découpage des paquets n'est pas identique d'une distribution à l'autre, tu peux par exemple découper KDE, Qt ou la glibc de bien des manières différentes pour aboutir au même résultat. Mais ces différences, qui existent en réalité, vont également casser ta résolution de dépendance.
Sans oublier parfois l'incompatibilité manifeste entre deux paquets de distributions différentes, si un paquet a besoin de Qt 4 et l'autre de Qt 5, tu peux avoir des soucis si la distribution cible n'a pas plusieurs exemplaires de la bibliothèque.
[^] # Re: Flatpak
Posté par freem . Évalué à 3. Dernière modification le 06 juin 2016 à 22:21.
Bien entendu, si la bonne version n'est pas disponible dans le bon système, ça passe pas.
C'est d'ailleurs une des faiblesses de Debian quand on veut des logiciels pas trop anciens (p.e., j'aimerai bien tester openmw, mais ils ont une dépendance sur une version de openscenemap qui n'est pas encore dans debian stable, backports inclus :'( ).
C'est juste que je supposais que si 2 distrib ont la même version mineure (c'est à dire avec API compatible, et puisque c'est interprété, pas de problème d'ABI) de python-qt4 (ou peu importe le nom) les paquets qui ne dépendraient que de ça n'auraient pas besoin d'être repackagé si le gestionnaire de paquet était compatible.
Manifestement, je me trompais, puisqu'ils semblerait que les mainteneurs changent les noms.
Probablement pour des raisons plus ou moins bonnes en fonction de la situation d'ailleurs: j'avais oublié qu'il puisse même y avoir des conflits de noms, par exemple dans Debian le paquet "apcalc" pour lequel "Le nom original de ce paquet est « calc » mais à dû être changé en « apcalc » pour debian car il y a déjà un autre paquet appelé « calc » dans Debian. Les binaires et les pages de manuel installés par ce paquet sont encore nommés « calc ».".
À noter qu'il n'y a plus de paquet "calc" depuis longtemps, et que celui qui à fait ce paquet à été sympa: il a mis dans la description le nom du binaire… combien de fois j'ai du décortiquer le paquet pour savoir ou les trucs étaient installés…
[^] # Re: Flatpak
Posté par ff9097 . Évalué à 0.
Pourquoi faire simple quand on peut faire compliqué. Ça ferait un package de moins à gerer pour le développeur qui veut proposer son logiciel sur Linux
[^] # Re: Flatpak
Posté par claudex . Évalué à 4.
C'est justement ce que j'explique dans la suite du commentaire, le plus gros du boulot, ce n'est pas le système de packaging qui reste assez semblable entre rpm et deb (une liste des dépendances, des règles pour le build, les trucs trop distro spécifique, on peut s'en passer pour fournir un paquet hors distro). Ce qui est compliqué, c'est de faire un paquet qui s'adapte à la distribution (bonne liste des dépendances, fichiers aux bons endroits) sinon, il suffirait d'utiliser alien tout le temps et il n'y aurait pas de problème. Ça voudrait aussi dire que les paquets fedora fonctionneraient sur opensuse, c'est loin d'être le cas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Flatpak
Posté par freem . Évalué à 2.
Ironiquement, deb semble antérieur à rpm, et c'est rpm qui a été adopté par le «standard». Si c'est la même chose, pourquoi? Si FDO était là pour favoriser l'amélioration de l'existant, pourquoi?
Il est plus facile d'améliorer quand il y a des concurrence à priori. Il suffit de voir les progrès que GCC fait depuis que clang est populaire.
[^] # Re: Flatpak
Posté par bolikahult . Évalué à 1.
À mon avis flatpack va s'imposer sur snap, y compris sur ubuntu, par contre pour mir je pense qu'il vont vraiment le garder, vu que leur convergence repose dessus… À moins que wayland propose aussi une base pour la convergence ?
[^] # Re: Flatpak
Posté par ff9097 . Évalué à 0.
Flatpak (aka xdg-app) est développé depuis pas mal de temps
[^] # Re: Flatpak
Posté par freem . Évalué à 2.
Ce qui n'empêche pas qu'il soit possible que ce soit le dernier arrivé. Je ne sais pas moi, personne ne donne de dates, et j'ai rien trouvé sur wikipedia.
[^] # Re: Flatpak
Posté par dj_ (site web personnel) . Évalué à 3.
D'après le github originel 14 décembre 2014
Pour Snap je vois ça une page avec 28 novembre 2014
On va dire égalité non?
[^] # Re: Flatpak
Posté par trancheX . Évalué à 0.
En dehors du fait de savoir qui a commencé le premier : on va pouvoir comparer 2 solutions, au lieu de se plaindre on va pouvoir regarder d'un point de vu strictement technique quelle approche semble la mieux.
Par exemple en regardant vite fait voilà ce qui ressort :
- Flatpak ne semble pas prévu pour être utilisé sur serveur / snap est annoncé comme idéal pour serveur et IOT
- Flatpak a prévu (pas encore implémenté) des "portals" permettant à l'utilisateur de refuser ou accorder des droit à une application / Snap ne semble pas avoir ceci de prévu
- Flatpack a prévu de s'appuyer sur SElinux+seccomp / Snap s'appuis sur appArmor+seccomp
- … etc, ça vaudra le coup de faire une comparaison plus détaillé, mais flatpak semble avoir été sorti bien avant d'être finalisé (ce n'est pas une critique j'ai l'impression que les objectifs sont plus ambitieux que ceux de snap) donc c'est encore un peu tôt
Puis les 2 projets vont pouvoir être utilisé conjointement. Rien ne devrait empêcher la distribution hôte de supporter les flatpak comme les snap conjointement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.