Bienvenue sur le site de l'AE !

Tim

L'ouverture du SVN est une mauvaise idée. Et ceci tout simplement à cause de ceci : http://ae.utbm.fr/forum2/?id_message=2240478#msg2240478 (merci Dustri! :] )

Je vais donc expliciter pour les personnes qui ne savent pas à quoi sert SVN : SVN est un gestionnaire de source, qui permet d'avoir un historique complet de l'ensemble des fichiers sources du site AE. Le fichier contenant l'ensemble des noms et numéros de téléphone des promo 10 est donc encore et toujours dans SVN, même s'il a été supprimé du site. Pourquoi ne pas le supprimer de SVN donc? Tout simplement parce que ce n'est pas possible car cela briserait le concept de "gestionnaire de versions"...

Ensuite pourquoi ne pas tout simplement recommencé avec un nouveau git/svn public? Simplement parce que ce n'est pas réaliste : qu'est ce qui empechera un prochain resp/adjoint info de refaire l'erreur d'avoir un fichier avec des infos en clair (mot de passe, donnée, ...) ? Rien du tout.

Merci donc à notre ami Dustri qui a donné le parfait exemple de pourquoi ce n'est pas une bonne idée d'ouvrir le SVN (ni un git d'ailleurs) du site AE! :)

La sécurité par l'obscurité, en voilà une bonne idée pour pallier à l'incompétence ou la bêtise.

Surtout qu'en plus le fait que le SVN soit privé n'a pas empêché Dustri de retrouver ça…

Haha.

L’ouverture du SVN est une mauvaise idée. Et ceci tout simplement à cause de ceci : http://ae.utbm.fr/forum2/?id_message=2240478#msg2240478 (merci Dustri! :] )

Avec un accès au SVN, je l'aurais vu plus vite.

Je vais donc expliciter pour les personnes qui ne savent pas à quoi sert SVN : SVN est un gestionnaire de source, qui permet d’avoir un historique complet de l’ensemble des fichiers sources du site AE. Le fichier contenant l’ensemble des noms et numéros de téléphone des promo 10 est donc encore et toujours dans SVN, même s’il a été supprimé du site. Pourquoi ne pas le supprimer de SVN donc? Tout simplement parce que ce n’est pas possible car cela briserait le concept de “gestionnaire de versions�?…

1. Il est bien sûr possible de supprimer un commit de SVN.
2. Il est bien sûr conseillé de ne pas commiter de fichiers visant à rester secrets.

Ensuite pourquoi ne pas tout simplement recommencé avec un nouveau git/svn public? Simplement parce que ce n’est pas réaliste : qu’est ce qui empechera un prochain resp/adjoint info de refaire l’erreur d’avoir un fichier avec des infos en clair (mot de passe, donnée, …) ? Rien du tout.

Qu'est-ce qui empecherait un resp/adjoint d'introduire un trou de sécurité ? Le fait d'avoir un accès au SVN permet à tout le monde de relire le code du site, et de faire remonter ce genre de failles.

Et comme dit au point précédent: Il faudrait éviter de faire ce genre de commits idiots avec des données confidentielles dedans.

Merci donc à notre ami Dustri qui a donné le parfait exemple de pourquoi ce n’est pas une bonne idée d’ouvrir le SVN (ni un git d’ailleurs) du site AE! :)

C'est bien connu, ouvrir un gestionnaire de version, c'est idiot. Personne ne le fait. À part peut-être la grande majorité des logiciels libres, comme ceux qui font tourner le site de l'AE (GNU, Linux, Apache, Bind, Php, …), ce qui a pour effet de renforcer dramatiquement la sécurité et sa transparence.

Les source du forum doivent être publiques. Je ne vois donc pas ce que ça change de rndre le SVN public lui aussi.

Ça fait plaisir de lire ce genre de sophisme de la part de quelqu'un à Bac+5 en informatique.

Dustri

Les source du forum doivent être publiques. Je ne vois donc pas ce que ça change de rndre le SVN public lui aussi.

Ça fait plaisir de lire ce genre de sophisme de la part de quelqu'un à Bac+5 en informatique.

les sources en soit ne sont pas privée, car comme tu le fait toi même, tu vérifie les sources à la recherche de trou de sécurité (que tu réussi d'ailleurs admirablement bien à trouvé semble t'il).

Seulement voilà, mettre à disposition de tout le monde les sources, et le gestionnaire de source sont 2 choses complètement différentes.

Les sources représentent à un temps T le code source du site AE. On n'a donc pas accès a un historique, on peut donc supprimer des fichiers que l'on aurait pas dût rendre public, les rendant ainsi inaccessible.

Alors que donner l'accès au gestionnaire de source rend le problème bien plus délicat.

[troll=on] D'ailleurs, as tu essayé d'envoyer un diff à l'équipe info pour corriger les nombreux soucis que tu as dût trouver pour régler tous ces problèmes de sécurité? Ou as tu préféré dénigrer l'équipe Info par ton niveau bien supérieur? :] [troll=off]

BenC`

La sécurité par l'obscurité, en voilà une bonne idée pour pallier à l'incompétence ou la bêtise.

Surtout qu'en plus le fait que le SVN soit privé n'a pas empêché Dustri de retrouver ça…

La sécurité par l'obscurité impliquerait que les sources ne soit pas disponibles, hors elle le sont ici : http://ae.utbm.fr/var/siteae-utbm-latest.tar.gz

Parce qu'effectivement ça a sa place se le forum :

Le bureau AE a toujours pour but de trouver une solution pour faciliter la relecture du code. SVN, GIT, Mercurial peu importe.

Ceci dit je vous renvoie vers ma dernière intervention...

Les sources représentent à un temps T le code source du site AE. On n’a donc pas accès a un historique, on peut donc supprimer des fichiers que l’on aurait pas dût rendre public, les rendant ainsi inaccessible.

Encore une fois:

1. Il est bien sûr possible de supprimer un commit de SVN.
2. Il est bien sûr conseillé de ne pas commiter de fichiers visant à rester secrets.

Et même sans SVN, j'ai accès a un moins 1 an d'historique, parce que je me fais chier à télécharger régulièrement l'archive. Ne pas ouvrir le gestionnaire de version ne sert à rien.

[troll=on] D’ailleurs, as tu essayé d’envoyer un diff à l’équipe info pour corriger les nombreux soucis que tu as dût trouver pour régler tous ces problèmes de sécurité? Ou as tu préféré dénigrer l’équipe Info par ton niveau bien supérieur? :] [troll=off]

J'aimerais bien, mais je n'ai pas accès au SVN.

Tu pourrais répondre à:

C’est bien connu, ouvrir un gestionnaire de version, c’est idiot. Personne ne le fait. À part peut-être la grande majorité des logiciels libres, comme ceux qui font tourner le site de l’AE (GNU, Linux, Apache, Bind, Php, …), ce qui a pour effet de renforcer dramatiquement la sécurité et sa transparence.

Faire un bête lien vers le SVN en lecture seule, ça doit prendre un bon quart d'heure à tout casser.

Dustri

Faire un bête lien vers le SVN en lecture seule, ça doit prendre un bon quart d'heure à tout casser.

Le problème c'est surtout ça apparemment...

Epyde

Attend, faut le temps de récupérer les accès >.>

Dustri

Les sources représentent à un temps T le code source du site AE. On n’a donc pas accès a un historique, on peut donc supprimer des fichiers que l’on aurait pas dût rendre public, les rendant ainsi inaccessible.

Encore une fois:

    Il est bien sûr possible de supprimer un commit de SVN.
    Il est bien sûr conseillé de ne pas commiter de fichiers visant à rester secrets.

Certes, c'est pas très utile de commiter des fichiers ayant pour but d'être secret, mais l'erreur est humaine non? Je ne pense pas que la personne ayant commiter la liste des promo 10 l'ai fait exprès.

Dustri

Et même sans SVN, j'ai accès a un moins 1 an d'historique, parce que je me fais chier à télécharger régulièrement l'archive. Ne pas ouvrir le gestionnaire de version ne sert à rien.

Ne croit tu pas être l'exception? Je pense pouvoir compter sur les doigts d'une main le nombre de personne maintenant, même de manière moins régulière, les sources du site AE pour reconstruire un historique...

Dustri

[troll=on] D’ailleurs, as tu essayé d’envoyer un diff à l’équipe info pour corriger les nombreux soucis que tu as dût trouver pour régler tous ces problèmes de sécurité? Ou as tu préféré dénigrer l’équipe Info par ton niveau bien supérieur? :] [troll=off]

J'aimerais bien, mais je n'ai pas accès au SVN.

En quoi un accès à SVN te permet de faire un diff? Qu'est ce qui t'empêche de corriger le soucis à partir des sources ouvertement accessible, pour d'effectuer ce diff et de l'envoyer par mail à ae.info@utbm.fr ? Tu n'a en aucun cas besoin d'un SVN pour réaliser cela...

Dustri

Tu pourrais répondre à:

C’est bien connu, ouvrir un gestionnaire de version, c’est idiot. Personne ne le fait. À part peut-être la grande majorité des logiciels libres, comme ceux qui font tourner le site de l’AE (GNU, Linux, Apache, Bind, Php, …), ce qui a pour effet de renforcer dramatiquement la sécurité et sa transparence.

Certes, mais ces projets open source dont tu parle ont rarement vocation a hébergé des données utilisateurs. C'est à dire que les données qui risquent d'apparaitre sont plutôt par exemple un fichier de mot de passe d'un des développeurs par exemple, ce qui a peu d'impacte sur le projet en général ou sur les données utilisateurs. Ici, nous sommes dans le cas d'un site web.

Tim

BenC`

La sécurité par l'obscurité, en voilà une bonne idée pour pallier à l'incompétence ou la bêtise.

Surtout qu'en plus le fait que le SVN soit privé n'a pas empêché Dustri de retrouver ça…

La sécurité par l'obscurité impliquerait que les sources ne soit pas disponibles, hors elle le sont ici : http://ae.utbm.fr/var/siteae-utbm-latest.tar.gz

Cacher les révisions en fait partie également (ou formulé autrement : cacher ce qui a été modifié). Et merci, j'ai été assez longtemps dans l'équipe info pour savoir où sont les sources ;)

Certes, c’est pas très utile de commiter des fichiers ayant pour but d’être secret, mais l’erreur est humaine non? Je ne pense pas que la personne ayant commiter la liste des promo 10 l’ai fait exprès.

D'où l'intéret d'ouvrir ce foutu SVN, qu'on puisse vérifier/relire.

Ne croit tu pas être l’exception? Je pense pouvoir compter sur les doigts d’une main le nombre de personne maintenant, même de manière moins régulière, les sources du site AE pour reconstruire un historique…

Ouvrir le SVN permeterai à plus de monde de les lire justement, et de comprendre l'évolution du site. Toi qui propose de garder le SVN fermé, tu as peur de quoi, vu que tu penses que je suis le seul à lire les sources ?

En quoi un accès à SVN te permet de faire un diff? Qu’est ce qui t’empêche de corriger le soucis à partir des sources ouvertement accessible, pour d’effectuer ce diff et de l’envoyer par mail à ae [dot] info [at] utbm [dot] fr ? Tu n’a en aucun cas besoin d’un SVN pour réaliser cela…

Je le ferai avec joie une fois le SVN ouvert.

Certes, mais ces projets open source dont tu parle ont rarement vocation a hébergé des données utilisateurs. C’est à dire que les données qui risquent d’apparaitre sont plutôt par exemple un fichier de mot de passe d’un des développeurs par exemple, ce qui a peu d’impacte sur le projet en général ou sur les données utilisateurs. Ici, nous sommes dans le cas d’un site web.

Je pense que les clef ssh/gpg des dev' de Linux sont plus précieuses que tout ce que tu pourras commiter sur le site de l'AE.

Mais une fois de plus (trois fois que je me répète):

1. On peut supprimer un commit
2. Il ne faut pas commiter des fichiers qui ont vocation à rester secret.
3. Le fait de garder le SVN fermé ne protège pas, parce qu'il me suffit de regarder dans les sources
4. Le SVN fermé n'encourage pas les contribution, et empêche les contributeurs potentiels de suivre l'évolution du code
5. Les dev' font des erreurs, le but n'est pas de chercher des coupables, mais de corriger rapidement. Si tu caches les soucis, ils seront corrigés moins rapidement.

Le pire, c'est que je ne suis absolument pas pour un SVN fermé :]

C'est juste que ça ne réglera absolument pas tous les problèmes qu'il peut se présenter, et que ca risque justement d'en créer d'autres / plus(?). Et je ne vois pas non plus qu'est ce que ca apportera.

Oui tu n'as pas arreté de dire que ca ne protège pas plus de le gardé fermé, que ca empêche les contributions, etc. Mais si toi même tu n'es pas capable de contribuer pour régler des problèmes de sécurités béants, alors même que ca t'intéresse, pourquoi d'autres personnes moins interessés le ferait?

Oui, moins j'en fais, mieux je me porte!

Tim

L'ouverture du SVN est une mauvaise idée.

Tim

Le pire, c’est que je ne suis absolument pas pour un SVN fermé :]

On pourra au moins saluer l'efficacité des arguments de Dustri :)

souille

Tim

L'ouverture du SVN est une mauvaise idée.

Tim

Le pire, c’est que je ne suis absolument pas pour un SVN fermé :]

On pourra au moins saluer l'efficacité des arguments de Dustri :)

C'est une mauvaise idée, car les gains par rapport aux chose à faire sont minimales. Si je ne le fait pas, et que quelqu'un d'autre s'en charge tant mieux.

Car à part ouvrir, il faut trouver l'ensemble des fichiers contenant des mdp, des données utilisateurs, etc.

Tim

Car à part ouvrir, il faut trouver l'ensemble des fichiers contenant des mdp, des données utilisateurs, etc.

Tu me fais peur là. Dans un projet les données non communes sont séparées du code qui les prend en charge. C'est pourquoi les mots de passes contenus dans le code publié ne sont pas ceux utilisés en production. De même les données utilisateurs et de l'ensemble du site sont sockées dans une base de donnée.

Qu'un fichier contenant des informations personnelles se retrouve dans le SVN est une très facheuse erreur, mais qui n'a rien a voir avec la nature du projet. Il faut qd même générer ce fichier (en exécutant du code sur le serveur), le transférer et l'enregistrer dans un sous dossier du code du site (sur le pc du développeur), puis l'ajouter à SVN et enfin l'envoyer sur le dépôt du serveur. J'ai autant de chances de publier mes photos de vacances.

Salut,

Tim

C'est une mauvaise idée, car les gains par rapport aux chose à faire sont minimales. Si je ne le fait pas, et que quelqu'un d'autre s'en charge tant mieux.

Car à part ouvrir, il faut trouver l'ensemble des fichiers contenant des mdp, des données utilisateurs, etc.

La notion de "gain minimaux" est assez subjective..

Et par conséquent, je suis prêt à parcourir les sources/historique de commits à la recherche de contenu "sensible" pour l'enlever si c'est vraiment ça qui fait peur.

Je n'ai pas non plus énormément de temps libre à y consacrer, mais je veux bien y dédier une partie à le faire, et éventuellement à rendre public le SVN/Git/je-ne-sais-quoi. ** Certes, je ne fais pas partie de l'équipe info, mais je suis persuadé qu'il y a plusieurs personnes qui sont prêtes à éplucher l'historique et qui ne font pas non plus partie de l'équipe info, mais qui sont prêtes à y consacrer une partie de leur temps (en un après-midi, c'est plié..) pour faire avancer les choses.

Et dans ce cas, ça pourrait aller vite et cette affaire serait réglée avant la rentrée.**

Car à part ouvrir, il faut trouver l’ensemble des fichiers contenant des mdp, des données utilisateurs, etc.

Certes il serait nécessaire de vérifier que des données sensibles ne soient pas dévoilées avec l'accès public. Cependant, une fois ces fichiers listés, les exclure de l'accès public grâce aux hooks svn ne doit pas poser trop de soucis.

C’est une mauvaise idée, car les gains par rapport aux chose à faire sont minimales. Si je ne le fait pas, et que quelqu’un d’autre s’en charge tant mieux.

Au contraire, les gains potentiels provenant de la participation d'étudiants motivés, pèsent très certainement bien plus lourd dans la balance qu'un après-midi de repérage des fichiers à exclure.

C'est justement pour permettre à ces personnes de participer efficacement, qu'un accès public au svn peut-être intéressant, les logs sont un apport non négligeable pour la compréhension du code, en fait c'est leur but premier.

Larfeuille

une fois ces fichiers listés, les exclure de l'accès public grâce aux hooks svn ne doit pas poser trop de soucis.

Encore une fois, ça se fait dans l'autre sens. Quand vous téléchargez Wordpress ou autre joyeuseté, les crédentials sont pas livrées avec ? Non, elles sont ajoutées sur la version en prod.

souille

Tim

Car à part ouvrir, il faut trouver l'ensemble des fichiers contenant des mdp, des données utilisateurs, etc.

Tu me fais peur là. Dans un projet les données non communes sont séparées du code qui les prend en charge. C'est pourquoi les mots de passes contenus dans le code publié ne sont pas ceux utilisés en production. De même les données utilisateurs et de l'ensemble du site sont sockées dans une base de donnée.

Qu'un fichier contenant des informations personnelles se retrouve dans le SVN est une très facheuse erreur, mais qui n'a rien a voir avec la nature du projet. Il faut qd même générer ce fichier (en exécutant du code sur le serveur), le transférer et l'enregistrer dans un sous dossier du code du site (sur le pc du développeur), puis l'ajouter à SVN et enfin l'envoyer sur le dépôt du serveur. J'ai autant de chances de publier mes photos de vacances.

Certes les données sont censés être séparés du code, mais je suis sûr qu'en tant qu'ancien responsable info, tu dois te douter qu'il y a encore des données dans le code du site AE...

Sinon le site AE c'est 102342 lignes de PHP, dans 526 fichiers PHP, et vu la lisibilité du code, ca ne s'épluche pas vraiment en 1 aprem :°

Et pour les gens motivés, on a déjà énormément de mal à recruter un responsable, un adjoint ou même un chargé de mission, alors des gens extérieur, j'ai peur d'en douter grandement.

Tim

tu dois te douter qu'il y a encore des données dans le code du site AE...

On ne peut jamais être sûr, non ? :) D'un autre côté s'il y en a, elles sont dans l'archive publiée.

Tim

et vu la lisibilité du code

Question de point de vue.

Certes les données sont censés être séparés du code, mais je suis sûr qu’en tant qu’ancien responsable info, tu dois te douter qu’il y a encore des données dans le code du site AE…

Sinon le site AE c’est 102342 lignes de PHP, dans 526 fichiers PHP, et vu la lisibilité du code, ca ne s’épluche pas vraiment en 1 aprem :°

Je l'ai pourtant épluché, et c'est de loin de gros projet php est le code le plus sympa que j'ai vu. J'ai reporté la seule donnée qu'il y avait dedans. Mais j'aurais été plus vite avec un SVN.

Et pour les gens motivés, on a déjà énormément de mal à recruter un responsable, un adjoint ou même un chargé de mission, alors des gens extérieur, j’ai peur d’en douter grandement.

Forcement, avec une telle attitude, j'ai pas envie de rapporter des bugs, et encore moins de les corriger. Sérieusement, ça fait trois plombes que l'équipe info doit ouvrir ce foutu SVN, ça a été voté, et on est encore en train de se battre pour qu'il soit ouvert, à enfoncer des portes ouvertes.

Faire du php, c'est pas marrant, mais faire du php sans avec accès au gestionnaire de sources, c'est vraiment pas marrant.

Encore une fois, ça se fait dans l’autre sens. Quand vous téléchargez Wordpress ou autre joyeuseté, les crédentials sont pas livrées avec ? Non, elles sont ajoutées sur la version en prod.

Bien d'accord mais le mal a l'air d'être déjà fait, j'ai peut-être mal compris.

Et pour les gens motivés, on a déjà énormément de mal à recruter un responsable, un adjoint ou même un chargé de mission, alors des gens extérieur, j’ai peur d’en douter grandement.

Un dépot ouvert facilite cette participation. De plus il y a une différence entre être responsable et proposer des changements, ça peut faire moins "peur" et attirer plus de monde.

souille

tu dois te douter qu'il y a encore des données dans le code du site AE...

On ne peut jamais être sûr, non ? :) D'un autre côté s'il y en a, elles sont dans l'archive publiée.

Tim

et vu la lisibilité du code

Question de point de vue.

Il doit sûrement y avoir des données dans l'archive publiée certes, mais si on ouvre le SVN maintenant, alors il faudra relire l'ensemble des commit depuis l'ouverture du SVN pour regarder si il n'y a pas une donnée qui s'y serait glissé. Pas impossible, mais plutôt gourmand en temps...

Dustri

Et pour les gens motivés, on a déjà énormément de mal à recruter un responsable, un adjoint ou même un chargé de mission, alors des gens extérieur, j’ai peur d’en douter grandement.

Forcement, avec une telle attitude, j'ai pas envie de rapporter des bugs, et encore moins de les corriger. Sérieusement, ça fait trois plombes que l'équipe info doit ouvrir ce foutu SVN, ça a été voté, et on est encore en train de se battre pour qu'il soit ouvert, à enfoncer des portes ouvertes.

Ce n'est pas une question d'attitude, c'est une constatation. Il s'est avéré que le semestre de printemps dernier, il n'y avait pas de responsable info car la personne en poste a démissionné dès le début pour des raison personnelles, mais que personne ne s'est présenté avant une bonne partie du semestre entamé.

Tim

Et pour les gens motivés, on a déjà énormément de mal à recruter un responsable, un adjoint ou même un chargé de mission, alors des gens extérieur, j'ai peur d'en douter grandement.

Bah justement je pense qu'il y a plus de personnes qui souhaitent s'investir ponctuellement dans le projet sans pour autant être responsable info...

Ces gens permettent de trouver des bugs, des failles... Bien plus vite que les respo....

Finalement la seule différence entre filer les sources et filer le svn c'est savoir qui a écrit les bêtises... Mais vous inquiétez pas tout le monde s'en fout.

Dans l'idéal on avait proposé à d'autres assos d'utiliser AEcms pour leur site avec tous les supra cools tools (compta, compte AE,...) Et si eux aussi avaient voulus contribuer... un dépôt ouvert aurait grandement facilité la chose.

Au final, je doute que quelqu'un d'autre à part nous, utilise aecms.

Moi j'aurais adoré participer, sur mon temps libre de temps en temps... avec un code ouvert, on put aurait organiser un hackathon AE et en un weekend on aurait trouvé/résolu pleins de bugs... trouver des responsables serait plus si difficile si on permet à tout le monde de toucher un peu tout seul.

Question conne : si on prends les source de l'archive (pas tout à fait à jour), et qu'on init un dépôt, on peut démarrer un fork ou c'est contraire à la license. Genre faut que ça soit le "propriétaire" du code (ici l'AE) qui ouvre ou tout un chacun a le droit ?

Vid

Question conne : si on prends les source de l'archive (pas tout à fait à jour), et qu'on init un dépôt, on peut démarrer un fork ou c'est contraire à la license. Genre faut que ça soit le "propriétaire" du code (ici l'AE) qui ouvre ou tout un chacun a le droit ?

Le site est sous license GPL : http://ae.utbm.fr/article.php?name=about qui dit que oui tu peux : http://fr.wikipedia.org/wiki/Licence_publique_g%C3%A9n%C3%A9rale_GNU

Bah voila, c'est facile, si il n'y a pas de repo rendu disponible par l'AE, il suffit de créé un repo nous même. Libre a eux de réintégrer les modif dans leur version après.

@okité: J'ai l'impression que tu passes complètement à côté de la problématique, ça me fait un peu peur.

Le but, ça n'est pas d'avoir un gestionnaire de version pour foutre du code dedans (Merci, j'ai déjà.), mais d'avoir accès à celui du site, du code déployé en production, pour éviter/remonter les multiples problèmes que le fait d'avoir uniquement une tarball engendrent.

Libre a eux de réintégrer les modif dans leur version après.

1. Super, tu as du code corrigé, mais il n'est pas déployé sur le site de l'AE. Au mieux, ce sera peut-être intégré, au pire, ça servira pour voir où sont les trous qui ne sont pas bouchés.
2. Super, tu vas devoir le maintenir synchronisé à la main parce qu'il n'y a toujours pas d'accès au SVN.

Tu veux en faire quoi de ton dépôt SVN ? Monter ton site de l'AE dans ton coin ?

Dustri

@okité: J'ai l'impression que tu passes complètement à côté de la problématique, ça me fait un peu peur.

Le but, ça n'est pas d'avoir un gestionnaire de version pour foutre du code dedans (Merci, j'ai déjà.), mais d'avoir accès à celui du site, du code déployé en production, pour éviter/remonter les multiples problèmes que le fait d'avoir uniquement une tarball engendrent.

Libre a eux de réintégrer les modif dans leur version après.

1. Super, tu as du code corrigé, mais il n'est pas déployé sur le site de l'AE. Au mieux, ce sera peut-être intégré, au pire, ça servira pour voir où sont les trous qui ne sont pas bouchés.
2. Super, tu vas devoir le maintenir synchronisé à la main parce qu'il n'y a toujours pas d'accès au SVN.

Tu veux en faire quoi de ton dépôt SVN ? Monter ton site de l'AE dans ton coin ?

Certes le SVN n'a pas encore été ouvert, mais ce qui me fait bien rigolé, c'est que malgré tous les problèmes que tu as trouvés (comme ton XSS de la page précédente), tu n'ai encore rien proposé à l'équipe info pour les corriger. Pour quelles raisons exactement?

Certes ce serait mieux que le SVN soit ouvert (ca je crois avoir compris), mais ne serait-il pas plus important de corriger ces problèmes?

Certes le SVN n’a pas encore été ouvert, mais ce qui me fait bien rigolé, c’est que malgré tous les problèmes que tu as trouvés (comme ton XSS de la page précédente), tu n’ai encore rien proposé à l’équipe info pour les corriger. Pour quelles raisons exactement?

Parce que ça devrait être fait depuis longtemps et que se foutre de moi ne me pousse ni à être sympa ni coopératif.

Certes ce serait mieux que le SVN soit ouvert (ca je crois avoir compris), mais ne serait-il pas plus important de corriger ces problèmes?

Tu as dit que personne à part moi ne regardait le code, alors ça devrait aller. Ça fait deux jours que la faille est publique, elle n'a toujours pas été corrigée; c'est pourquoi je doute qu'en faire remonter d'autres accélère leur correction.

Dustri

Parce [...] que se foutre de moi ne me pousse ni à être sympa ni coopératif.

Juste une question qui n'a rien à voire et par pure curiosité : ça ne te choque pas de sortir ça après le ton que tu utilises pour signaler un problème ?