Il n'y a pas un vraiment un seuil bien clair, on a une distribution de probabilité : on évalue un risque.
En fait, il y a bien un seuil, mais il ne peut s’évaluer qu’à l’échelle collective (par des études épidémiologiques), pas à l’échelle individuelle.
On ne peut pas dire qu’au-delà d’une dose de x Sv, tu vas avoir un cancer à cause de tel et tel effet.¹ Ce qu’on peut dire, c’est que l’incidence des cas de cancer est plus élevée dans une population qui a été exposée à x Sv ou plus que dans une population qui a été moins exposée.
Ça veut dire notamment :
que si tu as été exposé à x Sv, tu ne vas pas forcément développer un cancer pour autant ;
que si tu développes un cancer alors que tu as été exposé à cette dose, le cancer n’est pas nécessairement imputable à ton irradiation (tu aurais peut-être développé ce cancer même sans avoir été irradié).
C’est la même situation que pour le tabac : un individu peut fumer 2 paquets de cigarettes par jour pendant quarante ans sans jamais avoir de cancer, alors qu’un autre individu non-fumeur peut mourir d’un cancer du poumon à trente ans (donc, pas de lien de causalité évident à l’échelle individuelle). Pour autant, à l’échelle épidémiologique il est clair qu’il y a plus de cas de cancers chez une population de fumeurs que chez une population de non-fumeurs, et il n’y a guère que les industriels du tabac qui continuent à essayer de faire croire que le lien entre tabagisme et cancer n’est pas établi.
¹ En revanche, avec des doses très élevées, les effets deviennent déterministes et plus stochastiques. On peut dire sans erreur qu’au-delà d’un seuil de y Sv, un individu va souffrir d’un empoisonnement aigu aux radiations (bien avant d’avoir le temps de développer un quelconque cancer).
quand les deux brins d'ADN sont cassés, la cellule n'a plus aucun moyen de récupérer l'information perdue.
Pas tout-à-fait. Il existe aussi des mécanismes pour réparer les cassures double-brin.
Notamment, quand c’est possible, la cellule utilisera l’ADN de la chromatide homologue (quand celle-ci est présente, c’est-à-dire si la cassure survient entre la réplication de l’ADN et la division cellulaire) comme matrice pour réparer la double hélice endommagée. Dans ce cas, la réparation est fidèle.
Le problème est lorsqu’il n’y a pas de chromatide homologue à utiliser comme matrice. Dans ce cas, la réparation reste possible, mais avec un risque accru d’introduire des erreurs.
Le texte source de ce journal, au format DocBook, est disponible sous licence Creative Commons Paternité — Partage à l’Identique 2.0 (France).
La version publiée ici a été générée avec une feuille de style XSL (incluse dans l’archive ci-dessus) bricolée à LA RACHE, pour produire du Markdown à peu près conforme à ce qu’attend LinuxFR.¹
Pour la petite histoire, ce journal est celui que j’avais annoncé dans ce message datant de… juin 2015. J’annonce dès à présent que mon prochain journal sur OpenPGP sera consacré à la publication et à la diffusion des clefs OpenPGP, et devrait logiquement paraître vers le printemps 2018.
¹ Je ne sais pas exactement quelle est la flavor de Markdown utilisée sur LinuxFR.org, mais apparemment ce n’est aucune de celles prises en charge par Pandoc, d’où le recours à une feuille de style de mon cru…
C’est devenu je pense moins courant que les autres exemples que tu cites,
Je n’en mettrai pas ma main au feu. L’une des plus grosses vulnérabilités découvertes dans Android (Stagefright) était justement de ce type (failles dans la bibliothèque gérant les fichiers MP3/MP4).
Oui mais c'est parce qu'il n'ont pas demandé à Émilie.
Traditionnellement, la lettre E est réservée à Eve, qui joue le rôle d’un attaquant passif¹ souhaitant écouter la conversation (eavesdropping).
Quelle est la commande à utiliser pour signer avec un autre niveau de certification ?
Tu peux soit utiliser l’option --default-cert-level n pour toujours signer au niveau n, soit utiliser l’option --ask-cert-level pour que GnuPG te demande interactivement, au moment de signer, quel niveau tu souhaites.
Pour une certification non-exportable, on utilisera la commande lsign (local signature) au lieu de sign, et pour une certification non-révocable, on utilisera la commande lrsign. Pour une signature non-révocable et non-exportable, il suffit de combiner les préfixes (dans n’importe quel ordre), donc ce sera lnrsign ou nrlsign.
quelle est la confiance dans le programme qui génère cette clé ?
Elle doit être totale.
Idéalement. Après dans les faits, tu n’as que la confiance que tu peux avoir dans un logiciel libre, dont le code source est scrutable par tous et dont le développement se fait au grand jour. Ni plus, ni moins.
Ce n’est pas parfait — le problème de la « loi de Linus » (“Given enough eyeballs, all bugs are shallow.”) est que beaucoup de logiciels ne sont pas scrutés par « suffisamment d’yeux » pour qu’elle fonctionne. Mais GnuPG a quand même un avantage par rapport à un logiciel lambda : de par sa nature, il bénéficie de pas mal d’attention de la part de cryptologues et de chercheurs en sécurité.
Il y a quelques mois, un bug datant de l’origine de GnuPG (1998) et affectant le générateur de nombres aléatoires (mais apparemment pas assez pour compromettre la sécurité des clefs générées) a justement été corrigé, après avoir été découvert par deux chercheurs (Dörre et Klebanov, 2016).
Le générateur de nombres aléatoires du noyau Linux (d’où GnuPG obtient de quoi initialiser son propre RNG) bénéficie lui aussi de l’attention des chercheurs (Lacharme, 2012).
Est-ce assez pour avoir « totalement confiance » ? Peut-être pas totalement, mais en ce qui me concerne, assez pour avoir davantage confiance qu’avec des logiciels non-libres.
peut-on avoir plusieurs clefs associées à la même adresse ?
Rien ne s’oppose à ça. Le seul inconvénient est que tu risques de rencontrer des problèmes avec les méthodes de sélection de clefs.
Par exemple, si tu veux éditer la clef de bob@example.com, tu fais typiquement :
alice$ gpg2 --edit-key bob@example.com
S’il y a deux clefs (ou plus) associées à bob@example.com, GnuPG sélectionnera arbitrairement l’une d’elles, peut-être pas celle que tu veux.
Dans le pire des cas, si les deux clefs ont absolument la même identité (non seulement les adresses e-mails sont identiques, mais les noms également), il faudra avoir recours à l’identifiant de la clef (0xXXXXXXXX) pour les distinguer.
Si oui, quelle utilité ?
Je n’en vois guère. Il est relativement fréquent pour une même personne d’avoir plusieurs clefs, mais en général c’est pour séparer des activités qui n’ont rien à voir entre elles (une clef pour leurs activités professionnelles et une clef pour leurs communications personnelles par exemple), et donc ces clefs seront typiquement associées à des adresses e-mails différentes.
Le seul cas d’usage non-tordu qui me vient à l’esprit, où tu pourrais avoir deux clefs associées à la même adresse, est le cas d’un changement de clef, où pendant une certaine période ton ancienne clef et ta nouvelle cohabitent dans ton trousseau.
J'ai une question sur la politique ask du modèle TOFU : comment l'active-t-on ? Tu dis que les seules politiques par défaut possibles sont unknowkn, auto ou good; mais alors à quoi sert la politique ask ?
En fait, la politique ask est celle qui sert à implémenter la gestion des conflits. Lorsqu’un conflit est détecté (lorsqu’on tente d’ajouter un binding {bob@example.com, 0xNEWKEY} alors qu’un binding {bob@example.com, 0xOLDKEY} existe déjà dans la base), la politique assignée au nouveau binding est ask au lieu de la politique par défaut — informant de fait GnuPG qu’il devra demander explicitement à l’utilisateur son avis sur cette clef.
Lorsque l’utilisateur est sollicité, il peut soit résoudre le conflit en assignant une politique explicite (soit good s’il pense que la nouvelle clef est la bonne, soit bad si au contraire il pense que c’est une tentative d’usurpation), soit reporter la résolution à plus tard (parce qu’il veut plus de temps pour y réfléchir, ou qu’il espère avoir plus d’informations — peut-être en essayant de contacter son correspondant par un autre moyen pour savoir s’il a changé sa clef) en laissant la politique à ask.
(Le nom de cette politique vient de ce qu’elle apparaît, dans le menu affiché lors de la détection d’un conflit, sous l’étiquette Ask me again next time.)
Mais d'après ce que je viens de lire ici et là, c'est luksHeaderBackup qui permet cela et non luksDump.
Oui, en effet, my bad. luksDump ne fait qu’afficher les informations contenues dans l’en-tête sous une forme intelligible, c’est bien luksHeaderBackup pour sauvegarder l’en-tête.
Existe-t-il un moyen de "recréer" un /boot ou de récupérer la partition chiffrée sans utiliser celui d'origine
Oui, du moment que tu connais toujours la phrase de passe.
Depuis un autre système GNU/Linux (installé sur une autre partition, ou démarré depuis un live CD ou une clef USB), et en supposant que ta partition chiffrée est par exemple /dev/sda2 :
Ouvrir le volume chiffré :
root# cryptsetup luksOpen /dev/sda2 my_volume
Le monter quelque part
root# mount /dev/mapper/my_volume /mnt/tmp
Récupérer ce que tu veux dans /mnt/tmp
En priant pour qu’à aucun moment, suite aux différentes manœuvres que tu as tenté ou simplement à cause de ce cher Murphy, l’en-tête LUKS de la partition chiffrée n’ait été endommagé, parce que sinon c’est mort (il faut toujours sauvegarder l’en-tête d’une partition chiffrée avec luksDump !).
comment va-ton gérer lorsque les données entre le DNS et l'AC seront contradictoires ?
De deux choses l’une :
a) L’enregistrement TLSA est de type PKIX-TA ou PKIX-EE, ce qui signifie que la chaîne de certification présentée par le serveur doit être validée à la fois par PKIX (c’est-à-dire les autorités de certifications présentes dans le magasin du navigateur) et par DANE. S’il y a discordance entre les deux (PKIX dit que le certificat est valide mais il ne correspond pas à aucun enregistrement TLSA, ou inversement le certificat correspond à un enregistrement TLSA mais n’est pas valide du point de vue de PKIX), alors la chaîne de certification n’est pas valide.
b) L’enregistrement TLSA est de type DANE-TA ou DANE-EE, ce qui signifie que seules les informations du DNS sont à prendre en compte. Peu importe que le certificat soit, du point de vue de PKIX, invalide (par exemple parce que signée par une CA inconnue du navigateur), s’il correspond à l’enregistrement TLSA, il est valide.
Tu veux dire que c’est ce qu’il pense réellement et non pas une phrase politicienne calculée pour séduire l’électorat ?
OK, mais euh… c’est supposé être pour sa défense, ça ?
Et puis « à son insu »… Donald Trump est (entre autres choses) un homme de télévision, il ne pouvait pas ignorer qu’il était enregistré. (Ou au minimum qu’il pouvait être enregistré — les microphones qui ont enregistré la conversation n’étaient pas cachés, c’étaient ceux que Billy Bush et lui portaient sur eux !)
je pense qu'il voulait signifier - avec ses gros sabots - que quand on est milliardaire, il n'y a qu'à se baisser pour ramasser des femmes attirées par l'argent.
Mouais, permets-moi d’en douter.
Pour mémoire, voici la phrase en question :
You know I’m automatically attracted to beautiful women. I just start kissing them. It’s like a magnet. I just kiss. I don’t even wait. And when you’re a star, they let you do it. You can do anything… Grab them by the pussy. You can do anything.
Peut-être qu’un anglophone natif aura une lecture différente, mais moi je ne vois pas dans cette phrase une expression imagée. La seule image est la comparaison avec un aimant. Pour le reste, d’après moi il voulait dire littéralement ce qu’il a dit.
Depuis, pour ce sujet de montage de périphériques amovibles, je suis passé à umount, ça marche bien, je suis content.
Euh, umount, c’est l’outil classique de démontage. Tu veux parler de pmount ?
Sinon, moi j’utilise udisksctl (partie de UDisks2), ça marche bien, je suis content. Et je vois un certain intérêt à ce que l’outil que j’utilise en ligne de commande pour monter un périphérique amovible passe par le même mécanisme que les outils en mode graphique, plutôt que de passer par un mécanisme complètement différent.
Bon, alors on va le laisser « gérer », quoi que ce terme puisse signifier.
Un coup de RTFM, peut-être ?
console-kit-daemon is a service for defining and tracking users, login sessions and seats. It provides interfaces for managing switching sessions and session migration when using mechanisms such as Virtual Terminals (VT). ConsoleKit provides a number of interfaces to specify what displays are managed by the display manager, and how.
Avant que tu me dises qu’on n’a pas besoin de ConsoleKit pour ça : tout-à-fait, de la même façon qu’on n’a pas besoin de UPower pour gérer l’alimentation, de UDisks pour gérer les périphériques amovibles, de PolicyKit pour gérer les permissions, de systemd pour gérer les services, etc. Le but de tous ces outils n’a jamais été de permettre de faire des choses infaisables autrement, mais bien plutôt d’offrir des interfaces unifiées pour les faire, faisant abstraction des mécanismes sous-jacents.
Alors, oui, ça fait peur, et je serais totalement incapable de sortir cette commande à brûle-pourpoint sans consulter la doc.
Mais
① C’est pour ça qu’on a inventé les scripts shell. Je ne tape jamais moi-même la commande ci-dessus, j’ai un script pour ça (ainsi que pour appeler les méthodes de mise en veille et d’hibernation).
② Il serait trivial d’écrire un programme (compilé, pas un script) dont la seule tâche serait d’appeler cette méthode D-Bus, c’est juste qu’apparemment personne n’en a jamais ressenti le besoin. Pourquoi ? Probablement parce que les principaux utilisateurs de ConsoleKit sont les environnements graphiques, et que fournir un outil en mode ligne de commande n’a semblé nécessaire à personne.
Ouais, on peut râler sur ces censurés de développeurs qui ont le culot de développer des trucs…
Ou alors on peut prendre un (tout petit) peu de temps pour essayer de comprendre à quoi ils servent.
c'était UPower qui marchait je ne sais comment
UPower n’a jamais été en charge de l’extinction de la machine, et son fonctionnement n’a jamais été mystérieux pour quiconque lit la doc. C’est un service D-Bus qui donne accès aux informations sur l’état de l’alimentation du système (évitant ainsi d’aller fouiller directement dans /sys/class/power_supply), informe les applications qui le souhaitent des changements de cet état (passage d’une alimentation sur secteur à une alimentation sur batterie par exemple), et fournit des méthodes pour commander la mise en veille et l’hibernation.
puis UPower2 qui s'utilisait avec un appel de machin D-Bus tout à fait imbitable
Jamais entendu parler d’UPower2. Tu ne confonds pas avec UDisks et UDisks2 ?
puis ConsoleKit (ou PoliciKit, je confonds toujours ces MachinKits
ConsoleKit est un service de gestion des sessions utilisateur. PolicyKit est un service d’autorisation, par lequel un programme réalisant des tâches « privilégiées » peut mettre ses services à la disposition de programmes non-privilégiés.
En l’espèce, l’extinction de la machine nécessite des privilèges administrateurs. Au lieu d’acquérir de tels privilèges (via sudo ou assimilé), un utilisateur non-privilégié peut demander l’extinction au service ConsoleKit, qui vérifiera préalablement, via PolicyKit, que cet utilisateur est autorisé à le faire. Dans la configuration par défaut de PolicyKit et ConsoleKit, un utilisateur normal est autorisé à éteindre la machine s’il est physiquement connecté dessus (ça peut se changer pour ceux qui n’aimeraient pas cette idée).
maintenant peut-être un autre bidule à base de systemd qui est censé remplacer toutes ces merdes
systemd-logind remplace ConsoleKit pour gérer les sessions utilisateurs. Rien d’autre ne change.
c'est plus un «Arrêt par l'utilisateur», sans être root et sans passer par sudo, que je chercherais.
Si ConsoleKit est encore là (pas sûr vu qu’il est normalement remplacé par systemd-logind), un utilisateur (même non-root, du moment qu’il est connecté physiquement) peut appeler la méthode D-Bus org.freedesktop.ConsoleKit.Manager.Stop pour arrêter le système.
Depuis la ligne de commande, ça peut se faire avec dbus-send(1) :
Sur les systèmes où systemd-logind a remplacé ConsoleKit, la méthode équivalente est apparemmentorg.freedesktop.login1.Manager.PowerOff. Je soupçonne que l’on doit pouvoir également utiliser simplement systemctl halt (même en tant que simple utilisateur, encore une fois tant qu’il est physiquement connecté), mais n’utilisant pas systemd je ne peux être affirmatif.
Sauf erreur de ma part, je ne pense pas que le front-end de GnuPG permette de changer la phrase d’un passe d’une clef exclusivement utilisée pour SSH.
En revanche, tu peux toujours t’adresser directement à l’agent GnuPG :
$ gpg-connect-agent "PASSWD keygrip" /bye
L’agent te demandera alors la phrase de passe actuelle (pour déchiffrer la clef telle qu’elle est actuellement stockée), puis la nouvelle phrase de passe.
Reste à obtenir le keygrip. S’agissant d’une clef utilisée pour SSH, tu devrais le trouver dans le fichier ~/.gnupg/sshcontrol.
Du coup, le wrapper proposé ne résout pas le problème.
Le wrapper va en effet retourner NULL si la taille demandée est 0.
Je pense que s’il y a une possibilité légitime pour que le paramètre passé à xmalloc soit 0 (par exemple parce que ce paramètre dépend, d’une manière ou d’une autre, d’une donnée extérieure au programme), c’est un cas à gérer explicitement. Le wrapper ne se substitue pas à la validation des entrées. Il ne me semble pas pertinent de traiter de la même façon une entrée incorrecte et une situation de manque de mémoire.
Et s’il n’est pas légitime que le paramètre soit 0 (par exemple s’il ne l’est qu’à cause d’un « calcul foireux » en amont), alors c’est un bug, et le rôle du wrapper n’est pas de t’en prémunir. (A priori ce serait plutôt le rôle d’un assert(size != 0).)
Étant donné que le journal pose la question, je suppose qu'il cherche une solution…
Pas vraiment en fait, c’était plus un journal « exploratoire ». Présenter le problème et quelques-unes des solutions possibles, et voir ce que les autres programmeurs du coin ont à dire.
Au passage, une précision : comme le journal est construit (en gros ① on peut gérer gracieusement les erreurs d’allocation, ② mais c’est compliqué, ③ on peut aussi juste terminer en cas d’erreur vu que de toute façon avec un système à genoux on ne peut pas faire grand’chose), il donne peut-être l’impression que je recommande la terminaison immédiate sur erreur, ou que je considère ça comme « la bonne solution ».
Ce n’était pas mon intention. J’adopte généralement la méthode du « wrapper qui tue » dans mes programmes, parce qu’ils rentrent à fond dans la catégorie des programmes non-interactifs qu’on lance, font ce qu’ils ont à faire (ce qui typiquement prend un dixième de seconde), et terminent en rendant la main à l’utilisateur — le genre de programmes où il n’y guère d’intérêt à mon sens à essayer à tout prix de « gérer gracieusement » le manque de mémoire. Mais je ne veux surtout pas prétendre que c’est la bonne approche applicable à tous les cas de figure.
Au contraire, si je devais recommander quoi que ce soit, ce ne serait pas une méthode ou une autre, mais plutôt le fait de se poser quelques questions au début du développement (de quel type de programme s’agit-il ? quel devrait être, typiquement, le volume de données qu’il va manipuler ? est-ce un logiciel serveur supposé tourner indéfiniment, ou au contraire un programme à durée d’exécution limitée ? etc.) et de choisir la méthode de gestion du manque de mémoire en conséquence.
sous linux malloc (en fait l'appel système brk) ne renvois jamais null
Ce n’est pas figé dans le marbre. Le comportement est configurable par l’administrateur du système, donc même dans le cas d’un programme qui n’ambitionne pas d’être portable sur un autre OS il vaut mieux ne pas compter sur le comportement par défaut.
Pour mémoire, les comportements possibles sont :
ne jamais retourner NULL (overcommit) ;
retourner NULL dès lors que le processus consomme déjà une certaine quantité de mémoire (pas d’overcommit du tout), la limite par défaut étant fixée à la taille du swap + la moitié de la mémoire physique ;
ne pas retourner NULL sur la plupart des allocations (quitte à overcommitter s’il le faut), mais refuser quand même les allocations jugées « démesurées » — c’est le mode par défaut.
Merci pour le lien. J’avais déjà des réserves vis-à-vis de cette méthode, voilà qui finit de me convaincre que ce n’est pas une bonne idée.
Pour info, un argument que j’ai vu en faveur de cette méthode est que l’erreur de segmentation va provoquer la génération d’un core dump, qui peut être utile au programmeur pour une analyse post-mortem. Je ne suis pas vraiment convaincu, parce que je ne vois pas très bien ce qu’il y aurait de pertinent à analyser en cas de manque de mémoire (sauf éventuellement si c’est le programme lui-même qui est à l’origine de ce manque, à cause d’une consommation excessive ou d’une fuite). Au contraire, je pense que ça pourrait même compliquer l’analyse de tous les autres bugs, parce qu’alors à chaque segfault il faudrait se demander si ce n’est pas seulement dû à une allocation échouée plutôt qu’à un véritable bug.
Donc la question: ce genre de fonctionnalité existe-t-il? Peut-on le faire avec rspamd, ou dspam, ou n'importe quel autre système?
Je ne sais pas s’il existe un système le faisant tout seul « out-of-the-box », mais on peut obtenir la même chose à coup de règles procmail ou Sieve.
Chez moi par exemple, la règle Sieve qui envoie les mails marqués comme spam vers le dossier correspondant intervient après la règle qui envoie les mails de mes collaborateurs vers le dossier « travail », donc même si l’antispam a flaggé ces mails à tort (ce qui en pratique n’est jamais arrivé, il faut croire que mon filtre est bien entraîné — puis j’ai des collègues qui ne font pas suivre les chaînes de mail, ça aide), ils arriveront quand même au bon endroit.
L’inconvénient par rapport à ce que tu cherches est qu’il faut manuellement renseigner les adresses concernées dans le script Sieve. L’extension « Externally Stored Lists » (RFC 6134) pourrait aider à automatiser ça, mais l’implémentation de Sieve sur mon serveur ne la prend pas en charge.
[^] # Re: Effets stochastiques des rayonnements ionisants
Posté par gouttegd . En réponse au journal j'ai testé... devenir radioactif. Évalué à 10. Dernière modification le 07 décembre 2016 à 01:26.
En fait, il y a bien un seuil, mais il ne peut s’évaluer qu’à l’échelle collective (par des études épidémiologiques), pas à l’échelle individuelle.
On ne peut pas dire qu’au-delà d’une dose de x Sv, tu vas avoir un cancer à cause de tel et tel effet.¹ Ce qu’on peut dire, c’est que l’incidence des cas de cancer est plus élevée dans une population qui a été exposée à x Sv ou plus que dans une population qui a été moins exposée.
Ça veut dire notamment :
C’est la même situation que pour le tabac : un individu peut fumer 2 paquets de cigarettes par jour pendant quarante ans sans jamais avoir de cancer, alors qu’un autre individu non-fumeur peut mourir d’un cancer du poumon à trente ans (donc, pas de lien de causalité évident à l’échelle individuelle). Pour autant, à l’échelle épidémiologique il est clair qu’il y a plus de cas de cancers chez une population de fumeurs que chez une population de non-fumeurs, et il n’y a guère que les industriels du tabac qui continuent à essayer de faire croire que le lien entre tabagisme et cancer n’est pas établi.
¹ En revanche, avec des doses très élevées, les effets deviennent déterministes et plus stochastiques. On peut dire sans erreur qu’au-delà d’un seuil de y Sv, un individu va souffrir d’un empoisonnement aigu aux radiations (bien avant d’avoir le temps de développer un quelconque cancer).
[^] # Re: Effets stochastiques des rayonnements ionisants
Posté par gouttegd . En réponse au journal j'ai testé... devenir radioactif. Évalué à 10.
Pas tout-à-fait. Il existe aussi des mécanismes pour réparer les cassures double-brin.
Notamment, quand c’est possible, la cellule utilisera l’ADN de la chromatide homologue (quand celle-ci est présente, c’est-à-dire si la cassure survient entre la réplication de l’ADN et la division cellulaire) comme matrice pour réparer la double hélice endommagée. Dans ce cas, la réparation est fidèle.
Le problème est lorsqu’il n’y a pas de chromatide homologue à utiliser comme matrice. Dans ce cas, la réparation reste possible, mais avec un risque accru d’introduire des erreurs.
# Colophon
Posté par gouttegd . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 2. Dernière modification le 01 décembre 2016 à 23:20.
Le texte source de ce journal, au format DocBook, est disponible sous licence Creative Commons Paternité — Partage à l’Identique 2.0 (France).
La version publiée ici a été générée avec une feuille de style XSL (incluse dans l’archive ci-dessus) bricolée à LA RACHE, pour produire du Markdown à peu près conforme à ce qu’attend LinuxFR.¹
Une version PDF a été générée avec FOP et les feuilles de style du projet DocBook.
Pour la petite histoire, ce journal est celui que j’avais annoncé dans ce message datant de… juin 2015. J’annonce dès à présent que mon prochain journal sur OpenPGP sera consacré à la publication et à la diffusion des clefs OpenPGP, et devrait logiquement paraître vers le printemps 2018.
¹ Je ne sais pas exactement quelle est la flavor de Markdown utilisée sur LinuxFR.org, mais apparemment ce n’est aucune de celles prises en charge par Pandoc, d’où le recours à une feuille de style de mon cru…
[^] # Re: E comme...
Posté par gouttegd . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 3.
Rah, trop tard pour éditer. Il faut évidemment lire
nrsign(pour non-revocable signature), my bad.[^] # Re: Botnet
Posté par gouttegd . En réponse au message Les dangers sur Internet ?. Évalué à 5.
Je n’en mettrai pas ma main au feu. L’une des plus grosses vulnérabilités découvertes dans Android (Stagefright) était justement de ce type (failles dans la bibliothèque gérant les fichiers MP3/MP4).
[^] # Re: E comme...
Posté par gouttegd . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 4.
Traditionnellement, la lettre E est réservée à Eve, qui joue le rôle d’un attaquant passif¹ souhaitant écouter la conversation (eavesdropping).
Tu peux soit utiliser l’option
--default-cert-level npour toujours signer au niveau n, soit utiliser l’option--ask-cert-levelpour que GnuPG te demande interactivement, au moment de signer, quel niveau tu souhaites.Pour une certification non-exportable, on utilisera la commande
lsign(local signature) au lieu design, et pour une certification non-révocable, on utilisera la commandelrsign. Pour une signature non-révocable et non-exportable, il suffit de combiner les préfixes (dans n’importe quel ordre), donc ce seralnrsignounrlsign.¹ À moins que… ce ne soit Alice l’attaquant, et Eve l’interlocutrice légitime de Bob. ;)
[^] # Re: prédictibilité et confiance
Posté par gouttegd . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 6.
Idéalement. Après dans les faits, tu n’as que la confiance que tu peux avoir dans un logiciel libre, dont le code source est scrutable par tous et dont le développement se fait au grand jour. Ni plus, ni moins.
Ce n’est pas parfait — le problème de la « loi de Linus » (“Given enough eyeballs, all bugs are shallow.”) est que beaucoup de logiciels ne sont pas scrutés par « suffisamment d’yeux » pour qu’elle fonctionne. Mais GnuPG a quand même un avantage par rapport à un logiciel lambda : de par sa nature, il bénéficie de pas mal d’attention de la part de cryptologues et de chercheurs en sécurité.
Il y a quelques mois, un bug datant de l’origine de GnuPG (1998) et affectant le générateur de nombres aléatoires (mais apparemment pas assez pour compromettre la sécurité des clefs générées) a justement été corrigé, après avoir été découvert par deux chercheurs (Dörre et Klebanov, 2016).
Le générateur de nombres aléatoires du noyau Linux (d’où GnuPG obtient de quoi initialiser son propre RNG) bénéficie lui aussi de l’attention des chercheurs (Lacharme, 2012).
Est-ce assez pour avoir « totalement confiance » ? Peut-être pas totalement, mais en ce qui me concerne, assez pour avoir davantage confiance qu’avec des logiciels non-libres.
[^] # Re: La politique ask.
Posté par gouttegd . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 5.
Rien ne s’oppose à ça. Le seul inconvénient est que tu risques de rencontrer des problèmes avec les méthodes de sélection de clefs.
Par exemple, si tu veux éditer la clef de
bob@example.com, tu fais typiquement :S’il y a deux clefs (ou plus) associées à
bob@example.com, GnuPG sélectionnera arbitrairement l’une d’elles, peut-être pas celle que tu veux.Dans le pire des cas, si les deux clefs ont absolument la même identité (non seulement les adresses e-mails sont identiques, mais les noms également), il faudra avoir recours à l’identifiant de la clef (0xXXXXXXXX) pour les distinguer.
Je n’en vois guère. Il est relativement fréquent pour une même personne d’avoir plusieurs clefs, mais en général c’est pour séparer des activités qui n’ont rien à voir entre elles (une clef pour leurs activités professionnelles et une clef pour leurs communications personnelles par exemple), et donc ces clefs seront typiquement associées à des adresses e-mails différentes.
Le seul cas d’usage non-tordu qui me vient à l’esprit, où tu pourrais avoir deux clefs associées à la même adresse, est le cas d’un changement de clef, où pendant une certaine période ton ancienne clef et ta nouvelle cohabitent dans ton trousseau.
[^] # Re: La politique ask.
Posté par gouttegd . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 6.
En fait, la politique
askest celle qui sert à implémenter la gestion des conflits. Lorsqu’un conflit est détecté (lorsqu’on tente d’ajouter un binding {bob@example.com, 0xNEWKEY} alors qu’un binding {bob@example.com, 0xOLDKEY} existe déjà dans la base), la politique assignée au nouveau binding estaskau lieu de la politique par défaut — informant de fait GnuPG qu’il devra demander explicitement à l’utilisateur son avis sur cette clef.Lorsque l’utilisateur est sollicité, il peut soit résoudre le conflit en assignant une politique explicite (soit
goods’il pense que la nouvelle clef est la bonne, soitbadsi au contraire il pense que c’est une tentative d’usurpation), soit reporter la résolution à plus tard (parce qu’il veut plus de temps pour y réfléchir, ou qu’il espère avoir plus d’informations — peut-être en essayant de contacter son correspondant par un autre moyen pour savoir s’il a changé sa clef) en laissant la politique àask.(Le nom de cette politique vient de ce qu’elle apparaît, dans le menu affiché lors de la détection d’un conflit, sous l’étiquette Ask me again next time.)
[^] # Re: Il devrait toujours être possible d’ouvrir la partition chiffrée
Posté par gouttegd . En réponse au message Récupération d'un système chiffré.. Évalué à 2.
Oui, en effet, my bad.
luksDumpne fait qu’afficher les informations contenues dans l’en-tête sous une forme intelligible, c’est bienluksHeaderBackuppour sauvegarder l’en-tête.# Il devrait toujours être possible d’ouvrir la partition chiffrée
Posté par gouttegd . En réponse au message Récupération d'un système chiffré.. Évalué à 6.
Oui, du moment que tu connais toujours la phrase de passe.
Depuis un autre système GNU/Linux (installé sur une autre partition, ou démarré depuis un live CD ou une clef USB), et en supposant que ta partition chiffrée est par exemple
/dev/sda2:/mnt/tmpEn priant pour qu’à aucun moment, suite aux différentes manœuvres que tu as tenté ou simplement à cause de ce cher Murphy, l’en-tête LUKS de la partition chiffrée n’ait été endommagé, parce que sinon c’est mort (il faut toujours sauvegarder l’en-tête d’une partition chiffrée avec
luksDump!).[^] # Re: DANE: on met pas toute sa sécurité dans un seul panier ??
Posté par gouttegd . En réponse à la dépêche Firefox 50 Cent. Évalué à 6.
De deux choses l’une :
a) L’enregistrement TLSA est de type PKIX-TA ou PKIX-EE, ce qui signifie que la chaîne de certification présentée par le serveur doit être validée à la fois par PKIX (c’est-à-dire les autorités de certifications présentes dans le magasin du navigateur) et par DANE. S’il y a discordance entre les deux (PKIX dit que le certificat est valide mais il ne correspond pas à aucun enregistrement TLSA, ou inversement le certificat correspond à un enregistrement TLSA mais n’est pas valide du point de vue de PKIX), alors la chaîne de certification n’est pas valide.
b) L’enregistrement TLSA est de type DANE-TA ou DANE-EE, ce qui signifie que seules les informations du DNS sont à prendre en compte. Peu importe que le certificat soit, du point de vue de PKIX, invalide (par exemple parce que signée par une CA inconnue du navigateur), s’il correspond à l’enregistrement TLSA, il est valide.
[^] # Re: Lémédia
Posté par gouttegd . En réponse au journal Élections américaines. Évalué à 2.
Tu veux dire que c’est ce qu’il pense réellement et non pas une phrase politicienne calculée pour séduire l’électorat ?
OK, mais euh… c’est supposé être pour sa défense, ça ?
Et puis « à son insu »… Donald Trump est (entre autres choses) un homme de télévision, il ne pouvait pas ignorer qu’il était enregistré. (Ou au minimum qu’il pouvait être enregistré — les microphones qui ont enregistré la conversation n’étaient pas cachés, c’étaient ceux que Billy Bush et lui portaient sur eux !)
[^] # Re: Lémédia
Posté par gouttegd . En réponse au journal Élections américaines. Évalué à 5.
Mouais, permets-moi d’en douter.
Pour mémoire, voici la phrase en question :
Peut-être qu’un anglophone natif aura une lecture différente, mais moi je ne vois pas dans cette phrase une expression imagée. La seule image est la comparaison avec un aimant. Pour le reste, d’après moi il voulait dire littéralement ce qu’il a dit.
[^] # Re: sudo shutdown
Posté par gouttegd . En réponse au message [CLI] Arrêter la machine en utilisateur. Évalué à 2.
Euh, umount, c’est l’outil classique de démontage. Tu veux parler de pmount ?
Sinon, moi j’utilise udisksctl (partie de UDisks2), ça marche bien, je suis content. Et je vois un certain intérêt à ce que l’outil que j’utilise en ligne de commande pour monter un périphérique amovible passe par le même mécanisme que les outils en mode graphique, plutôt que de passer par un mécanisme complètement différent.
Un coup de RTFM, peut-être ?
Avant que tu me dises qu’on n’a pas besoin de ConsoleKit pour ça : tout-à-fait, de la même façon qu’on n’a pas besoin de UPower pour gérer l’alimentation, de UDisks pour gérer les périphériques amovibles, de PolicyKit pour gérer les permissions, de systemd pour gérer les services, etc. Le but de tous ces outils n’a jamais été de permettre de faire des choses infaisables autrement, mais bien plutôt d’offrir des interfaces unifiées pour les faire, faisant abstraction des mécanismes sous-jacents.
[^] # Re: sudo shutdown
Posté par gouttegd . En réponse au message [CLI] Arrêter la machine en utilisateur. Évalué à 1.
J’ai donné la commande plus haut :
Alors, oui, ça fait peur, et je serais totalement incapable de sortir cette commande à brûle-pourpoint sans consulter la doc.
Mais
① C’est pour ça qu’on a inventé les scripts shell. Je ne tape jamais moi-même la commande ci-dessus, j’ai un script pour ça (ainsi que pour appeler les méthodes de mise en veille et d’hibernation).
② Il serait trivial d’écrire un programme (compilé, pas un script) dont la seule tâche serait d’appeler cette méthode D-Bus, c’est juste qu’apparemment personne n’en a jamais ressenti le besoin. Pourquoi ? Probablement parce que les principaux utilisateurs de ConsoleKit sont les environnements graphiques, et que fournir un outil en mode ligne de commande n’a semblé nécessaire à personne.
[^] # Re: sudo shutdown
Posté par gouttegd . En réponse au message [CLI] Arrêter la machine en utilisateur. Évalué à 3.
Ouais, on peut râler sur ces censurés de développeurs qui ont le culot de développer des trucs…
Ou alors on peut prendre un (tout petit) peu de temps pour essayer de comprendre à quoi ils servent.
UPower n’a jamais été en charge de l’extinction de la machine, et son fonctionnement n’a jamais été mystérieux pour quiconque lit la doc. C’est un service D-Bus qui donne accès aux informations sur l’état de l’alimentation du système (évitant ainsi d’aller fouiller directement dans
/sys/class/power_supply), informe les applications qui le souhaitent des changements de cet état (passage d’une alimentation sur secteur à une alimentation sur batterie par exemple), et fournit des méthodes pour commander la mise en veille et l’hibernation.Jamais entendu parler d’UPower2. Tu ne confonds pas avec UDisks et UDisks2 ?
ConsoleKit est un service de gestion des sessions utilisateur. PolicyKit est un service d’autorisation, par lequel un programme réalisant des tâches « privilégiées » peut mettre ses services à la disposition de programmes non-privilégiés.
En l’espèce, l’extinction de la machine nécessite des privilèges administrateurs. Au lieu d’acquérir de tels privilèges (via sudo ou assimilé), un utilisateur non-privilégié peut demander l’extinction au service ConsoleKit, qui vérifiera préalablement, via PolicyKit, que cet utilisateur est autorisé à le faire. Dans la configuration par défaut de PolicyKit et ConsoleKit, un utilisateur normal est autorisé à éteindre la machine s’il est physiquement connecté dessus (ça peut se changer pour ceux qui n’aimeraient pas cette idée).
systemd-logind remplace ConsoleKit pour gérer les sessions utilisateurs. Rien d’autre ne change.
[^] # Re: Utilisateur et Administrateur
Posté par gouttegd . En réponse au message [CLI] Arrêter la machine en utilisateur. Évalué à 2.
Si ConsoleKit est encore là (pas sûr vu qu’il est normalement remplacé par systemd-logind), un utilisateur (même non-root, du moment qu’il est connecté physiquement) peut appeler la méthode D-Bus
org.freedesktop.ConsoleKit.Manager.Stoppour arrêter le système.Depuis la ligne de commande, ça peut se faire avec dbus-send(1) :
Sur les systèmes où systemd-logind a remplacé ConsoleKit, la méthode équivalente est apparemment
org.freedesktop.login1.Manager.PowerOff. Je soupçonne que l’on doit pouvoir également utiliser simplementsystemctl halt(même en tant que simple utilisateur, encore une fois tant qu’il est physiquement connecté), mais n’utilisant pas systemd je ne peux être affirmatif.# Demande directement à l’agent
Posté par gouttegd . En réponse au message gpg-agent - modifier le mot de passe qui protège les clefs ssh. Évalué à 3.
Sauf erreur de ma part, je ne pense pas que le front-end de GnuPG permette de changer la phrase d’un passe d’une clef exclusivement utilisée pour SSH.
En revanche, tu peux toujours t’adresser directement à l’agent GnuPG :
L’agent te demandera alors la phrase de passe actuelle (pour déchiffrer la clef telle qu’elle est actuellement stockée), puis la nouvelle phrase de passe.
Reste à obtenir le keygrip. S’agissant d’une clef utilisée pour SSH, tu devrais le trouver dans le fichier
~/.gnupg/sshcontrol.[^] # Re: undefined behaviour
Posté par gouttegd . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 2. Dernière modification le 27 octobre 2016 à 16:36.
Le wrapper va en effet retourner
NULLsi la taille demandée est 0.Je pense que s’il y a une possibilité légitime pour que le paramètre passé à
xmallocsoit 0 (par exemple parce que ce paramètre dépend, d’une manière ou d’une autre, d’une donnée extérieure au programme), c’est un cas à gérer explicitement. Le wrapper ne se substitue pas à la validation des entrées. Il ne me semble pas pertinent de traiter de la même façon une entrée incorrecte et une situation de manque de mémoire.Et s’il n’est pas légitime que le paramètre soit 0 (par exemple s’il ne l’est qu’à cause d’un « calcul foireux » en amont), alors c’est un bug, et le rôle du wrapper n’est pas de t’en prémunir. (A priori ce serait plutôt le rôle d’un
assert(size != 0).)[^] # Re: abort != avorter
Posté par gouttegd . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 5.
Je ne crois pas avoir utilisé avorter comme un verte transitif.
J’ai utilisé « avorter en cas d’erreur » et « avortement sur erreur », sans complément : le programme est ici le sujet, c’est lui qui avorte.
Lorsque j’ai voulu considérer le programme comme l’objet plutôt que le sujet, j’ai utilisé « terminer le programme » ou « quitter le programme ».
Pardon aux drosophiles.
[^] # Re: Mélange des deux
Posté par gouttegd . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 5.
Pas vraiment en fait, c’était plus un journal « exploratoire ». Présenter le problème et quelques-unes des solutions possibles, et voir ce que les autres programmeurs du coin ont à dire.
Au passage, une précision : comme le journal est construit (en gros ① on peut gérer gracieusement les erreurs d’allocation, ② mais c’est compliqué, ③ on peut aussi juste terminer en cas d’erreur vu que de toute façon avec un système à genoux on ne peut pas faire grand’chose), il donne peut-être l’impression que je recommande la terminaison immédiate sur erreur, ou que je considère ça comme « la bonne solution ».
Ce n’était pas mon intention. J’adopte généralement la méthode du « wrapper qui tue » dans mes programmes, parce qu’ils rentrent à fond dans la catégorie des programmes non-interactifs qu’on lance, font ce qu’ils ont à faire (ce qui typiquement prend un dixième de seconde), et terminent en rendant la main à l’utilisateur — le genre de programmes où il n’y guère d’intérêt à mon sens à essayer à tout prix de « gérer gracieusement » le manque de mémoire. Mais je ne veux surtout pas prétendre que c’est la bonne approche applicable à tous les cas de figure.
Au contraire, si je devais recommander quoi que ce soit, ce ne serait pas une méthode ou une autre, mais plutôt le fait de se poser quelques questions au début du développement (de quel type de programme s’agit-il ? quel devrait être, typiquement, le volume de données qu’il va manipuler ? est-ce un logiciel serveur supposé tourner indéfiniment, ou au contraire un programme à durée d’exécution limitée ? etc.) et de choisir la méthode de gestion du manque de mémoire en conséquence.
[^] # Re: undefined behaviour
Posté par gouttegd . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 5.
Ce n’est pas figé dans le marbre. Le comportement est configurable par l’administrateur du système, donc même dans le cas d’un programme qui n’ambitionne pas d’être portable sur un autre OS il vaut mieux ne pas compter sur le comportement par défaut.
Pour mémoire, les comportements possibles sont :
[^] # Re: undefined behaviour
Posté par gouttegd . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 5.
J’avoue que c’est ce que je pensais aussi.
Merci pour le lien. J’avais déjà des réserves vis-à-vis de cette méthode, voilà qui finit de me convaincre que ce n’est pas une bonne idée.
Pour info, un argument que j’ai vu en faveur de cette méthode est que l’erreur de segmentation va provoquer la génération d’un core dump, qui peut être utile au programmeur pour une analyse post-mortem. Je ne suis pas vraiment convaincu, parce que je ne vois pas très bien ce qu’il y aurait de pertinent à analyser en cas de manque de mémoire (sauf éventuellement si c’est le programme lui-même qui est à l’origine de ce manque, à cause d’une consommation excessive ou d’une fuite). Au contraire, je pense que ça pourrait même compliquer l’analyse de tous les autres bugs, parce qu’alors à chaque segfault il faudrait se demander si ce n’est pas seulement dû à une allocation échouée plutôt qu’à un véritable bug.
[^] # Re: "Furthermore, unlike competitors, Rspamd provides a lot of other checks and features."
Posté par gouttegd . En réponse au journal Rspamd continue son chemin. Évalué à 4.
Je ne sais pas s’il existe un système le faisant tout seul « out-of-the-box », mais on peut obtenir la même chose à coup de règles procmail ou Sieve.
Chez moi par exemple, la règle Sieve qui envoie les mails marqués comme spam vers le dossier correspondant intervient après la règle qui envoie les mails de mes collaborateurs vers le dossier « travail », donc même si l’antispam a flaggé ces mails à tort (ce qui en pratique n’est jamais arrivé, il faut croire que mon filtre est bien entraîné — puis j’ai des collègues qui ne font pas suivre les chaînes de mail, ça aide), ils arriveront quand même au bon endroit.
L’inconvénient par rapport à ce que tu cherches est qu’il faut manuellement renseigner les adresses concernées dans le script Sieve. L’extension « Externally Stored Lists » (RFC 6134) pourrait aider à automatiser ça, mais l’implémentation de Sieve sur mon serveur ne la prend pas en charge.