🚲 Tanguy Ortolo a écrit 12252 commentaires

Ext3 sans journal, ça s'appelle Ext2 puisqu'Ext3 est par définition Ext2 auquel a été ajoutée une journalisation. Mais pas de raison de se limiter à ça : tu peux utiliser Ext4 sans journal, et ça n'est pas Ext2, ça reste de l'Ext4. :-)

Sans journal, parce que sur une clef USB, mieux vaut limiter les écritures.

Si tu veux être à la pointe de la technologie, tu peux peut-être utiliser F2FS, mais je ne suis pas sûr que ce soit assez connu pour s'auto-monter facilement dans un environnement de bureau par exemple.

économie : la police de Bangkok (Thaïlande) pour avoir offert plus d'argent aux policiers qui refusent les pot-de-vins ;

Si j'ai bien compris, le but est d'encourager les policiers à payer un contrevenant pour qu'il tente de les corrompre, puis de refuser, et de partager avec lui la prime d'intégrité ?

Non, au contraire. Le second changement étant l'inverse du premier, ne pas faire le premier laisse une configuration prête pour l'étape 3. :-)

Tu aurais du matériel sur le sujet ?

Non, je n'ai que du logiciel.

D'accord, d'accord, ne poussez pas, je connais le chemin.

L’astuce de la « signature croisée » est de créer un autre certificat avec la même clef publique que le certificat racine, et de le faire signer par une autorité de certification pré-existante — ici, IdenTrust, dont le propre certificat racine est déjà dans les navigateurs.

C'est ça, sauf qu'ils l'appliquent en fait au certificat intermédiaire, si on regarde leur schéma indiqué plus haut.

2 - Cross-signature par une autre autorité connu par ton navigateur (Donc a partir de là ça marche "partout")

Non, c'est ce qu'ils semblent indiquer, mais c'est faux. Ça pourra marcher partout, pour les sites Web dont l'administrateur aura pensé à publier une chaîne de certification utilisant la version du certificat intermédiaire signé par cette autre autorité de certification déjà connue.

Un site Web qui aura commencé à l'étape 1 — avec la chaîne de certification utilisant la version du certificat intermédiaire signé par leur certificat racine reconnu par personne — et dont l'administrateur se sera ensuite endormi et n'aura pas modifié sa chaîne de certification, restera à l'étape 1 jusqu'à ce qu'advienne l'étape 3, où le certificat racine sera alors reconnu par tout le monde.

À noter également que l'étape 3 nécessitera également une action semblable de la part des administrateurs de sites. Mais facultative cette fois, car ne pas le faire fera simplement rester à l'étape 2, qui après tout fonctionne correctement.

Alors, pour comprendre tout ça, il faut bien distinguer clef privée, clef publique, certificat racine et certificat intermédiaire.

Aujourd'hui, Let's Encrypt signe les certificats qu'ils émettent avec la clef privée correspondant à une clef publique incluse dans un certificat intermédiaire nommée “Let's Encrypt Authority X1”, signé par la clef privée d'un certificat racine nommé “ISRG Root X1”, qui est par définition auto-signé, c'est à dire signé avec sa propre clef privée. Ce certificat racine est actuellement inconnu des navigateurs Web.

D'ici un mois, ils passeront donc à une certification par signature croisée. Autant que je sache, il s'agit d'une sorte de contournement d'une limitation de X.509 qui ne prévoit qu'une seule signature par certificat. Ce système donc, consiste à publier une seconde version du certificat intermédiaire “Let's Encrypt Authority X1”, ou peut-être de “ISRG Root X1”, portant le même nom et la même clef publique, mais signé par une autre autorité déjà largement reconnue. Cela ne déclenche rien de magique, en revanche, les administrateurs de sites utilisant un certificat signé par “Let's Encrypt Authority X1” peuvent alors choisir de publier cette seconde version du certificat intermédiaire, qui sera alors accepté par les navigateurs des visiteurs.

La mention de propagation de leur certificat racine est un peu ambigüe. Après la certification croisée, il va se passer deux choses :

• assez rapidement, les administrateurs de sites utilisant un certificat signé par “Let's Encrypt Authority X1” devraient manuellement changer la chaîne de certification qu'ils publient avec leur certificat, et y mettre la seconde version du certificat intermédiaire signé par une autre autorité ;
• plus lentement, les éditeurs de navigateurs devraient mettre à jour ceux-ci en y incluant le certificat racine “ISRG Root X1”.

Une fois ceci terminé, les administrateurs de sites pourront à nouveau changer la chaîne de certification, pour y remettre la première version du certificat intermédiaire, signé par “ISRG Root X1”, qui sera alors reconnu par les navigateurs à jour.

J'avais déjà entendu parler de ce truc, et après avoir regardé leurs explications, ça m'a l'air d'une jolie arnaque bien dissimulée. L'argument principal avancé pour promouvoir ce système de paiement est que l'utilisateur n'a pas besoin de transmettre son numéro de carte bancaire au marchand, mais seulement un identifiant et un mot de passe dédiés à Paylib. Or :

• c'est bidon, les sites marchands dignes de ce nom ne demandant pas les informations de carte bancaire, mais passant par une banque pour le paiement ;
• cela ne fait que déplacer le problème, les informations de carte bancaire étant simplement remplacée par les identifiants Paylib, qui suffisent tout autant à effectuer un paiement.

Alors, quelle différence avec le paiement par carte bancaire ? C'est indiqué dans la FAQ :

Que faire si je souhaite annuler une commande réglée avec Paylib, mon colis n’est pas arrivé, mon colis n’est pas conforme, je souhaite être remboursé…

Pour toute question relative à votre commande, nous vous invitons à vous rapprocher du e-commerçant chez qui vous avez réalisé votre achat.

Tiens donc… Avec un paiement par carte, la banque est tenue de rembourser en cas de débit frauduleux. Avec Paylib, on dirait bien que, les informations de carte bancaire n'entrant pas compte, l'utilisateur est seul responsable. Je comprends que ça intéresse les banques, du coup.

Pluzun. Le caoutchouc d'un chambre à air fait d'excellents élastiques, un peu plus durs que ceux qu'on trouve couramment, mais avec une excellente résistance au temps : un élastique ordinaire résiste quoi, un an avant de devenir cassant, alors qu'un élastique coupé dans chambre à air restera utilisable pendant des années.

Google : HEVC c'est trop cher, du coup on va développer un nouveau truc libre, VP9.
Cisco : HEVC c'est trop cher, et VP9 c'est NIH, donc on va développer un nouveau truc libre, Thor.
Plusieurs boîtes — donc Google et Cisco ! — : HEVC c'est trop cher, VP9 et Thor c'est NIH, donc on va développer un nouveau truc libre.

Au moins ça prouve qu'il y a un vrai intérêt, mais ça fait quand même bien 927.

Après le récent sondage sur la réception et l'envoi de courriels en texte brute ou html, on pourrait très bien imaginer envoyer du markdown qui serait rendu à la réception en html, auquel on pourrait répondre en markdown :)

On peut toujours rêver, mais ça restera à mon avis de l'ordre du rêve, sans jamais se concrétiser. Pour rappel, les formats prévus pour le courrier électronique, c'est text/plain, text/enriched et HTML (plusieurs types MIME pour celui-là je crois). Or justement, text/enriched, c'est ancien, assez chouette, très simple, et qui le prend en charge ? Aucun logiciel pour l'édition à ma connaissance, et assez peu pour la lecture…

Donc si je comprends bien ta réponse, pour résoudre un nom de domaine ou chercher une machine sur mon réseau local le résolveur (mon pc je suppose)

Non, le résolveur c'est celui qui est indiqué dans /etc/resolv.conf.

interroge son cache, si il y a rien il va sur un serveur racine, si y a rien il va chercher sur le DNS local ?

Oui, s'il s'agit d'une résolution sur un nom qui n'est pas dans une zone qu'il sert lui-même.

Je trouve pas très logique, surtout pour un domaine local. Il me semble plus normal d'interroger le DNS le plus proche et si il trouve pas il va chercher le suivant.

Désolé, j'avais mal compris la question, du coup je corrige ce que je disais. Pour une requête donnée, le résolveur :

1. si le nom demandé est dans une zone qu'il sert, il renvoie ce qu'il a à son sujet ;
2. sinon, si l'enregistrement demandé est dans son cache, il le renvoie ;
3. sinon, il interroge les serveurs racine, puis selon les réponses, des serveurs de plus en plus proches du nom demandé, jusqu'à obtenir une réponse qui fait autorité, qu'il place alors dans son cache et renvoie au client.

Pour les exemples, il ne faut pas inventer des noms.de.domaine.bidon, domaine.tld ou autres mon.dom. Il y a des noms de domaines dédiés à cela : example.com, example.net, example.org, example.edu, et un TLD .example.

L'avantage, c'est qu'il est garanti qu'ils ne seront jamais utilisés pour autre chose, contrairement aux exemples bidons qui peuvent être utilisés pour de vrai, et pour lesquels on risque de nuire à leur propriétaire en les utilisant comme exemples.

Alors, deux choses.

Premièrement, quand tu fais un dig +trace, tu ne testes pas du tout ton résolveur local ; au contraire, tu demandes à dig de ne pas l'interroger et d'effectuer lui-même la résolution. Cela effectue la même chose que ce que ferait ton résolveur, mais sans passer par lui.

Et deuxièmement, oui, ton résolveur se comporte ainsi, enfin presque. Pour être précis, pour une requête donnée, ton résolveur va d'abord chercher dans son cache, et s'il n'y trouve pas la réponse, il va d'abord interroger un des serveurs racine, et redescendre vers des serveurs de plus en plus proches du nom demandé en fonction de ce qu'il obtient à chaque étape.

Par ailleurs, SCP n'est généralement qu'un sous-ensemble de SFTP : cela utilise le sous-système SFTP sur l'hôte distant.

Non, désolé, en tout cas pas avec la commande scp d'OpenSSH. On le voit bien en désactivant le sous-système SFTP sur le serveur distant : on ne peut alors plus s'y connecter en SFTP, mais on peut toujours y déposer ou y récupérer des fichiers avec scp.

Tu obtiens des marges optiques,

C'est quoi ?

Le mien l'affiche, curieusement, sous la forme d'esperluettes avec empattement, ce qui est très moche compte tenu de ce que le reste du texte est affiché linéales chez moi.

Je suis intrigué par ces options, pourrais-tu préciser ce qu'elles font ?

\usepackage{microtype}

Style=Swash,Numbers={OldStyle,Proportional}

Enfin, Numbers=Oldstyle, je sais, ça demande d'utiliser des chiffres elzéviriens. Mais Numbers=Proportional, est-fce que ce ne serait pas la cas par défaut, et le contraire de Numbers=Monospaced ?

On peut faire du "FTPFS", ou du "HTTPFS" aussi si on a envie, c'est pareil

Ben non justement. Des pilotes de système de fichier par FTP ou HTTP émuleront certains trucs, genre à retransférer un fichier entier pour une simplement modification à l'intérieur, ces protocoles n'étant pas faits pour cela et ne fournissant vraiment pas tout ce qu'il faut pour les appels systèmes liés à la manipulation de fichiers.

Finalement, la question est sans doute : pour toi (c'est très subjectif…), c'est quoi un "vrai FS"?

Un truc qui fournit de quoi open(), write() read() lseek() et ce genre de truc.

Ça veut quand même dire, en fonction du client mail, que beaucoup de monde y a accès.

Pas forcément. Tu peux mettre tout ça dans un répertoire dont le contenu n'est pas listé par le serveur Web (Option -Indexes avec Apache), voire franchement à accès restreint par identifiant et mot de passe. Et avec un navigateur Web qui prend en charge la lecture vidéo, nul besoin d'enregistrer le fichier, il le lira directement.

Je repeins Obiwan Kenobi avec mon tambourin à vapeur et je saute trois cases.

20000km ça me parait léger comme durée de vie. Ceux qui font 10000 à 20000km par année ne changent pas de vélo tous les ans forcément.

Ceux qui roulent autant prennent sans doute des vélos de meilleure qualité que celui que j'avais acheté à l'époque, un peu en urgence d'ailleurs. Pour le prix que je l'avais payé, je m'estime heureux avec mes 20.000 km.

Tiens, tant que j'y pense, un avantage de l'acier, à ce qu'il me semble, c'est que, quand ça commence à se casser, ça se déchire lentement, ce qui laisse largement le temps d'aller en acheter un nouveau en roulant précautionneusement. En fait, mon premier vélo d'adulte en acier, après des années de service, a mis plusieurs mois à se casser après que sa barre inférieure eût commencé à se déchirer près du tube de fourche.

Tandis que l'aluminium, ça se déchire beaucoup plus vite : mon vélo suivant en alu, s'est cassé en une journée après avoir commencé à se déchirer au même endroit. Évidemment, comme c'était moins de 2.000 kilomètres après l'avoir acheté, il s'agissait clairement d'un vice caché, de sorte que je l'ai fait changer en faisant jouer la garantie ; après l'avoir changé, il a tenu un peu plus de 20.000 kilomètres, et a finalement commencé à se déchirer, toujours au même endroit : cette fois-ci, je m'attendais à ce que ça casse rapidement et à disposer de moins de 50 kilomètres pour en changer, et j'ai donc immédiatement été en acheter un autre avant qu'il ne lâche.

Pour mon premier vélo, je n'avais pas su identifier le problème, de sorte que je roulais comme si de rien n'était : pour les cyclistes inexpérimentés donc, si votre vélo commence à grincer quand vous êtes en danseuse, sans que vous puissiez identifier la cause, c'est qu'un tube de votre cadre a commencer à se déchirer et qu'il est temps d'en changer. Pas de panique toutefois, si votre vélo n'est pas un B'Twin à cadre design, la rupture d'un tube du cadre ne vous fera pas chuter : c'est un triangle, et avec un côté brisé, ça reste en un seul morceau, même si ça devient alors très fragile, et très mou, de sorte que ça se comporte très mal. Si votre vélo est un B'Twin, eh bien, ça dépend où ça casse : si c'est dans le triangle, tout va bien, si c'est dans la partie frontale qui n'a qu'un seul tube, c'est comme une rupture de fourche, vous êtes mort.

Oui et non. Les cadres acier, j'en ai plié/cassé quelques un.

C'est normal ça, un vélo n'est pas éternel, ça finit par casser. J'ai cassé un cadre acier après des années sans compteur, puis un cadre alu après un peu plus de 20.000 kilomètres — ce qui me semble plutôt raisonnable comme longévité — et j'utilise actuellement un cadre acier dont j'espère qu'il durera plus longtemps vu ce que je l'ai payé.

Et les cadres en acier, plus souple que l'aluminium qu'on trouve partout. En comparaison au carbone, je ne sais pas.