🚲 Tanguy Ortolo a écrit 12689 commentaires

À noter qu'ifupdown prend nativement en charge les profils de connexion. On peut ainsi définir des pseudo-interfaces :

iface chezmoi inet dhcp
 wpa-conf /etc/wpa-supplicant/chezmoi.conf
iface boulot inet dhcp
 wpa-conf /etc/wpa-supplicant/boulot.conf

Puis selon l'endroit où on est, lancer la bonne commande :

# ifup wlan0=chezmoi
# ifup wlan0=travail

Même chose, c'est le gestionnaire de connexion de Debian.

Es-tu vraiment Cykon Technology Limited, propriétaire du nom de domaine greuh.com ?

Si ce n'est pas le cas, répète après moi : inventer des noms de domaines fictifs ou pire, utiliser des noms de domaine réels à titre d'exemple, c'est mal, il faut utiliser les noms de domaines dédiés à cela que sont example.com, example.org, example.net, example.edu et les noms de domaine de niveau supérieur example, test et invalid.

Donc:

send-hook '~t kiki@*.*' my_hdr From: "kiki kiki@greuh.com"

serait fonctionnel ?

Ben oui, c'est ce que j'avais donné comme exemple hein.

Par contre tu fais exactement ce que tu dénonces, tu mets en comparaison un jeu 2D et un jeu 3D en disant : graphismes 3D < graphismes 2D.

C'était une comparaison grossière, mais l'idée, c'est que pour atteindre en troidé une qualité semblable à ce qui a pu se faire à plat, il faut un matériel très haut de gamme, même aujourd'hui. Pour ce jeu précis, c'est très, très loin d'atteindre la qualité de trucs comme Blade Runner par exemple.

C'est faisable.

set from="tanguy@ortolo.invalid"
send-hook . unmy_hdr From:
send-hook '~t @.*.debian\.' my_hdr From: "Tanguy Ortolo <tanguy+debian@ortolo.invalid>"

La première ligne définit l'adresse qui est utilisée par défaut pour construire le champ From des messages envoyés. La troisième ligne surcharge cette adresse en forçant la mise en place d'un en-tête personnalisé From:, lorsque j'écris à une adresse liée au projet Debian. La seconde ligne s'assure que dans tous les cas, cet en-tête qui a pu être défini lors de la rédaction d'un message précédent, est supprimé, laissant la place au mécanisme de construction du champ From: par défaut à partir de la variable from définie à la première ligne.

Il s'agit d'un jeu d'aventure Point & Click comme on le faisait dans les années 90s, mais en plus beau (Monkey Island pour les vieux de Linuxfr)

Mouais, pas convaincu. J'ai regardé les captures d'écran : visiblement il s'agit d'un jeu en troidé, donc très moche par rapport à ce qui peut se faire à plat. Dommage.

Enfin ça contient pas mal d'info de pourquoi et comment internet ;)

On cherche encore à m'invoquer, c'est ça ?

ZOMG le nom de l'application…

Tu oublies tout simplement les gens qui ont acheté pour se loger puis ont un taf ailleurs, doivent vendre et acheter ensuite, mais dont le crédit courra toujours sur la somme initiale, donc grosse perte financière par rapport à la location initiale, et donc surface en moins en pratique (dommage hein).

Aucune perte ici. Une dépense initiale plus importante que celle qui aurait pu avoir lieu s'ils avaient acheté plus tard, ce qui est le premier cas que j'ai identifié.

Bah, si l'idée qu'il ne faut pas acheter pouvait se répandre et provoquer un bon vieux krach immobilier, ça ne pourrait faire que du bien :

• les gens qui ont acheté une maison pour y vivre n'y perdraient rien puisque s'ils y vivent, ils n'ont pas à la vendre et son prix ne leur change strictement rien (ils peuvent être dégoûtés d'avoir acheté avant le krach, mais ça n'a aucune conséquence pratique) ;
• les gens qui ont acheté pour stocker de l'argent y perdraient, mais ce n'est pas grave parce que de l'argent dans un coffre, même si ce coffre a une forme de maison, ne sert à rien et ne manque à personne s'il disparaît ;
• les gens qui ont acheté pour spéculer y perdraient, mais c'est une bonne chose parce que détourner la fonction normale de l'immobilier (loger des gens) pour en faire un support de spéculation, c'est mal ;
• les gens qui cherchent à acheter pour se loger y gagneraient, ce qui est une excellente chose parce que c'est quand même le but normal de l'immobilier ;
• les gens qui ont acheté pour se loger mais compte déménager n'y gagneraient ni n'y perdraient rien si les prix s'effondrent partout (moins cher vendu, mais maison suivante moins cher achetée).

Et bien figurez-vous que la réponse est…

Vu la façon dont tu poses la question, je m'attendais à une réponse intéressante. Sauf qu'en fait non.

(à quand OpenWrt vodka-pomme ?) ;-)

Pfiou, ça devient un truc de riche, OpenWrt, avec ce dernier cocktail, il faut acheter plein d'ingrédient, les précédents étaient plus simples, avec des ingrédients plus communs :

• Backfire : crème de whiskey, liqueur de café et vodka ;
• White Russian : liqueur de café, vodka et crème.

Quoi qu'il en soit : santé !

Non, seulement du Web.

Il ne faut pas utiliser de pseudo nom de domaine imaginaire lorsqu'on veut donner un exemple : truc.tld, mondomaine.com, moi.domain, toutes ces horreurs sont à proscrire à cause du risque de collision avec un nom de domaine qui pourrait exister.

À la place, il faut utiliser les noms de domaines standards réservés pour cet usage : example.com, example.org, example.net, example.edu, ainsi que les pseudo-noms de domaines de niveau supérieur example, invalid et test.

Je ne vois pas Mozilla dans la liste des auteurs de cette lettre. Savez-vous s'ils ont été contactés, ou s'ils s'en fichent ?

La vidéo ne serait pas disponible sous un format librement lisible par hasard ?

À ce que je vois, il s'agit d'URI de type URL. Est-ce vraiment pertinent ? Tout comme les schémas news, mid et magnet, cela me semble un mésusage des URL pour ce qui devrait être des URN…

Cela répond au problème de faire transiter le mot de passe en clair, ce qui est la question de ce fil.

Oui, ça y répond, c'est même une des deux solutions que j'ai indiquées, à savoir : la mauvaise, où le mot de passe est stocké en clair sur le serveur.

donc non, pas besoin de transferer un mot de passe en clair, ou d'équivalent au mot de passe.

Si. Dans l'exemple que tu donnes, le mot de passe en question, stocké en clair côté serveur, c'est la clef HMAC.

Dynamique, je sais ce que ça veut dire, une liste aussi je sais ce que c'est, SPF je connais, mais qu'est-ce que c'est qu'une liste SPF ?

Qu'est-ce que c'était que ce truc au juste ?

Je prends les devants avant qu'on ne me réplique qu'avec l'identification Digest de SIP, le mot de passe n'est pas stocké en clair : c'est techniquement exact mais ce qui est stocké, qui est un hachage du mot de passe et d'une information de domaine, est suffisant pour s'identifier, et constitue donc le mot de passe réel.

À noter que, pour pouvoir ne stocker qu'un hachage du mot de passe sur un serveur, il faut que ce mot de passe soit transmis en clair au code de vérification lors des tentatives d'identification. Ce problème peut être résolu de deux façons :

• une bonne : sécuriser l'étape d'identification avec une couche de chiffrement comme TLS ;
• une mauvaise : passer à un système d'identification par défi-réponse, qui implique… de stocker le mot de passe en clair sur le serveur !

À noter qu'au moins un protocole, SIP, interdit « pour raisons de sécurité » les identifications par mot de passe simple, et propose à la place, toujours « pour raisons de sécurité » une identification par défi-réponse…