Plutôt que de forcer une mise à jour automatique, il suffit peut-être de faciliter la mise à jour.
Dans l’espace privé, il est signalé qu’une nouvelle version est disponible, on a un lien « mettre à jour », on clique, et bing c’est à jour !
Mais il n’y a rien de plus compliqué que de faire simple 
Ça c’est vraiment un autre type de feature… prévenir la webmestre, c’est (dans notre système actuel) le rôle de la liste spip-ann. Peut-être qu’une manière d’améliorer le taux d’inscription à cette liste, serait de mettre dans l’espace privé un message (aux webmestres) disant « le saviez-tu, si tu t’inscris à la liste spip-ann tu seras mis au courant des failles de sécurité ». Il faudrait cliquer « oui je suis inscrit » pour la désactiver, et l’alerte reviendrait de toute façon une fois par an.
Bonjour,
J’ai rouvert la discussion sur un ticket de spip.
La mise à jour automatique existe pour d’autres logiciels beaucoup plus répandus que SPIP et reste fiable (je n’ai pas trouvé de plainte à ce sujet). Perso je découvre Wordpress et j’apprécie en tant que #novice qu’il soit automatiquement à jour, ce qui est le comportement par défaut depuis la version 4.0
Ils n’ont pas de site mirroir, donc effectivement ça fait des requêtes vers un organisme centralisé. Nous avons déjà ce fonctionnement pour les plugins, après réflexion je ne vois pas de raison de ne pas l’étendre à SPIP.
Bonjour,
Souvenons-nous de la maj qui conflictait avec yaml… Si cela avait été fait automatiquement, on aurait bien bien ri.
Suske
2014-11-21 12:37 GMT+01:00 Guy Cesaro <guy.cesaro@gmail.com>:
Bonjour,
Le 21 novembre 2014 10:35, Gilles Vincent <gilles.vincent@gmail.com> a
écrit :J'ai rouvert la discussion sur un ticket de spip.
La mise à jour automatique existe pour d'autres logiciels beaucoup plus
répandus que SPIP et reste fiable (je n'ai pas trouvé de plainte à ce
sujet). Perso je découvre Wordpress et j'apprécie en tant que #novice qu'il
soit automatiquement à jour, ce qui est le comportement par défaut depuis
la version 4.0
Ils n'ont pas de site mirroir, donc effectivement ça fait des requêtes
vers un organisme centralisé. Nous avons déjà ce fonctionnement pour les
plugins, après réflexion je ne vois pas de raison de ne pas l'étendre à
SPIP.Je ne suis pas d'accord : On peut trouver de nombreuses plaintes
d'utilisateurs pour des dysfonctionnements suite à des mises à jour
mineures de SPIP rien que sur les forums de contrib.
Une mise à jour mineure c'est une de type 2.1.12 vers 2.1.13, pas vers une
3.x
Je n'ai pas la même perception que toi sur le nombre de plaintes qui
surviennent suite à des mises à jour sur une même branche (2.0 / 2.1 / 3.0
/ et bientôt 3.1)
La maj auto de l'écran de sécu me paraît plus urgente, plus nécessaire et
plus "simple" à mettre en place que la maj auto de SPIP. Plus simple dans
le sens où ce n'est qu'un fichier, et il y a moins de risque de provoquer
un dysfonctionnement du site avec l'écran de sécu qu'une maj de SPIP même
mineure.
Calomnie ! (spéciale dédicace à Cédric)
Si c'était le cas ce serait qu'on a un vrai problème sur la sortie de nos
versions - Les mineures fixent des bugs et des problèmes de sécurité. Où
vois-tu des problèmes de mise à jour ?
Essayons de rester sur le sujet tant qu'il s'intitule "Maj automatique de
l'écran de sécurité". Ok pour discuter d'autre chose, comme la maj de SPIP,
dans d'autres sujets ou tickets.
Là dessus je suis d'accord.
2014-11-21 18:15 GMT+01:00 <suske@brubel.net>:
Souvenons-nous de la maj qui conflictait avec yaml... Si cela avait été
fait automatiquement, on aurait bien bien ri.
Le problème ici ne vient pas de la mise à jour automatique ou non, mais du
fait que ce conflit n'avait pas été détecté.
Le problème c'est qu'il peut y avoir des pre-releases pour les mises à jour
majeures, mais pas sur les mineures -- ce qu'il faudrait peut-être mettre
en place.
On pourrait reproduire le mode dev / testing / stable qu'on a dans d'autres
logiciels libres
Suske
Le 21 novembre 2014 12:37:15 CET, Guy Cesaro <guy.cesaro@gmail.com> a
écrit :Bonjour,
Le 21 novembre 2014 10:35, Gilles Vincent <gilles.vincent@gmail.com> a
écrit :J'ai rouvert la discussion sur un ticket de spip.
La mise à jour automatique existe pour d'autres logiciels beaucoup plus
répandus que SPIP et reste fiable (je n'ai pas trouvé de plainte à ce
sujet). Perso je découvre Wordpress et j'apprécie en tant que #novice qu'il
soit automatiquement à jour, ce qui est le comportement par défaut depuis
la version 4.0
Ils n'ont pas de site mirroir, donc effectivement ça fait des requêtes
vers un organisme centralisé. Nous avons déjà ce fonctionnement pour les
plugins, après réflexion je ne vois pas de raison de ne pas l'étendre à
SPIP.Je ne suis pas d'accord : On peut trouver de nombreuses plaintes
d'utilisateurs pour des dysfonctionnements suite à des mises à jour
mineures de SPIP rien que sur les forums de contrib.
La maj auto de l'écran de sécu me paraît plus urgente, plus nécessaire et
plus "simple" à mettre en place que la maj auto de SPIP. Plus simple dans
le sens où ce n'est qu'un fichier, et il y a moins de risque de provoquer
un dysfonctionnement du site avec l'écran de sécu qu'une maj de SPIP même
mineure. Commençons par la maj auto de ce dernier et on verra par la suite
pour un plus vaste projet diabolique de maj auto de SPIP.Essayons de rester sur le sujet tant qu'il s'intitule "Maj automatique de
l'écran de sécurité". Ok pour discuter d'autre chose, comme la maj de SPIP,
dans d'autres sujets ou tickets.------------------------------
spip-team@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-team
--
Suske
Gilles Vincent a écrit :
Calomnie ! (spéciale dédicace à Cédric)
Si c'était le cas ce serait qu'on a un vrai problème sur la sortie de
nos versions - Les mineures fixent des bugs et des problèmes de
sécurité. Où vois-tu des problèmes de mise à jour ?
L'historique des commit montre qu'on ne sait pas se tenir au principe "une mise à jour mineure doit pouvoir se faire les yeux fermés et n'avoir aucune conséquence sur le fonctionnement des sites existant".
Cédric
2014-11-24 8:58 GMT+01:00 Cédric Morin <cedric@yterium.com>:
Gilles Vincent a écrit :
Calomnie ! (spéciale dédicace à Cédric)
Si c'était le cas ce serait qu'on a un vrai problème sur la sortie de
nos versions - Les mineures fixent des bugs et des problèmes de
sécurité. Où vois-tu des problèmes de mise à jour ?L'historique des commit montre qu'on ne sait pas se tenir au principe "une
mise à jour mineure doit pouvoir se faire les yeux fermés et n'avoir aucune
conséquence sur le fonctionnement des sites existant".
C'est tout le problème de la créativité 
Et heureusement qu'on se permet de garder ce niveau d'entropie dans le
développement, car on n'a pas les ressources humaines / temps pour
s'acharner à du génie logiciel quasi industriel, et surtout on n'avancerait
pas !
En tout cas tout ce qui se fait c'est génial !
Je m'excuse si j'ai parfois l'air critique sur les développements, car
sérieux j'adore la façon dont avance se transforme Spip au fil des
améliorations !! J'adore ce que vous faites, je suis carrément fan !
Le 14/11/2014 à 14:46, Cédric Morin a écrit :
Je dirais que 2 suffisent (update et update1).
Le but c'est pas de faire du balancing/disponibilité mais du contrôle :
SPIP interroge https://update.spip.net en vérifiant le certificat.
Si le checksum de l'écran n'est pas le même qu'en local, il interroge aussi https://update1.spip.net en verifiant le certificat, et SI les deux fichiers sont identiques il met a jour l'ecran de sécu.En parallèle on a un CRON quelque part qui régulièrement télécharge l'écran sur les 2 sources et vérifie qu'ils sont cohérents. Si jamais il y a différence, mail d'alerte sécu ici sur spip-team.
Ainsi :
- le https nous protège en principe d'une attaque man-in-the-middle
- un attaquant doit compromettre "en même temps" les 2 domaines update et update1 pour pouvoir diffuser un écran corrompu.D'où l'intéret d'avoir les 2 domaines hébergés sur 2 serveurs qui n'ont rien à voir (aucun accès commun, type d'installation différent etc.)
Bon, du coup je suppose que le point faible devient le DNS spip.net sur lequel il suffit de prendre la main.
Est-ce que ça veut dire qu'il faudrait aussi répartir sur 2 domaines différents chez 2 registars différents, si on veut aller jusqu'au bout de la redondance sécuritaire ?
Tiens je retombe sur ce fil totalement par hasard. Ça en est où cette histoire de mise à jour totalement automatique pour la sécurité ?
(et qui pourrait avoir un mécanisme équivalant pour la vérif des zip de la dist aussi dans le même genre mais pas de màj automatique, après c'est une autre fonctionnalité de permettre la mise à jour de la dist en PHP par bouton dans l'interface) (mais c'est intéressant aussi et ça existe dans d'autres CMS, et ça facilite pour celleux pas sur un hébergement qui fait à leur place)
C'était intéressant toute cette discussion. Yavait eu des tickets toujours en cours autour de ça du coup ?
--
RastaPopoulos
C'est est qu'à l'époque on était pas forts en https et pas prêts, mais que maintenant on pourrait le faire.
En pratique il suffit que quelqu'un d'entre nous héberge un update.spip.net avec un certificat SSL, et il y a juste à faire svn up sur l'écran de sécu pour mettre à jour la propagation quand il faut.
Et d'un autre côté on peut avec Ben héberger un miroir de contrôle avec un autre domaine/autre registar aussi en SSL (je pense que c'est une bonne idée de pas faire 2 sous-domaines de spip.net comme je l'exposais ci-dessous).
La seule contrainte est d'être capable de maintenir les domaines/sous-domaines puisqu'on va dans ce cas les graver dans le dur du code de SPIP
Il ne faut pas retarder la release de la 3.2 pour ça, on peut très bien l'intégrer dès que c'est dispo.
--
Cédric
RastaPopoulos a écrit :
Le 14/11/2014 à 14:46, Cédric Morin a écrit :
Je dirais que 2 suffisent (update et update1).
Le but c'est pas de faire du balancing/disponibilité mais du contrôle :
SPIP interroge https://update.spip.net en vérifiant le certificat.
Si le checksum de l'écran n'est pas le même qu'en local, il interroge
aussi https://update1.spip.net en verifiant le certificat, et SI les
deux fichiers sont identiques il met a jour l'ecran de sécu.En parallèle on a un CRON quelque part qui régulièrement télécharge
l'écran sur les 2 sources et vérifie qu'ils sont cohérents. Si jamais
il y a différence, mail d'alerte sécu ici sur spip-team.Ainsi :
- le https nous protège en principe d'une attaque man-in-the-middle
- un attaquant doit compromettre "en même temps" les 2 domaines update
et update1 pour pouvoir diffuser un écran corrompu.D'où l'intéret d'avoir les 2 domaines hébergés sur 2 serveurs qui
n'ont rien à voir (aucun accès commun, type d'installation différent
etc.)Bon, du coup je suppose que le point faible devient le DNS spip.net
sur lequel il suffit de prendre la main.
Est-ce que ça veut dire qu'il faudrait aussi répartir sur 2 domaines
différents chez 2 registars différents, si on veut aller jusqu'au bout
de la redondance sécuritaire ?Tiens je retombe sur ce fil totalement par hasard. Ça en est où cette
histoire de mise à jour totalement automatique pour la sécurité ?(et qui pourrait avoir un mécanisme équivalant pour la vérif des zip de
la dist aussi dans le même genre mais pas de màj automatique, après
c'est une autre fonctionnalité de permettre la mise à jour de la dist en
PHP par bouton dans l'interface) (mais c'est intéressant aussi et ça
existe dans d'autres CMS, et ça facilite pour celleux pas sur un
hébergement qui fait à leur place)C'était intéressant toute cette discussion. Yavait eu des tickets
toujours en cours autour de ça du coup ?
Le 30/06/2017 à 15:30, Cédric Morin a écrit :
La seule contrainte est d'être capable de maintenir les domaines/sous-domaines puisqu'on va dans ce cas les graver dans le dur du code de SPIP
Pour update.spip.net (ou ecran.spip.net si que pour l'écran mais bon on peut imaginer que ça puisse servir à signer d'autres zip/mises à jour plus tard) ça devrait aller. C'est plus pour l'autre domaine avec autre registrar qu'il faut être certain.
Il ne faut pas retarder la release de la 3.2 pour ça, on peut très bien l'intégrer dès que c'est dispo.
Oui oui évidemment, c'est juste que j'étais retombé dessus totalement par hasard et que je ne me rappelais pas avoir revu des choses à ce sujet depuis 3 ans, malgré l'idée intéressante.
--
RastaPopoulos
Le 30/06/2017 à 16:11, RastaPopoulos a écrit :
Le 30/06/2017 à 15:30, Cédric Morin a écrit :
La seule contrainte est d'être capable de maintenir les
domaines/sous-domaines puisqu'on va dans ce cas les graver dans le dur
du code de SPIPPour update.spip.net (ou ecran.spip.net si que pour l'écran mais bon on
peut imaginer que ça puisse servir à signer d'autres zip/mises à jour
plus tard) ça devrait aller. C'est plus pour l'autre domaine avec autre
registrar qu'il faut être certain.
de la même manière que Cedric bosse en parallèle avec Ben ce qui donne
une bonne probabilité de pérennité pour le maintient du sous-domaine
ecran.spip.net (ou autre), je peux proposer de maintenir en association
avec tofulm le 2ème sous-domaine (qui ne sera pas en spip.net pour avoir
un DNS différent): pour l'instant ce qu'on aurait de plus "spipien"
comme domaine c'est spipha.fr
à bientôt,
Cyrille
Le 30/06/2017 à 19:01, cy_altern a écrit :
de la même manière que Cedric bosse en parallèle avec Ben ce qui donne
une bonne probabilité de pérennité pour le maintient du sous-domaine
ecran.spip.net (ou autre), je peux proposer de maintenir en association
avec tofulm le 2ème sous-domaine (qui ne sera pas en spip.net pour avoir
un DNS différent): pour l'instant ce qu'on aurait de plus "spipien"
comme domaine c'est spipha.fr
Attention en priorité on ne parle pas de l'hébergement.
spip.net (et tout sous-domaine) c'est le domaine officiel, donc on sait qu'on l'aura toujours à l'infini pour le projet SPIP (et dans le Redmine c'est Fil et Ben qui s'en occupent)
Pour le deuxième domaine, là par contre il faut être sûr car ce sera un autre et ça ne devra plus bouger. On a spip.org aussi mais même registrar à priori non ? (=> en fait tous les domaines qu'on a sont sur Gandi) Et donc il faudrait une autre domaine d'un autre registrar à définir une bonne fois pour toute.
L'hébergement derrière, lui, il pourra changer, dans le code source ce sont les domaines qui seront inscrits en dur (mais il faut aussi définir qui s'en occupe bien sûr).
--
RastaPopoulos
Le 30/06/2017 à 19:19, RastaPopoulos a écrit :
Le 30/06/2017 à 19:01, cy_altern a écrit :
de la même manière que Cedric bosse en parallèle avec Ben ce qui donne
une bonne probabilité de pérennité pour le maintient du sous-domaine
ecran.spip.net (ou autre), je peux proposer de maintenir en association
avec tofulm le 2ème sous-domaine (qui ne sera pas en spip.net pour avoir
un DNS différent): pour l'instant ce qu'on aurait de plus "spipien"
comme domaine c'est spipha.frAttention en priorité on ne parle pas de l'hébergement.
oui, je pensais au sous-domaine permettant la redondance des infos à
tester pour une éventuelle maj automatique de l'écran de sécu. Cf le
message de Cedric du 14/11/2014:
Le but c'est pas de faire du balancing/disponibilité mais du contrôle :
SPIP interroge https://update.spip.net en vérifiant le certificat.
Si le checksum de l'écran n'est pas le même qu'en local, il interroge aussi https://update1.spip.net en verifiant le certificat, et SI les deux fichiers sont identiques il met a jour l'ecran de sécu.
à bientôt,
Cyrille
Salut
Avoir update1.spip.net et update2.spip.net me semble plus simple, le
fait d'avoir un double registar n'apporte rien et les problèmes ont
supplémentaires ont déjà été indiqués
Si on veut faire plus "sécurisé" c'est d'avoir un serveur DNS
redondant chez un autre ASN.
Il est aussi possible d'avoir un load balancing sur le mème sous
domaine update.spip.net qui renvoit aléatoirement sur x serveurs
updates.
Je peux héberger l'un ou l'autre des services.
Km
Le 02/07/2017 à 13:09, cam.lafit@azerttyu.net a écrit :
Il est aussi possible d'avoir un load balancing sur le mème sous
domaine update.spip.net qui renvoit aléatoirement sur x serveurs
updates.
Mais ce n'était pas pour faire du load balancing, c'était pour avoir deux fois le contenu et que le script puisse télécharger les deux et contrôler, il me semble. Et que donc ça voit tout de suite si l'un des serveurs est compromis.
--
RastaPopoulos
Le 02/07/2017 à 13:38, Fil a écrit :
Il me semble qu'on peut utiliser ipfs pour ca. Et plus précisément ipns qui permet de signer la provenance _et_ le contenu. Tout en étant accessible par un simple appel HTTPS.
Génial ! Ce serait encore plus moderne et pérenne !
--
RastaPopoulos
Il me semble qu’on peut utiliser ipfs pour ca. Et plus précisément ipns qui permet de signer la provenance et le contenu. Tout en étant accessible par un simple appel HTTPS.