J'utilise uniquement Jabber et les transports. Pour autant que je sache, il n'existe pas encore de moyen de transférer des fichiers avec les clients MSN/ICQ/... en utilisant les transports donc voilà. L'avantage c'est que je peux utiliser une seule connexion SSL pour me connecter à toutes mes adresses d'IM. Vu que je passe la moitié de mon temps sur un réseau non switché où tout le monde peut sniffer ce qu'il veut, je trouve ça assez pratique (bon ça serait switché ça serait presque pareil).
Pour en revenir à cette histoire de mdp, si tu as gardé le même fonctionnement, pas besoin d'utiliser de mdp. Le seul "secret" à connaitre est l'url. Pour protéger les répertoires, le htaccess est probablement la meilleure solution. Je pense que ça le fait même récursivement.
Le délais de 3 secondes empéche rien: qqun peut brute-forcer tranquillement avec X connexions en paralléle, il aura juste les résultat de chacune 3 secondes plus tard mais rien ne l'empèche de refaire une requète avant que le délais se soit écoulé. Et en fait il a même pas besoin de faire ça, il a juste à "brute-forcer" l'url.
Un truc plus "sécurisé" serait de faire une page PHP qui prend 2 paramètres: le mdp et le fichier à accéder. Si le mdp est correct mais que le fichier à accéder n'existe pas, tu "fournis" un listing des fichiers. Si le mdp est correct et le fichier existe, tu renvois directement le fichier. De cette manière tu peux interdire complétement l'accés aux fichiers directement via Apache: on ne peut y accéder que par l'interface web. Mais il faut faire très attention aux fichiers accessibles (gaffe aux trucs genre .. et liens symboliques). Idéalement tu devrais avoir le listing des fichiers accessibles défini explicitement dans un fichier de configuration par exemple.
Ce genre de script existe déjà, suffit de chercher un peu. Enfin pour le mdp je suis pas sur mais ça tu peux le rajouter au niveau d'Apache et comme ça tu n'as qu'une seule page à protéger.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si j'ai bien compris, tu veux vérifier le mdp et rediriger la personne vers une page à l'url "impossible à deviner" s'il est correct. C'est pas la bonne manière de faire. Si tu penses vraiment que ton url peut rester "secret", autant donner l'url comme mdp, pas besoin de te casser la tête avec PHP et ça sera pas moins sécurisé. Ca le sera même plus si la "difficulté" du mdp est moindre que celle de l'url. Si elle l'est plus, c'est le mdp qui sert à rien.
Maintenant si tu veux un "vrai" accés par mdp, tu vas devoir soit tout mettre dans la même page PHP protégée par elle même (affichage de la page uniquement si le mdp est correct, pas moyen de contourner comme c'est le cas dans ton exemple), soit utiliser les sessions et les cookies pour protéger les autres pages (accès que si le cookie est bon et le cookie ne peut être mis que par la page de login, ou un truc comme ça, j'ai jamais touché à ça), soit utiliser une protection au niveau d'Apache comme suggéré plus haut, qui va te permettre de protéger tout le répertoire du même coup.
A mon avis, la solution la plus facile/rapide à mettre en place est celle des htaccess. C'est pas plus compliqué que ta solution, ça l'est même moins: t'as pas à faire de PHP, t'as juste à maintenir un fichiers d'utilisateurs/mdp. Si tu veux tu peux t'amuser à faire une interface PHP pour gérer le fichier. Si tu veux vraiment pas avoir à taper un login mais juste un mdp, alors amuse toi avec les sessions/cookies ou intégre tout dans la même page si c'est possible.
Pour le problème du brute-force. Avec le système actuel, le méchant n'a qu'à brute-forcer un URL ou un mdp, le plus faible des deux. Avec le htaccess, il doit brute-forcer un login+mdp (en admettant que le login reste "secret" aussi). De toute façon toute application de ce genre est "brute-forçable". Si tu penses que ça en vaut la peine, tu as plusieurs solutions pour limiter les risques. Le plus simple est probablement de bien choisir le mdp, après tu peux t'arranger pour qu'on ne puisse pas faire plus de X tentatives de login par heure (mais pas avec des cookies, du JS ou autre truc "client-side", dans ce cas ça sert à rien et ça fait chier les visiteurs) ou commencer à chercher un système d'authentification plus correct (à coups de PGP/SSL/TLS/... par exemples) mais ça devient tout de suite plus lourd. Yavait un article sur l'authentification par mdp dans le Linux Magazine France du mois dernier je pense (si qqun avec le magazine sous la main peut confirmer...). Ca peut peut-être t'intéresser.
Personnellement, j'ai un serveur FTP avec un compte "invité" qui me sert de temps en temps ("hé pq je peux pas t'envoyer de fichiers par MSN?"). Le mdp change aléatoirement toutes les X heures et il est enregistré dans un fichier auquel moi seul ai accés. Avec ça, bonne chance pour le brute-force. Faut voir si ça peut être applicable à ton cas. Dans le même genre, voir http://slashdot.org/comments.pl?sid=111503&cid=9469343(...)
Le mdp est généré par exemple par un md5 de la somme de l'heure actuelle et du "vrai" mdp (une truc plus correct serait genre md5(md5(time).md5(passwd)), le "." pour la concaténation). Comme ça, toute personne qui a le "vrai" mdp peut reconstituer le mdp actuel mais il change toutes les X heures/minutes. Tu peux aussi t'arranger pour que le mdp change après que qqun se soit loggué, comme ça si la connexion est sniffée, l'attaquant ne sait quand même pas obtenir le mdp puisqu'il a déjà changé (mais bon dans ce cas tu as d'autres problèmes).
Par ailleurs je recommande la lecture de cet article-ci à tous ceux qui débutent dans les applications web (et ça peut surement pas faire de mal à ceux qui en font déjà depuis un moment): http://www.linux-mag.com/2002-09/security_01.html(...)
Ba la tour Montparnasse Infernale entre potes en fin de soirée après une cuite ça passe encore. Mais c'est vrai qu'à jeun c'est assez lourd (même apès 12h de LAN).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Pour info ext3 c'est "juste" ext2+journalisation. Donc ça veut dire que si tu sais accéder à du ext2, tu sais accéder à du ext3 (ça sera juste un peu moins fiable puisque la journalisation ne sera pas activée).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
perso je n'ai pas envie de partager des fichiers a contenu ethiquement inacceptable. De plus legalement, je pense que tu es tout de meme responsable du contenu de ton disque dur, bref ca ne me tente pas.
C'est pas parce que eDonkey ne te tente pas que c'est pas utilisé non plus :)
et puis tout se casse :)
C'est pour ça que j'ai mis "impossible" entre guillemets. Je suis pas cryptologiste (logue?graphe?) mais pour ce que j'en ai compris, pour savoir qui partage quoi sur Freenet, c'est vraiment pas facile. Même avec des moyens conséquents..
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Soit tu livres tes cles dans la minute soit tu es tres mal barré.
Il est possible de faire un système de fichiers avec plusieurs niveaux de clés de telle manière qui soit "impossible" de savoir si tout a été décrypté ou s'il reste des données cryptées. Enfin si je me souviens bien de ce que j'ai lu là: http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf(...)
(oui je sais il parait qu'on doit dire chiffrer et pas crypter)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'utilise le même 17'' depuis plusieurs années et j'ai fait qq dizaines de LAN avec sans problème. Et pour une LAN tu laisses pas le moniteur s'acclimater 24h avant de l'allumer.
Si c'est parce que j'ai eu de la chance faut croire que (presque) tous ceux avec qui j'ai fait des LAN ont de la chance aussi alors. J'ai jamais vu qu'un seul cramage de moniteur (et c'était pas juste le moniteur, à mon avis c'était plutôt un problème d'alimentation).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Pour autant que je sache, la db de journaux/commentaires de DLFP ne contient pas une table juste pour les liens donc tu devrais quand même faire du parsing même avec un accès à la base. A moins de commencer à mettre une table pour les liens+description+mots clés qui serait complétée à chaque ajout d'un commentaire/journal, ce qui nécessite encore plus de travail mais c'est vrai que c'est surement la solution la plus "propre". Si ça t'intéresse, je pense que rien ne t'empèche de contacter les admins pour leur proposer l'idée et voir si ça peut être intégré si tu codes le patch. Ca sera aussi plus propre et efficace qu'un cron qui collecte tous les liens une fois par semaine :)
Pour la recherche par mots clés le pauvre serveur va peut être pas supporter mais pour le listing de liens ça ne devrait pas poser de problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
franchement le jour ou l'on voudra arreter le "piratage", tu peux me croire ce sera tres vite fait. les problemes sont juridiques, pas techniques, et la legislation est en train de s'adapter au piratage massif.
Ben y parait quand même qu'avec Freenet (yen a d'autres mais j'ai pas les noms sous la main), il est "impossible" de déterminer ce que tu upload/download. La solution technique ça serait de bloquer tout le traffic Freenet (en admettant qu'il soit reconnaissable) mais bon...
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Quand tu veux porter plainte contre quelqu'un dont tu connais uniquement l'IP, je pense que tu es censé porter plainte contre X et l'IP est "juste" un indice. Après si la justice juge que c'est nécessaire, elle va demander à l'ISP de lui donner l'identité de la personne qui utilisait l'IP au moment des faits. Mais faut quand même prouver que cette personne a bien fait qq chose d'illégal. Des logs c'est pas des preuves pour autant que je sache. Pas plus qu'une photo ou une vidéo.
Mais bon JNSPJ :op
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ca m'étonnerait quand même que ça soit pas fait exprès. Personnellement j'aime pas trop non plus, surtout quand (presque) tous les noms propres sont en rouge. Ca serait intéressant de faire un peu évoluer le dictionnaire DLFP. Genre que les modérateurs/relecteurs puissent ajouter des mots qui sont passés dans une dépèche par exemple.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si t'es le seul à aspirer tous les journaux, ça devrait pas poser trop de problèmes et si tu fais ça bien t'as pas besoin de tout aspirer à chaque fois. S'il y a bcp de monde qui commence à pomper, le patch devient légitime. Tu peux aussi faire en sorte que le script cherche dans le cache de ton navigateur plutôt que directement sur le site.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si l'idée c'est de récupérer tous les liens qui sont passés dans les journaux, tu n'as pas besoin d'attendre que qqun de DLFP le fasse. Tu peux écrire un script qui va collecter les liens et les stocker comme tu veux assez facilement (Perl+LWP+HTML::Parser sont tes amis). Après tu peux aussi faire un patch pour DLFP pour qu'à chaque nouveau journal, tous les liens soient stockés qq part mais tu peux aussi bien monter ta propre page qui liste tous les liens que ton bot aura récupéré.
Le problème c'est plutôt le tri des liens après et ça c'est pas très automatisable. A moins qu'à chaque lien on doive mettre une description et des mots clés ou un truc du genre.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Il parait que jadis tout le monde avait une adresse fixe.
Pour autant que je sache, les informations que récupèrent les majors sur les réseaux P2P sont distribuées publiquement et volontairement. Pas besoin de sniffer quoi que ce soit. Quand tu partages des fichiers sur un réseau P2P "classique", tu es censé savoir que n'importe qui peut associer ton adresse IP aux fichiers que tu partages. C'est pas une information confidentielle et en faire une base de données n'est probablement pas illégal. Tant que les ISP ne laissent pas n'importe qui retrouver la personne qui utilise une adresse IP donnée, je ne vois pas trop le problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'ai pas fait grand chose avec les threads et c'était en C donc je vais peut-être dire des bêtises mais il me semble que la notion de thread est indépendante de celle de process (même si l'implémentation Linux génére en fait un process par thread) et on ne peut envoyer un signal qu'à un process, donc il est logique qu'on ne puisse pas envoyer un signal à un thread. Par contre tu peux demander à un thread de s'arréter avec pthread_cancel(). Après tu fais ce que tu veux avec une fonction que tu as passé à pthread_cleanup_push() dans le dit thread par exemple. Enfin tout ça c'est pour les threads POSIX en C, je sais pas si c'est implémenté comme ça en Perl.
[^] # Re: non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 2.
Sinon pour le transfert de fichiers sans FTP/MSN/... -> http://linuxfr.org/tips/296.html(...)
Pour en revenir à cette histoire de mdp, si tu as gardé le même fonctionnement, pas besoin d'utiliser de mdp. Le seul "secret" à connaitre est l'url. Pour protéger les répertoires, le htaccess est probablement la meilleure solution. Je pense que ça le fait même récursivement.
Le délais de 3 secondes empéche rien: qqun peut brute-forcer tranquillement avec X connexions en paralléle, il aura juste les résultat de chacune 3 secondes plus tard mais rien ne l'empèche de refaire une requète avant que le délais se soit écoulé. Et en fait il a même pas besoin de faire ça, il a juste à "brute-forcer" l'url.
Un truc plus "sécurisé" serait de faire une page PHP qui prend 2 paramètres: le mdp et le fichier à accéder. Si le mdp est correct mais que le fichier à accéder n'existe pas, tu "fournis" un listing des fichiers. Si le mdp est correct et le fichier existe, tu renvois directement le fichier. De cette manière tu peux interdire complétement l'accés aux fichiers directement via Apache: on ne peut y accéder que par l'interface web. Mais il faut faire très attention aux fichiers accessibles (gaffe aux trucs genre .. et liens symboliques). Idéalement tu devrais avoir le listing des fichiers accessibles défini explicitement dans un fichier de configuration par exemple.
Ce genre de script existe déjà, suffit de chercher un peu. Enfin pour le mdp je suis pas sur mais ça tu peux le rajouter au niveau d'Apache et comme ça tu n'as qu'une seule page à protéger.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 3.
Maintenant si tu veux un "vrai" accés par mdp, tu vas devoir soit tout mettre dans la même page PHP protégée par elle même (affichage de la page uniquement si le mdp est correct, pas moyen de contourner comme c'est le cas dans ton exemple), soit utiliser les sessions et les cookies pour protéger les autres pages (accès que si le cookie est bon et le cookie ne peut être mis que par la page de login, ou un truc comme ça, j'ai jamais touché à ça), soit utiliser une protection au niveau d'Apache comme suggéré plus haut, qui va te permettre de protéger tout le répertoire du même coup.
A mon avis, la solution la plus facile/rapide à mettre en place est celle des htaccess. C'est pas plus compliqué que ta solution, ça l'est même moins: t'as pas à faire de PHP, t'as juste à maintenir un fichiers d'utilisateurs/mdp. Si tu veux tu peux t'amuser à faire une interface PHP pour gérer le fichier. Si tu veux vraiment pas avoir à taper un login mais juste un mdp, alors amuse toi avec les sessions/cookies ou intégre tout dans la même page si c'est possible.
Pour le problème du brute-force. Avec le système actuel, le méchant n'a qu'à brute-forcer un URL ou un mdp, le plus faible des deux. Avec le htaccess, il doit brute-forcer un login+mdp (en admettant que le login reste "secret" aussi). De toute façon toute application de ce genre est "brute-forçable". Si tu penses que ça en vaut la peine, tu as plusieurs solutions pour limiter les risques. Le plus simple est probablement de bien choisir le mdp, après tu peux t'arranger pour qu'on ne puisse pas faire plus de X tentatives de login par heure (mais pas avec des cookies, du JS ou autre truc "client-side", dans ce cas ça sert à rien et ça fait chier les visiteurs) ou commencer à chercher un système d'authentification plus correct (à coups de PGP/SSL/TLS/... par exemples) mais ça devient tout de suite plus lourd. Yavait un article sur l'authentification par mdp dans le Linux Magazine France du mois dernier je pense (si qqun avec le magazine sous la main peut confirmer...). Ca peut peut-être t'intéresser.
Personnellement, j'ai un serveur FTP avec un compte "invité" qui me sert de temps en temps ("hé pq je peux pas t'envoyer de fichiers par MSN?"). Le mdp change aléatoirement toutes les X heures et il est enregistré dans un fichier auquel moi seul ai accés. Avec ça, bonne chance pour le brute-force. Faut voir si ça peut être applicable à ton cas. Dans le même genre, voir http://slashdot.org/comments.pl?sid=111503&cid=9469343(...)
Le mdp est généré par exemple par un md5 de la somme de l'heure actuelle et du "vrai" mdp (une truc plus correct serait genre md5(md5(time).md5(passwd)), le "." pour la concaténation). Comme ça, toute personne qui a le "vrai" mdp peut reconstituer le mdp actuel mais il change toutes les X heures/minutes. Tu peux aussi t'arranger pour que le mdp change après que qqun se soit loggué, comme ça si la connexion est sniffée, l'attaquant ne sait quand même pas obtenir le mdp puisqu'il a déjà changé (mais bon dans ce cas tu as d'autres problèmes).
Par ailleurs je recommande la lecture de cet article-ci à tous ceux qui débutent dans les applications web (et ça peut surement pas faire de mal à ceux qui en font déjà depuis un moment): http://www.linux-mag.com/2002-09/security_01.html(...)
Pour le coup des md5, vaut mieux comprendre ce qu'on fait avant de l'implémenter. Voir par exemple dans le même magazine: http://www.linux-mag.com/2002-09/cryptography_01.html(...)
-- Krunch le parano
PS: désolé pour les anglicismes et fautes d'orthographes/grammaire mais il est 3h30 passé là
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: je m'insurge
Posté par Krunch (site web personnel) . En réponse au sondage Parmi ces films, le plus naze est. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# supair
Posté par Krunch (site web personnel) . En réponse au journal Le village d'Apt. Évalué à 2.
Quelle vie trépidante nous avons nous les debianeux/euses/istes/ien/iennes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Woody?
Posté par Krunch (site web personnel) . En réponse au journal Sarge décision. Évalué à 0.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# FreeDNS
Posté par Krunch (site web personnel) . En réponse au message Héberger son site chez soi. Évalué à 3.
http://freedns.afraid.org/(...)
http://www.no-ip.com/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: peut-être...
Posté par Krunch (site web personnel) . En réponse au message smp. Évalué à 2.
3.0
$ dmesg | grep ^Processors:
Processors: 2
$ uname -r
2.4.18-1-686-smp
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mais encore?
Posté par Krunch (site web personnel) . En réponse au message live cd perso. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Heu
Posté par Krunch (site web personnel) . En réponse au message logiciel de caisse. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# mais encore?
Posté par Krunch (site web personnel) . En réponse au message live cd perso. Évalué à 2.
Au fait tu n'as besoin d'être root que pour utiliser mount et losetup.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: X3 ?
Posté par Krunch (site web personnel) . En réponse au message Partition X3 sous Windows. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
C'est pour ça que j'ai mis "impossible" entre guillemets. Je suis pas cryptologiste (logue?graphe?) mais pour ce que j'en ai compris, pour savoir qui partage quoi sur Freenet, c'est vraiment pas facile. Même avec des moyens conséquents..
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
(oui je sais il parait qu'on doit dire chiffrer et pas crypter)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # hu?
Posté par Krunch (site web personnel) . En réponse au journal cramage de moniteur. Évalué à 2.
Si c'est parce que j'ai eu de la chance faut croire que (presque) tous ceux avec qui j'ai fait des LAN ont de la chance aussi alors. J'ai jamais vu qu'un seul cramage de moniteur (et c'était pas juste le moniteur, à mon avis c'était plutôt un problème d'alimentation).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: shut up and code
Posté par Krunch (site web personnel) . En réponse au journal Lister les liens dans les journaux. Évalué à 2.
Pour la recherche par mots clés le pauvre serveur va peut être pas supporter mais pour le listing de liens ça ne devrait pas poser de problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Petite information au passage
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 3.
Mais bon JNSPJ :op
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: pour 2)
Posté par Krunch (site web personnel) . En réponse au message Petites questions sur Bash et la commande ls. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# it's not a bug it's a feature
Posté par Krunch (site web personnel) . En réponse au message orthographe, bug ?. Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: shut up and code
Posté par Krunch (site web personnel) . En réponse au journal Lister les liens dans les journaux. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# shut up and code
Posté par Krunch (site web personnel) . En réponse au journal Lister les liens dans les journaux. Évalué à 3.
Le problème c'est plutôt le tri des liens après et ça c'est pas très automatisable. A moins qu'à chaque lien on doive mettre une description et des mots clés ou un truc du genre.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 4.
Pour autant que je sache, les informations que récupèrent les majors sur les réseaux P2P sont distribuées publiquement et volontairement. Pas besoin de sniffer quoi que ce soit. Quand tu partages des fichiers sur un réseau P2P "classique", tu es censé savoir que n'importe qui peut associer ton adresse IP aux fichiers que tu partages. C'est pas une information confidentielle et en faire une base de données n'est probablement pas illégal. Tant que les ISP ne laissent pas n'importe qui retrouver la personne qui utilise une adresse IP donnée, je ne vois pas trop le problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# s/les/des
Posté par Krunch (site web personnel) . En réponse à la dépêche Sortie de Nessus 2.1.0. Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mon avis à moi rien qu'à moi
Posté par Krunch (site web personnel) . En réponse au message threads - fork() .... Évalué à 2.
http://www.opengroup.org/onlinepubs/007908799/xsh/pthread.h.html(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.