Benoît Sibaud a écrit 9651 commentaires

J'avais même oublié avoir été directement concerné comme upstream sur une CVE… cf https://www.cvedetails.com/cve/CVE-2002-1805/

Une erreur de balisage Markdown (cf le modèle qui indique que les pseudos/noms affichés sont prévus en italique https://linuxfr.org/wiki/modele-de-depeche-meilleurs-journaux ). Corrigé, merci.

• https://linuxfr.org/users/devnewton/liens/un-musee-de-l-informatique-aneanti-en-ukraine
• https://linuxfr.org/users/antistress/liens/deux-superordinateurs-du-temps-des-dinosaures-se-devoilent-au-musee-bolo-en-suisse-letemps-ch
• https://linuxfr.org/news/le-micral-n-au-musee-des-arts-et-metiers-le-10-decembre
• https://fr.wikipedia.org/wiki/Mus%C3%A9e_de_l%27informatique_%28La_D%C3%A9fense%29 (fermé en 2010)
• https://fr.wikipedia.org/wiki/Mus%C3%A9e_de_l%27informatique

« en France, il existe :

• à la Grande Arche de la Défense, le Musée de l'Informatique actuellement fermé ;
• à Rouen, le Musée BIOS (Biens Informatique Obsolètes Secourus) ;
• à Paris, l'association WDA,
• à Grenoble, l'aconit se consacre à la conservation et la restauration d'ordinateurs anciens, »

Autant je comprends les défauts potentiels voire avérés des CVSS, car il y a des enjeux autour d'un seuil qualitatif et des intérêts contradictoires, autant je n'ai pas connaissance de beaucoup de soucis propres aux CVE.

Les CVE sont des identifiants, on les retrouve dans les alertes sécurité (de chaque distribution, éditeur, projet, etc.), dans le suivi de sécurité (comme https://security-tracker.debian.org/tracker/
https://launchpad.net/ubuntu-cve-tracker etc. ), dans les outils de sécurité (trivy, les dependabot/renovate, wazuh, etc.), dans les discussions autour de la sécurité (jusque dans les étiquettes sur linuxfr.org), etc. Bref c'est comme les identifiants SPDX des licences pour les inventaires logiciels (SBOM), les UUID pour identifier des volumes, etc., etc. Il y a des tas de CVE dont chacun se contrefiche (n'utilisant pas le matériel ou le logiciel ou la version concernée), s'accommode (aucun intérêt pour la sécurité, impact faible ou inexistant dans sa situation), doit faire avec (pas de solution connue/pas de correction fournie, exemple failles sur les "vieux" CPU). Potentiellement des CVE "abusives" (auquel cas il n'y aura pas vraiment de correction à prévoir).
Globalement les avantages me semblent très largement compenser le défaut de déclaration abusive (qui ferait perdre un peu de temps à certains), sauf à montrer de l'abus est massif.

Les CVSS sont censées aider à prioriser les corrections (de critique fin du monde à un gars touché au fond du Nebraska), mais au final, sauf impossibilité (blocage fonctionnel, incapacité à tester/risquer, changement de licence, etc.) j'essaie de déployer toutes les corrections disponibles (ce qui ne règle pas le cas des non disponibles). Mais c'est un point de vue d'adminsys, pas de spécialiste sécurité. Indirectement je me base sur les CVSS via les outils de sécurité que j'utilise (trivy ou les alertes sécurité reçues parleront de gravité critique/majeure/mineure en fonction du CVSS).

Corrigé, merci.

les Release Notes (par ex https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgradingpackages ) disent : apt update && apt upgrade --without-new-pkgs && puis apt full-upgrade

Le dry-run actuel annonce :

1475     inactive accounts never used to purge
0    users to minimize
0    accounts to minimize because inactive and not seen since 1 year
0    active accounts not seen since 3 years to inactivate and minimize
1474     users without comments/contents to purge
1474     accounts to purge
1458     logs to purge
1474     friendly_id_slugs to purge
0    taggings to purge
0    oauth_access_grants for an oauth_application to purge
0    oauth_access_tokens for an oauth_application to purge
0    oauth_applications to purge
0    oauth_access_grants to purge
0    oauth_access_tokens to purge
0    deleted comments to minimize
0    comments from non-public contents to purge
0    taggings from non-public contents to purge
0    wiki_versions from non-public wiki_pages to purge
0    slugs from non-public wiki_pages to purge
0    non-public wiki_pages to purge
0    slugs from non-public trackers to purge
0    non-public trackers to purge
0    slugs from non-public posts to purge
0    non-public posts to purge
0    poll_answers to from non-public polls to purge
0    slugs from non-public polls to purge
0    non-public polls to purge
0    slugs from non-public bookmarks to purge
0    non-public bookmarks to purge
0    slugs from non-public diaries to purge
0    diaries converted into non-public news to purge
0    non-public diaries to purge
2    news_versions from non-public news to purge
1    paragraphs from non-public news to purge
1    links from non-public news to purge
1    slugs from non-public news to purge
1    non-public news to purge
1    non-public contents to purge

(c'est bien pénible à écrire, assez propice à la boulette, et il reste la partie sans filet à écrire)

Fusionné et déployé.

Avant :

1874 comptes valides et s’étant connectés au cours des trois derniers mois avec 29.2 jours de moyenne sans visite et 27.8 jours d’écart‑type

Après :

2458 comptes utilisés sur le site au cours des trois derniers mois avec 22.2 jours de moyenne sans visite et 25.9 jours d’écart‑type

Conservation et/ou expiration ?

Merci, déployée.

MR https://github.com/linuxfrorg/linuxfr.org/pull/374 comprenant en plus une mise à jour de l'aide, déjà visible sur le site.

Ça ferait un gros défi pour LinuxFr.org, vu qu'on a un lectorat présent un peu partout rendant la chose très théoriquement possible. Par contre une "grosse" base de données à transmettre est un souci, il faudrait ne transmettre que des mises à jour depuis la dernière rotation. Ça ne faciliterait pas les sauvegardes non plus (bien qu'une large part des données soit largement réparties alors). Ni l'accès aux logs (pour déboguer ou sur demande des autorités). Ni la responsabilité RGPD plus largement distribuée (et la purge d'un compte compliquée, en moins d'une rotation). Ni la multiplication des lois à respecter, sauf à n'avoir des points de présence que sur le territoire français continental ou ultramarin. Ni la coordination de tous les acteurs techniques nécessaires. Ni la longueur de mon commentaire.

GIF le permet contrairement aux autres formats

GIF permet de discuter longuement de comment on le prononce, contrairement à d'autres formats modernes.

Et la sur- ou sous-interprétation des propos de façon générale.

Exemple de sur-interprétation d'une IA par une autre : https://www.radiofrance.fr/franceinter/une-intelligence-artificielle-imitant-macron-et-de-gaulle-interdite-sur-la-plateforme-twitch-5490581

Corrigé, merci.

Hypothèse : du jargonnage en français (*) qui fait qu'on y trouve souvent on/off, en plus de un/zéro, I/O, 1/0 ou éteint/allumé. Et statistiquement, cela ressort dans les traductions automatiques.

(*) par exemple on pourrait trouver Gio ou GiB, noyau ou kernel, etc. dans un texte en français

Corrigé, merci.

Corrigé, merci.

Sans parler du daemon moniteur de rayons sur le système pour développeurs, le raymond DevOS.

macOS, iOS, sailfishOS, lineageOS

Équipe 1er degré : parce que sans OS, ça donnerait de bêtes noms très communs comme mac, I, sailfish ou lineage. Ça serait difficile à défendre comme marque, difficile pour communiquer, difficile pour rechercher de l'information dessus, etc.

Équipe second degré : effectivement personne n'appelerait un système d'exploitation fenêtres ou androïde, ou un langage rouille, va, python ou rubis

vu https://ubuntu.com/security/notices/USN-6304-1 vient de paraître
alors
https://security-tracker.debian.org/tracker/CVE-2023-40303 (vulnérable)
https://security-tracker.debian.org/tracker/CVE-2022-39028 (corrigée)

man sshd_config

     RequiredRSASize
             Specifies the minimum RSA key size (in bits) that sshd(8) will accept.  User and host-based authentication keys smaller than this limit will
             be refused.  The default is 1024 bits.  Note that this limit may only be raised from the default.

et c'est toujours la valeur par défaut

# sshd -T|grep -i requiredrsasize
requiredrsasize 1024

https://metadata.ftp-master.debian.org/changelogs//main/o/openssh/openssh_9.2p1-2_changelog

openssh (1:8.8p1-1) unstable; urgency=medium

  * New upstream release (https://www.openssh.com/releasenotes.html#8.8p1,
    closes: #996391):
    - This release disables RSA signatures using the SHA-1 hash algorithm by
      default.  (Existing RSA keys may still be used and do not need to be
      replaced; see NEWS.Debian if you have problems connecting to old SSH
      servers.)

(et peut-être RequiredRSASize directive to set a minimum RSA key length je n'ai pas vérifié la valeur par défaut)

Depuis un post client en Debian 12, il n'était plus possible de se connecter à certains serveurs sans modifier sa configuration ssh pour ces serveurs. Et les connexions depuis ces serveurs problématiques vers des Debian 12 pour les sauvegardes ne fonctionnaient plus non plus. -> il était temps de remplacer certaines clés RSA

Ensuite sur le choix : ECDSA n'a pas trop la côte ("Possible NSA backdoor" sur sshcheck.com par exemple), donc il reste ed25519 ou RSA-SHA2. C'est plus facile de changer d'algo pour voir si on n'a rien oublié et les clés ed25519 sont plus courts, deux arguments pas spécialement sécu pour arbitrer entre les deux choix possibles.

Même sur une seule planète on peut faire compliqué, cf https://fr.wikipedia.org/wiki/Ann%C3%A9e_(calendrier). Et puis pourquoi retrancher 2000 et pas plus ou moins, ouvrant la porte à des futurs bugs de l'an 3000 ou autres. On devrait donner un caractère unicode comme identifiant pour chaque version, dans l'ordre, parce qu'il y en a plein :).

https://thedailywtf.com/articles/Captchad--Beware-of-OmenCat pour des captchas pénibles pour les humains (tiré d'un de mes commentaires d'il y a un bout de temps)
ou
l’article « Cracking CAPTCHAS for cash: a review of CAPTCHA crackers » (M. Serrão, Shanu Salunke, Amrita Mathur, 2013) qui explique que le CAPTCHA de l’époque de LinuxFr.org est contournable à 100 % (tiré de https://linuxfr.org/news/ces-articles-papiers-et-autres-publications-qui-mentionnent-linuxfr-org ) -> bref en 2013 l'ordinateur savait déjà battre les CAPTCHA (cf http://caca.zoy.org/wiki/PWNtcha )