The "C" locale is the minimal locale. It is a rather neutral locale which has the same settings across all systems and compilers, and therefore the exact results of a program using this locale are predictable. This is the locale used by default on all C programs.
J'ai testé sur deux autres machines (Debian stable et testing), toutes les deux configurées avec du fr_FR.UTF-8 comme locale, et le comportement celui que j'ai toujours vu : c'est le point qui est utilisé comme séparateur décimal.
#include <stdio.h>#include <stdlib.h>#include <locale.h>intmain(intargc,char**argv){floatv;char*l;if(argc==1){printf("Usage: %s 3.14\n",argv[0]);return-1;}/* Get the name of the current locale. */l=setlocale(LC_NUMERIC,NULL);printf("Locale used: %s\n",l);v=strtof(argv[1],0);printf("The first argument is: %f\n",v);return0;}
C'est moi qui parse la valeur, à coup de strtof() (parce que les strtoX() sont les seules méthodes qui permettent de vérifier que ce que l'on a obtenu est correct (sans avoir à sortir l'artillerie lourde, genre boost::lexical_cast)).
Du coup, j'ai tenté de vérifier ma locale juste avant l'appel à strtof().
D'après http://www.cplusplus.com/reference/locale/locale/locale/, en C++ :
std::locale g = std::locale(); est sensé me donner ma locale globale (pas certain de ce que cela signifie),
std::locale d = std::locale(""); est sensé me donner la locale par défaut du système,
std::use_facet< std::numpunct >(la_locale).decimal_point(); est sensé me donner le séparateur décimal.
Sur les deux machines, la locale par défaut est C avec comme séparateur décimal est le point, et la locale globale est bien fr_FR.UTF-8 avec la virgule. Mais je ne suis pas certain de savoir laquelle est utilisée…
Sur ma machine virtuelle, c'est bien le point. Sur le serveur, c'est la virgule. Ce qui explique le comportement du serveur. Reste à trouver pourquoi il utilise une locale différente. Moi qui avait pris une LTS en pensant être tranquille…
Je pense qu'en attendant, je vais changer pour du lexical_cast.
En effet, il manquait l'info comme quoi la commande locale retourne la même chose sur les 2 machines.
Ainsi que celle disant que si, sur le serveur, je force LC_NUMERIC=C, je peux utiliser le point comme séparateur décimal.
La configuration des deux machines est sensiblement identique.
Oui, en français le séparateur décimal est la virgule. Mais mis à part les tableurs qui sont relativement sensibles sur ce point, je n'ai jamais tapé de nombre décimaux avec une virgule dans mon terminal.
De ce que je me souviens, atof() utilise par défaut la locale C, qui justement spécifie le point comme séparateur décimal.
Du coup, c'est plutôt le comportement de ma machine virtuelle qui me parait être le bon.
Sur le coup, j'ai été surpris qu'aucun média français n'en parlait.
Et puis je me suis souvenu que ce sujet avait déjà pas mal été évoqué les années précédentes, donc j'ai mis ça sur le fait que la route est longue jusqu'à San Francisco…
Oui, enfin pour que des cours se passent bien, c'est comme dans un couple : les 2 parties doivent faire des efforts.
Alors certes, il y a des profs qui ne sont pas très pédagogues, mais il y a aussi beaucoup d'étudiants qui se croient plus malin que le prof et qui pensent que le poly suffit à comprendre le cours. En tout cas, là ou j'enseigne (école d'ingé).
Je viens d'essayer Jirafeau, un fork de Jyraphe, que le remplace allègrement. Interface un peu moins vieillote, quelques fonctions d'administration pratiques.
Jyraphe est en effet un peu abandonné (comme beaucoup de services de ce genre sur lesquels je suis tombé), mais à l'avantage d'être relativement simple à mettre en place ainsi que d'être ultra léger (il y a quoi, 300 lignes de code) et donc facilement bidouillable.
J'ai dégoté un fork, Zyraphe, qui est vivant, et semble proposer quelques fonctionnalités en plus. J'ai pas eu trop le temps de tester : https://github.com/zirafe/zirafe.
Coquelicot : ça à l'air de fonctionner, c'est packagé dans Debian, c'est du Ruby pas très complexe (lorsque l'on s'y connait un minimum en Ruby/Sinatra).
Récemment j'ai eu l'occasion d'utiliser ZendTo, qui m'avait pourtant rebuté au début car un peu trop « complexe pétrochimique » (en vue de la tâche à accomplir). J'aime bien leur façon de proposer le service : tu créé un « dropoff » (pour faire simple, un dossier) pour une occasion spécifique, dont tu envoi le lien à tes clients, et dans laquelle ils vont déposer les fichiers. Parmi les choses qui me rebutent un peu : les comptes utilisateur sont à administrer depuis la ligne de commande, et je n'ai pas trouvé ça très intuitif à utiliser.
FileZ : je ne me souvient plus pourquoi je ne l'avais pas retenu, pourtant ni le code ni l'appli ne m'ont l'air trop dégueu…
Au final, j'ai pas trop trouvé mon bonheur, et comme ça m'a filé l'occasion d'expérimenter 2-3 trucs, je suis en train de développer une solution « à la ZendTo » beaucoup plus light. Mais il n'y a encore rien de très concret…
Certes, ce système de fichier n'est pas libre, mais la question était d'en avoir un qui soit standardisé.
Après, quand on voit le nombre de gros bonnets faisant parti du SDCard consortium et qui ont reconnu ce système de fichier pour les prochaines générations de cartes, si la question du brevet était réellement un point critique pour eux, ils n'avaient qu'à en choisir un autre ou bien proposer autre chose…
Pour faire tourner un serveur Web et 2-3 sites, même en Rails, un eeepc suffit amplement. Je te conseillerait peut-être de lui passer sa mémoire vive à 2Go, ça ne pourrait que lui faire du bien…
Moi, ça fait 3 ans que j'ai un Eeepc 701 (le tout premier, avec un Celeron@600MHz) qui me sert de serveur web et de serveur de versionning (Redmine + svn + git(olite)), et je suis entièrement satisfait du recyclage de cette machine. Passée à 2Go de ram, et couplée à un disque dur en usb2 pour les données (parce que le ssd de 4Go interne, c'est quand même très limité), outre le fait que des fois il faut attendre quelques secondes que la machine Ruby/Rails se mette en branle, elle répond tout à fait à mes besoins.
Le tout sous une Debian stable, mise à jour il y a quelques semaines, et agrémenté d'un petit script pour éteindre la machine proprement lorsqu'une coupure de courant de plus de 10min survient (onduleur du pauvre), ce qui actuellement me pose le plus de problème n'est pas la machine mais la nouvelle politique de Dyndns concernant les noms de domaines gratuits…
De quel type de projet veux tu suivre l'activité ?
Si c'est un projet de développement, Redmine est probablement une bonne solution.
Si c'est un projet d'ordre « général », tu peux peut-être regarder du coté de Collabtive, j'ai rapidement testé l'an dernier et ai trouvé ça plutôt sympa.
Pardon pour l'oubli des « s ». Ceci dit, peut-être que P'tit Gibus l'aurait écrit ainsi…
Par contre, non, ça c'est faux : « Conditionnel => Si j’aurais su, j’aurais pas venu ! ».
La seule façon d'utiliser le conditionnel dans une condition, c'est d'omettre le « si » :
- « Si j'aurais su, j'aurais pas venu ! » : doublement incorrect
- « Si j'aurais su, je ne serais pas venu ! » : incorrect
- « Si j'avais su, je ne serais pas venu ! » : correct
- « J'aurais su, je ne serais pas venu ! » : correct
Le problème des mnémonique, c'est qu'il faut s'en rappeler, sinon ça ne fonctionne pas. La bonne, c'est "Les si n'aiment pas les ré".
Ou encore, se souvenir de la célèbre phrase de P'tit Gibus dans La Guerre des Boutons : "Si j'aurai su, j'aurai pas venu !". Enfin, faut-il être d'une génération qui connaisse La Guerre des Boutons…
Si mes souvenirs sont bons, Bitmessage c'est : « on broadcast (à un groupe), et décode celui qui peut » ?
En effet, c'est une solution pour certains points évoqués.
Cependant, en mettant de coté l'aspect chiffrement sur lequel repose Bitmessage, si la solution au respect de la vie privée est le broadcast, il y a pour moi comme un problème conceptuel…
L'intérêt d'une attaque par dictionnaire, c'est de se baser sur un dictionnaire existant, sans avoir à calculer quoi que ce soit, pour ne faire que des recherches dans une table de hachage. Donc si le dictionnaire ne prend pas en compte le grain de sel, il ne te servira pas à grand chose.
Après, ça dépend des ressources dont tu disposes. Si tu as de quoi calculer un dictionnaire de hash rapidement, en effet, un grain de sel unique ne fait que délayer un peu les choses. Et si c'est des hashs différents, autant faire du brutforce, car il n'y a aucun intérêt à stocker le dictionnaire calculé.
Oui, mais si j'ai bien compris, comme de toute façon on ne peut pas faire confiance au réseau qui peut être écouté, quand bien on peut avoir un protocole avec lequel le destinataire ne connait pas l'adresse de l'appelant, un mec bien placé qui écoute la communication peut avoir l'info qu'il faut. Alors certes, le problème n'est peut-être pas forcément le même, l'info n'est pas récupérée par la même personne (destinataire vs. écoutant), mais au final ça change rien au problème de respect de la vie privée…
J'ai un peu de mal à saisir le concept de "protocole indiscret" :
Oui, le serveur de destination peut être compromis.
Oui, quelqu'un peut écouter sur un élément de réseau intermédiaire.
Par contre, dire qu'un protocole est un élément à risque car il « contient » nos données, je trouve ça un peu gros, car c'est quand même son rôle. Ou encore que les paquets contiennent des informations concernant la provenance/destination des données : pour envoyer un paquet d'un point A à un point B, le protocole aura forcément besoin de savoir comment joindre B. Idem si tu écris une lettre, il faut à un moment ou un autre mettre l'adresse du destinataire. Ou alors tu choisis de ne pas dépendre du protocole LaPoste et délivres ta lettre toi même, mais là encore, il suffit de te suivre pour obtenir l'adresse de ton destinataire.
Sinon, quand je lis :
Pour déjouer sérieusement la surveillance, il faudrait des protocoles avec des tailles de paquets variables, n'ayant pas de chaîne de bits prévisibles à un endroit fixe dans le paquet, etc.
et :
Les protocoles devraient être conçues de façon à ne transmettre que les données strictement nécessaires à l'accomplissemnt de la tâche.
L'un des intérêts de la technique du grain de sable, c'est de pouvoir éviter/limiter les attaques par dictionnaire.
Imaginons que l'attaquant ait calculé les SHA512 de tous les mots du Larousse, si tous les mots de passes sont préfixés par "plop" avant d'être haché, l'attaquant doit se retaper le calcul de l'ensemble des hash en préfixant tous les mots du Larousse par "plop".
Et puis si on utilise correctement la technique, on met un grain de sable différent pour chacun, et l'attaque par dictionnaire devient légèrement plus compliquée…
En fait, je m'aperçois que y'a bien longtemps que je n'ai pas jeté un œil à Ajaxplorer, je croyais que ça permettait juste de parcourir un dossier, pas d'y écrire. Je ne savais pas non plus que ça gérait des utilisateurs.
SparkleShare, Dropbox […], c'est surtout axé synchronisation, et ça, je n'en ai pas besoin.
Owncloud, j'y avais pensé, mais ça oblige mes clients à se créer un compte et à nous de gérer les autorisations (l'upload "anonyme" semble être prévu pour la version 6). Et puis j'ai jamais été fan d'Owncloud. Idem pour Dropbox & Co.
# Problème résolu
Posté par cfx . En réponse au message [Résolu] Problème de séparateur décimal. Évalué à 1.
Et le coupable est : Qt.
Il me manquait un commit sur la version que je compilais sur ma machine virtuelle.
Commit qui transformait mon application console en application console Qt.
Et Qt charge la locale du système, donc fr_FR.UTF-8.
http://harmattan-dev.nokia.com/docs/library/html/qt4/qcoreapplication.html#locale-settings
Merci à toi Francesco d'avoir pris un peu de son temps pour essayer de m'aider.
[^] # Re: info
Posté par cfx . En réponse au message [Résolu] Problème de séparateur décimal. Évalué à 0.
Non, la locale par défaut qui est sensée être utilisée par un programme en C est la locale "C".
Source : http://www.cplusplus.com/reference/clocale/
J'ai testé sur deux autres machines (Debian stable et testing), toutes les deux configurées avec du fr_FR.UTF-8 comme locale, et le comportement celui que j'ai toujours vu : c'est le point qui est utilisé comme séparateur décimal.
[^] # Re: info
Posté par cfx . En réponse au message [Résolu] Problème de séparateur décimal. Évalué à 0.
Bon, en fait c'est juste dix fois plus simple d'utiliser boost::lexical_cast que des strtoX().
[^] # Re: info
Posté par cfx . En réponse au message [Résolu] Problème de séparateur décimal. Évalué à 0. Dernière modification le 15 octobre 2013 à 19:34.
C'est moi qui parse la valeur, à coup de strtof() (parce que les strtoX() sont les seules méthodes qui permettent de vérifier que ce que l'on a obtenu est correct (sans avoir à sortir l'artillerie lourde, genre boost::lexical_cast)).
Du coup, j'ai tenté de vérifier ma locale juste avant l'appel à strtof().
D'après http://www.cplusplus.com/reference/locale/locale/locale/, en C++ :
std::locale g = std::locale(); est sensé me donner ma locale globale (pas certain de ce que cela signifie),
std::locale d = std::locale(""); est sensé me donner la locale par défaut du système,
std::use_facet< std::numpunct >(la_locale).decimal_point(); est sensé me donner le séparateur décimal.
Sur les deux machines, la locale par défaut est C avec comme séparateur décimal est le point, et la locale globale est bien fr_FR.UTF-8 avec la virgule. Mais je ne suis pas certain de savoir laquelle est utilisée…
Sauf qu'à priori, comme strtof() est une fonction C et non C++, elle utilise une autre locale.
D'après http://www.cplusplus.com/reference/clocale/localeconv/, les lignes suivantes me donne le séparateur décimal :
struct lconv * lc = localeconv();
std::cout << lc->decimal_point << std::endl;
Sur ma machine virtuelle, c'est bien le point. Sur le serveur, c'est la virgule. Ce qui explique le comportement du serveur. Reste à trouver pourquoi il utilise une locale différente. Moi qui avait pris une LTS en pensant être tranquille…
Je pense qu'en attendant, je vais changer pour du lexical_cast.
[^] # Re: info
Posté par cfx . En réponse au message [Résolu] Problème de séparateur décimal. Évalué à 0.
En effet, il manquait l'info comme quoi la commande
localeretourne la même chose sur les 2 machines.Ainsi que celle disant que si, sur le serveur, je force LC_NUMERIC=C, je peux utiliser le point comme séparateur décimal.
La configuration des deux machines est sensiblement identique.
Oui, en français le séparateur décimal est la virgule. Mais mis à part les tableurs qui sont relativement sensibles sur ce point, je n'ai jamais tapé de nombre décimaux avec une virgule dans mon terminal.
De ce que je me souviens, atof() utilise par défaut la locale C, qui justement spécifie le point comme séparateur décimal.
Du coup, c'est plutôt le comportement de ma machine virtuelle qui me parait être le bon.
[^] # Re: Fuck Adobe
Posté par cfx . En réponse au journal C'est un scandale !. Évalué à 6.
Pour que ça prenne 2 minutes, il faut habiter en face de la préfecture…
Moi ça me prendrait 40 minutes de tram pour faire l'aller-retour (dont ~10 minutes à l'attendre).
Et je ne te parle pas de mes parents qui habitent à 40 minutes de route (aller). Plus trouver un place ou se garer, puis marcher jusqu'à la pref…
Bref, tes 2 minutes, c'est plutôt 2h pour beaucoup de personnes.
# That's weird
Posté par cfx . En réponse au journal Mon premier journal bookmark... mais que fait la police ?. Évalué à 4.
L'annonce a même été relayée il y a quelques jours dans le magazine Wired :
http://www.wired.com/wiredenterprise/2013/09/gendarmerie_linux/
Sur le coup, j'ai été surpris qu'aucun média français n'en parlait.
Et puis je me suis souvenu que ce sujet avait déjà pas mal été évoqué les années précédentes, donc j'ai mis ça sur le fait que la route est longue jusqu'à San Francisco…
[^] # Re: Bon courage !
Posté par cfx . En réponse au journal prise de note en cours. Évalué à 7.
Oui, enfin pour que des cours se passent bien, c'est comme dans un couple : les 2 parties doivent faire des efforts.
Alors certes, il y a des profs qui ne sont pas très pédagogues, mais il y a aussi beaucoup d'étudiants qui se croient plus malin que le prof et qui pensent que le poly suffit à comprendre le cours. En tout cas, là ou j'enseigne (école d'ingé).
[^] # Re: jyraphe
Posté par cfx . En réponse au message Partage de fichier minimaliste. Évalué à 3.
Je viens d'essayer Jirafeau, un fork de Jyraphe, que le remplace allègrement. Interface un peu moins vieillote, quelques fonctions d'administration pratiques.
https://gitorious.org/jirafeau
# Question similaire
Posté par cfx . En réponse au message Partage de fichier minimaliste. Évalué à 3.
J'ai posé une question similaire il y a quelques semaines :
http://linuxfr.org/forums/general-cherche-logiciel/posts/logiciel-de-depot-mise-a-disposition-de-fichiers
Jyraphe est en effet un peu abandonné (comme beaucoup de services de ce genre sur lesquels je suis tombé), mais à l'avantage d'être relativement simple à mettre en place ainsi que d'être ultra léger (il y a quoi, 300 lignes de code) et donc facilement bidouillable.
J'ai dégoté un fork, Zyraphe, qui est vivant, et semble proposer quelques fonctionnalités en plus. J'ai pas eu trop le temps de tester : https://github.com/zirafe/zirafe.
Coquelicot : ça à l'air de fonctionner, c'est packagé dans Debian, c'est du Ruby pas très complexe (lorsque l'on s'y connait un minimum en Ruby/Sinatra).
Récemment j'ai eu l'occasion d'utiliser ZendTo, qui m'avait pourtant rebuté au début car un peu trop « complexe pétrochimique » (en vue de la tâche à accomplir). J'aime bien leur façon de proposer le service : tu créé un « dropoff » (pour faire simple, un dossier) pour une occasion spécifique, dont tu envoi le lien à tes clients, et dans laquelle ils vont déposer les fichiers. Parmi les choses qui me rebutent un peu : les comptes utilisateur sont à administrer depuis la ligne de commande, et je n'ai pas trouvé ça très intuitif à utiliser.
FileZ : je ne me souvient plus pourquoi je ne l'avais pas retenu, pourtant ni le code ni l'appli ne m'ont l'air trop dégueu…
Au final, j'ai pas trop trouvé mon bonheur, et comme ça m'a filé l'occasion d'expérimenter 2-3 trucs, je suis en train de développer une solution « à la ZendTo » beaucoup plus light. Mais il n'y a encore rien de très concret…
[^] # Re: Standard de système de fichiers
Posté par cfx . En réponse au journal Partition de type NTFS volume set ou NTFS. Évalué à 2.
Certes, ce système de fichier n'est pas libre, mais la question était d'en avoir un qui soit standardisé.
Après, quand on voit le nombre de gros bonnets faisant parti du SDCard consortium et qui ont reconnu ce système de fichier pour les prochaines générations de cartes, si la question du brevet était réellement un point critique pour eux, ils n'avaient qu'à en choisir un autre ou bien proposer autre chose…
[^] # Re: Standard de système de fichiers
Posté par cfx . En réponse au journal Partition de type NTFS volume set ou NTFS. Évalué à -2.
Système de fichier standard pour les supports amovibles : exFAT.
News de la semaine dernière concernant l'arrivée dans le noyau Linux d'un module exFAT : http://linuxfr.org/users/ymorin/journaux/un-module-noyau-pour-le-support-exfat-en-gplv2
[^] # Re: Consommation de mémoire vive
Posté par cfx . En réponse au message Mise en oeuvre de redmine pour le suivi d'activité. Évalué à 1.
Pour faire tourner un serveur Web et 2-3 sites, même en Rails, un eeepc suffit amplement. Je te conseillerait peut-être de lui passer sa mémoire vive à 2Go, ça ne pourrait que lui faire du bien…
Moi, ça fait 3 ans que j'ai un Eeepc 701 (le tout premier, avec un Celeron@600MHz) qui me sert de serveur web et de serveur de versionning (Redmine + svn + git(olite)), et je suis entièrement satisfait du recyclage de cette machine. Passée à 2Go de ram, et couplée à un disque dur en usb2 pour les données (parce que le ssd de 4Go interne, c'est quand même très limité), outre le fait que des fois il faut attendre quelques secondes que la machine Ruby/Rails se mette en branle, elle répond tout à fait à mes besoins.
Le tout sous une Debian stable, mise à jour il y a quelques semaines, et agrémenté d'un petit script pour éteindre la machine proprement lorsqu'une coupure de courant de plus de 10min survient (onduleur du pauvre), ce qui actuellement me pose le plus de problème n'est pas la machine mais la nouvelle politique de Dyndns concernant les noms de domaines gratuits…
# Suivi de l'activité de quoi ?
Posté par cfx . En réponse au message Mise en oeuvre de redmine pour le suivi d'activité. Évalué à 1.
De quel type de projet veux tu suivre l'activité ?
Si c'est un projet de développement, Redmine est probablement une bonne solution.
Si c'est un projet d'ordre « général », tu peux peut-être regarder du coté de Collabtive, j'ai rapidement testé l'an dernier et ai trouvé ça plutôt sympa.
[^] # Re: Mauvais screenshot
Posté par cfx . En réponse à la dépêche ElementaryOS Luna. Évalué à 1.
Pardon pour l'oubli des « s ». Ceci dit, peut-être que P'tit Gibus l'aurait écrit ainsi…
Par contre, non, ça c'est faux : « Conditionnel => Si j’aurais su, j’aurais pas venu ! ».
La seule façon d'utiliser le conditionnel dans une condition, c'est d'omettre le « si » :
- « Si j'aurais su, j'aurais pas venu ! » : doublement incorrect
- « Si j'aurais su, je ne serais pas venu ! » : incorrect
- « Si j'avais su, je ne serais pas venu ! » : correct
- « J'aurais su, je ne serais pas venu ! » : correct
[^] # Re: Mauvais screenshot
Posté par cfx . En réponse à la dépêche ElementaryOS Luna. Évalué à 6.
Le problème des mnémonique, c'est qu'il faut s'en rappeler, sinon ça ne fonctionne pas. La bonne, c'est "Les si n'aiment pas les ré".
Ou encore, se souvenir de la célèbre phrase de P'tit Gibus dans La Guerre des Boutons : "Si j'aurai su, j'aurai pas venu !". Enfin, faut-il être d'une génération qui connaisse La Guerre des Boutons…
[^] # Re: bcrypt
Posté par cfx . En réponse au journal OVH sous le coup d'un acte de piraterie. Évalué à 0.
En effet, il semble que j’opposai brutforce par dictionnaire à dictionnaire/rainbow table.
[^] # Re: Protocole indiscret ?
Posté par cfx . En réponse au journal Prise en compte de la vie privée dans les protocoles réseaux. Évalué à 2. Dernière modification le 25 juillet 2013 à 13:13.
Si mes souvenirs sont bons, Bitmessage c'est : « on broadcast (à un groupe), et décode celui qui peut » ?
En effet, c'est une solution pour certains points évoqués.
Cependant, en mettant de coté l'aspect chiffrement sur lequel repose Bitmessage, si la solution au respect de la vie privée est le broadcast, il y a pour moi comme un problème conceptuel…
[^] # Re: bcrypt
Posté par cfx . En réponse au journal OVH sous le coup d'un acte de piraterie. Évalué à 1.
L'intérêt d'une attaque par dictionnaire, c'est de se baser sur un dictionnaire existant, sans avoir à calculer quoi que ce soit, pour ne faire que des recherches dans une table de hachage. Donc si le dictionnaire ne prend pas en compte le grain de sel, il ne te servira pas à grand chose.
Après, ça dépend des ressources dont tu disposes. Si tu as de quoi calculer un dictionnaire de hash rapidement, en effet, un grain de sel unique ne fait que délayer un peu les choses. Et si c'est des hashs différents, autant faire du brutforce, car il n'y a aucun intérêt à stocker le dictionnaire calculé.
[^] # Re: Protocole indiscret ?
Posté par cfx . En réponse au journal Prise en compte de la vie privée dans les protocoles réseaux. Évalué à 2.
Oui, mais si j'ai bien compris, comme de toute façon on ne peut pas faire confiance au réseau qui peut être écouté, quand bien on peut avoir un protocole avec lequel le destinataire ne connait pas l'adresse de l'appelant, un mec bien placé qui écoute la communication peut avoir l'info qu'il faut. Alors certes, le problème n'est peut-être pas forcément le même, l'info n'est pas récupérée par la même personne (destinataire vs. écoutant), mais au final ça change rien au problème de respect de la vie privée…
# Protocole indiscret ?
Posté par cfx . En réponse au journal Prise en compte de la vie privée dans les protocoles réseaux. Évalué à 4.
J'ai un peu de mal à saisir le concept de "protocole indiscret" :
Sinon, quand je lis :
et :
je me dis que cela va devenir compliqué…
[^] # Re: bcrypt
Posté par cfx . En réponse au journal OVH sous le coup d'un acte de piraterie. Évalué à 6.
L'un des intérêts de la technique du grain de sable, c'est de pouvoir éviter/limiter les attaques par dictionnaire.
Imaginons que l'attaquant ait calculé les SHA512 de tous les mots du Larousse, si tous les mots de passes sont préfixés par "plop" avant d'être haché, l'attaquant doit se retaper le calcul de l'ensemble des hash en préfixant tous les mots du Larousse par "plop".
Et puis si on utilise correctement la technique, on met un grain de sable différent pour chacun, et l'attaque par dictionnaire devient légèrement plus compliquée…
# Pour Debian
Posté par cfx . En réponse au message Reinstaller sa distribution personnalisé. Évalué à 1.
live-build : http://live.debian.net/manual/current/html/live-manual/toc.fr.html
[^] # Re: ici on utilise ajaxplorer
Posté par cfx . En réponse au message Logiciel de dépôt/mise à disposition de fichiers. Évalué à 1.
En fait, je m'aperçois que y'a bien longtemps que je n'ai pas jeté un œil à Ajaxplorer, je croyais que ça permettait juste de parcourir un dossier, pas d'y écrire. Je ne savais pas non plus que ça gérait des utilisateurs.
[^] # Re: Mauvaise solution
Posté par cfx . En réponse au message Logiciel de dépôt/mise à disposition de fichiers. Évalué à 0.
Si ça ne tenait qu'à moi…
SparkleShare, Dropbox […], c'est surtout axé synchronisation, et ça, je n'en ai pas besoin.
Owncloud, j'y avais pensé, mais ça oblige mes clients à se créer un compte et à nous de gérer les autorisations (l'upload "anonyme" semble être prévu pour la version 6). Et puis j'ai jamais été fan d'Owncloud. Idem pour Dropbox & Co.