Bonjour,
je viens de lire sur fcs le fil "[Long] Pratiques de codage php et
webapps" (nov/déc 2004), très intéressant.
<HS, présentation du contexte>
J'ai écrit un cgi en Perl pour un intranet (donc 'a priori' pas de pb de
sécurité ha! ha! :-) Je viens de tenter de le sécuriser avec l'option
-T de Perl, je me heurte à quelques problèmes comme le refus de
$mon_rep = `pwd`; ("dans quel répertoire suis-je ?") ainsi que d'autres
liés aux modules que j'utilise (ie File::Temp).
</HS>
Ma question, amha indépendante de Perl :
Mes "formulaires" se résument à des boutons "submit", des boutons-radio
et des images cliquables (image.x, image.y)
Quels seraient d'après vous les problèmes potentiel ?
Si besoin d'explications supplémentaires :
- les "images cliquables" sont des cartes géographiques sur lesquelles
les coordonnées (image.x, image.y) permettent de retrouver les
coordonnées géographiques.
- les boutons-radio permettent un choix (du cgi) entre deux réponses
- les boutons "submit" renvoient leur "valeur faciale" (une
coordonnée-temps)
<HS, présentation du contexte> J'ai écrit un cgi en Perl pour un intranet (donc 'a priori' pas de pb de sécurité
Bof... Un p'tit troyen sur une des machines de ton intranet et zou, plus aucune barrière entre intranet et Internet.
-T de Perl, je me heurte à quelques problèmes comme le refus de $mon_rep = `pwd`; ("dans quel répertoire suis-je ?")
Surtout, "exécuter une commande du shell". Je ne connais pas Perl, mais en "safe mode" PHP, c'est interdit. Entre deux méthodes pour obtenir le résultat, une franchement crade[*] et une propre et officielle, utiliser la deuxième améliore la fiabilité, la sécurité et la portabilité de ton programme. N'hésite pas à lire le manuel de Perl.
[*] Il doit être possible de faire plus crade. Par exemple, lancer Debug.exe pour appeler la fonction 47h de l'interruption 21h.
Ma question, amha indépendante de Perl : Mes "formulaires" se résument à des boutons "submit", des boutons-radio et des images cliquables (image.x, image.y) Quels seraient d'après vous les problèmes potentiel ?
Aucun (pour toi) de ce côté : c'est au client de décider si tu es digne de confiance ou pas, et, si oui, d'aller sur ton site. J'imagine que dans un Intranet, la question ne se pose pas vraiment.
Le problème se pose plutôt côté serveur, i.e. côté script Perl. Et en voyant ton "`pwd`", je n'ose imaginer le reste du code... Il va falloir que quelqu'un relise ton code et pointe tous les coups foireux dans le même style. Une fois que tu auras réparé tout ça, et obtenu un code à peu près propre, tu pourras commencer à travailler sérieusement sur la sécurité du script.
-- ;-)
On 19 Mar 2005 21:49:35 GMT, Jean-Pierre Vidal
<jeanpierre.vidal@free.fr>:
<HS, présentation du contexte>
J'ai écrit un cgi en Perl pour un intranet (donc 'a priori' pas de pb de
sécurité
Bof... Un p'tit troyen sur une des machines de ton intranet et zou,
plus aucune barrière entre intranet et Internet.
-T de Perl, je me heurte à quelques problèmes comme le refus de
$mon_rep = `pwd`; ("dans quel répertoire suis-je ?")
Surtout, "exécuter une commande du shell". Je ne connais pas Perl,
mais en "safe mode" PHP, c'est interdit.
Entre deux méthodes pour obtenir le résultat, une franchement crade[*]
et une propre et officielle, utiliser la deuxième améliore la
fiabilité, la sécurité et la portabilité de ton programme.
N'hésite pas à lire le manuel de Perl.
[*] Il doit être possible de faire plus crade. Par exemple, lancer
Debug.exe pour appeler la fonction 47h de l'interruption 21h.
Ma question, amha indépendante de Perl :
Mes "formulaires" se résument à des boutons "submit", des boutons-radio
et des images cliquables (image.x, image.y)
Quels seraient d'après vous les problèmes potentiel ?
Aucun (pour toi) de ce côté : c'est au client de décider si tu es
digne de confiance ou pas, et, si oui, d'aller sur ton site. J'imagine
que dans un Intranet, la question ne se pose pas vraiment.
Le problème se pose plutôt côté serveur, i.e. côté script Perl. Et en
voyant ton "`pwd`", je n'ose imaginer le reste du code...
Il va falloir que quelqu'un relise ton code et pointe tous les coups
foireux dans le même style. Une fois que tu auras réparé tout ça, et
obtenu un code à peu près propre, tu pourras commencer à travailler
sérieusement sur la sécurité du script.
<HS, présentation du contexte> J'ai écrit un cgi en Perl pour un intranet (donc 'a priori' pas de pb de sécurité
Bof... Un p'tit troyen sur une des machines de ton intranet et zou, plus aucune barrière entre intranet et Internet.
-T de Perl, je me heurte à quelques problèmes comme le refus de $mon_rep = `pwd`; ("dans quel répertoire suis-je ?")
Surtout, "exécuter une commande du shell". Je ne connais pas Perl, mais en "safe mode" PHP, c'est interdit. Entre deux méthodes pour obtenir le résultat, une franchement crade[*] et une propre et officielle, utiliser la deuxième améliore la fiabilité, la sécurité et la portabilité de ton programme. N'hésite pas à lire le manuel de Perl.
[*] Il doit être possible de faire plus crade. Par exemple, lancer Debug.exe pour appeler la fonction 47h de l'interruption 21h.
Ma question, amha indépendante de Perl : Mes "formulaires" se résument à des boutons "submit", des boutons-radio et des images cliquables (image.x, image.y) Quels seraient d'après vous les problèmes potentiel ?
Aucun (pour toi) de ce côté : c'est au client de décider si tu es digne de confiance ou pas, et, si oui, d'aller sur ton site. J'imagine que dans un Intranet, la question ne se pose pas vraiment.
Le problème se pose plutôt côté serveur, i.e. côté script Perl. Et en voyant ton "`pwd`", je n'ose imaginer le reste du code... Il va falloir que quelqu'un relise ton code et pointe tous les coups foireux dans le même style. Une fois que tu auras réparé tout ça, et obtenu un code à peu près propre, tu pourras commencer à travailler sérieusement sur la sécurité du script.
-- ;-)
Jacques Caron
Salut,
On 19 Mar 2005 21:49:35 GMT, Jean-Pierre Vidal wrote:
Ma question, amha indépendante de Perl : Mes "formulaires" se résument à des boutons "submit", des boutons-radio et des images cliquables (image.x, image.y) Quels seraient d'après vous les problèmes potentiel ?
Le problème c'est le fait de croire que le seul moyen d'accéder à ton script c'est d'utiliser le formulaire en question, alors que n'importe quel script kiddie sait modifier une URL (si le formulaire est soumis en GET) ou créer un formulaire "alternatif" qui appellera ton script (ça marche dans tous les cas). S'il est un peu plus évolué, le script kiddie pourra même jusqu'à utiliser un outil comme curl (voire libcurl), ou même envoyer une requête de son choix avec telnet.
Bref, le script ne doit pas "faire confiance" au formulaire, et éviter tous les pièges habituels.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 19 Mar 2005 21:49:35 GMT, Jean-Pierre Vidal <jeanpierre.vidal@free.fr>
wrote:
Ma question, amha indépendante de Perl :
Mes "formulaires" se résument à des boutons "submit", des boutons-radio
et des images cliquables (image.x, image.y)
Quels seraient d'après vous les problèmes potentiel ?
Le problème c'est le fait de croire que le seul moyen d'accéder à ton
script c'est d'utiliser le formulaire en question, alors que n'importe
quel script kiddie sait modifier une URL (si le formulaire est soumis en
GET) ou créer un formulaire "alternatif" qui appellera ton script (ça
marche dans tous les cas). S'il est un peu plus évolué, le script kiddie
pourra même jusqu'à utiliser un outil comme curl (voire libcurl), ou même
envoyer une requête de son choix avec telnet.
Bref, le script ne doit pas "faire confiance" au formulaire, et éviter
tous les pièges habituels.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On 19 Mar 2005 21:49:35 GMT, Jean-Pierre Vidal wrote:
Ma question, amha indépendante de Perl : Mes "formulaires" se résument à des boutons "submit", des boutons-radio et des images cliquables (image.x, image.y) Quels seraient d'après vous les problèmes potentiel ?
Le problème c'est le fait de croire que le seul moyen d'accéder à ton script c'est d'utiliser le formulaire en question, alors que n'importe quel script kiddie sait modifier une URL (si le formulaire est soumis en GET) ou créer un formulaire "alternatif" qui appellera ton script (ça marche dans tous les cas). S'il est un peu plus évolué, le script kiddie pourra même jusqu'à utiliser un outil comme curl (voire libcurl), ou même envoyer une requête de son choix avec telnet.
Bref, le script ne doit pas "faire confiance" au formulaire, et éviter tous les pièges habituels.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Jean-Pierre Vidal
Le Sun, 20 Mar 2005 03:29:23 +0000, Fabien LE LEZ a écrit :
Surtout, "exécuter une commande du shell". Je ne connais pas Perl, mais en "safe mode" PHP, c'est interdit.
Je suis bien d'accord avec toi, et je sais qu'il ne faut pas utiliser d'appel direct au shell, d'ailleurs dans mon code le `pwd` était commenté par un "pas mieux pour le moment". J'expliquais seulement que je suis en train de le nettoyer en activant l'option -T qui doit être le pendant du "safe mode" PHP. Je débute en programmation "côté serveur", je teste sur un serveur qui n'écoute que 127.0.0.1:80. Merci toutefois pour les liens, j'ai un peu honte de ne pas avoir trouvé tout seul "perl+get+current+directory" pour trouver une fonction qui n'existe pas nativement en Perl (le manuel Perl, je le connais, et j'avais cherché :).
Mon interrogation était formulée plus loin :
Quels seraient d'après vous les problèmes potentiel ? (sous-entendu : il n'y a pas de zone de saisie de texte dans les
"formulaires") et tu y as répondu en partie :
Aucun (pour toi) de ce côté [...]
Le problème se pose plutôt côté serveur, i.e. côté script Perl.
Jean-Pierre
Le Sun, 20 Mar 2005 03:29:23 +0000, Fabien LE LEZ a écrit :
Surtout, "exécuter une commande du shell". Je ne connais pas Perl,
mais en "safe mode" PHP, c'est interdit.
Je suis bien d'accord avec toi, et je sais qu'il ne faut pas utiliser
d'appel direct au shell, d'ailleurs dans mon code le `pwd` était
commenté par un "pas mieux pour le moment". J'expliquais seulement que je
suis en train de le nettoyer en activant l'option -T qui doit être le
pendant du "safe mode" PHP. Je débute en programmation "côté serveur",
je teste sur un serveur qui n'écoute que 127.0.0.1:80.
Merci toutefois pour les liens, j'ai un peu honte de ne pas avoir trouvé
tout seul "perl+get+current+directory" pour trouver une fonction qui
n'existe pas nativement en Perl (le manuel Perl, je le connais, et j'avais
cherché :).
Mon interrogation était formulée plus loin :
Quels seraient d'après vous les problèmes potentiel ?
(sous-entendu : il n'y a pas de zone de saisie de texte dans les
"formulaires") et tu y as répondu en partie :
Aucun (pour toi) de ce côté
[...]
Le problème se pose plutôt côté serveur, i.e. côté script Perl.
Le Sun, 20 Mar 2005 03:29:23 +0000, Fabien LE LEZ a écrit :
Surtout, "exécuter une commande du shell". Je ne connais pas Perl, mais en "safe mode" PHP, c'est interdit.
Je suis bien d'accord avec toi, et je sais qu'il ne faut pas utiliser d'appel direct au shell, d'ailleurs dans mon code le `pwd` était commenté par un "pas mieux pour le moment". J'expliquais seulement que je suis en train de le nettoyer en activant l'option -T qui doit être le pendant du "safe mode" PHP. Je débute en programmation "côté serveur", je teste sur un serveur qui n'écoute que 127.0.0.1:80. Merci toutefois pour les liens, j'ai un peu honte de ne pas avoir trouvé tout seul "perl+get+current+directory" pour trouver une fonction qui n'existe pas nativement en Perl (le manuel Perl, je le connais, et j'avais cherché :).
Mon interrogation était formulée plus loin :
Quels seraient d'après vous les problèmes potentiel ? (sous-entendu : il n'y a pas de zone de saisie de texte dans les
"formulaires") et tu y as répondu en partie :
Aucun (pour toi) de ce côté [...]
Le problème se pose plutôt côté serveur, i.e. côté script Perl.
Jean-Pierre
Nicolas George
Jean-Pierre Vidal wrote in message :
J'expliquais seulement que je suis en train de le nettoyer en activant l'option -T qui doit être le pendant du "safe mode" PHP.
Non, ce n'est pas ça. Le safe-mode de PHP considère le code du programme comme potentiellement hostile, et ne lui donne que très peu de possibilités d'accès au système. Ça sert typiquement pour l'hébergement web sans hébergement shell, comme le service de pages web personnelles de la plupart des fournisseurs d'accès. Le pendant de ça dans le monde perl est le module Safe.
Le taint mode de perl considère le code comme digne de confiance, et lui donne naturellement tous les droits (shell, filesystem, sockets, etc.). Ce sont les données issues de l'extérieur qui sont considérées comme potentiellement hostiles, et perl refuse qu'elles soient utilisées comme arguments à certaines fonctions avant d'être vérifiées/nettoyées.
Dans le cas présent, `pwd` utilise implicitement des variables d'environnement, qui sont des données issues de l'extérieur. C'est ça qu'il faut corriger. D'ailleurs, le message d'erreur devrait être quelque chose comme « Insecure $ENV{PATH} while running with -T switch », ce qui est assez clair : la variable d'environnement PATH peut être hostile. Dans le cas d'un CGI ce n'est pas vrai, mais le taint mode sert aussi pour les scripts SUID.
Jean-Pierre Vidal wrote in message
<pan.2005.03.20.14.49.47.732760@free.fr>:
J'expliquais seulement que je
suis en train de le nettoyer en activant l'option -T qui doit être le
pendant du "safe mode" PHP.
Non, ce n'est pas ça. Le safe-mode de PHP considère le code du programme
comme potentiellement hostile, et ne lui donne que très peu de possibilités
d'accès au système. Ça sert typiquement pour l'hébergement web sans
hébergement shell, comme le service de pages web personnelles de la plupart
des fournisseurs d'accès. Le pendant de ça dans le monde perl est le module
Safe.
Le taint mode de perl considère le code comme digne de confiance, et lui
donne naturellement tous les droits (shell, filesystem, sockets, etc.). Ce
sont les données issues de l'extérieur qui sont considérées comme
potentiellement hostiles, et perl refuse qu'elles soient utilisées comme
arguments à certaines fonctions avant d'être vérifiées/nettoyées.
Dans le cas présent, `pwd` utilise implicitement des variables
d'environnement, qui sont des données issues de l'extérieur. C'est ça qu'il
faut corriger. D'ailleurs, le message d'erreur devrait être quelque chose
comme « Insecure $ENV{PATH} while running with -T switch », ce qui est assez
clair : la variable d'environnement PATH peut être hostile. Dans le cas d'un
CGI ce n'est pas vrai, mais le taint mode sert aussi pour les scripts SUID.
J'expliquais seulement que je suis en train de le nettoyer en activant l'option -T qui doit être le pendant du "safe mode" PHP.
Non, ce n'est pas ça. Le safe-mode de PHP considère le code du programme comme potentiellement hostile, et ne lui donne que très peu de possibilités d'accès au système. Ça sert typiquement pour l'hébergement web sans hébergement shell, comme le service de pages web personnelles de la plupart des fournisseurs d'accès. Le pendant de ça dans le monde perl est le module Safe.
Le taint mode de perl considère le code comme digne de confiance, et lui donne naturellement tous les droits (shell, filesystem, sockets, etc.). Ce sont les données issues de l'extérieur qui sont considérées comme potentiellement hostiles, et perl refuse qu'elles soient utilisées comme arguments à certaines fonctions avant d'être vérifiées/nettoyées.
Dans le cas présent, `pwd` utilise implicitement des variables d'environnement, qui sont des données issues de l'extérieur. C'est ça qu'il faut corriger. D'ailleurs, le message d'erreur devrait être quelque chose comme « Insecure $ENV{PATH} while running with -T switch », ce qui est assez clair : la variable d'environnement PATH peut être hostile. Dans le cas d'un CGI ce n'est pas vrai, mais le taint mode sert aussi pour les scripts SUID.
Jean-Pierre Vidal
Le Sun, 20 Mar 2005 13:09:21 +0000, Jacques Caron a écrit :
Bref, le script ne doit pas "faire confiance" au formulaire, et éviter tous les pièges habituels.
Je crois avoir compris : m'assurer que tous les arguments venant du formulaire sont inclus dans la fourchette (l'ensemble) que j'attends, y compris et surtout (je n'en avais pas parlé) ceux que j'ai caché dans un champ "hidden" de la page html, pour usage ultérieur : Merci Jean-Pierre
Le Sun, 20 Mar 2005 13:09:21 +0000, Jacques Caron a écrit :
Bref, le script ne doit pas "faire confiance" au formulaire, et éviter
tous les pièges habituels.
Je crois avoir compris : m'assurer que tous les arguments venant du
formulaire sont inclus dans la fourchette (l'ensemble) que j'attends, y
compris et surtout (je n'en avais pas parlé) ceux que j'ai caché dans un
champ "hidden" de la page html, pour usage ultérieur : Merci
Jean-Pierre
Le Sun, 20 Mar 2005 13:09:21 +0000, Jacques Caron a écrit :
Bref, le script ne doit pas "faire confiance" au formulaire, et éviter tous les pièges habituels.
Je crois avoir compris : m'assurer que tous les arguments venant du formulaire sont inclus dans la fourchette (l'ensemble) que j'attends, y compris et surtout (je n'en avais pas parlé) ceux que j'ai caché dans un champ "hidden" de la page html, pour usage ultérieur : Merci Jean-Pierre
Nicob
On Sun, 20 Mar 2005 19:41:46 +0000, Jean-Pierre Vidal wrote:
Je crois avoir compris : m'assurer que tous les arguments venant du formulaire sont inclus dans la fourchette (l'ensemble) que j'attends, y compris et surtout (je n'en avais pas parlé) ceux que j'ai caché dans un champ "hidden" de la page html, pour usage ultérieur
C'est à peu près ça. Si tu attends un entier situé entre 1 et 10, il faut faire la vérif avant d'utiliser la variable. Et c'est pareil pour les chaines de texte. Ah oui, il faut aussi bien faire gaffe aux fonctionnalités "dangereuses" de Perl (null-byte, exécution de commande via open, ...)
Si tu peux diffuser le code de ton CGI, ce pourrait être l'occasion de faire une analyse commentée du biniou ...
Nicob
On Sun, 20 Mar 2005 19:41:46 +0000, Jean-Pierre Vidal wrote:
Je crois avoir compris : m'assurer que tous les arguments venant du
formulaire sont inclus dans la fourchette (l'ensemble) que j'attends, y
compris et surtout (je n'en avais pas parlé) ceux que j'ai caché dans un
champ "hidden" de la page html, pour usage ultérieur
C'est à peu près ça. Si tu attends un entier situé entre 1 et 10, il
faut faire la vérif avant d'utiliser la variable. Et c'est pareil pour
les chaines de texte. Ah oui, il faut aussi bien faire gaffe aux
fonctionnalités "dangereuses" de Perl (null-byte, exécution de commande
via open, ...)
Si tu peux diffuser le code de ton CGI, ce pourrait être l'occasion de
faire une analyse commentée du biniou ...
On Sun, 20 Mar 2005 19:41:46 +0000, Jean-Pierre Vidal wrote:
Je crois avoir compris : m'assurer que tous les arguments venant du formulaire sont inclus dans la fourchette (l'ensemble) que j'attends, y compris et surtout (je n'en avais pas parlé) ceux que j'ai caché dans un champ "hidden" de la page html, pour usage ultérieur
C'est à peu près ça. Si tu attends un entier situé entre 1 et 10, il faut faire la vérif avant d'utiliser la variable. Et c'est pareil pour les chaines de texte. Ah oui, il faut aussi bien faire gaffe aux fonctionnalités "dangereuses" de Perl (null-byte, exécution de commande via open, ...)
Si tu peux diffuser le code de ton CGI, ce pourrait être l'occasion de faire une analyse commentée du biniou ...
Nicob
Jean-Pierre Vidal
Le Mon, 21 Mar 2005 09:26:59 +0000, Nicob a écrit| :
Si tu peux diffuser le code de ton CGI, ce pourrait être l'occasion de faire une analyse commentée du biniou ...
J'ai tenté de répondre en privé, voici la réponse publique :
Je pense pouvoir diffuser le code, je considère qu'il m'appartient. De plus, il s'agit d'un script, ce n'est pas la meilleure façon de se cacher :)
Mais :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont ~400 en rapport avec le cgi)
2 - rien qu'avec ce que j'ai appris dans ce fil, j'ai un certain nombre de corrections à apporter, nombre qui est sans constestation possible à deux chiffres.
Donc, si je le livre tel que, je m'expose à des remarques du style "ouaf ! ouaf ! t'as vu comment il programme le mec ?", voir la première réaction à mon post. (et il y a mon ego...)
Et, donc : - soit je le poste "en l'état", dans un but didactique que je comprends (j'aurais moi-même été friand d'un tel fil) - soit je poste dans 1 (jour | semaine | mois) une version "nettoyée" en fonction de ce que j'ai appris.
Ton avis ?
Jean-Pierre
Le Mon, 21 Mar 2005 09:26:59 +0000, Nicob a écrit| :
Si tu peux diffuser le code de ton CGI, ce pourrait être l'occasion de
faire une analyse commentée du biniou ...
J'ai tenté de répondre en privé, voici la réponse publique :
Je pense pouvoir diffuser le code, je considère qu'il m'appartient. De
plus, il s'agit d'un script, ce n'est pas la meilleure façon de se cacher :)
Mais :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont
~400 en rapport avec le cgi)
2 - rien qu'avec ce que j'ai appris dans ce fil, j'ai un certain nombre de
corrections à apporter, nombre qui est sans constestation possible à
deux chiffres.
Donc, si je le livre tel que, je m'expose à des remarques du style "ouaf
! ouaf ! t'as vu comment il programme le mec ?", voir la première
réaction à mon post. (et il y a mon ego...)
Et, donc :
- soit je le poste "en l'état", dans un but didactique que je comprends
(j'aurais moi-même été friand d'un tel fil)
- soit je poste dans 1 (jour | semaine | mois) une version "nettoyée" en
fonction de ce que j'ai appris.
Le Mon, 21 Mar 2005 09:26:59 +0000, Nicob a écrit| :
Si tu peux diffuser le code de ton CGI, ce pourrait être l'occasion de faire une analyse commentée du biniou ...
J'ai tenté de répondre en privé, voici la réponse publique :
Je pense pouvoir diffuser le code, je considère qu'il m'appartient. De plus, il s'agit d'un script, ce n'est pas la meilleure façon de se cacher :)
Mais :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont ~400 en rapport avec le cgi)
2 - rien qu'avec ce que j'ai appris dans ce fil, j'ai un certain nombre de corrections à apporter, nombre qui est sans constestation possible à deux chiffres.
Donc, si je le livre tel que, je m'expose à des remarques du style "ouaf ! ouaf ! t'as vu comment il programme le mec ?", voir la première réaction à mon post. (et il y a mon ego...)
Et, donc : - soit je le poste "en l'état", dans un but didactique que je comprends (j'aurais moi-même été friand d'un tel fil) - soit je poste dans 1 (jour | semaine | mois) une version "nettoyée" en fonction de ce que j'ai appris.
Ton avis ?
Jean-Pierre
Stephane Catteau
Jean-Pierre Vidal nous disait récement dans fr.comp.securite <news: :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont ~400 en rapport avec le cgi)
Ce n'est pas tant le nombre de lignes qui importe ici, que le faible rapport avec le thème du forum. Donc si tu veux le publier, maintenant ou plus tard, je pense que le mieux est encore de le faire dans le forum <news://fr.comp.lang.perl>, quitte à revenir ensuite ici pour parler des points/problèmes en rapport avec la sécurité informatique.
-- Stéphane Catteau Co-modérateur de fr.comp.securite Pour joindre l'équipe de modération <mailto: Les conseils d'utilisation <http://fr.comp.securite.free.fr/cu.php>
Jean-Pierre Vidal nous disait récement dans fr.comp.securite
<news:pan.2005.03.21.19.57.33.801659@free.fr> :
1 - je crains de me faire jeter par les modérateurs (~600 lignes,
dont ~400 en rapport avec le cgi)
Ce n'est pas tant le nombre de lignes qui importe ici, que le faible
rapport avec le thème du forum. Donc si tu veux le publier, maintenant
ou plus tard, je pense que le mieux est encore de le faire dans le
forum <news://fr.comp.lang.perl>, quitte à revenir ensuite ici pour
parler des points/problèmes en rapport avec la sécurité informatique.
--
Stéphane Catteau Co-modérateur de fr.comp.securite
Pour joindre l'équipe de modération <mailto:fcs-mod@moderos.fr.eu.org>
Les conseils d'utilisation <http://fr.comp.securite.free.fr/cu.php>
Jean-Pierre Vidal nous disait récement dans fr.comp.securite <news: :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont ~400 en rapport avec le cgi)
Ce n'est pas tant le nombre de lignes qui importe ici, que le faible rapport avec le thème du forum. Donc si tu veux le publier, maintenant ou plus tard, je pense que le mieux est encore de le faire dans le forum <news://fr.comp.lang.perl>, quitte à revenir ensuite ici pour parler des points/problèmes en rapport avec la sécurité informatique.
-- Stéphane Catteau Co-modérateur de fr.comp.securite Pour joindre l'équipe de modération <mailto: Les conseils d'utilisation <http://fr.comp.securite.free.fr/cu.php>
Cedric Blancher
Le Mon, 21 Mar 2005 21:11:16 +0000, Jean-Pierre Vidal a écrit :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont ~400 en rapport avec le cgi)
Pourquoi pas le mettre en ligne sur un site web et poster un lien ?
--
A l'heure actuelle, il s'est formé une sorte "d'aristocratie" de Linux qui essaye de maintenir ses connaissances pour elles et d'en priver les autres en innondant chaque débutant de documentations -+- EF in Guide du liuxien pervers : "Comprenne qui pourra..." -+-
Le Mon, 21 Mar 2005 21:11:16 +0000, Jean-Pierre Vidal a écrit :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont
~400 en rapport avec le cgi)
Pourquoi pas le mettre en ligne sur un site web et poster un lien ?
--
A l'heure actuelle, il s'est formé une sorte "d'aristocratie" de Linux
qui essaye de maintenir ses connaissances pour elles et d'en priver les
autres en innondant chaque débutant de documentations
-+- EF in Guide du liuxien pervers : "Comprenne qui pourra..." -+-
Le Mon, 21 Mar 2005 21:11:16 +0000, Jean-Pierre Vidal a écrit :
1 - je crains de me faire jeter par les modérateurs (~600 lignes, dont ~400 en rapport avec le cgi)
Pourquoi pas le mettre en ligne sur un site web et poster un lien ?
--
A l'heure actuelle, il s'est formé une sorte "d'aristocratie" de Linux qui essaye de maintenir ses connaissances pour elles et d'en priver les autres en innondant chaque débutant de documentations -+- EF in Guide du liuxien pervers : "Comprenne qui pourra..." -+-
Fabien LE LEZ
On 21 Mar 2005 21:11:16 GMT, Jean-Pierre Vidal :
- soit je poste dans 1 (jour | semaine | mois) une version "nettoyée" en fonction de ce que j'ai appris.
Mieux vaut effectivement publier une version corrigée, ça évitera que dix personnes pointent toutes les erreurs évidentes... Note que si le script est long, tu peux le mettre en téléchargement sur un site plutôt que de le poster. Note aussi que pour corriger les erreurs n'ayant pas de rapport direct avec la sécurité, fr.comp.lang.perl est ton ami.
-- ;-)
On 21 Mar 2005 21:11:16 GMT, Jean-Pierre Vidal
<jeanpierre.vidal@free.fr>:
- soit je poste dans 1 (jour | semaine | mois) une version "nettoyée" en
fonction de ce que j'ai appris.
Mieux vaut effectivement publier une version corrigée, ça évitera que
dix personnes pointent toutes les erreurs évidentes...
Note que si le script est long, tu peux le mettre en téléchargement
sur un site plutôt que de le poster.
Note aussi que pour corriger les erreurs n'ayant pas de rapport direct
avec la sécurité, fr.comp.lang.perl est ton ami.
- soit je poste dans 1 (jour | semaine | mois) une version "nettoyée" en fonction de ce que j'ai appris.
Mieux vaut effectivement publier une version corrigée, ça évitera que dix personnes pointent toutes les erreurs évidentes... Note que si le script est long, tu peux le mettre en téléchargement sur un site plutôt que de le poster. Note aussi que pour corriger les erreurs n'ayant pas de rapport direct avec la sécurité, fr.comp.lang.perl est ton ami.
