🚲 Tanguy Ortolo a écrit 12091 commentaires

J'ai rarement vu un mot aussi laid que ce « webinaire », suis-je le seul affecté par cette répulsion lexicale ?

À part ça et pour ne pas commencer et finir sur cette remarque négative et vaguement hors sujet, c'est cool, bonne idée que ces séminaires en ligne !

Ah, d'accord, mais ça aussi, ça vaut le coup d'expliquer pourquoi. La raison, c'est que des trucs comme fsck modifient les données, et qu'on peut vouloir repartir des données récupérées sans modification pour utiliser un autre outil. Or, pour ce faire, il faut disposer d'une sauvegarde de l'image récupérée, dans la mesure où relancer la récupération à partir du disque dur endommagé n'est pas du tout souhaitable.

Enfin, il faut toujours travailler sur un double.

Autant indiquer pourquoi ! C'est tout simplement parce que, si le disque dur est partiellement en panne, il est probable que cela ira en empirant, et que des zones de plus en plus grandes vont devenir inaccessibles ou corrompues. Du coup, plutôt que de travailler in situ, mieux vaut rapidement copier tout ce qu'on peut, ce qui permet ensuite d'avoir autant que temps qu'on veut pour travailler sur l'image ainsi récupérée en catastrophe.

GNU ddrescue est correctement conçu pour récupérer un maximum de données, n'hésitez pas à l'utiliser. Comme expliqué dans cette dépêche, lorsqu'il tombe sur une erreur, il saute une large plage pour s'éloigner au plus vite de cette zone et éviter ainsi d'endommager encore plus le disque dur, puis, quand il a fini de récupérer ce qui est facilement récupérable, il repasse plus finement sur les zones à problèmes.

dd_rescue au contraire, est à fuir comme la peste, parce qu'il est très mal conçu pour récupérer des données, ou alors très bien conçu pour en perdre un maximum, selon la façon dont vous le prenez : lorsqu'il tombe sur une erreur, il passe immédiatement plus finement dessus, histoire d'être sûr de bien flinguer le disque dur ou la tête de lecture…

Ça enlève quoi à l'architecte que le bâtiment qu'il a dessiné soit photographié puis imprimé à des milliards d'exemplaires ?

Ça l'empêche de réclamer du fric dessus. Ce qui est totalement indu, puisqu'il a déjà été payé pour son boulot.

Si on veut améliorer la sécu, ça va « forcément » passer par une décision unilatérale et violente des navigateurs et autres, qui va laisser beaucoup de monde sur le carreau.

Je confirme, et j'ai vécu ça au travail. On héberge des clients, et un jour, on nous a demandé d'appliquer une politique de sécurité précise, qui incluait entre autre la désactivation de la prise en charge SSLv3. Cette politique de sécurité n'étant pas du tout optionnelle, on l'a appliquée, sachant très bien que ça allait râler. Et ça n'a pas loupé, une semaine après, on a vu arriver des demandes provenant de notre support client, qui ont donné lieu à des échanges comme :

• Tel client a une erreur « trucbidule SSLv3 not supported », il faut que vous répariez ça.
• C'est normal et voulu, on a désactivé SSLv3. Le client doit mettre à jour ses systèmes. (Ticket fermé par le sysadmin)
• Ça ne va pas, ils ne peuvent plus du tout utiliser leur plate-forme. Il faut que vous réactiviez ça. (Ticket rouvert par le support client)
• On l'a désactivé parce que c'est interdit par la nouvelle politique de sécurité et on ne reviendra pas dessus. Le client doit mettre à jour ses systèmes. Il n'y a pas de solution alternative. (Ticket fermé par le sysadmin)
• On ne peut pas demander ça au client, c'est un problème critique de production. Réactivez SSLv3. (Ticket rouvert par le support client)
• C'est interdit, on ne peut pas faire ça. Je transfère à la hiérarchie pour confirmation. (Ticket envoyé à la hiérarchie par le sysadmin)
• Je confirme, il est interdit de réactiver SSLv3. C'est la politique de sécurité de l'entreprise, pas de discussion possible. (Ticket fermé par la hiérarchie)

Pour info, le site de consultation République Numérique permet d'afficher toutes les propositions d'une personne donnée, donc, pour accéder directement à celles des associations sus-mentionnées, voici :

• celles de Wikimedia France ;
• celles de SavoirCom1 ;
• celles de l'April ;
• celles de la Quadrature du Net.

Là, ce n'est pas vraiment une option, plutôt une sous-commande.

Excellent, je ne connaissais pas !

Comme on l'a vu, il n'est pas réaliste pour l'administrateur d'un serveur de courrier d'imposer le chiffrement pour toutes les transmissions sortantes. En revanche, il peut être utile de le faire pour les noms de domaines destinataires dont on sait qu'ils le prennent en charge avec une configuration correcte.

Voici donc comment le faire avec Postfix. Avertissement : je n'ai pas essayé, pas encore du moins. Dans /etc/postfix/master.cf, définir un nouveau transport forcetls :

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      unix  -       -       -       -       -       smtp
force-tls unix  -       -       -       -       -       smtp -o smtp_tls_security_level=verify

Ensuite, définir une table de transports, dans /etc/postfix/main.cf :

transport_maps = hash:/etc/postfix/transport

Créer cette table, en y mettant les noms de domaines pour lesquels on veut transmettre exclusivement en TLS avec vérification :

laposte.net     force-tls:

Hacher cette table, puis redémarrer Postfix :

# postmap /etc/postfix/transport
# service postfix restart

À noter qu'avec cette configuration, pour un nom de domaine donné, Postfix ira chercher les MX, par résolution DNS souvent non sécurisée — DNSSEC est encore loin d'être la norme — puis, s'il fait partie de cette liste des noms de domaines pour lesquels il doit transmettre exclusivement en TLS avec vérification, vérifier que le certificat utilisé couvre bien le nom du MX choisi — et non le nom de domaine destinataire.

Cela laisse donc un vecteur d'attaque, par réécriture des réponses DNS, qui permet à l'attaquant d'indiquer son propre MX qui prendra en charge TLS avec un certificat qui couvre bien son nom. Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire. Cela a plus de sens, puisqu'on cherche à s'assurer qu'on est bien en train de transmettre aux serveurs d'un nom de domaine destinataire donné, et non à un MX précis. L'ennui, c'est qu'il semble qu'il est justement courant d'utiliser un certificat qui couvre le nom de MX et non le nom de domaine destinataire, ce qui est donc moins sûr, mais beaucoup plus pratique lorsqu'on fait de l'hébergement virtuel de noms de domaines multiples, faute de SNI : cette vérification correcte serait donc en pratique peu utilisable… À vérifier toutefois ; pour info, cela se fait avec une autre valeur de smtp_tls_security_level ou en modifiant globalement le smtp_tls_verify_cert_match.

Ce que je retiens notamment, c’est que ce qui dissuade de valider strictement les certificats n’est pas la proportion de certificats auto-signés (qui sont en fait négligeables contrairement à ce que je pensais, de même que les certificats signés par des CA non-reconnues), mais la proportion de certificats incorrects

Non, c'est plus simple que ça. Ce qui dissuade de valider les certificats, c'est que, quand on accepte par ailleurs de transmettre les messages en clair quand le serveur en face ne prend pas en charge TLS, ça ne sert tout simplement à rien du tout.

En effet, valider les certificats sert à se prémunir des attaques par réécriture, où l'attaquant fournit son propre certificat usurpé, ce qui est alors détecté. Sauf que, dans un tel cas d'attaque, le première chose que l'attaquant va faire, c'est transmettre la réponse initiale du serveur destinataire, en en enlevant l'indication de prise de TLS. Le serveur émetteur continuera donc en clair, et l'interception pourra avoir lieu.

Par conséquent, vérifier les certificats des serveurs destinataires qui prennent en charge TLS n'apporte de protection contre aucun type d'attaque. Cette vérification n'a d'intérêt que si on n'accepte pas de transmettre en clair, or ce n'est pas une option réaliste aujourd'hui.

ça ne protège que des écoutes passives

Ben si, justement : ce n'est pas celui qui écoute qui décide, donc si les deux serveurs sont OK, ben c'est chiffré.

C'est ce que je dis ! J'ai écrit que ça ne protégeait que des écoutes passives, pas que ça ne protégeait pas des écoutes passives…

Attention, actuellement, le chiffrement des transmissions par SMTP est purement opportuniste, donc vulnérable aux attaques avec réécriture — le fameux homme du milieu. C'est à dire qu'au moment de transmettre un message, on se connecte au serveur distant, puis :

• s'il propose le chiffrement, on démarre une sessions TLS sans vérifier son identité ;
• sinon, on transmet en clair.

On ne peut pas raisonnablement refuser de transmettre sans TLS, parce que plein d'adresses seraient alors injoignables par courrier électronique, leurs serveurs ne proposant pas de chiffrement. Il ne sert à rien de vérifier l'identité du serveur destinataire en contrôlant son certificat, parce que ça n'ajouterait rien, puisqu'on accepte de toute façon de transmettre en clair, ce qui est encore moins sûr.

Donc, dans ce contexte, chiffrer, c'est bien, c'est ce qu'on appelle du chiffrement opportuniste, mais il faut être conscient que ça ne protège que des écoutes passives et aucunement des attaques par réécriture.

La morale républicaine, c'est ce qui a été invoqué pour punir les collabos.

Eh bien ils auraient mieux fait d'appeler ça morale tout court, ou morale nationale, puisqu'on peut voir la collaboration avec l'ennemi comme une traîtrise à la Nation.

La morale républicaine, c'est ce qui a été invoqué pour punir les collabos. C'est à rapprocher du devoir d'insurrection, qui est énoncé dans la déclaration des droits de l'Homme et qui a donc valeur constitutionnelle.

Ah non. Il est énoncé dans la DDHC de 1793, mais pas dans celle de 1789 qui est d'usage plus courante et seule référencée par la Constitution de 1958.

Je maintiens ma position : quoi que puisse être cette morale républicaine, elle semble liée à la République, et je doute qu'elle puisse justifier de violer sa loi.

Pour faire plus fort, c'est comme nègre, puis noir (parce que nègre évoque l'esclavage), puis black (parce que noir évoque le fait que la personne dont on parle a la peau noire, ce qui pourrait passer pour raciste aux yeux de crétins finis).

Personnellement, j'utilise systématiquement le terme de morale, parce que je trouve parfaitement stupide de changer un mot pour un synonyme à cause des préjugés d'autrui, et refuse de me plier cela.

Chez moi les termes « morale » et « éthique » sont synonymes.

Chez moi aussi, mais il y a une différence en fait : même en les utilisant pour désigner exactement la même chose, la morale donne des boutons à des gens qui supportent très bien l'éthique. Donc, si tu veux appeler au troll, il faut utiliser le terme de morale. Si tu veux passer le même message, mais sans que les gens s'imaginent que tu es un vieux réac parce que tu parle de morale, il faut utiliser le terme d'éthique.

C'est comme libre et open source en quelque sorte : techniquement, ça désigne la même réalité¹ mais ces termes synonymes ont ce que j'appellerais une différence contextuelle d'utilisation, faut d'une meilleure façon d'exprimer cette différence.

Notes :
¹ Les définitions du libre et de l'open source utilisent des critères éventuellement différents, mais le concept est fondamentalement le même, surtout considérant le fait que la définition de l'open source est une reprise des critères du logiciel libre de Debian.

L'intérêt de la morale républicaine est qu'elle peut être invoquée pour justfier un acte de désobéissance civile

D'une morale laïque si tu veux, mais de la morale républicaine, j'en doute, parce que :

1. qu'est-ce que c'est que ce truc-là, la morale républicaine ?
2. si ça existe, et que c'est lié à la République française, ça doit être un truc défini par la loi, donc ça ne risque pas de justifier de la violer.

Accessoirement, parler de morale républicaine, de sursaut républicain face à la barbarie islamiste, et ce genre de trucs, ça donne l'impression qu'on croit que la république, et l'esprit républicains, sont la solution à ces problèmes, ce qui est très insultant pour pas mal de nations et les peuples qui nous entourent, qui sont des États de droit démocratiques mais pas des républiques.

Ah oui, au temps pour moi, ça ne parallélise pas les appels.

La réponse est dans le message d'origine :

Télécharge sur les sites officiels:
- Chrome
- Dropbox

Au passage, ton programme, là, c'est l'exemple typique d'implémentation hautement inefficace de la suite de Fibonacci : chaque appel du programme déclenche deux autres appels, ce qui fait qu'il a, en temps de calcul comme en consommation mémoire, un coût qui varie en fonction exponentielle du numéro du terme que tu veux calculer.

La bonne façon de faire consiste à trouver un moyen de mémoriser les termes déjà calculés, de façon à éviter de les recalculer ; on peut ainsi arriver à écrire un programme dont le coût est proportionnel au numéro du terme à calculer. Mais je doute que ce soit possible par appels successifs d'un programme.

Alors serais ce installer de base par lenovo!?

Peut-être bien oui. J'ai vu récemment passer des nouvelles parlant de logiciels malveillants ou de portes dérobées installées par les fabricants, et il me semble que ce sont justement Lenovo qui ont ouvert le bal. N'étant pas concerné par ces problèmes, je n'y ai pas fait très attention, mais ça vaudrait le coup que tu cherche des infos à ce sujet.

Cela fait maintenant quelques temps que ce logiciel est stable et produit des résultats consistants

Des résultats cohérents. Quelque chose de consistant, c'est plutôt un plat qui tient au corps, et je ne pense pas que le but d'un codec soit de produire des fichiers consistants…

Le passage à la carte resto a un avantages : on peut payer le montant qu'on veut dans les limites imposées.

Et plein d'inconvénients, notamment :

• on ne peut pas l'utiliser pour donner à un mendiant ;
• son utilisation est beaucoup plus facile à pister ;
• le commerçant doit payer une commission supérieure à l'organisation émettrice de la carte ;
• par conséquent, ce n'est pas accepté partout, encore moins que les tickets.

Concernant l'avant dernier point, notons l'hypocrisie des réseaux de titres restaurant : d'après leur discours, la carte permet de simplifier le système. Mais s'ils prennent une commission supérieure, c'est que ça doit coûter plus cher, et si ça coûte plus cher, pourquoi ne pas rester aux tickets ‽

• Une corde de 0m n'existe pas. Si bien-même, cette corde n'aurai aucune matière, ce qui n'est pas facile à étirer.

Très facile au contraire. Le néant n'apporte aucune résistance à l'étirement. En revanche l'escargot risque d'avoir du mal à glisser dessus sans tomber, parce que c'est un support qui ne fournit aucune réaction.

• Si on tire sur la corde, où se trouvera l'escargot après ? Est-ce que l'escargot se trouvera en début ou fin de corde ? Peut-être à 80% de la corde ou au milieu ?

C'est ce que je dis, il sera à NaN mètres…

Second erratum :

À la fin de chaque heure, un géant tire sur la corde et celle-ci s'allonge de façon élastique.

Et non pas au début, puisque, vu le début et la suite :

Un petit escargot est posé à l'extrémité d'une corde parfaitement élastique de 100m.
[…]
À l'issue de la première heure, l'escargot à parcouru 1m, le géant tire sur la corde, celle-ci passe à 200m.

Le géant n'a pas tiré au début de la première heure, sinon la corde aurait mesuré 200 m dès le départ.

Autre façon de corriger l'énoncer, un peu plus tordue :-D :

Un petit escargot est posé à l'extrémité d'une corde parfaitement élastique de 0m.
[…]
Au début de chaque heure, un géant tire sur la corde et celle-ci s'allonge de façon élastique.

Puisque cette corde de zéro mètre sera donc directement étirée pour mesurer 100 m dès le départ. L'ennui c'est que la position de l'escargot sera alors NaN.