Hypothèse : ça a été fait par que souvent les gens écrivent « voici un lien https://example.invalid. » en mettant un point en fin de phrase, et que le cas est plus fréquent qu'une adresse qui finit réellement avec un point ?
D'après les dizaines de messages reçus par semaine, ce qui rapporterait serait de se faire payer pour du placement produit déguisé (pardon du contenu produit en partenariat)…
Se faire récolter/traire gratuitement ou spammer ne rapporte évidemment rien.
MAIS OVI SVPPRIMONS TOVS LES ACCENTS ET LES SIGNES DE PONCTVATION CA NE SERT A RIEN TOVT CA ET PVIS LES MINVSCVLES QVEL GASPILLAGE TOVT VN DEVXIEME ALPHABET POVR FAIRE EXACTEMENT LA MEME CHOSE
Le .deb (ou le .rpm) peut être signé numériquement. Si c'est le cas ET que la clé est déjà connue ou obtenue depuis un moyen sûr, alors c'est mieux qu'un script shell non signé plus facile à modifier.
Ça ne change pas grand chose si personne ne vérifie la signature ou que la clé de signature est définie/contrôlée par l'attaquant.
4.2.1. The "atom:author" Element
The "atom:author" element is a Person construct that indicates the
author of the entry or feed.
atomAuthor = element atom:author { atomPersonConstruct }
If an atom:entry element does not contain atom:author elements, then
the atom:author elements of the contained atom:source element are
considered to apply. In an Atom Feed Document, the atom:author
elements of the containing atom:feed element are considered to apply
to the entry if there are no atom:author elements in the locations
described above.
(...)
3.2. Person Constructs
A Person construct is an element that describes a person,
corporation, or similar entity (hereafter, 'person').
atomPersonConstruct =
atomCommonAttributes,
(element atom:name { text }
& element atom:uri { atomUri }?
& element atom:email { atomEmailAddress }?
& extensionElement*)
3.2.1. The "atom:name" Element
The "atom:name" element's content conveys a human-readable name for
the person. The content of atom:name is Language-Sensitive. Person
constructs MUST contain exactly one "atom:name" element.
Pigz compresses using threads to make use of multiple processors and cores.
man xz
-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.
Le changement doit d'abord être fait côté RoR pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier le daemon img pour séparer le traitement des requêtes HTTP "/img/encoded_uri vers les clés redis "img/uri" et le cache disque des img" par rapport aux requêtes "/avatars/encoded_uri vers les clés avatars/uri et le cache des avatars".
Il faudra aussi déplacer les avatars stockés dans l'actuel cache des img dans leur propre cache.
Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.
Dans les critères de choix : taille du résultat par rapport à l'original, vitesse, consommation CPU, consommation mémoire, possibilité de gérer un flux ou non.
Mon choix par défaut serait du xz (privilégier le taux de compression), en ignorant les consommations de ressources (en général non critiques). Du très commun/courant. Exception: le traitement en flux genre bdd_dump|compression backup.truc où une compression lente ralentit le 'dump' (et donc peut allonger la durée de verrous ou de lourdeurs sur la base de données (ou quel que soit le processus à gauche du pipe).
Et seulement si j'ai besoin (purement par simplicité), je change les paramètres par défaut.
"We value your privacy (…) click to consent to our and our 1445 partners". Effectivement vous valorisez ma vie privée, en grand partageur… (dédicace à ce commentaire)
Histoire de pinailler sur la forme (je n'ai pas le niveau en maths pour pinailler sur le fond), cette formulation serait à éviter dans un tel ouvrage (à vrai dire, je ne vois pas quand quel cadre écrit ou oral c'est une bonne idée, à part comme effet de manche… soit c'est évident et pas la peine d'expliciter « c'est évident » puisque c'est évident ; soit ça ne l'est pas et ça ne sert à rien non plus de dire/écrire « je fais partie de gens pour qui c'est évident, et vous ? »). Ça me fait penser aux règles de Vale pour la documentation (genre https://github.com/cockroachdb/docs/blob/master/vale/CockroachDB/Hyperbolic.yml ) pour éviter des mots inutiles.
# Visiblement ce n'est pas propre à la tribune
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi les liens qui se terminent par un point ne sont pas « linkifié » correctement. Évalué à 5 (+2/-0).
Exemple avec un %2e
https://fr.wikipedia.org/wiki/X_Corp%2e
Exemple avec un .
https://fr.wikipedia.org/wiki/X_Corp.
Hypothèse : ça a été fait par que souvent les gens écrivent « voici un lien https://example.invalid. » en mettant un point en fin de phrase, et que le cas est plus fréquent qu'une adresse qui finit réellement avec un point ?
[^] # Re: Toujours pareil
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Doctolib déploie une IA pour capter et analyser les conversations patients-médecins ! . Évalué à 5 (+2/-0).
D'après les dizaines de messages reçus par semaine, ce qui rapporterait serait de se faire payer pour du placement produit déguisé (pardon du contenu produit en partenariat)…
Se faire récolter/traire gratuitement ou spammer ne rapporte évidemment rien.
[^] # Re: Infos à vérifier
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Faille d'exécution de code à distance dans cups. Évalué à 5 (+2/-0).
Corrigé, merci.
[^] # Re: Enfin!
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Unicode en version 16.0.0, le plein de hiéroglyphes égyptiens et de symboles informatiques. Évalué à 10 (+13/-0).
I. REVENIR A L ALPHABET LATIN LE VRAI
II. IE GRAVE SVR MARBRE POVR MOINS BAVASSER
III. TOVT VNIFIER PAR L IMPERIALISME
IV. SESTERCES!
# Liens supplémentaires
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Faille d'exécution de code à distance dans cups. Évalué à 6 (+3/-0).
Références CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, CVE-2024-47177
# Vidéos du GUADEC 2024
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Vidéos des dernières conférences : BreizhCamp, JDLL et transcriptions April. Évalué à 3 (+0/-0).
https://linuxfr.org/users/vmagnin/liens/les-videos-du-guadec-2024-sont-en-ligne
[^] # Re: Le paradoxe de la sécurité
Posté par Benoît Sibaud (site web personnel) . En réponse au lien RootAsRole v3.0!. Évalué à 4 (+1/-0).
Le .deb (ou le .rpm) peut être signé numériquement. Si c'est le cas ET que la clé est déjà connue ou obtenue depuis un moyen sûr, alors c'est mieux qu'un script shell non signé plus facile à modifier.
Ça ne change pas grand chose si personne ne vérifie la signature ou que la clé de signature est définie/contrôlée par l'attaquant.
# Voir journal
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Vérifier si CUPS tourne sur votre serveur Ubuntu et le désactiver. Évalué à 3 (+0/-0). Dernière modification le 28 septembre 2024 à 11:26.
https://linuxfr.org/users/samuel/journaux/faille-d-execution-de-code-a-distance-elevation-de-privilege-dans-cups
et
https://linuxfr.org/users/cg/liens/une-faille-de-securite-a-distance-jugee-tres-serieuse-sera-rendue-publique-le-6-octobre-2024
# LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Down de juillet et avenir du Journal du hacker . Évalué à 7 (+4/-0).
Nous (équipe LinuxFr.org) évaluons ce qui serait possible et comment on pourrait aider. La proximité avec les liens LinuxFr.org est assez évidente.
[^] # Re: Enfin!
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Unicode en version 16.0.0, le plein de hiéroglyphes égyptiens et de symboles informatiques. Évalué à 4 (+1/-0).
Ce n'est pas le but des zones à usage privé ? so that third parties may assign their own characters without conflicting with Unicode Consortium assignments
https://en.wikipedia.org/wiki/Private_Use_Areas#Private_Use_Areas
[^] # Re: Je suis inclu
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Haiku a 23 ans - Haiku R1 bêta 5 (partie 3 : documentation, finances et GSOC). Évalué à 5 (+2/-0).
Corrigé, merci.
[^] # Re: je réfléchis
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Pour une poignée de gigabits..... Évalué à 8 (+5/-0).
Et si tu pouvais apprendre à mettre des étiquettes correctement aussi stp.
[^] # Re: Correction de hack ?
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche SPIP 4.3 : une sortie estivale. Évalué à 4.
Oui je suis bien d'accord c'est pénible ces acteurs du SEO qui jouent les pénibles chez les autres.
# précédent
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Linux boots in 4.76 days on the Intel 4004. Évalué à 6 (+3/-0).
https://linuxfr.org/users/cg/liens/demarrage-de-linux-sur-un-processeur-4-bits-intel-4004-de-1971
# Spécifications pour les flux Atom
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Le flux RSS mésuse la balise <author>. Évalué à 3 (+0/-0).
https://www.rfc-editor.org/rfc/rfc4287#section-4.2.1
[^] # Re: pigz
Posté par Benoît Sibaud (site web personnel) . En réponse au message Question sur la gestion des fichiers compressés avec gzip sous Linux. Évalué à 6 (+3/-0).
man pigz
man xz
# Analyse
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Séparer le cache des avatars du cache des autres images. Évalué à 3 (+0/-0). Dernière modification le 23 septembre 2024 à 11:25.
Le changement doit d'abord être fait côté RoR pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier le daemon img pour séparer le traitement des requêtes HTTP "/img/encoded_uri vers les clés redis "img/uri" et le cache disque des img" par rapport aux requêtes "/avatars/encoded_uri vers les clés avatars/uri et le cache des avatars".
Il faudra aussi déplacer les avatars stockés dans l'actuel cache des img dans leur propre cache.
Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.
# Avis plus ou moins éclairé
Posté par Benoît Sibaud (site web personnel) . En réponse au message Question sur la gestion des fichiers compressés avec gzip sous Linux. Évalué à 6 (+3/-0). Dernière modification le 23 septembre 2024 à 08:02.
Dans les critères de choix : taille du résultat par rapport à l'original, vitesse, consommation CPU, consommation mémoire, possibilité de gérer un flux ou non.
Mon choix par défaut serait du xz (privilégier le taux de compression), en ignorant les consommations de ressources (en général non critiques). Du très commun/courant. Exception: le traitement en flux genre
bdd_dump|compression backup.truc
où une compression lente ralentit le 'dump' (et donc peut allonger la durée de verrous ou de lourdeurs sur la base de données (ou quel que soit le processus à gauche du pipe).Et seulement si j'ai besoin (purement par simplicité), je change les paramètres par défaut.
Des comparaisons anciennes :
[^] # Re: Le karma...
Posté par Benoît Sibaud (site web personnel) . En réponse au journal LinuxFr.org : première quinzaine de septembre 2024. Évalué à 4 (+1/-0). Dernière modification le 22 septembre 2024 à 17:10.
Je dirais bien trop longtemps. (Bon après on gère des choses sur les images des 13 dernières années, donc tout est relatif)
# Datacenter et LQDN
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Data centers : des données… pas données (podcast France Inter). Évalué à 5 (+2/-0). Dernière modification le 22 septembre 2024 à 12:00.
À rapprocher de Conférence de presse à Marseille contre les data centers
- 16 septembre 2024 côté LQDN
# OSnews
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Google donne des armes aux applis contre les utilisateurs d'Android rootés / dégooglisés. Évalué à 10 (+10/-0). Dernière modification le 21 septembre 2024 à 10:36.
"We value your privacy (…) click to consent to our and our 1445 partners". Effectivement vous valorisez ma vie privée, en grand partageur… (dédicace à ce commentaire)
[^] # Re: Constante de Weiner
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Y a le Frido 2024 qu'est là. Évalué à 6 (+3/-0).
Les problèmes de communication commence avec un nombre de Cro-Magnon supérieur ou égal à la constante de Weiner.
[^] # Re: Apparamment, ils ont remis ça…
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Des centaines de blessés dans l'explosion de leurs bipeurs !. Évalué à 6 (+3/-0).
Ils avaient vu sur un forum qu'il fallait juste le PN pour commander une batterie ?
[^] # Re: Constante de Weiner
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Y a le Frido 2024 qu'est là. Évalué à 2 (+0/-1).
Histoire de pinailler sur la forme (je n'ai pas le niveau en maths pour pinailler sur le fond), cette formulation serait à éviter dans un tel ouvrage (à vrai dire, je ne vois pas quand quel cadre écrit ou oral c'est une bonne idée, à part comme effet de manche… soit c'est évident et pas la peine d'expliciter « c'est évident » puisque c'est évident ; soit ça ne l'est pas et ça ne sert à rien non plus de dire/écrire « je fais partie de gens pour qui c'est évident, et vous ? »). Ça me fait penser aux règles de Vale pour la documentation (genre https://github.com/cockroachdb/docs/blob/master/vale/CockroachDB/Hyperbolic.yml ) pour éviter des mots inutiles.
[^] # Re: Jolie contrepèterie
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Y a le Frido 2024 qu'est là. Évalué à 4 (+1/-0).
Bien vu, c'était bien mon intention quand j'ai mis ce titre (à la base pour éviter la collision de slug avec les dépêches précédentes).