Le RAS a mis SPIP en evaluation sur ses machines...
Nous le proposerons probablement très bientôt à nos membres.
Une première petite remarque :
Pour que tout fonctionne, j'ai dû patcher (je ne suis pas spécialiste de PHP!)
Les include ne fonctionait pas, j'ai du remplacer *tous* les
include(file) et include(path/file)
par
include(./file) et include(./path/file)
du coup tout fonctionne sans problème.
Pour permettre une install guarantie 'premier coup' cela ne vaut-il pas
le coup de l'intégrer dans les les prochaines versions ?
Et une question :
phpNuke est connu pour avoir (eu) des trous de sécurité. Quant est il
de spip de ce point de vue ?
@micalement,
--
Francois Sauterey
Tel: +33 1 40 33 68 46
email: Francois@Sauterey.eu.org
Hello,
Francois Sauterey wrote:
Une première petite remarque :
Pour que tout fonctionne, j'ai dû patcher (je ne suis pas spécialiste de PHP!)
Les include ne fonctionait pas, j'ai du remplacer *tous* les
include(file) et include(path/file)
par
include(./file) et include(./path/file)
du coup tout fonctionne sans problème.
Pour permettre une install guarantie 'premier coup' cela ne vaut-il pas
le coup de l'intégrer dans les les prochaines versions ?
?? Ah... heu, il vaudrait mieux configurer PHP de façon à ce
que le répertoire courant soit dans les chemins d'inclusion
par défaut, non ? (cf. variable include_path dans le fichier
de config php). C'est bizarre tout de même, personne n'a jamais
eu cette erreur.
phpNuke est connu pour avoir (eu) des trous de sécurité. Quant est il
de spip de ce point de vue ?
SPIP étant très jeune et peu testé pour l'instant (en tout cas,
beaucoup moins que Nuke), on ne saurait trop dire. On a essayé de
sécuriser les choses importantes, mais on ne sait absolument pas
si c'est bien fait. Pour info, toutefois les mots de passe ne sont
pas stockés en clair (cryptage et hashage), et les fonctionnalités
les plus destructives (restauration, sauvegarde et effacement de la
base) nécessitent de créer un fichier spécifique par FTP, donc
impossible d'utiliser frauduleusement ces fonctions, même si on a
récupéré le mot de passe d'un admin.
D'autre part, la restriction d'accès à ecrire/ étant faite par
.htaccess, la sécurité dépend aussi fortement du serveur HTTP.
Notons que le cryptage des mots de passe dans le .htpasswd est
forcé en MD5 et non en DES, et que le dit .htpasswd se trouve
lui-même dans un répertoire inaccessible par HTTP (ecrire/data).
Côté sécurité, si on pouvait avoir des avis sur la chose, ça
nous intéresserait vraiment beaucoup !
Amicalement,
Antoine.
--
New! 0x52A5E9D4, B9D2 9F64 EDFA 9C6C 0536 B85B 9321 0CCF 52A5 E9D4