Pièces jointes

Bonjour,

Il pourrait être intéressant d'attacher des pièces jointes à un message/extrait/tutoriel… (à définir). Par exemple, pour fournir un fichier C compilé, un .xcf pour GIMP, un zip des fichiers relatifs à un TP Python…

Merci !

Cela pourrait comporter des risques :

• pour le serveur (par l'importation de fichiers malsains) ;
• pour l’utilisateur (qui téléchargerait des fichiers dangereux).

Pour ce qui est des tutoriels, cela pourrait être vérifié lors de la publication du tutoriel, mais je ne sais pas trop comment on pourrait faire une vérification pour les messages. De pus, il faudrait voir une limite de taille car sinon l'espace disque du serveur sera vite rempli !

@Situphen :

Pour les messages, ne pourrait-on pas ajouter un bouton : "Les utilisateurs approuvent le contenu" ? Comme le système de notes, et au bout d'un certains nombres de votes négatifs, alerter un modérateur.

KevinF

Peut-être… mais ce ne sera pas possible pour les messages privés !

Ce n'est effectivement peut-être pas souhaitable pour les messages : un hébergement externe est amplement suffisant pour cela. En revanche, ce serait extrêmement appréciable pour les tutoriels et, dans ce cas, les validos pourront contrôler les fichiers.

les validos pourront contrôler les fichiers.

techniquement, non.

On ne peut pas exposer un bénévole à une infection de son ordinateur parce qu'un membre a envoyé un fichier verrolé.

Il ne faut pas non plus oublier que ZDS est un logiciel open source et qu'un fork existe déjà, ouvrir cette faille chez nous c'est l'ouvrir chez eux. Et si nous on a une structure associative pour s'assurer qu'on a les moyens de prendre les mesures adéquates, ça n'est pas forcément le cas partout !

Si vous voulez qu'on puisse mettre des pièces jointes, il faudra que zds possède un serveur externe (ou une VM/chroot dans le serveur actuel) où un antivirus tourne et éjecte les fichiers verrolés. Comme tout est externalisé de zds, cela devient de ce fait un truc en plus non nécessaire pour les autres forks et désactivé par défaut.

Voilà ce que j'ai à en dire.

Et en n'autorisant que les .zip, ça réduirait les problèmes de sécurité ?

Une archive (ici .zip) peut contenir des fichiers vérolées qui sont nocifs à l'utilisateur !

Pour moi le problème des fichiers vérolé est un faux problème : avec ce principe il faudrait interdire tous les liens.

A titre personnel je pense que ce serait une bonne chose si on est surs que nos serveurs ont la capacité de stockage pour ça et que ça ne pose pas des problèmes de sécurité pour le serveur.

A noter qu'il peut y avoir d'autres solutions : avoir une intégration de services externe pour inciter les membres a utiliser de tels services sans le gérer directement.

Pour moi le problème des fichiers vérolé est un faux problème : avec ce principe il faudrait interdire tous les liens.

J'approuve, mais le fait que ZdS héberge de tels fichiers ne pourrait-il pas poser problème (pas techniquement, mais juridiquement, moralement…) ?

Ha ça c'est un autre soucis. Mais si les membres signale les messages les modérateur pourraient intervenir.

Il y a aussi côté référencement. Si on commence à avoir des sous-domaine blacklistés parce qu'il y a des virus chez nous ça peut vite dégénérer. Pour l'instant on a une bonne note sur Web Of Trust, faut pas gâcher ça.

Dans un premier temps, je pense que laisser à l'auteur le choix d'héberger ses PJ sur des services externes est meilleur. Du moins, le temps de voir non pas la faisabilité mais la viabilité de permettre l'hébergement de fichiers.

Quant à le risque pour l'utilisateur, il est seul responsable de la protection de son OS. La responsabilité de protéger son système lui revient.

Techniquement, l'hébergement sur le serveur de ZdS de fichiers fournis par l'auteur est déjà possible : ce sont les galeries, et il y a déjà un système de limite de taille, etc. Il s'agirait simplement d'étendre le concept à l'hébergement d'autres types de fichiers. Et pour cela, il faudrait définir une liste de formats autorisés (déterminé par un file, bien sûr, pas par l'extension) selon le meilleur compromis utilité/sécurité. En première approximation, je verrais bien les formats suivants.

• Tous les principaux formats d'image, y compris ceux qui ne peuvent pas s'afficher directement (XCF, PSD, etc.)
• Des fichiers de DAO ou des modèles 3D.
• Des PDF : ne serait-ce que pour permettre d'importer une version faite maison du tuto à offrir en téléchargement aux lecteurs.
• Dans le même ordre d'idée, des DjVU.
• Des fichiers plein texte : cela regroupe les longs codes sources (pour éviter de les mettre dans des balises Secret), les SVG, les sources LaTeX, les RTF.
• Éventuellement des fichiers de bureautique. File est capable de distinguer les fichiers OpenDocument des archives ZIP ordinaires, en revanche, il ne repère pas les .docx. Mais il repère les .doc tout court. Il faut voir si cela représente une vulnérabilité de proposer ce qui est de facto une archive ZIP mais qui n'a pas vocation à être utilisée comme telle.

Éventuellement des fichiers de bureautique. File est capable de distinguer les fichiers OpenDocument des archives ZIP ordinaires, en revanche, il ne repère pas les .docx. Mais il repère les .doc tout court. Il faut voir si cela représente une vulnérabilité de proposer ce qui est de facto une archive ZIP mais qui n'a pas vocation à être utilisée comme telle.

A noter qu'ouvrir un zip en python est ultra facile. On peut imaginer que si on propose un zip (catégorie a laquelle appartiendra les docx) la validation du fichier n'est autorisé que si l'ensemble des fichiers dans le zip sont eux-aussi valides. Ce qui rendrait possible les docx mais aussi une archive plein de codes sources.

Je pense qu'un contrôle a base de whitelist est le plus sûrs.

OK pour la vérification récursive. Du coup, pour éviter un problème avec les ODT, .docx, etc., il faut autoriser aussi les fichiers de police de caractère. J'ajouterai aussi qu'il peut être intéressant, dans certains contextes, de proposer des fichiers bureautiques en lecture seule : il faudrait alors que l'auteur puisse fournir à la vérification automatique le mot de passe qui protège l'archive.

Par ailleurs, est-ce que l'exploration d'autres formats d'archives est aussi simple à faire en Python que le ZIP ? Genre, pour pouvoir proposer des TBZ, TGZ et TXZ, voire de simples tarballs.

J'ajouterai aussi qu'il peut être intéressant, dans certains contextes, de proposer des fichiers bureautiques en lecture seule : il faudrait alors que l'auteur puisse fournir à la vérification automatique le mot de passe qui protège l'archive.

Pourquoi pas mais en deuxième temps je pense. Tout comme les autres formats. En général en python, rien n'est vraiment compliqué. Dans le cas des archives c'est juste d'avoir l'algo pour décompresser. L'avantage des zip est que c'est supporté nativement, les autres je ne sais pas. Dans tous les cas je pense qu'il faut éviter de faire trop compliqué en v1. Je pense que cette proposition devrait faire l'objet d'une ZEP histoire de détailler tout ce qu'il faut et des conditions de validation. En gardant à l'esprit que la première version doit rester simple. Une fois tout le truc en place il sera facile de rajouter un format.

Je m'en occupe quand j'ai un moment, alors.

Des PDF : ne serait-ce que pour permettre d'importer une version faite maison du tuto à offrir en téléchargement aux lecteurs.

Ca devrait pas faire l'objet d'une suggestion a part ca ? "Pouvoir remplacer la version auto par une version perso" ?

Ça viendra après. En première approximation, on pourra importer le PDF sur ZdS et le proposer via un lien intégré dans le tuto. Et quand ce sera en place, on passera au moyen de remplacer la version auto.

Oui car de toute façon la possibilité de lié des pdf est utile même si il correspond à autre chose que l'article.