🚲 Tanguy Ortolo a écrit 12224 commentaires

Parce que c'est mieux que de ne pas chiffrer du tout. Le chiffrement sans authentification est vulnérable aux attaques par réécriture, mais pas aux écoutes passives.

On ne t'a pas attendu pour ça !

https://en.wikipedia.org/wiki/DANE
http://www.bortzmeyer.org/6698.html
https://tools.ietf.org/html/rfc6698

Reste à convaincre les éditeurs de logiciels clients de s'y mettre. Bon courage.

Même avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du http.

Pluzun. C'est d'ailleurs un gros problème des navigateurs actuels, pour lequel j'avais ouvert un rapport de bogue sur Firefox : lorsqu'un utilisateur se connecte sur un serveur dont le certificat ne peut pas être validé, il y a un avertissement effrayant, alors que lorsqu'il envoie en clair un mot de passe, ce qui est bien pire, il n'y a aucun avertissement.

J'ai commencé la construction d'un site web pour la première fois et j'ai choisi de rediriger tout le traffic vers l'HTTPS par défaut.

Ce qui est une grave erreur. En effet, le visiteur peut ainsi s'habituer à taper l'adresse sans HTTPS et se reposer sur la redirection sans y prêter attention. En cas d'attaque, la première chose que fera un pirate en interception et réécriture sera de faire sauter la redirection en question et de laisser l'internaute rester en HTTP.

Il y a plusieurs alternatives à cette approche dangereuse :

1. ne pas fournir du tout d'accès HTTP : l'internaute qui essaie sans HTTPS tombe sur un refus de connexion et doit de facto s'habituer à bien demander du HTTPS ;
2. fournir un simple page d'erreur en HTTP, expliquant qu'il faut bien taper HTTPS ;
3. utiliser HSTS, l'internaute essayant en HTTP se retrouvant dirigé en HTTPS et son navigateur retenant cela pour ne plus jamais y accéder en HTTP.

Par contre, GOG ne recompile pas ses jeux pour Linux avec Wine – je ne pense d'ailleurs pas qu'il disposent des sources pour cela.

Si ce sont eux qui s'occupent du portage, j'espère bien que si ! Si je m'occupais d'un portage et qu'un éditeur de jeux me refusait les sources, je crois que je l'enverrai chier illico : je ne peux pas bosser correctement sans cela.

En effet, l'UEFI est plus « moderne ». Façon Intel, qui ont considéré que la voie à suivre pour un shell moderne, par exemple, était de le calquer sur un grand modèle tel qu'MS-DOS : on trouve donc dans un shell EFI des lettres de lecteur et des \ comme séparateur de répertoires… De même, ils ont considéré que le meilleure chose à faire pour le format d'exécutable à adopter était de prendre exactement le même que celui de Microsoft Windows, de sorte qu'un file sur un exécutable EFI indique qu'il s'agit d'un exécutable pour Windows.

C'est aussi considérablement plus complexe qu'un BIOS, donc parfois considérablement plus bogué malheureusement.

EFI Stub

L'architecture ARM 64 bits dispose désormais de la gestion d'EFI stub. Linux EFI stub permet à un système disposant d'un firmware (U)EFI de démarrer l'image du noyau directement sans avoir à passer par un bootloader (tel que Grub ou elilo). Ceci est notamment possible en ajoutant du code au début de l'image du noyau afin de faire croire au firmware (U)EFI qu'il s'agit d'une image de type PE/COFF, de cette façon le noyau se fait passer pour un exécutable (U)EFI.

Pourquoi « faire croire » et « se faire passer » ? Le noyau, ainsi préfixé par un en-tête et un code initial approprié, ne devient-il pas un vrai exécutable PE/COFF pour UEFI ? Exécutable qui fera plein de trucs et cessera rapidement d'utiliser l'UEFI, ce qui ne change rien à sa nature initiale, si ?

Ce qui est justement un des deux usages de Wine, probablement le moins connu, puisque ce logiciel permet :

• de faire tourner des logiciels conçus et compilés pour Windows, sous une couche de traduction ;
• et donc, de compiler des logiciels conçus pour Windows, en les liant à la libwine, de façon à produire des binaires natifs pour GNU/Linux.

Ce qui est intéressant, c'est que les binaires résultants ne tournent pas sous Wine mais sont bel et bien des binaires natifs pour GNU/Linux, qui appellent simplement des fonctions de la libwine. Cela a également ceci d'intéressant que ces logiciels peuvent même éventuellement être ensuite partiellement adaptés et utiliser en même temps des fonctions tout à fait indisponibles sous Windows. Autrement dit, avoir accès aux deux API Win32 et POSIX.

Petite question : quel intérêt y aurait-il à activer la fonction UEFI, à part casser grub et l'install ?

Pour un simple utilisateur qui ne veut pas se prendre la tête, à peu près aucun. Pour un bidouilleur, le plaisir d'utiliser une technologie censée être conçue de façon moderne et plus souple que celle d'un BIOS, notamment pour la façon dont se fait l'amorçage. En effet, avec un BIOS, l'amorçage c'est :

1. chercher, dans une liste pré-configurée de périphériques, un code de démarrage ;
2. l'exécuter, dans un environnement standard ;
3. c'est ensuite à ce code, qui doit être minuscule (512 octets il me semble) de sauter sur un endroit où est vraiment stocké le code principal du chargeur de démarrage ;
4. c'est ensuite au chargeur de démarrage de proposer plusieurs possibilités de démarrage et de lancer un système d'exploitation.

En particulier, le BIOS ne prévoit rien du tout pour permettre de choisir entre plusieurs systèmes d'exploitation : c'est au chargeur de démarrage de le faire, et comme c'est aussi à lui de charger chaque système, cela donne de belles contorsions pour permettre de choisir entre un GNU/Linux (que GRUB sait lancer) et un Windows (que GRUB ne sait pas lancer, et pour lequel il doit passer la main au chargeur de Microsoft, qui doit donc toujours être là mais pas lancé directement à l'amorçage).

En UEFI, cela a été rationnalisé :

1. l'UEFI propose une liste pré-configurée de systèmes d'exploitation (en fait de chargeurs de démarrage), chacun correspondant à un fichier présent sur une partition spéciale formatée en FAT ;
2. selon le choix de l'utilisateur, il exécute le fichier correspondant au choix de l'utilisateur ;
3. le fichier en question est un chargeur de démarrage qui se charge donc de la suite.

Il y a là deux avantages sur le BIOS :

• le choix du système à démarrer ne dépend pas d'une bidouille impliquant de chaîner des chargeurs de démarrage mais est prévu par la norme, l'utilisateur pouvant définir une liste des systèmes disponible, chacun correspondant à un fichier à exécuter ;
• la mise en place d'un chargeur de démarrage est « propre », dans la mesure où elle consiste seulement à mettre un fichier sur une partition formatée en FAT, puis à passer un appel UEFI demandant d'ajouter une option de démarrage correspondant à ce fichier (à comparer avec la méthode BIOS qui consiste à mettre le code principal du chargeur de démarrage dans l'espace intersticiel entre le MBR et le premier cyclindre, puis à éditer les 512 octets de code de démarrage de la MBR pour y mettre un saut sur cet espace intersticiel).

Ça semble une très bonne occasion d'apprendre. Comme tu n'es logiquement pas encore développeur Debian, il te faudra un sponsor pour envoyer ce paquet : n'hésite pas à me contacter pour ça. D'ailleurs, si tu as des questions, pareil, tu peux me contacter, sachant qu'en période de vacances je ne peux pas toujours répondre très vite.

Si tu as besoin de documentation, il y a le wiki Debian, un guide du nouveau mainteneur Debian, et comme références la Charte Debian (Debian Policy) et la référence du développeur Debian.

Des tas d'accès très rapprochés, c'est quand on charge la CSS ou les images d'une page par exemple : dans ce cas, on peut envisager de ne faire qu'une seule résolution. Mais cacher pour des requêtes ultérieures, c'est une autre histoire.

Si, il y a un point commun, parce que dans les calendriers luni-solaires, l'année est en moyenne calée sur la période orbitale de la Terre autour du soleil, et que dans le seul calendrier purement lunaire utilisé, le calendrier musulman, l'année est certes différente mais assez proche, trop proche pour donner l'énorme écart de comptage mentionné plus haut.

Ben, vu que FDN passe par les DSLAM de Nerim, c'est mal barré…

Bon, je me réponds tout seul, ce sont les termes d'OVH. C'est inquiétant.

Au passage, j'ai regardé ce que Nerim proposait dans mon possible futur domicile : rien, absolument rien. Pas éligible à quoi que ce soit. Ça ne me surprend pas du tout, parce que pour de tous les endroits que j'ai essayés (chez mes parents, chez mes grands-parents, à mon domicile actuel), j'ai toujours obtenu le même résultat : pas éligible ou éligible seulement à des offres très chères.

• Débit correct et constant, étant un ancien abonné Free cela change la vie. Leur politique de "web neutre" a été un des arguments pour lequel je me suis abonné chez eux.

Tu fais exprès de répondre à une question de moi en parlant de neutralité du Web ? Ou sont-ce leurs propres termes ?

À noter qu'on peut payer par virement et pas seulement par prélèvement automatique.

Yeaaaaaaaaah ! Ça c'est la classe, le virement c'est un truc qu'on peut automatiser mais que le client contrôle totalement, contrairement au prélèvement qui revient à donner les clefs du comptes pour un usage discrétionnaire.

Ce ne serait pas une explication : il me semble qu'un point commun à tous les calendriers est la définition de l'année, faite pour coller plus ou moins bien avec une période orbitale de la Terre autour du soleil.

Bien vu, merci !

Damned, grillé !

Un complément d'Hugo Roy à ce sujet justement : http://hroy.eu/posts/jdn-licences-libres-5-approximations/

Pour remplacer le terme « contaminant », il propose « héréditaire ».

Bravo, c'est une réinvention de ce qui se fait depuis le début de SMTP : ce qui est à droite de l'@, c'est le nom de domaine ou l'adresse IP du serveur de destination.

Chez nous dans ce genre de cas, on écrit généralement de la part du collègue distrait des gentillesses à tout le monde, du genre : « Je vous aime tous et je vous fais de gros bisous. »

Avec des routes dynamiques par BGP donc. Ça implique d'avoir son AS, et la propagation de nouvelles routes n'a rien d'instantané.

Oui, d'ailleurs, si veut faire de la « disponibilité de services », il faut 2 repartiteurs de charge en failover, pour ne pas avoir de SPOF.

Pour avoir un SPoF de moins, parce que tu en auras toujours un avec ces techniques : ton FAI.