Mais libre à toi de choisir un fournisseur d'accès à Internet v6 à utiliser par-dessus ton accès à Internet v4. C'est à mon avis bien plus simple à mettre en place que du double NAT ou des vues DNS.
mettre en place un système de mise à jour dynamique du DNS, avec une clef pour cette machine de la morte, qui n'autorise qu'à mettre jour les enregistrements TLSA ;
[^] # Re: Romulien
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Microsoft ♥ France. Évalué à  3.
Eh bien je te laisse y répondre, en ce qui me concerne peu me chaud, j'ai mieux à faire que perdre du temps de telles arguties linguistiques, surtout considérant le fait que nous ne connaissons pas la langue du Borg.
[^] # Re: Romulien
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Microsoft ♥ France. Évalué à  3.
Tentative de troll détectée, désolé.
Le Borg communique par la pensée, donc l'écriture n'est pas pertinente. Vu le genre de civilisation dont il s'agit, il y a des chances qu'ils ne pensent pas sous forme verbalisée comme nous le faisons, donc même la prononciation ne devrait pas y est pas pertinente.
[^] # Re: J’ai pas tout compris mais j’y mets mon grain de sel quand même
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal des (autres) listes de mots pour générer des phrases de passe en français . Évalué à  4.
Oui, la méthode 936, c'est bien, d'ailleurs moi aussi j'ai maintenant pour mot de passe “correct horse battery staple”.
Sérieusement, c'est marrant, cette méthode, mais ça ne donne des trucs faciles à retenir que si on a beaucoup de chance.
[^] # Re: Romulien
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Microsoft ♥ France. Évalué à  4.
Pour un contre-exemple, évoquons le cas du Borg. En anglais, c'est un nom collectif, comme “people”, qui est au singulier mais avec lequel les verbes s'accordent au pluriel, ce qui colle très bien avec les caractéristiques du Collectif : “We are the Borg.”
La traduction française est « Borgs », ce qui est à mon avis une erreur : « Nous sommes les Borgs. » Il eût mieux valu conserver une forme plus proche de la traduction anglaise, comme « Nous sommes le Borg » — ce n'est pas délirant, on pourrait dire de même « Nous sommes l'Humanité » — ou encore « Nous sommes le Collectif Borg ».
[^] # Re: Romulien
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Microsoft ♥ France. Évalué à  5.
Disons que pour savoir si le mot “Romulan” doit être ou non traduit en français, j'ai comment il était formé. C'est une construction classique de gentilé — le nom des habitants — à partir du nom propre « Romulus » qui se trouve être du latin. Dans l'univers de Star Trek, « Romulus » est censé être un mot latin qui a été choisi pour désigner en anglais une planète dont le nom local n'a strictement rien à voir. Dans la vraie vie, c'est un mot latin qui a été choisi par le scénariste pour son évoquer l'empire romain.
Dans les deux cas — dans la fiction comme dans la réalité — le sens du mot “Romulan” est à au mot latin « Romulus » dont il dérive, et non au côté anglophone du suffixe « -an ». Il n'y a donc aucune raison de conserver la forme anglais “Romulan” dans un texte en français, et nous pouvons donc utiliser à la place la forme française « Romulien » qui nous est plus naturelle.
C'est comme pour les Ligoniens que tu as évoqué : en anglais, ce sont des “Ligonians”, mais ça se traduit.
# Romulien
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Microsoft ♥ France. Évalué à  6.
En français, on dit « romulien », me semble-t-il. « Romulan », c'est clairement de l'anglais, et ça n'a pas vraiment d'intérêt, s'agissant d'un nom qui est — grammaticalement — une construction classique sur un terme latin et — dans la fiction de Star Trek — une traduction d'un terme romulien qui n'a strictement rien à voir.
C'est comme pour les Vulcains, on n'a pas vraiment de raison de les appeler des Vulcans.
[^] # Re: Pointeurs multiples
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à  4.
Oui, c'est ça. Après, à moins d'avoir des logiciels faits pour cela, ça ne sert pas à grand chose je pense.
[^] # Re: Pointeurs multiples
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à  2.
Argh, si c'est le cas, décidément, ce n'est pas demain que je passerai à Wayland. Mais bon, ça doit dépendre du compositeur ça, et de toute façon, si je passe à Wayland, ce sera pour un compositeur pavant, pas pour celui de Gnome. :-)
[^] # Re: Pointeurs multiples
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à  10.
Ce n'est pas tant que cette option soit désactivée, c'est simplement que ça n'a pas de sens sans réglage.
Il y a une notion de pointeurs et de claviers maîtres, qui sont affichés et exposés aux logiciels. Grossièrement, un pointeur maître, c'est une flèche à l'écran, et un clavier maître, c'est un curseur de saisie.
Ces périphériques maîtres sont associés par deux, un pointeur et un clavier maître à chaque fois.
À côté de cela, il y a les périphériques réels, dits asservis, qui sont tous attachés à un périphérique maître. Quand on bouge une souris physique, ça envoie les événements correspondants au pointeur maître auquel elle est attachée. De même, quand on appuie sur une touche d'un clavier, ça envoie l'événement correspondant au clavier maître auquel il est attaché.
Par défaut, il y a une seule paire de périphériques maîtres, donc un pointeur maître et un clavier maître associé, et tous les périphériques réels y sont attachés, afin que quand on bouge un souris, ça bouge le pointeur à l'écran, et que quand on tape sur un clavier, ça écrive dans la zone de saisie qui a le focus. Par exemple, chez moi :
À partir de là , on peut s'amuser à détacher des périphériques physiques : leurs événements ne sont alors plus transmis nulle part. Attention, c'est un bon moyen de se blo
On peut créer une nouvelle paire de périphériques maîtres, et y attacher des périphériques (si on a effectivement plusieurs souris, tablettes graphiques, joysticks et claviers, sinon ça ne sert à rien) : à l'écran, ça donne un pointeur supplémentaire, et potentiellement un focus de saisie supplémentaire.
Pour en revenir sur ce que je disais au début, en fait XInput est activé par défaut, seulement avec la seule configuration raisonnable et non troublante : tous les pointeurs et tous les claviers sont fusionnés.
# Pointeurs multiples
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à  8.
D'où sort cette affirmation ? Avec XInput, on peut tout à fait avoir plusieurs pointeurs, et plusieurs claviers d'entrée bien distincts ! Ça se comporte certainement de façon étrange pour des logiciels qui ne sont pas prévus pour cela, mais côté serveur X, c'est prêt.
# Wayland et copier-coller Ă la souris
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à  6.
Est-ce à dire que le copier-coller à la souris a finalement été implémenté ? Parce que sans ça, il y a toute une catégorie d'utilisateurs, notamment de développeurs, qui ne passeront pas à Wayland.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  3.
Mais libre à toi de choisir un fournisseur d'accès à Internet v6 à utiliser par-dessus ton accès à Internet v4. C'est à mon avis bien plus simple à mettre en place que du double NAT ou des vues DNS.
Comment ça nom de domaine HS ? Si tu as un de tes serveurs de nom chez toi, coupé d'accès à Internet, tu peux toujours résoudre tes noms. Pas les autres noms, mais les noms de ta zone DNS, si.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  5. Dernière modification le 26 septembre 2016 à 12:52.
Eh bien, tout va bien alors, Let's Encrypt est une CA moderne, parce qu'ils ne posent aucun problème avec HPKP et DANE. Avec HPKP, c'est la clef publique qui est épinglée. Avec DANE, tu as le choix, donc tu peux épingler la clef publique. Il suffit, tous les 90 jours, de changer, non pas de clef et de certificat, mais seulement de renouveler le certificat avec la même clef, et ça roule, rien à changer pour HPKP ni DANE.
Ah, c'est vrai, ta religion t'impose d'épingler le certificat et de changer de clef tous les 90 jours, c'est ça ?
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  4.
N'importe quoi. Ça permet certaines attaques qui sans cela seraient impossibles, mais ça conserve au contraire une bonne partie de l'intérêt de DNSSEC, à savoir de rendre la falsification de réponses DNS beaucoup plus difficile. Sans DNSSEC par exemple, contrôler un bout du lien entre le client et un serveur de nom faisant autorité pour une zone donnée suffit à changer les réponses pour ce qu'on veut. Avec DNSSEC, ce n'est plus possible, il faut avoir accès à la clef de signature de la zone.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  4.
Encore une fois, il y a une solution simple (IPv6 et pas de NAT), et d'autres solutions compliquées, c'est au choix.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  4.
Quand on n'utilise pas franchement des algorithmes à courbe elliptiques, qui permettent de réduire considérablement la taille des enregistrements pour une sécurité identique, voire supérieure.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  4.
Il y a une autre raison : il est beaucoup plus facile de changer de ZSK que de KSK, cette dernière devant être déclarée au bureau d'enregistrement, ce qui s'automatise assez mal.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  3.
Oui, puisqu'il n'y aura pas de NAT. Le nom de domaine de ton serveur résoudra sur son adresse IPv6, qui sera joignable depuis l'intérieur comme depuis l'extérieur.
C'est un peu hors sujet, parce que récupérer l'adresse d'un truc qu'on vient d'installer, c'est plutôt une question pour ceux qui ont fait la procédure d'installation. Tu peux toujours faire un nmap sur le sous-réseau IPv6, même si ça risque d'être un peu plus long. Il y a sans doute des outils plus appropriés ; personnellement, si un mDNS est installé sur cette nouvelle machine :
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  3.
Dans ce cas, tunnel. Avec SixXS par exemple.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  3.
donc tu passe en IPv6.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  5.
À noter qu'avec Let's Encrypt, s'il est nécessaire de changer de certificat au moins tous les 90 jours, et qu'il est en pratique recommandé de le faire tous les 2 mois, il n'est nullement nécessaire de changer aussi souvent de clef. Le client officiel, Certbot, génère effectivement une nouvelle clef à chaque fois, mais ce n'est pas obligatoire, et d'autres implémentations permettent de renouveler les certificats existants à la place.
Compte tenu de ceci, si veut limiter la fréquence des changements, il est pertinent de procéder à des renouvellements sans changer de clef. Si on veut également mettre en place HPKP et DANE, on peut alors épingler non pas le certificat, qui changera tous les deux ou trois mois, mais la clef publique, qui demeurera tant qu'on ne l'aura pas manuellement changée.
Ainsi, si la récupération des certificats a lieu sur une machine donnée, celle-ci n'a plus besoin de pouvoir mettre à jour des enregistrements DNS, seulement de fournir les certificats renouvelés aux serveurs qui les utiliseront.
En suivant la recommandation de renouvellement tous le deux mois, cela laisse une marge d'un mois pour que les serveurs les récupèrent, ce qui peut très bien se faire de façon tirée, sans aucune synchronisation. Personnellement, je recommanderais d'aller chercher les éventuelles mises à jour toutes les semaines.
Maintenant, on peut avoir des raisons personnelles pour ne pas vouloir telle ou telle étape de ce système, par exemple parce qu'on n'aime pas PKIX-EE ou DANE-EE avec SPKI (cf. http://www.bortzmeyer.org/7218.html), mais ce sont là des contraintes qu'on s'impose, et en aucun cas des raisons de blâmer Let's Encrypt.
En clair, si tu veux changer de clef à chaque fois, et utiliser HPKP et DANE, oui, il va falloir mettre à jour des trucs qui, sans cela, auraient pu être laissés, mais c'est ton choix, donc ton problème. Et si tu veux épingler, non pas la clef, mais le certificat ou l'AC, il va aussi falloir mettre à jour des trucs, mais encore une fois, c'est ton choix, donc ton problème, pas celui de Let's Encrypt.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  6.
Mais non. C'est trop compliqué pour l'utilisateur qui veut héberger son blog sur un système distribué et redondant pour avoir une haute disponibilité. Or ça, excuse-moi mais c'est tout sauf un utilisateur lambda. Et accessoirement, ce n'est pas de l'auto-hébergement, à moins d'avoir plusieurs maisons.
Je ne devais pas être au courant de ce détail, c'est pour ça que j'ai pu réussir à l'utiliser. Et sans problème, je dois dire.
S'il ne possède pas d'alternative, ce n'est pas leur faute, c'est seulement que personne n'en a proposé. Au boulot, donc.
Décidément, c'est une manie…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  4.
Un des buts de Let's Encrypt étant de favoriser l'automatisation, ça n'arrivera pas.
Vu tes idées et ton goût pour la maintenance manuelle, je suggérerais plutôt de monter une alternative à Let's Encrypt, proposant le même service mais sans le but d'automatisation.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  4.
Je ne connais pas les détails d'HPKP, ne m'y étant pas intéressé parce que cette idée me semble foireuse, mais concernant TLSA, il me semble qu'on peut avoir plusieurs enregistrements à la fois, ce qui résoudrait le problème ici : au renouvellement du certificat, ta machine de la mort ajoute un TLSA, et ensuite les serveurs ont un mois pour tirer le nouveau certificat avant que le précédent expire. Lorsqu'il expire, la machine de la mort retire l'ancien TLSA.
Pour sécuriser encore plus cela, et éviter que ta machine de la mort ait la main sur tout le DNS, tu peux au choix :
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à  5.
Eh bien, ça confirme que cette difficulté d'automatisation tient à ton infrastructure particulière, pas aux caractéristiques du service de Let's Encrypt.
Personnellement, à ta place je mettrais en place un système tiré. Tous les deux mois, ta machine spéciale fait signer et récupère un nouveau certificat, et toutes les semaines par exemple, tes machines tirent le certificat et relancent ou rechargent d'elles-mêmes leurs services. Si tu veux faire plus fin, elles peuvent ne relancer ou recharger leurs services que si le certificat a changé et après vérification de sa validité. Ça n'a pas besoin d'être spécialement synchronisé. Avec ce système, ta machine de la mort n'a plus d'accès root pour faire n'importe quoi, seulement moyen de filer de la merde comme certificat, ce qui est infiniment plus facile à résoudre en cas de problème, et rien de plus.
Si tu préfères faire ça à la main une fois par an, tu n'es pas obligé de te fournir chez Let's Encrypt. Et ce n'est pas une raison pour leur reprocher… pour leur reprocher quoi, au juste ?
Lapin compris.
Comme je l'indique plus haut, tu peux l'automatiser, seulement tu as choisi de bouder cette possibilité pour des raisons qui t'appartiennent. C'est ton choix, donc tu ne peux pas en blâmer Let's Encrypt.