• [^] # Re: Mise-à-jour de sécurité sous snap

    Posté par (site web personnel) . En réponse au journal Mon premier snap sur Xenial. Évalué à 3.

    C'est vraiment le grale pour le test

    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.

    Pour savoir si tu as besoin de reconstruire tu as montré la commande. C'est automatisable encore une fois.

    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 !!!