🚲 Tanguy Ortolo a écrit 12334 commentaires

Blocs

Diverses corrections au niveau de la gestion des blocs, cela va de l’ordonnanceur, à la gestion du bug de l'année 2038.
Pas mal de changements côté NVMe (qui permet une bien meilleure exploitation des disques solides que AHCI), […]

Des périphériques à l'état solide, des SSD quoi, qui ne sont justement pas des disques !

(Au passage, je n'ai jamais compris d'où sortait ce nom étrange de « périphérique à l'état solide », comme si les vénérables disques durs étaient à l'état liquide ou gazeux : personnellement, je préfère parler de périphérique de stockage flash.)

où est défini la longueur de la clé symétrique dans mon système,est ce paramètrable ?

C'est le paramètre de configuration Ciphers du client OpenSSH, cf ssh_config.

Oulà, ce n'est pas non plus « la documentation Debian », c'est une documentation sur Debian !

en lisant la doc sur ssh:

C'est gentil, mais ça, ce n'est pas la doc sur SSH, c'est une documentation sur SSH, à laquelle j'ai participé d'ailleurs.

Si tu veux plus de détails, c'est la RFC qui définit le protocole SSH qu'il va falloir aller voir. Mais de mémoire, il me semble qu'une clef symétrique est simplement une chaîne d'octets aléatoires d'une certaine longueur. Donc, pour répondre à tes questions :

comment le client génère t il la clé symétrique

En prenant des octets dans /dev/random je pense.

a quel moment

Au début, vu que cette clef symétrique va être utilisée dans toute la suite, dans la mesure où elle est au cœur de l'initialisation d'un canal sécurisé, qui est l'objet de la connexion SSH.

et est ce toujours la même clé ?

D'une session sur l'autre, non, elle est générée pour chaque connexion SSH. En revanche, pendant que tu es connecté par SSH quelque part, elle reste la même. À moins qu'il n'y ait un mécanisme de renégociation, je n'ai pas vérifié.

impossibilité de révoquer : si si, tu peux révoquer (suffit de faire un mail au support frama et on suspend ton don récurrent par CB)

Non, je parle de révocation directe par le donateur. Mettre fin à un prélèvement en demandant au débiteur de l'arrêter, c'est super quand tout va bien, mais par nature, ce genre de méthode ne marche que quand tout va bien, or le but de ce genre de démarche est parfois de mettre fin à un problème, qu'il s'agisse d'un abuse volontaire, d'un bug ou d'un piratage.

Bref, on prend évidemment les virements permanents (j'en profite pour rappeler que certaines banques font payer les virements de banque à banque !).

Il me semble que c'est interdit par le règlement SEPA. Ou plutôt, qu'un virement SEPA peut être facturé, mais obligatoirement au même tarif qu'il soit ou non à destination d'une autre banque. Du coup, la seule façon licité de facturer les virement externes, c'est de facturer aussi les virements internes, et une banque qui en serait là ne garderait pas ses clients bien longtemps.

Le don récurrent par CB a plusieurs inconvénients :

• les frais ;
• l'expiration ;
• l'impossibilité de le révoquer sans gros effets de bords, la seul possibilité étant l'opposition sur la carte, autant que je sache.

L'adhérent qui n'a pas accès à Internet, je ne suis pas sûr qu'il soit très concerné par la possibilité de don ou de cotisation par virement. Pour eux, ce sera plutôt des chèques, non ?

À noter que, si SEPA prévoit plusieurs champs (objet sur quatre lignes, référence, et plus encore il me semble…) certaines banques permettent très peu de personnalisation, voire limitent artificiellement l'ensemble de caractères utilisable. Ainsi, avec la BNP, on ne peut remplir qu'un seul champ (a priori, l'objet je pense), sur une seule ligne limitée à quelque chose comme 60 caractères, sans possibilité d'utiliser le caractère « / ». Ça viole la règlementation SEPA, et quant un fournisseur demande d'utiliser une référence avec un / dedans, ce qui n'est pas si bizarre que ça quand on y pense, eh bien on ne peut pas, et on doit déclencher un traitement manuel en les contactant pour leur expliquer qu'on n'a pas pu à cause de la banque, et qu'il faut qu'ils cherchent le virement avec tel autre objet à la place.

Super, alors si c'est une fausse excuse pour que je refuse de donner mon identité bancaire à une association pour qu'elle prélève sur mon compte, c'est également une fausse excuse pour qu'elle refuse de me donner le sien pour que j'y verse mes dons.

Un IBAN est un identifiant qui n'est pas censé être sensible mais qui l'est quand même, les associations ont des raisons de ne pas le publier / le communiquer à des inconnus.

Merci pour cet argument, c'est pour ça qu'il n'est pas question que je l'écrive sur un papier pour le donner à un démarcheur d'association. :-)

Ah oui, l'April, je m'en souviens bien en effet.

Pourquoi les associations ayant des permanents ont des besoins récurrents d'argent ? (tiré de l'épisode 3)

À ce sujet, j'ai tout de même une interrogation. J'ai l'impression que le fait que les associations qui démarchent les gens dans la rue ne cherchent à obtenir des dons réguliers que depuis quelques années. Alors soit je me trompe, et elles procèdent ainsi depuis bien plus longtemps, soit il s'agit d'un phénomène nouveau, et dans ce cas, qu'est-ce qui a bien pu changer pour créer cette pratique ?

Enfin, deuxième interrogation : avez-vous déjà vu une association acceptant les dons réguliers par virement plutôt que par prélèvement ? Personnellement, il est hors de question que j'autorise une association à prélever librement sur mon compte, en fait je déteste fournir ainsi les clefs de mon compte à qui que ce soit, et je n'accepte de le faire que pour un nombre très limité de fournisseurs, qui se comptent sur les doigts d'une main. En effet, une telle autorisation est discrétionnaire, et permet au débiteur de prélever ce qu'il veut, quand il veut. On m'objecte régulièrement les deux réponses suivantes :

• une association sérieuse n'abusera pas d'une autorisation de prélèvement, et ne l'utilisera que pour prélever le montant prévu aux dates prévues ;
• je peux toujours contrôler ces prélèvements, et au besoin y faire opposition a posteriori, et révoquer cette autorisation.

Seulement, ce n'est pas suffisant. Une association sérieuse n'abusera effectivement pas volontairement d'une autorisation de prélèvement, mais des erreurs, des bugs, des piratages, des actes de malveillance, ça arrive, et ce n'est jamais voulu. Une autorisation de prélèvement est une porte ouverte à ce genre de problème, une porte que je préfère laisser fermer pour éliminer ce risque. Quand à la possibilité d'opposition et de révocation, c'est bien, mais ça nécessite de contrôler soigneusement son relevé de compte, et encore une fois, je préfère éliminer a priori tout risque plutôt que de le contrôler a posteriori.

Tout ça pour dire qu'il existe une alternative à l'autorisation de prélèvement, qui ne comporte aucun de ces inconvénients, et dont le résultat pratique est le même pour le débiteur : le virement permanent. Seulement, de toutes les associations qui m'ont démarchées pour obtenir un don régulier de ma part, aucune n'a accepté de me donner leur identité bancaire pour que j'établisse un virement permanent. Dommage pour elles, je veux bien leur donner de l'argent à ma façon, mais si elles n'en veulent pas…

Le SATA est toujours échangeable à chaud, pas besoin de matériel spécifique. En revanche, ce que tu peux avoir, c'est des paniers qui permettent de changer facilement les disques durs.

Ben non, pas vraiment. Dans les deux il y a une carte mère, un ou plusieurs processeurs, de la mémoire, des disques durs et des trucs branchés sur PCIe. Le gros serveur aura sans doute deux alims, plus puissantes, plus de processeurs, plus de mémoire, plus de disques durs, mais fondamentalement, c'est la même chose en plus gros.

Apparemment, il est très malsain de lancer un 'fsck.ext4' sur une partition dm-crypt.

Oulà oui ! C'est à dire, si tu as lancé le fsck sur le périphérique physique sous-jacent, c'est très malsain en effet, parce que ce qu'il contient n'est pas du tout de l'Ext4, mais du LUKS qui contient, chiffré, un volume Ext4. Essayer de l'interpréter comme de l'Ext4, ça va donner du grand n'importe quoi. Imagine une voiture contenant un vélo, et un type en train d'essayer de la réparer comme si c'était un vélo, sans voir que ce qu'il doit réparer, c'est le vélo qui est dedans : « Oulà, votre vélo a deux roues de trop, il faut les retirer ! », etc.

Du coup, mon mot de passe ne marche plus pour déchiffrer la partition. Quelqu'un sait-il si je peux espérer quelque chose de mieux que ne rien récupérer du tout ?

Non, là j'ai bien peut que ce soit bel et bien fichu, après qu'fsck ait longuement réparer un truc qui n'était pas de l'Ext4 de façon à ce que ça ressemble à un Ext4 bien propre, le résultat n'a sans doute plus grand chose de récupérable en tant que LUKS…

Quelqu'un sait-il pourquoi 'fsck.ext4' ne donne absolument aucune alerte pour empêcher les débiles de mon genre de faire ce que j'ai fait ?

Alors, j'ai une hypothèse à ce sujet. Un volume LUKS, ça a un en-tête qui commence au tout début, qui s'étend sur 592 octets, et qui est suivi de plusieurs emplacements de stockage de clefs de déchiffrement (qui sont chiffrées avec un mot de passe). Un système de fichiers Ext4, ça a un superbloc qui commence à l'octet 1024.

Du coup, je soupçonne ta partition d'avoir un jour contenu directement un système de fichiers Ext4, avec son superbloc à l'octet 1024, s'étendant sur une certaine longueur (les octets 0 à 1023 sont inutilisé par Ext4, pour laisser de la place à un éventuel chargeur de démarrage il me semble). Plus tard, tu as sans doute mis à la place un volume LUKS, avec son en-tête de l'octet 0 à l'octet 591, suivi par un emplacement contenant la clef de déchiffrement protégée par ton mot de passe, suivie par des emplacements réservés à d'autres clefs mais laissés vide dans ton utilisation. Le superbloc de ton ancien système de fichiers Ext4 est donc probablement resté intouché, dans la zone réservée pour ces éventuelles clefs supplémentaires.

Tu avais donc un une partition contenant un volume LUKS, identifiable à son en-tête à l'octet 0, mais également un ancien superbloc Ext4, éventuellement tronqué et sans données correctes pour sons système de fichiers, mais toujours reconnaissable. C'est à mon avis pour ça que fsck a bien détecté un système de fichiers Ext4 (sans cela, il se serait terminé immédiatement en t'indiquant que ce n'était pas de l'Ext4, ou que c'était abîmé au point d'être méconnaissable et irrécupérable) et a commencé à faire son boulot.

Pour éviter ce genre de truc, étant donné que les différentes utilisations d'un disque dur ou d'une partition (système de fichier FAT, Ext*, NTFS, volume physique LVM, volume RAID, volume LUKS…) placent leurs superblocs, leurs méta-données, bref leur point d'entrée et signature permettant de les reconnaître, à différents endroits, le plus sûr consiste, à chaque changement d'usage d'un périphérique, à le remplir de zéros. Ou au moins à remplir de zéros le début (disons quelques mébi-octets, pour être sûr) et la fin (parce que des tables de partitions GPT ont une copie de leurs méta-données à la fin ,et que certains volumes RAID ont l'intégralité de leurs méta-données à la fin !).

http://www.ivg.social-sante.gouv.fr/decryptage-des-idees-recues-sur-l-ivg.html

Est-ce que l’IVG peut rendre stérile ou causer des difficultés pour tomber enceinte par la suite ?
Une IVG ne rend pas stérile, une grossesse peut être envisagée dès le mois qui suit.

Y a-t-il des conséquences psychologiques après une IVG ?
Réponse du gynécologue Philippe Faucher :

"La majorité des études scientifiques sérieuses qui ont été publiées sur le sujet montrent qu’il n’y a pas de séquelle à long terme psychologique de l’avortement. Il n’y a pas de syndrome post-traumatique qui persisterait à distance, plusieurs années après un avortement.

Au moment de l’IVG, ce n’est pas un moment très agréable à passer.
Mais là c’est comme pour la douleur physique, il y a des femmes qui le vivent on va dire plutôt bien et puis il y a des femmes qui le vivent plutôt mal : donc qui sont tristes, qui pleurent. Et à ce moment là il ne faut pas hésiter à demander à des professionnels formés à l’accompagnement psychologique de vous aider."

Cela évoque une possible conséquence psychologique uniquement à court terme.

Mauvaises définitions quand même, parce qu'elles ont toute l'inconvénient de définir la guérison comme une maladie… Ce n'est pas lié à l'observation précédente, mais c'est encore plus important.

Je suis demandeur de publications scientifiques tendant à démontrer que le fœtus n'a pas encore de conscience pouvant l'amener à ressentir des sensations (douleur physique) ou des émotions (peur) en deçà de 12 semaines.

Qu'il en ait ou non n'est pas vraiment la question, en tout cas pas toute la question. Un homme sous anesthésie générale n'a ni sensation ni émotions, mais cela ne suffit pas à le considérer comme non humain, non vivant ou pouvant être librement supprimé.

Il me semble que la question sous-jacente à ta remarque est celle de l'humanité ou de la vie du fœtus, mais elle est distincte de sa capacité à ressentir sensations et émotions. C'est sans doute lié, mais pas identique.

Quelques mots qui ne sont consensuels que parcequ'ils relatent des faits : la grossesse involontaire peut être dramatique, pour la femme, son éventuel compagnon, et le potentiel futur enfant.

Ça, autant que je sache, c'est consensuel. Encore que, pour l'embryon ou le fœtus, la grossesse elle-même n'est que très normale, c'est ce qui se passera à la fin, avortement ou accouchement et accueil potentiellement très mauvais, qui peut être dramatique.

L'avortement est une solution d'urgence, parfois traumatisante, réellement, et tout le temps perturbante, culpabilisatrice (plus ou moins intériorisé).

Ça ce n'est pas du tout consensuel, c'est même une partie du débat enflammé sur ce sujet. D'après une bonne partie de ses partisans et, il me semble, pour le Ministère, l'avortement volontaire — la précision est d'importance, parce qu'avortement, c'est synonyme de fausse couche, volontaire ou non — ne cause aucun traumatisme, aucune perturbation, et la culpabilisation éventuelle n'est qu'extrinsèque, due à des interventions extérieures. D'après les opposants à l'avortement, c'est un acte qui peut avoir des conséquences physiques et psychiques pour la femme qui y recours. Pour ajouter à tout cela, d'après certains partisans, énoncer cela est un acte culpabilisateur, ce qui est explique des actions pour expliquer que cet acte n'a pas de conséquences autres que son but principal, et une volonté de rendre inaudible, voire de faire taire ceux qui tiennent de tels discours.

J'ignore s'il y a des partisans de l'avortement volontaire qui pensent que l'avortement peut avoir de telles conséquences, et, s'il y en a, s'ils sont nombreux. Mais, pour revenir à l'objet de mon propos, cela n'a rien de consensuel.

Comme mentionné plus haut, un sort | uniq fera l'affaire. Mais cette idée du -u, je gage que tu ne la sors pas de nulle part : c'est également une option de sort, tout à fait appropriée pour ton cas, parce qu'elle lui demande de faire aussi le boulot de uniq. Autrement dit, ces deux commandes sont équivalentes :

sort | uniq
sort -u

Firefox 50 reconnait le certificat Racine de l’Internet Security Research Group: ISRG Root X1. Auparavant c'était Digital Signature Trust Co qui signait les certificats via Let's Encrypt Authority X1 Let's Encrypt Authority X3 pour qu'ils soient reconnus dans tous les navigateurs.

À noter que cette reconnaissance est un début, mais ne sera utilisable en pratique que quand tous les navigateurs majeurs en auront fait de même. J'explique…

Le modèle X.509, et en particulier le format de certificats, présente depuis ses débuts une limitation majeure, en ce qu'un certificat ne peut porter qu'une seule signature d'autorité de certification. Soit dit en passant, c'est cette limitation technique qui impose un modèle de confiance pyramidal, par opposition à la toile de confiance de systèmes de OpenPGP, et qui a d'importantes conséquences négatives en matière d'organisation et de sécurité : c'est à cause de cela qu'il y a peu d'autorités de certification, qu'il est difficile d'en créer de nouvelles, et que la défaillance d'une seule compromet à chaque fois la sécurité de tout le réseau.

Le problème de la création d'une nouvelle autorité s'est posé à Let's Encrypt : n'étant reconnue par aucun navigateur, les certificats qu'ils émettent, signés par leur clef intermédiaire fournie dans un certificat signé par leur clef racine fournie dans un certificat reconnu par personne, auraient été à peu près inutilisables. Pour éviter cela, ils ont émis une version alternative de leur certificat racine, portant la même clef publique, mais qu'ils ont fait signer par une autorité reconnue, IdenTrust. Notons en passant qu'il ne s'agit alors plus vraiment d'un certificat racine, mais d'un certificat intermédiaire, strictement parlant.

Les administrateurs de serveurs utilisant des certificats émis par Let's Encrypt peuvent donc configurer leur serveur pour exposer leur certificat, suivi du certificat intermédiaire de Let's Encrypt, suivi du certificat « racine » temporaire de Let's Encrypt. Ainsi, pour le client, il s'agit d'un certificat signé par une chaîne qui remonte jusqu'à un certificat d'autorité de certification reconnu.

Lorsque le certificat racine de Let's Encrypt sera reconnu partout, les administrateurs de serveurs utilisant des certificats émis par Let's Encrypt pourront les configurer pour exposer leur certificat, suivi du certificat intermédiaire de Let's Encrypt et c'est tout. Mais pour le moment, ce n'est pas une option, parce que pour tous les autres navigateurs, il s'agirait d'un certificat sans chaîne de certification remontant à un certificat d'autorité de certification reconnu.

Comme on dit en Klingon, jusqu'où s’arrêteront ils ?

Quo non ascendet.

Sur tes deux postulats, c'est vrais, et c'est une réalité. Mais c'est pas vraiment un problème de développeur, mais plutôt de distribution nan? Donc ça veut dire que tu n'es pas d'accord avec la politique des distro sur ce point là? Il faudrait garder /bin/sh QUE pour du full POSIX selon toi? Je serai curieux que tu m’éclaire :)

Pas du tout, chaque distro fait ce qu'elle veut, ce qui est important, c'est que /bin/sh implémente au moins ce que demande POSIX. Ça peut être dash, comme ça peut être Bash, les deux conviennent, dash est seulement plus léger.

Du côté de celui qui rédige des scripts, ce qui est essentiel, c'est de ne pas cibler /bin/sh en utilisant des trucs non POSIX, typiquement des bashismes. Et ce qui devrait être important, c'est de ne pas cibler inutilement /bin/bash alors qu'on n'utilise aucun de ses fonctionnalités spécifiques.

Coder pour Bash c'est mal, il faut cibler /bin/sh sans commettre de bashisme.

Plus sérieusement, en ce domaine, ce sont les attitudes suivantes que je déplore :

• comme /bin/sh n'est pas forcément Bash et que j'ai toujours utilisé Bash, je cible /bin/bash sans réfléchir, même si mon script ne contient aucun bashisme ;
• comme /bin/sh n'est pas forcément Bash et que j'ai toujours utilisé Bash, je cible /bin/bash sans réfléchir, et j'utilise des bashismes qui n'apportent rien du tout.

En revanche, je n'ai pas grand chose contre l'utilisation de Bash pour ses fonctionnalités propres, qui permettent parfois de se passer d'appels à des outils externes.

Ça n'aidera pas. Un DRM, même basé sur une norme, inclut une partie secrète. Le jour où le fournisseur du module de déchiffrement cessera de le fournir, tous les contenus qui l'utilisaient deviendront illisibles.