jben a écrit 861 commentaires

Si la bijection réciproque est facile à calculer (du genre ce n'est pas un chiffrement avec une clef non disponible), c'est strictement équivalement à un stockage en clair.

Différencier le stockage via une fonction bijective dont la réciproque est connu et le stockage en clair stricto sensu, c'est caractéristique soit d'une incompétence flagrante soit d'une volonté de nuire. Je te laisse choisir.

si il y a un salt, là ça devient très dur.

Tu plaisantes j'espère ?

Je récupère le sel, qui est pas utilisateur en même temps que la base. Pour chaque utilisateur, je bruteforce connaissant le sel, chez moi, avec mon vieux processeur je fais 10⁵ hash/seconde, bref en espérance 5 secondes pour avoir le mot de passe d'un utilisateur.

Alors c'est vrai que qu'on ne peux pas travailler de manière globale, et qu'on doit travailler utilisateur par utilisateur, mais ça me parait un peu faiblard de baser la sécurité là dessus.

Ça me fait penser aux incompétents qui anonymisent une base de donnée de faisant un hash(nom.prenom) en fournissant à coté la liste des (nom,prenom)s.

Pourquoi réinventer la roue à chaque fois ? On a un standard pour faire cela, reconnu et tout et tout, ça se nomme HMAC et ça s'utilise avec un algo de calcul de condensat (MD5, SHA-1, SHA-2, SHA-3…). J'en parle dans un commentaire sur un des nombreux journaux sur le sujet. Moi je le fais en python, vous le faites en javascript, soit, on se fout de l'implémentation. Mais c'est pas une raison pour ne pas utiliser HMAC au lieu d'un algo maison.

Commentaire sur le reste du journal : à chaque fois on utilise les mêmes arguments, à chaque fois on voit les mêmes propositions, à chaque fois avec les mêmes défauts, et à chaque fois les même réponses. Ce genre de débat est aussi inintéressant qu'un débat sur la moto.

J'ai voulu tenter de mettre cela (que j'encode ici en base64) ça ne passe pas

8J2TnvCdk7Eg8J2Tu/Cdk6rwnZOw8J2Triwg8J2TuPCdk7Eg8J2TrfCdk67wnZO88J2TrvCdk7zw
nZO58J2TuPCdk77wnZO7LCDwnZOe8J2TsSDwnZO/8J2TsvCdk67wnZO18J2TtfCdk67wnZO88J2T
vPCdk64g8J2TrvCdk7fwnZO38J2TrvCdk7bwnZOy8J2Triwg8J2TtyfwnZOq8J2Tsi3wnZOz8J2T
riDwnZOt8J2TuPCdk7fwnZOsIPCdk73wnZOq8J2Tt/Cdk70g8J2Tv/Cdk67wnZOs8J2TviDwnZO6
8J2TvvCdk64g8J2TufCdk7jwnZO+8J2TuyDwnZOs8J2TrvCdk73wnZO98J2TriDwnZOy8J2Tt/Cd
k6/wnZOq8J2TtvCdk7LwnZOuID8K

Encore un système qui ne supporte pas les unicodes plus haut que U+10000. Je ne sais pas pourquoi, mais c'est assez fréquent.

Tu remarqueras que la tranche horaire à laquelle je poste des messages avec accents est toujours différente de celle à laquelle je poste des messages avec accents. Tu remarqueras aussi que j'ai souvent tendance à poster en fin de journée, voire en pleine nuit. Tu pourras alors inférer que je me trouve sur un autre continent, et que je n'ai pas accès à du bépo partout où je suis.

Non mais cette excuse pourrie, à un moment ça suffit. Ça fait plusieurs années que j'utilise un qwerty-us en France ou ailleurs (actuellement ailleurs), et je ne vous pas en quoi ça pose un problème.

Tu peux avoir plein de raison de ne pas mettre les accents, allant de la mauvaise foi à la flemme en passant pas l'ignorance orthographique (ce qui est mon cas), mais le choix du clavier ne fait définitivement pas partie de ces raisons. Te viendrais-t'il à l'idée de poster sur un forum russe/chinois/whatever en utilisant que l'ASCII avec comme excuse « nan mais je ne sais pas faire autre chose avec mon clavier ».

En fait à la relecture de ton commentaire (le temps d'édition est trop court) j'ai pensé à autre chose. Ça dépend quelle est ta constante. Si (comme moi) tu as une certaine distance à faire qui est fixé, alors afficher en L/km est judicieux, tu minimise le pognon mis pour une distance. Si tu as une certaine quantité de carburant à mettre et après tu marches à pied, alors afficher en km/L est judicieux, tu maximise la distance pour un pognon fixé.

C'est ce que je disais dans mon premier messages, les deux ont leurs avantages, même si perso je préfère l'un à l'autre. Mais il n'y a pas une grandeur qui est tout bien et l'autre tout mal.

Si tu passe de .065 à .069 L/km, alors tu passes de 500 à 470 km. Je pense que le ressenti est le même dans les deux cas. Ton raisonnement était fallacieux.

Après tu dis que ce que tu vois c'est la distance, oui, mais c'est aussi ce que tu ne maîtrise pas. Souvent tu cherche à diminuer la quantité d'essence pour un même trajet. Et de plus présenté comme ça, c'est directement lié au pognon que tu dépenses pour faire avancer ta boîte de métal (j'ai aussi une voiture, ce n'est pas un raisonnement anti-voiture, mais il faut avouer que ça reste une boîte de métal) ou à la quantité de polluants que tu rejette. Bref ce sachant que tu dois faire une certaine distance qui t'est imposée, cette consommation en L/km est proportionnellement lié à ton pogon ou à ta conscience écologique suivant ton obédience.

Mais donc: je ne l'ai pas touché, pas de témoin à part mes passagers (apparemment ça ne compte pas pour les assureurs) et donc 100% pour ma gueule.

Quand ton assureur te propose une solution que tu ne trouve pas acceptable, il n'y a que trois raisons de le laisser faire, et de ne pas porter l'affaire au civil contre l'autre automobiliste ou ton assureur suivant le cas (souvent tu attaques l'autre automobilistes et les assureurs vont se joindre au dossier) :

• Considérer que les assureurs sont des dieux qui ont raison.
• Ne pas vouloir s'emmerder pour cela.
• Avoir tort.

Après le problème, c'est que pour l'avoir déjà fait, c'est que les assureurs ne sont pas effrayés par un imbécile se mettant à déclamer « je vais aller en justice », il faut vraiment le faire. Ce n'est que quelques jours avant l'audience (une heure avant dans mon cas) que comme par miracle, les assureurs réussissent à se mettre d'accord sur une solution que tu trouve acceptable.

En fait elles sont toutes les deux pertinentes dans certains cas.

Par exemple, je fais 10 km avec une conduite souple .05 L/km (20 km/L), et 10 km avec une conduite agressive, .1 L/km (10 km/L), ma consommation moyenne sera de .075 L/km (13.3 km/L) et non .067 L/km (15 km/L). On peut faire la moyenne des L/km mais pas des km/L.

Par contre si tu dit, « j'utilise la moitié de mon plein pour me faire plaisir en conduisant comme une brute (se faire plaisir dans ou sur un engin motorisé, c'est étrange) et l'autre moitié en conduite éco », alors dans ce cas, il faudra faire la moyenne des km/L et non des L/km.

Après je pense que intuitivement, on fait plus de somme et moyenne de quantité qui correspondent à des L/km et donc que l’unité européenne est plus adaptés. Je pense que l'utilisation d'une distance par volume de carburant nous conduit à faire des moyenne non appropriées, et à sous-estimer notre consommation réelle.

Avec une phrase par ligne c'est assez rare d'avoir 2000 caractères, sauf quand j'écris aux impôts.

Après c'est aussi trompeur le numéro de ligne, des fois il fait référence à la dernière ligne du paragraphe…

Édit: j'ai cru que tu avais répondu à l'commentaires que je viens de poster dans ce thread.

Le fait que le retour à la ligne (simple) ne soit pas significatif permet aussi des trucs sympa. J'essai par exemple lorque je rédige un document MarkDown ou LaTeX qui est versionné, d'utiliser la logique une phrase, une ligne. Les lignes peuvent être longues ce n'est pas le problème, je ne respecte pas de limite de nombre de caractères pas ligne. En tout cas, ça permet au gestionnaire de version d'être plus efficace, et d'avoir moins de conflits.

Mais pour cela, il faut que le retour à la ligne (simple, toujours) ne soit pas significatif.

Sans vouloir le défendre, quand j'écris un commentaire sur linuxfr, je mets des retours à la ligne un peu n'importe où, avec l'habitude que les retours à la ligne (non dupliqués) ne sont pas significatifs en MarkDown. Ce n'est qu'après avoir écrit mon commentaire que je suis obligé de le relire pour les supprimer, et ça me les brise sérieusement. J'ai proposé un rapport de bug pour proposer de rendre ce comportement optionnel resté sans effet à ce jour.

Ceci n'est en aucun cas une critique, j'essaie juste d'avoir une explication rationnelle à certains retours à la ligne intempestifs que l'on constate.

Le module cifs est-il chargé lors du montage des filesystems au boot ? Si il n'est chargé qu'après, ça expliquerai pourquoi le mount -a fonctionne et qu'il ne fait pas au boot. Tu as regardé les logs de démarrage ?

je n'ai que très, très rarement besoin de lancer des recherches sur autre chose que le sujet, l'expéditeur ou les destinataires de mes messages

Le problème c'est que le sujet n'est pas chiffré avec OpenPGP. Alors il y a des gens comme moi, quand ils envoient un mail chiffré, mettent en sujet « Mail chiffré ». Va faire tes recherches après avec des sujets aussi significatifs…

Au final, moi je fais des recherches par expediteur, destinataire et date… C'est limité, d'où l’intérêt de bien trier ses mails et ne pas compter sur google un système de recherche ultérieur.

Il est courant de noter en point la différence de deux proportions effectuées sur une population non constante.

Donc si je reprends les données du journal il s'agit bien d'un bond de 2.38 % à 4.21 %, et si on veut parler de la difference on va parler de 1.83 points de pourcentage et non 1.83 %, car parler de 1.83 % sous-entendrai qu'on est resté à population constante.

Après je répond juste à ce qu'est un point de pourcentage. Le commentaire initial qui demande si c'est un bond en points de pourcentage, j'avoue que je ne comprends pas.

Je te propose deux alternatives :

• Tu mets en place un serveur SMTP. Utiliser postfix dans ton c'est un peu utiliser une pioche pour planter une paquerette. Un serveur plus léger et plus simple à configurer comme opensmtpd (il est dans debian testing, et il se backporte facilement sur stable) peut être un bon choix.

• Tu code ton propre serveur smtp qui recevra le mail et fera la requete. Cela parrait difficile, mais en fait il ne suffit que d'utiliser l'implementation de twisted, et il y a même un tutorial pour réaliser un serveur SMTP.

Et en dernière alternative, que je ne te propose pas, mais qui existe, si tu as envie de te pourrir le cerveau et que tu es un masochiste à un stade avancé, tu peux configurer exim.

Alors vous avez en plus des disques pour les données, ok. Donc ma remarque sur la taille tombe à l'eau.

Si je demandais pour le moyen de transport, c'est que pour moi, tout ce qui est info (portabe et disque) ça va dans la remorque mono-roue. Une remorque mono-roue ça ne vibre pas beaucoup et c'est idéal pour transporter le materiel. (Je viens de passer d'acheter une mono-roue, par rapport à la remorque classique à deux roues que j'utilisais avant, ça n'a rien à voir au niveau vibrations et effort sur le pédaleur). Par contre aucune nécessité de séparer les sauvegardes, à moins que tu envisage le cas attaque par des zombis, si l'un survit il aura les données, par contre avoir deux copies c'est une bonne idée.

Après je le redis car je le pense, 2GiB pour traiter des raws pour moi c'est faible, mais c'est mon avis. darktable c'est bien, et au niveau distrib, ce que vous voulez. (Je n'ai rien dit pour le traitement des fichiers audio, car je n'y connais… rien).

L'essentiel est surtout de vous familiariser avec le système et les logiciels avant de partir, au moment où vous avez accès à tout le nain-ternet.

Et ton sac tu le met où ? Surtout pas sur le bonhomme. Si tu ne veux pas te fatiguer inutilement le cycliste n'a aucun sac, et tu charge le vélo comme un mulet. Sacoches avant et arrières + remorques.

C'est vrai que je viens de faire le calcul, ça fait 22km par jour en moyenne. Et 29km en altérnant un jour de repos pour trois jour de vélo.

Mais peut-être qu'ils ont prévu plein de choses en plus du vélo, et donc ça explique la nécessité d'un ordinateur.

Tout d'abord à propos de la machine.

• Comment comptez-vous la transporter ? Sacoches, remorques, remorque monoroue ? Et quelle protection ? J'ai déjà fait de la rando vélo avec un ordinateur, c'est quelque chose à prendre en compte pour le choix de la machine (solidité, masse…).

• Es-tu sûr que de GiB de RAM est suffisant pour ton usage ? Je traite de temps en temps des raws avec ma machine, et j'utilise pour cela environ 4 GiB de RAM, après ça dépends de ce que tu fais, mais perso quand ça se met à swapper je deviens fou.

• SSD ou disque dur de 128 ou 256 GiB… Dans les deux cas c'est pas suffisant pour garder en stock vos six mois de voyages. Ça passe si vous faites le traitement au fur et à mesure, mais vous ne pourrez pas garder les raws. Après vous prévoyez peut-être d'uploader au fur et à mesure les raws. Pour avoir déjà vécu deux semaines de rando vélo avec une connexion aléatoire, ça me semble hasardeux.

À propos de l'OS et des logiciels.

Ce qu'il vous faut c'est installer un OS stable, et vous n'avez semble-t'il aucun besoin de temps réel, donc ubuntu studio n'apparait pas necessaire, et utiliser un noyau temps-réel si vous n'en avez pas besoin, c'est au mieux inutile.
Après au niveau soft, pour le traitement photo perso j'ai un fort amour pour darktable. Mais l'essentiel est que vous prépariez la machine bien avant de partir, et que vous vous entrainiez à utiliser les logiciels avant de partir, ainsi si vous avez des problèmes, vous pouvez encore les corriger. Il faut aussi que vous téléchargiez toute la doc possible et inimaginable.

Et enfin pour vous faire peur, vous avez prévu quoi si la machine vous lache en plein millieu ? Dans une modeste rando vélo de quelques centaine de kilometres sur une dizaine de jour mon ordi m'a laché, il me servait pour les itinéraires… Ça arrive ce genre de chose.

Ce n'est pas de toi dont je parlais, nous savons bien tous ici que tu n'as aucune haine contre ce système d'exploitation (il n'y a aucune attaque dans cette phrase).

Tes arguments sont recevables, mais ils ne contredisent pas les miens. Je ne me fais aucune illusion, avec une distribution libre, nous sommes potentiellement soumis au même risque, que nous ayons accès aux sources ou non. La proportion de personnes lisant les sources, et étant en mesure de faire une analyse assez poussée pour détecter une faille vicieusement introduite est absolument ridicule.

Alors oui, il est plus simple de le faire sur du code fermé, il n'y a pas à écrire du code vicieux qui passe pour du code anodin, mais à mon sens c'est négligeable. Vu les moyens de la NSA, entre introduire une backdoor visible dans le code avec une procédure de collaboration de Microsoft ou introduire une backdoor avec du code vicieux en apparence anodin dans une distribution libre, ils ont probablement les moyens de faire les deux.

Quand je parlais de bugs, il fallait lire code au comportement anodin ayant un effet différent que celui qui est affiché, comprendre que ça inclue les failles potentiellement volontaire.

Pour moi, l'accès au code source, et la possibilité de compilation de code modifié, offre plein d'avantages, mais pas celui de lutter contre des backdoors volontairement introduites, dans un cas on a une procédure de pression sur l'éditeur, dans l'autre cas on a un déploiement de trésors d'inventivité comme la modification de l'aléa des générateurs pseudo-aléatoire, la proposition d’algorithme cryptographique, l'écriture de code très vicieux. La NSA ne semble être à court ni de moyens ni d'inventivité.

À un moment il faudrait arrêter de faire les gamins.

Je n'utilise pas windows mais je n'ai aucune haine contre ce système d'exploitation. Il faudrait arrêter de toujours vouloir dire que ce qu'on utilise est le meilleur de ce qui existe en dénigrant tout le reste. Et en plus en arrêtant le dénigrement systématique on y gagne en crédibilité, du moins avec les gens n'étant pas soumis à un aveuglement.

En quoi le fait que les organisations gouvernementale puisse recompiler le code source qu'elle reçoivent de Microsoft nous concerne t'il ? Nous n'avons pas accès au code source de Microsoft, qu'ils puissent le recompiler ou non après l'avoir reçu, comme dirait notre ancien président, ça m'en touche une sans faire bouger l'autre. J'ose espérer que les organisations gouvernementales savent ce qu'elle font, et il serait un peu prétentieux de dire qu'elle ne font qu'un partie du boulot et que nous grands savant de dlfp connaissont mieux leur boulot.

Après il faut aussi être réaliste, l'accès au code source et pouvoir le modifier c'est bien, c'est bien pour ajouter des fonctionnalités, faire autre chose que ce à quoi il est destiné, bref jouir du logiciel de manière complète. Par contre pour la sécurité, seulement une petite partie des failles est trouvée par une analyse du code source, et d'autre techniques comme le fuzzing donnent des résultats autrement plus intéressants.

Je crois que j'ai confondu avec zhe.

Est-ce que xhe est une abomination de plus dans le même goût ?

(Je trouve que le temps pour éditer son message est trop cout. Voici que je suis en train d'être obligé de me répondre, c'est comme ça que commence la folie.)

Il me semblait que xhe était une horreur introduite pour remplacer he or she, en gros l'invention américaine pour remplacer le they singulier, trop britanique à leur goût (et surtout trop correct à mon sens). Donc ça me semble en plus d'être une abomination (le fait de mettre xhe quel que soit le contexte), une erreur ici de remplacer the par xhe.