GuiGui's Show

Résumé : les erreurs rapportées ci-dessous (et dans le titre) sont rares pour une machine virtuelle (peu de pages web en parle), je n'ai pas de solution à proposer et, dans mon cas, la machine virtuelle a totalement crashé deux mois après les premiers symptômes. Vérifie tes sauvegardes. :)

En juillet 2020, l'une de nos machines virtuelles Proxmox+KVM kernel-panic-ait, parfois plusieurs fois par jour. Puis ce comportement a disparu sans intervention humaine.

Début août 2020, /var passe en lecture seule. Je redémarre la VM, un fsck se déclenche et la partition était à nouveau montée en écriture. Le lendemain, notre supervision m'indique que cette partition est à nouveau en lecture seule. dmesg indique que la transition a eu lieu 256 minutes (4 h) après le démarrage. Les erreurs consignées sont :

kernel: sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
kernel: end_request: I/O error, dev sda, sector 29954432
kernel: Aborting journal on device sda7.
kernel: ext3_abort called.
kernel: EXT3-fs error (device sda7): ext3_journal_start_sb: Detected aborted journal
kernel: Remounting filesystem read-only

Pourquoi uniquement /var alors que toutes les partitions de cette machine virtuelle sont stockées dans le même LV LVM sur l'hyperviseur ? Car il s'agit d'un serveur, donc une fois qu'il a démarré et que les principaux binaires sont en RAM, il n'y a quasi plus de lecture et encore moins d'écriture sur /, alors que /var reçoit les journaux systèmes et applicatifs en permanence.

I/O wait côté hyperviseur ? Je n'y crois pas, car les graphes sur la page de résumé de l'hyperviseur dans l'interface web de Proxmox ne le montrent pas.

La VM n'a pas assez de temps CPU pour effectuer ses opérations car ses ressources CPU sont sous-dimensionnées ou que l'hyperviseur est débordé par d'autres VMs ? Je n'y crois pas, car top affichait « 0,0 st » (st = steal time = temps volé). Mais comme je n'étais pas là au moment du passage en lecture seule… De plus, c'était les vacances, donc la charge de ce serveur était très réduite et aucun changement n'a été mis en œuvre par les administrateurs sur l'ensemble du périmètre (cette VM, l'hyperviseur, le réseau, etc.).

Très peu de ressources sur le web mentionnent les erreurs que je rencontre.

Je trouve la première partie des erreurs extraites de mon dmesg dans un ticket chez VirtualBox.
La première piste est un problème d'I/O côté hyperviseur. Comme vu ci-dessus, aucun élément me permet d'affirmer cela.
La deuxième est de désactiver NCQ (optimisation des I/O en laissant le disque dur ordonnancer lui-même les requêtes afin de les traiter dans l'ordre de l'emplacement physique des données). Je n'y crois pas : 1) mes erreurs ne mentionnent pas NCQ ; 2) il y a trop d'abstractions (ext4 sur une partition étendue dans un LV LVM dans un volume RAID matériel) pour que NCQ puisse agir. J'ai quand même désactivé NCQ dans la VM.

Je trouve la deuxième partie des erreurs dans un rapport de bug chez Red Hat. Problème dans Linux censé avoir été corrigé à la fin des années 2000 mais qui est toujours là en 2013 et 2014… La version du système de notre VM date justement de la fin des années 2000, mais la version de notre noyau est ultérieure à celle dans laquelle le correctif est apparu.
Je me laisse convaincre que, peut-être, le journal ext est corrompu, ce qui explique le déclenchement automatique d'un fsck à chaque redémarrage, même quand la partition /var n'a pas été remontée en lecture seule.

La partition /var étant utilisée par plein de processus, je ne peux pas travailler dessus. Je redémarre donc en single user mode (une entrée GRUB me le proposait, sinon il faut éditer la ligne et ajouter « single » à la fin de la ligne « linux » et démarrer en pressant ctrl+x) puis je tape les commandes suivantes proposées dans un commentaire du rapport de bug :

tune2fs -O ^has_journal /dev/sda7
fsck.ext4 -f /dev/sda7
tune2fs -j /dev/sda7
reboot

Vu que fsck n'a pas trouvé d'erreur, je pense que tout cela a été vain.

Quoique… Cela a tenu un mois et demi.

Le serveur a totalement crashé mi-septembre 2020. Impossible de booter car absence de partition… Il semble qu'il ne s'agissait donc pas d'un problème temporaire type I/O wait / temps CPU volé, etc.
Un coup de testdisk depuis un Live CD a permis de remettre la partition / dans le MBR, mais pas /var…

Nous avons monté une nouvelle machine virtuelle. La configuration du service a été récupérée depuis Bacula. Les données des utilisateurs du service étaient stockées dans un partage NFS. Aucune perte de données à déplorer.

Nginx prend en charge nativement le rate-limiting, c'est-à-dire la limitation du nombre de requêtes par intervalles de temps sur une page web, sur plusieurs pages web, sur un site web entier. Il est même possible de mettre des adresses IP en liste blanche, de limiter uniquement les requêtes de type POST, de cumuler plusieurs critères de limitation (par hôte virtuel + par adresse IP source, par exemple), etc.

Dans mon cas, le CAPTCHA maison d'un formulaire de contact web est extrêmement faillible. C'est une leçon d'humilité pour les anti-Google dans mon genre : on ne remplace pas reCAPTCHA en un claquement de doigts. Comme dans tout formulaire, un email est envoyé à l'administrateur du site web et un autre à la personne qui a rempli le formulaire. En changeant la valeur du champ HTML « email », il est donc possible d'envoyer un email à n'importe quelle adresse email. Bien sûr, le sujet de l'email ne sera pas au choix du spammeur et le message du spammeur sera entouré de phrases convenues ajoutées par le site web comme « vous avez envoyé le message suivant à l'administrateur du site machin.example », mais cela convient aux spammeurs.

En attendant que les développeurs nous informent qu'ils feront rien et que nos utilisateurs nous valident que ce formulaire est inutile car ils ne souhaitent pas traiter les réclamations par email mais par une demande dans notre système de tickets, une limitation du trafic a été utile pour juguler temporairement le spam sans perdre en fonctionnalité.

D'abord, je déclare un limiteur dans /etc/nginx/conf.d/rate-limiting.conf (mieux vaut ici que de modifier nginx.conf, car ça permet au gestionnaire de paquets du système de mettre à jour nginx.conf sans intervention humaine) : limit_req_zone $binary_remote_addr zone=contact:10m rate=1r/m;. On travaille sur l'adresse IP (stockée, par nginx, dans la variable interne « $binary_remote_addr »). On nomme le limiteur « contact ». Il pourra occuper 10 Mo de mémoire tout au plus (ce qui permet de stocker environ 16 000 états IPv4 ou 8 k états IPv6). Il limitera le trafic à une requête par minute.

Ensuite, j'active le limiteur dans le bloc « server » de l'hôte virtuel :

location /contact {
    limit_req   zone=contact burst=3 nodelay;
    uwsgi_pass  django;
}

Je limite les requêtes uniquement sur la page « /contact » du site web.

J'utilise le limiteur nommé « contact ». Au-delà d'une requête par minute, j'autorise un pic jusqu'à 3 requêtes (par minute, toujours). Je dégage au plus vite les requêtes excédentaires (au-delà du pic) afin de ne pas consommer inutilement des ressources (nombre de connexions simultanées, RAM, etc.) plutôt que de mettre en file d'attente les requêtes excédentaires en attendant qu'un slot se libère après l'expiration du temps d'attente (1 minute tout au plus).

« django » fait référence à un upstream de type socket fichier défini en amont. Car, oui, ce nginx est en frontal d'une application Python Django servie par le serveur d'applications uwsgi.

Je recharge la configuration avec systemctl restart nginx, et c'est terminé. \o/

Avec cette configuration, on est passé de 3000 spams en quelques heures à deux spams par heure puis l'emmerdeur a laissé tomber. :)

Si j'avais voulu limiter uniquement les requêtes POST, voici ce que j'aurai mis dans /etc/nginx/conf.d/rate-limiting.conf :

map $request_method $limit_post {
    default    "";
    POST       $binary_remote_addr;
}

limit_req_zone $limit_post zone=contact:10m rate=1r/m;

Ça ne fonctionnait pas car notre spammeur avait résolu le CAPTCHA. Dit autrement : il faisait plusieurs requêtes de type GET sur le formulaire web. Dès qu'il reconnaissait l'URL d'une image qu'il avait décodé (exemple : s'il trouvait <img src="/images/captcha_a52b844ab3acbd1169db9a66647285b5fc694284/" […] /> dans le code source de la page web, alors il savait qu'il fallait remplir le champ HTML « captcha » avec la valeur « 7 » car cette URL pointera toujours sur un CAPTCHA qui dit « 5 + 2 = ? », seul le fond, le bruit, changera), il envoyait une requête POST, et, forcément, il tapait dans le mille dès cette première requête, ce qui met en échec toute limitation de trafic.

Au final, puisque le CAPTCHA est faillible, que l'application web envoie l'email destiné à l'administrateur à une adresse email invalide sans tenir compte de la configuration (autre bug signalé), que les développeurs ne corrigeront pas l'application web, et que nos utilisateurs ne veulent pas traiter les réclamations par email, nous avons mis en place une page web qui invite les visiteurs à déposer une demande d'assistance dans notre outil de gestion de ces demandes.

Pour ce faire, voici la nouvelle configuration que l'on trouve dans l'hôte virtuel de nginx :

location /contact {
    root /chemin/vers/ma/super/appli/;
    try_files /erreurContact.html $uri;
}

La racine du site web (document root) est tel chemin. Lorsqu'une requête arrive, essaye de servir le fichier « erreurContact.html » (qui se trouve dans la racine du site web), sinon sers l'URL qui t'es demandée. Comme la page existera toujours, c'est toujours elle qui sera servie.

Next Inpact est un journal spécialisé dans le numérique, le droit du numérique, et les nouvelles technologies en général. J'y ai un compte, un abonnement, tout ça.

Depuis quelques mois, le site web ne fonctionnait plus correctement avec mon Firefox :

• J'étais déconnecté après une durée très courte (quelques minutes) et environ aléatoire alors que je ne change pas d'adresse IP ni de navigateur web ;
  
  
• Quand j'ouvrais un lien vers un autre article dans un nouvel onglet (en cliquant sur la molette de la souris), j'étais déconnecté dans ce nouvel onglet mais toujours connecté dans l'onglet "principal" (même après un F5). Je parle bien d'un lien interne, pas d'un lien vers Inpact Hardware ou Bonsplans.tech ou autre site web du groupe ;
  
  
• Lors du chargement d'une page web, ça affichait le thème clair par défaut avant de passer au thème sombre que j'ai choisi dans les paramètres de mon compte utilisateur.

Les cookies sont bien autorisés par uMatrix. Je n'ai pas de filtrage actif sur Next Inpact. J'ai tenté de désactiver toutes mes extensions : ça ne fonctionne pas mieux.

En revanche, tout fonctionne bien depuis un profil Firefox vierge. J'arrive à la conclusion qu'un de mes règlages dans about:config doit foutre la grouille… Identifier lequel s'avère être compliqué.

Au final, j'ai « autorisé » explicitement « nextinpact.com », « www.nextinpact.com », « compte.nextinpact.com » et « api-v1.nextinpact.com » à déposer des cookies "permanents" (qui ne seront pas supprimés à la fin de la session c'est-à-dire à la fermeture de Firefox ‒ car j'ai configuré Firefox pour ce faire) depuis le gestionnaire de cookies de Firefox (Édition, Préférences, Vie privée et sécurité, bouton « Gérer les permissions… » dans la rubrique « Cookies et données de site »). Je ne comprends pas pour quoi cela fonctionne, mais ça fonctionne.

Un script JavaScript pour Greasemonkey (extension Firefox) qui permet de dégager, pour de vrai, la popup « connectez-vous » de YouTube. Contrairement aux règles de filtrage pour uBlock que l'on trouve partout, le champ de recherche reste fonctionnel et la vidéo n'est pas mise en pause.

Quand on refuse les cookies (et que l'on n'a pas de compte Google YouTube), ce script est indispensable, sinon la lecture de chaque vidéo est interrompue après quelques secondes pour tenter d'afficher la popup et il faut alors cliquer à nouveau sur la vidéo pour que la lecture reprenne. De même, les liens contenant une estampille temporelle (exemple : « watch?v=XXXXXXXXX&t=300 ») ne fonctionnent plus : le site tente de charger sa popup… on clique pour lire la vidéo… qui reprend du début (au lieu de commencer depuis l'estampille temporelle).

Pendant qu'il m'emmerdait avec cette popup, j'ai bien pensé à ne plus utiliser YouTube, le dernier service Google dont je n'arrive pas à me séparer. Mais pour aller où ?

La communauté PeerTube ? Il y a des moteurs de recherche comme Sepia Search et PeerTube index. L'impossibilité de reprendre la lecture d'une vidéo après plusieurs heures me gonfle vraiment. Mais surtout, c'est l'absence de contenus qui me retient de franchir le pas. J'utilise YouTube pour regarder des conneries, pas pour déprimer sur l'état du monde. Or, sur ce point, PeerTube est à YouTube ce que les cinémas Utopia sont au cinéma ou ce que les Mutins de Pangée sont à Netflix ou la FNAC : on y trouve du contenu chiant qui donne à réfléchir ou des contenus niais de bobo gauchiste (genre X est un immigré unijambiste (une mine antipersonnel…) qui se fait tabasser par les flics dans une manif' écolo ; Y, jolie jeune femme, se prend d'amour pour lui, et, ensemble, ils vont changer le monde et pratiquer le sexe féministe). Ça va deux minutes.

J'ai pensé à utiliser une instance Invidious (interface qui fait le relai entre des utilisateurs et YouTube). L'extension Firefox Privacy Redirect permet de rediriger automatiquement toute requête YouTube (ou Twitter ou Google Maps) vers une ou plusieurs instances Invidious. Sauf que :

• Il existe peu d'instances et la plupart sont d'une lenteur exécrable. La liberté a un coût, certes, mais il ne faut pas déconner ;
  
  
• L'écosystème n'est pas encore pérenne. Exemple : l'instance de DryCat a été stoppée du jour au lendemain. Or, j'ai besoin de pérennité quand je propose des liens sur mon shaarli ;
  
  
• YouTube change souvent des petits détails techniques. Ces changements font qu'Invidious ne fonctionne plus. Exemple : la recherche (aucun résultat) et l'affichage de la liste des vidéos d'une chaîne (« Could not get channel info. ») sont cassés depuis plusieurs mois sur l'instance Invidious de FDN. Il faut attendre que le mainteneur d'une instance se sorte les doigts pour mettre à jour, ce qui peut prendre masse de temps. Notons que ce point est aussi vrai pour le script Greasemonkey sus-mentionné… ;
  
  
• Utiliser Invidious pour se rendre invisible de Google, c'est comme utiliser un VPN pour fuir son FAI : ça déporte le problème plus loin. Si les pages web passent à travers l'instance Invidious, les vidéos, elles, sont directement récupérées depuis YouTube, donc YouTube sait que telle adresse IP a regardé telle vidéo. C'est moins mauvais qu'un cookie ou qu'un compte Google qui associe chaque vidéo à une machine ou à un utilisateur, mais quand même. Ensuite, puis-je faire confiance au mainteneur et à l'hébergeur de l'instance Invidious ? Quel sont leurs modèles économiques ? Tout cela n'est pas dit.

Bref, rester sur YouTube avec un script Greasemonkey reste le moins mauvais choix. Jusqu'à quand ?

J'suis mal en campagne, et mal en ville, peut-être un p'tit peu trop fragile. Allô maman bobo.
[…]
Moi je voulais les sorties de port à la voile, la nuit barrer les étoiles. Moi les chevaux le révolver et le chapeau clown, la belle Peggy du saloon.
J'suis mal en homme dur, et mal en p'tit cœur, peut-être un p'tit peu trop rêveur. Allô maman bobo.

Énorme +1. Qui suis-je ? Trop attentionné et pas assez. Trop sensible et pas assez. Trop concerné / impliqué et pas assez. Trop pragmatique et trop rêveur. Comment se trouver ? Comment gérer ses contradictions ? Comment trouver sa place ? Vastes questions pour tant de tristesse. :'(

Pour joindre / fusionner plusieurs fichiers PDF en un seul fichier, j'utilise pdftk (paquet logiciel du même nom dans Debian) : pdftk 1.pdf 2.pdf 3.pdf cat output 123.pdf.

Chez moi, pdfjoin / pdfjam fonctionnent jamais : au-delà du premier PDF, les PDF suivants sont orientés selon le format paysage alors qu'ils sont conçus au format portrait, comme le premier document…

Résumé : impossible de se connecter à un lecteur réseau winwin / CIFS depuis une machine Ubuntu 20.04 ? Ajouter client min protocol=NT1 dans la section [global] du fichier /etc/samba/smb.conf. Attention : cela pose des problèmes de sécurité !

Depuis le gestionnaire de fichiers d'une machine Ubuntu 20.04, impossible de se connecter à un serveur CIFS. L'erreur suivante s'affiche avant même de demander l'identifiant + domaine + mot de passe :

Oups ! Quelque chose s'est mal passé.
Message d'erreur non géré : impossible de monter le partage Windows : Le logiciel a provoqué l'abandon de la connexion.

Si l'on essaye de s'y connecter avec le logiciel smbclient, on obtient l'erreur suivante avant toute demande d'identifiant :

smbclient //serveur.monorganisation.exemple/nom_lecteur -u <identifiant>
protocol negotiation failed: NT_STATUS_CONNECTION_DISCONNECTED

En revanche, cela fonctionne toujours avec mount -t cifs //serveur.monorganisation.exemple/nom_lecteur /point/de/montage -o username=<identifiant>,vers=1.0.

Il ne faut pas aller chercher bien loin : mount d'une part et smbclient et gvfs d'autre part ne doivent pas utiliser le même sous-système, et l'antique version 1 du protocle SMB doit être désactivée dans l'un d'eux. C'est en effet le cas depuis la version 4.11 de Samba… Qui est justement celle distribuée dans Ubuntu 20.04. On notera que le problème se présentera aux Debianeux avec Bullseye. ;)

Un contournement est indiqué dans le journal des changements de Samba : il faut ajouter client min protocol=NT1 dans la section [global] du fichier /etc/samba/smb.conf. Pas besoin de redémarrer quoi que ce soit : la modification est immédiatement effective.

SMBv1 est dépréciée + elle pose des problèmes de sécurité, donc il faut la réactiver avec précaution. Dans notre cas, c'est en attendant la fin de la migration vers notre nouveau NAS.

La girafe a un long cou car elle prend du recul. Elle a de grandes pattes car elle est orientée résultats, elle veut trouver une solution.

2020, """"formation"""" obligatoire « Bien vivre le télétravail ».

Rigole pas, c'est avec ton pognon qu'on finance ce genre de bullshit. Les charlatans ne perdent pas de temps, et les gaspilleurs qui les financent non plus.

Tu vas me dire « tu prends une phrase dans une formation de plusieurs heures ».

Même pas. Y'avait aussi :

• la communication non-violente renommée OSBD (observation, sentiment, besoin, demande) étudiée sous l'aspect hausse de la productivité (on ne pratique pas la CNV afin d'atteindre une plus grande humanité, mais pour engendrer plus de fric en exploitant mieux les sous-fifres ‒ je fais le même reproche au team building ‒).
  
  
• les exercices de reformulation permettant de faire passer la pilule (demande de comptes, d'avancement, inquisition dans l'organisation), auprès des sous-fifres ;
  
  
• l'infantilisation : "il faut éviter le « tu » accusatoire. On ne dit pas « tu devais faire ceci pour telle date », mais « ceci devait être fait pour telle date »", le « on » / « nous » au lieu du « tu » ;
  
  
• un "il faut se donner de la force !" avec les mouvements bullshit des bras ;
  
  
• les analogies foireuses et les schémas tout claqués que tous les formateurs se partagent entre eux et recyclent.

Je suis bien content d'avoir échappé à c'te connerie même si, au fond, je suis l'idiot : mieux vaut être payé à (faire semblant d')écouter c'te blague qu'à travailler, ça demande moins d'efforts.

Allez, je vais être gentil : j'imagine que cette """"formation"""" est déjà plus acceptable (en termes de gaspillage de pognon) que les """"formations"""" sophrologie et autres gabegie en matière de formation professionnelle.

Ça me rappelle l'habilitation électrique ou une formation sur les méthodes agiles : bullshit over bullshit for more bullshitness.

Tant qu'il y aura des gens pour trouver ces """"formations"""" « pas si mal »…

Saka: Tain mais les meufs sur Tinder
Saka: C'est quoi votre délire avec le filtre chien ?
Saka: Vous comptez attirer qui ? Les zoophiles ?

Énorme +1.

J'essaye d'intégrer une image au format png dans un document PDF avec ImageMagick : convert image.png document.pdf.

Cette fois-ci, ça ne fonctionne pas : convert-im6.q16: attempt to perform an operation not allowed by the security policy 'PDF' @ error/constitute.c/IsCoderAuthorized/408.

Réponse sur StackOverflow : suite à une vulnérabilité dans Ghostscript, et en attendant le correctif, l'une des mesures de mitigation consistait à désactiver le traitement de scripts PostScript lorsqu'on utilise ImageMagick en ajoutant des lignes dans /etc/ImageMagick-6/policy.xml. Si l'on a un Ghostscript à jour (gs --version >= 9.24), on pourrait désactiver la restriction visant PDF en commentant la ligne « <policy domain="coder" rights="none" pattern="PDF" /> » dans la configuration d'ImageMagick. La solution fonctionne, mais les risques ne sont pas précisés et l'histoire (c'est lié à la vulnérabilité X) ne colle pas avec la réalité de ce qui s'est passé dans Debian.

Allons plus loin et découvrons quelques outils et horreurs de l'écosystème Debian.

Plusieurs points me font tiquer : la vulnérabilité date de 2018, Debian stable embarque une version corrigée de Ghostscript depuis septembre 2018[*] a minima, et je pouvais encore convertir vers PDF il y a quelques mois. Conclusion : la configuration d'ImageMagick a été changée récemment. Quand ? Pourquoi puisque Ghostscript été corrigé à date ?

ls -lh /etc/ImageMagick-6/policy.xml affiche le 25 juin 2020 comme date de dernière modification. Si tu l'as modifié avant de penser à faire un ls, tu peux vérifier l'horodatage dans le paquet binaire. (Quand le temps aura passé, il faudra récupérer la version dont je parle, 6.9.10.23+dfsg-2.1+deb10u1, depuis les archives des paquets Debian). Pour savoir que le fichier /etc/ImageMagick-6/policy.xml provient du paquet logiciel imagemagick-6-common : apt-file search /etc/ImageMagick-6/policy.xml ou dpkg -S /etc/ImageMagick-6/policy.xml.

Ça ne prouve pas que la modification est apparue dans la version 6.9.10.23+dfsg-2.1+deb10u1 ? Il suffit de récupérer la version précédente, 6.9.10.23+dfsg-2.1, du paquet logiciel dans les archives de paquet de Debian. Le paquet date de mai 2019 et le fichier policy.xml ne contient pas les changements.

J'aurais voulu utiliser git pour retrouver l'info, mais : 1) le dépôt Debian d'ImageMagick n'a pas de branche ni tag pour la version 6.9.10.23+dfsg-2.1+deb10u1 (c'est probablement normal : il s'agit d'une version publiée par l'équipe sécurité de Debian, pas par les mainteneurs Debian d'ImageMagick), ni pour la version 6.9.10.23+dfsg-2.1 ni pour la version 6.9.10.23+dfsg-2 et les tags de version 6.9.10-23 et 6.9.10.23-dfsg-1 ne contiennent pas les modifications de policy.xml. La version upstream ne contient pas non plus la modification. On trouve l'adresse du dépôt git Debian depuis la page du Package Tracker dédiée à ImageMagick. On trouve le dépôt officiel / upstream avec un moteur de recherche (ou dans les commits du dépôt Debian si l'on a l'œil et de la chance).

Cette date de modification de policy.xml, 25 juin 2020, apparaît dans le journal des changements du paquet (/usr/share/doc/imagemagick-6-common/changelog.Debian.gz ou lien « Debian Changelog » dans la page dédiée au paquet) : tout plein de vulnérabilités ont été corrigées ce jour-là. Les bulletins de sécurité Debian associés sont le DSA-4712-1 et le DSA-4715-1 [**]. L'identifiant CVE de la vulnérabilité mentionnée sur StackOverflow n'est pas mentionné dans la liste (et pour cause, elle a été corrigée + elle concerne un autre logiciel, Ghotscript).

On remarque que les vulnérabilités corrigées ce jour-là (25 juin 2020) ont été enregistrés en 2019 dans le CVE… Ça fait long la correction de la vulnérabilité. :O Il est donc plus probable que le changement dans le fichier policy.xml d'ImageMagick soit une mesure préventive afin de tenter de mitiger, à l'avance, les vulnérabilités liées à des logiciels tiers dont Ghostscript. Dans Debian stable, il y a actuellement 36 vulnérabilités non-corrigées dans ImageMagick.

Sur un serveur web avec du contenu dynamique exposé sur Internet, je pense qu'il ne faut pas désactiver les restrictions définies dans policy.xml.

En revanche, sur mon ordinateur de bureau, je peux désactiver la restriction PDF sereinement en la commentant avec <!-- --> (c'est comme ça qu'on commente en XML…) : 1) je ne télécharge pas n'importe quoi depuis n'importe où, que ce soit sur le web ou par email ou Jabber ou… ; 2) dans mon gestionnaire de fichiers, je désactive l'indexation et la prévisualisation des fichiers, qui sont toutes deux susceptibles de faire exécuter du PostScript dangereux dans mon dos.

Bref, ce n'est pas simple faire court sans dire nawak / faire des raccourcis et ce n'est pas simple non plus d'approcher la vérité dans un écosystème aussi vaste que Debian…

[*] Comment sais-je que Ghostscript n'est plus vulnérable depuis septembre 2018 ? Je cherche le numéro de CVE, donné sur StackOverflow, dans le Security Tracker de Debian (champ de recherche tout en bas). Je trouve le numéro du bulletin de sécurité Debian : DSA-4294-1. Je consulte les archives de la liste de diffusion debian-security-announce (si t'es l'admin d'un parc de machines Debian, je te conseille de t'y abonner) ou je cherche dans le dépôt git du security tracker de Debian (fonctionnalité « blame » pour identifier le commit qui a ajouté telle ligne dans tel fichier). Dans les deux cas, je trouve que la vulnérabilité CVE-2018-16509 dans Ghostscript a été corrigée le 16 septembre 2018.

[**] Même raisonnement qu'au point précédent pour trouver ces bulletins de sécurité Debian.