Benoît Sibaud a écrit 9836 commentaires

Entrée fermée, merci.

Un certificat, soit tu le demandes / renouvelles à la main, soit automatiquement (protocole ACME, l'utilisation la plus connue est Let's Encrypt).
Il faut s'assurer qu'il marche au déploiement (ie. bien déployé, correctement, et initialement valide).
Ensuite il est souvent stocké quelque part, et utilisé. Et donc il faut surveiller les certificats stockés (fichier, dans git, etc.) pour voir s'ils vont expirer et agir en amont, mais aussi les certificats actifs, pour savoir si on a bien déployé les bons et s'ils vont bientôt expirer. Et réagir à l'expiration à venir doit être suffisamment rapide pour gérer la demande du nouveau certificat (validation éventuelle, paiement, etc.) et son déploiement avant l'expiration.
Et si tout est automatisé, il faut surveiller l'automatisation pour s'assurer que ça marche.

Quand les périodes de validité sont longues, on se retrouve avec des incidents tous les ans ou les deux ans car l'automatisation n'est pas en place, que les équipes ont changé entre-temps, etc. Plus les périodes sont courtes, plus soit tu automatises, soit tu as une armée de personnes pour suivre la cadence, soit tu as beaucoup d'incidents.

(et des certificats il y en a utilisés par des tas de logiciels différents pour des protocoles différents, donc la supervision peut être assez variée aussi, et puis il y a plein de cas plus compliqués comme le même domaine avec une IP intranet et un certificat d'une autorité interne et aussi une IP internet et un certificat d'une autorité publique, et il faut superviser les deux du coup, etc.).

Pour revenir à la question : des sites pas visibles (au sens ton navigateur ne voudra pas y aller sauf à lui dire que tu sais ce que tu fais), éventuellement des pertes financières et des données (oups on n'a pas effectué le virement car votre certificat était expiré et que notre client n'a pas voulu transmettre, oups on n'a pas reçu vos données car notre certificat était expiré et que votre client n'a pas voulu transmettre, etc.). Et un besoin de mettre "plus souvent" à jour les certificats de autorités aussi, donc potentiellement une fin de vie plus rapide des vieux téléphones mobiles (et autres équipements devenus sans suivi) si personne ne peut leur fournir des mises à jour.

J'ai fait les deux qui me manquaient hier.

Et tu demandais ce que je changerais : perso j'avais tiqué sur le wifi en 1986 dans les hôtels, mais c'est purement sur la partie narrative.

Un rappel de commandes / une historisation pourrait être sympa.

Bien, on a les tables présentes et donc une base de départ. Sans liste des colonnes et graphe des relations ça va cependant être coton. Je me lance aussi :

(la première fois, j'ai essayé plein de commandes pour avoir les tables et le schéma aussi… avant de voir qu'ils sont donnés… et après on dira aux enfants de lire les énoncés avant de commencer…)

On a la liste des tables présentes, et si on clique sur une table on a son schéma :

Exemple:

witness_statements

Column   Type    Key
id       INTEGER ⚿ 
guest_id INTEGER ⛓
clue     TEXT   

(donc 'id' est la clé primaire, et guest_id une clé étrangère vers le champ 'id' de la table 'guest')

Sinon l'exploration des tables avec LIMIT 1 suffit aussi à comprendre ce qu'elles contiennent.

Doublon du commentaire juste en dessous

Liens retirés ou remplacés (les versions dans Archive.org ne sont pas utilisables)

PPS : si la modération peut transformer la longue multiligne de code en bloc SQL…

Fait, merci.

comme 3O ou 40 tranches

Ambiguïté de bouton, c'est un O pas un 0. Il faut revoir l'ergonomie du clavier.

Ce pourrait-il que :

$ host -t A git.atlanticaweb.fr
git.atlanticaweb.fr has no A record
$ host  git.atlanticaweb.fr
git.atlanticaweb.fr has IPv6 address 2a01:4f9:c012:a658::1

• LQDN appelle à un moratoire sur la construction des plus gros data centers. (ie. pas tous les datacenters)
• en ligne ne veut pas nécessairement dire datacenter (penser P2P ou LAN partie par exemple)

Ceci étant dit, je ne sais pas trop faire un serveur efficace et énergétiquement efficace à domicile (genre LinuxFr@home), à première vue.

• Les bénévoles de l'association Hygiène Sans Frontière peuvent laver votre linge.
• Notre patrouille de scouts « Loutres laveuses » peut laver votre linge contre une petite pièce.
• Notre société Ménage3000™ peut vous envoyer du personnel pour laver votre linge.
• Le linge peut être lavé avec du savon noir.
• Le savon noir Schmurtz™ peut laver votre linge.
• La lessive PlusPlusMieux™ lave plus blanc que blanc.
• Si vous ne lavez pas votre linge trois fois par jour, notre étude américaine montre un accroissement du risque de maladies de peau de 27% et vos enfants pourraient souffrir de maladies respiratoires et cutanées. (étude EntubeFluorée 2025 sur un échantillon de commerciaux des entreprises de l'agrochimie)
• « Mangez des pods de lessive Burp3000 » (Juana Kevina, influenceuse TokTok) …

les mises à jour qui foirent. Tu as la chance de ne pas avoir eu ce genre de problème, mais je peux t'assurer qu'ils sont encore très courants dans le monde Linux.

ça ne résout pas tous les problèmes. On avait depuis longtemps la garantie d'une mise à jour d'un fichier de façon atomique. Et le fait que le descripteur de fichier est valide tant qu'il reste au moins une utilisation. Du coup on pouvait remplacer libtruc.so.2.0 par libtruc.so.2.1, et même pour les processus utilisant l'ancienne version au même moment, ça allait (par contre le changement effectif nécessitait un redémarrage du processus).

Avec du btrfs ou avec une installation séparée dans une autre arborescence (ce que fait Nix), on a une bascule atomique d'un ensemble de fichiers vers un autre (et le retour arrière possible). Donc on élimine les cas où on a mis à jour la moitié des fichiers seulement avant d'être interrompu par une erreur du script, une saturation du disque ou une coupure électrique par exemple. Mais il faut toujours gérer les redémarrages.

Et ça ne traite pas forcément le cas des données (si tu migres de TrucSQL v2 à TrucSQL v3, les binaires sont mis à jour, les données sont éventuellement converties avec "pertes", et peut-être que le retour arrière n'est pas prévu…).
Et ça ne traite pas forcément le cas des fichiers utilisateurs (configuration, fichiers temporaires, cache, etc.) : si la v3 ajoute un fichier truc et que la v2 ne peut pas fonctionner avec ce fichier truc présent, et que personne ne personne à l'enlever/mettre de côté pendant le retour arrière, alors ça casse encore. trucpourrait aussi être un core dump imprévu par exemple.
Et ça ne traite pas le cas des fins de vie : tu mets à jour ton appli parce qu'elle contient/utilise une ressource qui expire (genre un certificat ou une clé GPG), alors le retour arrière ne fera pas de miracle non plus.
Et probablement d'autres cas…

Et comme on ne peut pas avoir toutes les propriétés que l'on veut en simultané, si chaque logiciel vient avec ses propres dépendances "privées" à lui, alors gérer la sécurité globale de tout cela est plus compliqué par exemple.

https://blog.middleearth.fr/ublock-origin-nest-pas-un-adblocker.html

uBlock Origin n'est pas un adblocker
C'est un outil de sécurité indispensable.

(déjà évoqué ici me semble-t-il)

Oumph : c’est mes yeux ou quoi ?
ElVirolo : Je crois que ça doit être vos yeux!
Oumph : Ah, ouais, c’est mes yeux, ouais !

(Les Bronzés font du ski^Wweb)

What if we made all advertising illegal? It's such a wild idea that I've never heard it in the public discourse.

Pfff la personne ne lit pas LinuxFr org. Supprimer / interdire la pub y a déjà été proposé plusieurs fois (et ce n'est sans doute pas l'idée la plus wild vue ici).

Et on pourrait aussi monter un raisonnement par l'absurde sur le droit à la vie privée et ce que ça donnerais si il était absolu, mais ça serait plus glauque. Par exemple et comme ça a été le cas pendant longtemps, considérer que les violences domestiques sont du domaine du privé serait quand même une catastrophe avec un droit de la vie privée absolu.

Dans le cadre privé, tu peux (techniquement) insulter qui tu veux, tu peux faire des contrefaçons et du recel de contrefaçons, tu peux faire pousser des plantes illégales, tu peux (toujours techniquement) commettre des violences familiales, etc. C'est hors de portée (techniquement) de la justice. Jusqu'à ce que quelqu'un parle, témoigne, une découverte fortuite par les forces de l'ordre, une perquisition pour une autre raison, une exposition publique reliée (communication en public, diffusion de contrefaçons, mise en vente de plantes illégales, etc.), etc.

Une dystopie serait une surveillance 24/7 de tout le monde supprimant le domaine privé (pas de vie privée, de secret des communications de secret bancaire, de secret médical, etc.)

A priori on veut notamment garder des communications privées : l'échelle peut donc aller de "privée réservée au participants" à "visible par tous ceux sur le chemin". Actuellement la règle est grosso-modo "privée autant que voulu par les correspondants - ils communiquent en clair ou en chiffrement bout en bout - dans la limite des exceptions sécuritaires).

Par exemple le L32-3 du Code français des postes et télécom https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000034312035 définit le secret des correspondances, à qui il s'applique, ce qui est secret (y compris ce qui est en clair, l'identité des correspondants par exemple). Et les interceptions / écoutes judiciaires ou administratives ( https://www.legifrance.gouv.fr/codes/section_lc/LEGITEXT000006071154/LEGISCTA000029563661?query=interceptions+l%C3%A9gales&searchField=ALL&tab_selection=code&anchor=LEGISCTA000029563661#LEGISCTA000029563661 ,
https://fr.m.wikipedia.org/wiki/Interceptions_obligatoires_l%C3%A9gales , https://www.service-public.fr/particuliers/vosdroits/F2515 , etc.) viennent en opposition. Dans les cas d'interception, les intermédiaires techniques doivent fournir un accès à l'échange tel qu'ils le voient passer, en retirant donc leurs propres couches de sécurité éventuelles. Mais l'échange peut avoir été chiffré/codé par les participants eux-mêmes, qu'il soit texte, audio, vidéo ou données. Rien n'oblige jusqu'ici à parler en clair, dans la langue du pays, sans sous-entendu, sans métaphore et en rappelant le contexte pré-existant.

Le moyen de l'interception est souvent le transporteur de la communication (obligation d'opérateur télécom par exemple) mais ça pourrait être le fournisseur d'un des équipements de communication (penser logiciel et matériel de son smartphone par exemple), une sonorisation du lieu d'un participant (micro-espion, Alexa/Siri/…), un autre intermédiaire technique (l'IA traductrice ou preneuse de notes par exemple). Ce qui amène la question d'attaquer l'équipement de communication lui même par les services, pour les écoutes légalement. Ce qui amène la question : faut-il prévoir / affaiblir initialement l'équipement ou laisser les services se démerder pour trouver une faille (et quelles conséquences s'ils se ratent en essayant, genre briquer l'équipement ou perte de données).

On arbitre donc entre ce qu'on veut faire, ce qu'on peut techniquement faire à coup sûr (interceptions téléphoniques avec un réseau conçu pour ça) ou qu'on peut essayer techniquement de faire (cybersécurité offensive, intrusion au domicile) ou ce qu'on contraint les gens à faire (a priori ou a posteriori). Et la contrainte que les méchants ne respectent pas les lois.

l'obligation d'avoir le dernier appareil à la mode, pour des prétextes de cybersécurité :

prétextes ? Il y a de vraies raisons à mettre à jour pour des raisons de cybersécurité justement. Et si je devais râler ça serait plutôt sur la qualité initiale (qui oblige à multiplier les mises à jour derrière), en raison de la priorité donnée au fonctionnel et au dernier truc qui fera vendre. Ce n'est pas un hasard si le législateur a tapé du poing sur la table et ajouter plein de textes pour renforcer les contraintes en sécurité informatique pesant sur les différents acteurs (NIS2, CRA, etc.). On peut râler sur la durée limitée de la prise en charge sécurité par exemple, sur l'indice de réparabilité matérielle et logicielle, sur la transparence et le code source, sur les magasins d'application, sur les pouvoirs publics qui utilisent aveuglément des moyens privés sans réflexion, etc., mais ne pas mettre à jour un téléphone mobile c'est une grosse bêtise.

Les 4 raisons données sont liées à Microsoft, et pas intrinsèquement à LibreOffice. Et ça m'attriste un peu.

Fin du support de Windows 10
Augmentation des prix des logiciels propriétaires
Lassitude à l'égard de l'IA
L'épuisement de l'abonnement

Potentiellement c'est aussi les bons choix de LibreOffice d'une part, et le filtre rédactionnel de ZDNet qui compare tout à ce que son lectorat connait plutôt que LibreOffice ex-nihilo. Et ça me réjouit un peu.

Il y a une erreur d'envoi te concernant. Je remonte l'info à Florent.

L'accent circonflexe sur apparaît n'est plus nécessaire depuis la réforme de l'orthographe de 1990.
https://fr.wikipedia.org/wiki/Rectifications_orthographiques_du_fran%C3%A7ais_en_1990

Venant juste de finir de regarder My 2025 uv-based Python Project Layout for Production Apps par Hynek Schlawack, je dirais que sur le second cas, "extremely fast" et "in Rust" sont justement un des avantages (du non fonctionnel certes), avec une meilleure gestion des dépendances et de l'outillage d'empaquetage. Autant une app générique écrit en Rust ou autres, on peut se dire peu importe, autant un outil dédié à un langage dans un autre langage, ça interroge toujours un peu (est-ce le temps de bootstrapper le nouveau langage ? Une limitation actuelle du langage le temps de définir la norme ? Etc.).

Après sur un outil de renommage de fichiers, je suis plus intéressé par les fonctionnalités effectivement, à savoir s'il sera dispo en standard ou pas dans ma distribution/conteneur, s'il fait des blagues comme 'rename' qui est différent suivant les distributions, etc.

kof kof comme Thunderbird ?
https://linuxfr.org/users/wilk/liens/thunderbird-pro-c-est-pas-pour-les-amateurs

Il y a aussi IGMP 3 qui est sorti, mais le public connaissant et utilisant les deux est probablement restreint.

Nous sachons qu'il y a tout un système derrière D, et qu'il s'appellerio…

Version du 1er avril https://dlang.org/changelog/2.111.0.html