cg a écrit 1869 commentaires

Quand c'est prêt, faire un financement participatif pour obtenir le visa de sécurité de l'ANSSI a du sens : format ouvert, code ouvert, audité et certifié, l'État a tout à y gagner :).

Le truc pénible, c'est que la certification vaut pour une version spécifique, ce qui mène à avoir une ligne "LTS" qui ne bouge pas, et une version qui vit sa vie.

C'est une super initiative, c'est vrai que ça manque. Je connais Zed! qui fait ça, mais c'est propriétaire.

Je viens de relire l'entrée du suivi, et c'est quand même le point le plus débattu, ce qui entretien la légende ! Mais je conçois que ce n'est pas la seule raison :).

Je me demandais s'il existe un schéma d'archi (ou un texte) qui présente les différentes composants du site ? Je ne connais pas trop RoR, mais ça me rend curieux :).

Hello,

j'ai tendance à classer ce genre d'éditeur comme une TUI (Terminal User Interface ou Text User Interface), mais pas comme CLI (Command-Line Interface).

sed et awk sont des éditeurs en ligne de commande, oui. edit ou vi sont des TUI.

Voilà, c'était la minute pédante, bonne fin de dimanche :).

Merci pour l'exposé.

L'avantage du plan d'adressage LLA est d'être indépendant de l'infrastructure, il devrait donc pouvoir être "relocalisé" facilement en cas de besoin. Si le VLAN en arrière plan doit être étendu mutli-site, in maillage VXLAN chiffré devrait pouvoir faire l'affaire.

Avec des IPs RFC1918 et un VLAN aussi, c'est généralement portable. Ce qui a mis le bazar ici c'est le DHCP.

Les archi "cloudesques" […] pods/conteneurs […] orientées services (ou micro-services) […] frontal […] ingress-controler/load-balancer/reverse-proxy) qui relaie […]

C'est une complexité inutile pour un site comme Linuxfr :).

Par contre, pour te rejoindre, mais sur le côté IP publique, l'argument de ne pas proposer d'IPv6 parce que la fonction de vote regarde les IPs pour éviter la triche, bof en 2025 non ?.

J'ajoute au résumé : la souris est (était) vendue environ 35€. Une souris de qualité équivalente (souris simple type Logitech M100) se trouve pour 9-10€.

Donc faire de la petite/moyenne série, avec des composants sourcés avec soin, ça multiplie le prix par environ 3,5. Pour le fun, suivons cette logique (qui est sans doute incomplète et fausse à l'échelle) :

• Un PC portable à 800€ serait à 2800€.
• Un téléphone à 300€ serait à 1050€.
• Un serveur à 10000€ serait à 35000€.

Et le raisonnement inverse : le Fairphone 6 vendu 600€ serait à 170€ ?

Bon, ces calculs sont très vraisemblablement totalement bidons :).

Merci de ce retour !

Oui sur le client actuel qu'on utilise, et son futur remplaçant, les fonctionnalités ne sont pas les mêmes en fonction de l'OS du endpoints, et c'est pénible :-/.

J'aime bien qu'il donne des stats par lettre manquée. Je constate que j'ai un problème aigu avec les i et les o :).

Ah, j'aurais bien aimé avoir ce proctocole disponible il y a quelques années, j'avais du modifier un sextoy pour le piloter en MIDI (pour faire de la musique), alors qu'il ne proposait qu'une interface entrée audio (l'objet d'origine vibrait selon les basses de la musique d'un baladeur branché dessus).

Des Indiens d'Inde, d'Amérique du Nord ou d'Amérique du Sud :p ?

Je crois que c'était aussi pour générer du trafic entrant vers les réseau de Free, pour avoir des accords de peering favorables avec les autres opérateurs.

S'il y a des capteurs type LIDAR pour la profondeur, en plus de la caméra, ou qu'une technique type photogrammétrie (voir aussi MeshRoom pour un exemple parlant) est utilisée, tu peux rendre l'usurpation par photo simple assez difficile.

Le scan de rétine ou de paume ont ceci d'intéressant qu'ils ne fonctionnent que si la personne est vivante, donc ça ne marche pas avec une photo, un moulage ou un prélèvement d'organe :).

Je me dis que Devnewton pourrait se lancer dans un projet d'authentificafion, à base d'empreinte anale (<- lien à contenu choquant) :).

Imagine du code québecois : nb_chars ? Tu comptes les caractères ou les voitures ?

Ma parade est d'utiliser des noms de variable, de classe, de fonction… à rallonge, quitte à exaspérer mes collègues :).

Ça pourrait donner nombre_de_voitures ou number_of_cars (mais je mettrais plutôt cars_count ou quantity_of_cars).

Au final, je crois que le plus important est d'essayer d'être cohérent et d'éviter les mélanges. Et dès qu'on utilise des bibliothèques tierces, ça devient super difficile (EndEntity vs end_entity vs endentity ?)

Hello, chouette billet !

Il y a un truc, par contre, qui est typique, et un peu agaçant, c'est quand on confère un sens spécifique - voire magique - au terme anglais alors que son équivalent en français porte le même sens. Ça mène à utiliser des termes dont on ignore le sens en français, qui deviennent des termes-concepts, au sens un peu flou. Des trucs comme thread, stack, log, proxy, prompt, policy… Ça pourrait ressembler à du jargon mais ça n'en est pas vraiment. C'est vraiment la situation ou le terme en français est considéré comme "incorrect" car supposé ne pas avoir le même sens - alors que si. Souvent, il se cache dessous une mauvaise maîtrise du concept.

Dans mon cas, ça m'est arrivé à trois reprises d'être dans une équipe qui s'internationalise (avec des États-uniens, Italiens, Allemands), et avoir toute la doc et les noms de variables en anglais au départ a bien aidé. C'est vrai que ça peut être un frein si tu embauches une personne qui a un niveau d'anglais moyen.

Anecdote amusante, j'ai acheté un bouquin d'apprentissage au Python¹, écrit par un Français, et les noms de variables sont carrément avec des accents, c'est assez amusant à considérer :). Du coup dans l'interpréteur interactif, j'ai essayé avec des noms de variables dans une langue qui se lit de droite à gauche, ça donne de drôles de trucs en terme de gestion du curseur 😅.

Openconnect est vachement bien, mais on est obligé d'utiliser les clients bloated/proprio, car ces clients supportent les "postures", qui consistent à vérifier l'état du endpoint avant d'autoriser la connexion au réseau.

Exemples de postures :
- une machine qui n'est pas à jour ne va avoir accès qu'aux repos de paquets/serveurs de patch.
- La connexion au VPN est refusée si l'antivirus est coupé.
- Le client VPN désactive le routage de paquets à la connexion.
- La connexion au VPN se coupe si un second utilisateur se loge sur la machine.

Je ne crois pas que openconnect permettre ces contrôles, peut-être qu'on pourrait le faire via des scripts type pre-up.d ?

Il y a deux raisons à cela : Docker étant mieux connu des utilisateurs, c'est plus simple et plus fluide pour elles et eux d'utiliser Docker. Et comme on évite de valider plusieurs outils pour rendre des services très similaires (les analyses de risques peuvent être chronophages), le choix a penché du côté de Docker.

C'est vrai que ça peut s'évaluer en terme de risque. C'est sans doute plus facile de trouver un truc louche dans un fichier d'entrée que dans le code compilé ou compressé. À voir aussi si l'anti-virus peut-être configuré pour dire "pour tel process, n'analyser que les écritures et pas les lectures".

Bonne suggestion en tout cas, merci.

Au cas où tu ne connaisses pas, pass est assez populaire aussi (format différent de keepass).

Bonne question ! OVHcloud a un petit paquet de certifications, selon les services.

Pour le périmètre de nos laptops Linux (donc les laptops + tout le bazar autour qu'on voit sur le schéma), on passe des audits SOC, ISO27K1, PCI-DSS, et des audits internes. Certains laptops sont également soumis à SecNumCloud (c'est une autre histoire).

Donc pourquoi PCI-DSS et pas HDS ou autre chose ? Je n'ai pas forcément les tenants et aboutissants, et ça m'avait d'ailleurs surpris aussi au départ.

Déjà, ça permet d'intervenir sur des plateformes de paiement, et toutes les plateformes qui ont un niveau de sécurité inférieur. Et puis le fait que ce soit déjà utilisé ailleurs en interne est assez pratique pour les équipes qui gèrent le SMSI, ça permet de mutualiser l'effort pour elles et eux j'imagine.

Décider que l'ensemble des postes de travail va répondre à cette norme qui est quand même assez exigeante, c'est mettre la barre assez haut, certes, mais est-ce superfétatoire ? À l'ère du RGPD, considérer les données des clients comme aussi critiques que des données bancaires, c'est du bon sens, quelque part, je crois :).

Salut,
sans même réfléchir, on doit mettre un anti-virus comportemental (EDR/XDR) parce que c'est imposé par la norme PCI-DSS.

Un anti-virus qui ne fonctionne que par signature est utile pour protéger le voisin sous Windows, en effet, mais le vrai truc c'est la détection de comportement étranges, et ça, clamav ne ne fait pas :-/. Il y a des choses comme Wazuh ou OSSEC qui permettent ce genre de détection.

Bien sûr, c'est impactant en terme de performances, surtout sur des compilations de code, ou des milliers de petits fichiers sont analysés, et avec des compilateurs qui font des trucs assez intenses (genre compiler du C++ qui utilise des templates/des generics).

Si je te suis bien, je pense que ce "metaroot" correspond à ce que l'on propose aux utilisateurs des laptops avec le Docker rootless : tu es root dans les containers, mais c'est un root différent de celui du système (c'est géré par les usernamespaces).

Snap est souvent vu comme un méchant truc, mais je dois dire que sur certains aspects, ça facilite l'administration. Un truc à explorer, oui.

En effet, on utilise quelques surcouches (wrappers), pour laisser un peu de latitude à l'utilisateur sans pour autant laisser les clés sur le frigo.

Il y en a un pour apt, qui limite les opérations possibles, en particulier l'installation d'un paquet qui n'est pas dans un repo autorisé, mais qui protège aussi de l'obtention d'un shell root, par exemple quand dpkg demande quoi faire pour les fichiers de configs modifiés, ou qu'un pager complaisant à une option pour lancer une commande (par exemple less ou more et leur commande !). On encore qui bride les options du type "ne pas vérifier les signatures".

On a aussi un wrapper pour systemctl, qui permet de start/stop/restart des services, mais pas tous (par exemple on protège syslog, l'antivirus, cron et quelques autres…). Ce wrapper m'a permis d'apprendre les bases de Python¹, j'ai bien aimé :). Le plus amusant était de protéger un service en prenant en compte ses petits noms (par exemple sshd peut aussi s'appeller openssh, ssh, avec sans le .service, syslog.service a aussi des variantes, fun).

Quand on fait ce genre de développement, on doit bien faire attention, en plus de ne pas introduire de trou de sécu supplémentaires, à ne pas utiliser des options qui n'existent que sur la version courante des outils qu'on utilise, mais aussi sur les versions passées en cours d'upgrade, et dans la version future. Donc pas trop d'options toutes nouvelles et pas d'options dépréciées.

Il y a aussi un "truc" (je sais plus la terminologie), qui se charge dans le démon Docker pour vérifier que les containers sont bien lancés sans les droits root.

Enfin on s'amuse bien, et quand on trouve un trou, on le rebouche :).

Je dirais : il pourrait agir au lieu de parler, et suivre l'exemple de Microsoft, en achetant une centrale nucléaire pour alimenter ses centres de données :).

C'est vrai que c'est un facteur d'étonnement régulier. On voit quelqu'un arriver et dire "euh vous avez oublié de me donner le mot de passe root".

Et en fait, le compte root n'a pas de mot de passe, et sudo ne donne pas de shell root. Étrange :).

Pour prendre le métier de développeuse, qui demande en effet beaucoup d'outillage, parfois des besoins spécifiques, et de pouvoir installer la moitié de la terre sur son ordi pour pouvoir tester, on a plusieurs solutions.

Tout d'abord, il y a des machines virtuelles disponibles sur le réseau. Et puis, avec le CI/CD, c'est assez pratique d'externaliser sa chaîne de fabrication.

Ensuite, parce que c'est quand même pratique, et souvent plus rapide pour tester, on peut faire du dev en local. Il y a Docker installé sur les laptops, mais Docker sans droits root, en userspace. Ça permet de monter des plateformes de test avec Docker compose, par exemple. Surtout ça permet de garder le système du laptop un minimum propre. Il y a aussi possibilité de lancer des VMs (avec qemu, via Gnome Boxes ou virt-manager, toujouts sans droits root).

Enfin, si d'aventure ton laptop n'a pas un outil utilisé dans un Makefile, ton éditeur préféré ou nyancat pour rigoler, et bien il y a un accès à une version limitée de apt, qui permet d'installer ce qu'il y a dans les dépôts préconfigurés (tu ne peux pas faire apt install ./untruc.deb).

Et si vraiment, malgré tout cela, le besoin n'est pas comblé, alors une demande est faite, évaluée, validée, documentée comme exception et zou, en fonction du cas on va développer un patch dans notre système ou juste faire une install manuelle.

Un exemple précis de ça est que quelques personnes d'une équipe particulière avait besoin de pouvoir faire des captures réseau avec Wireshark. Mais Puppet gère les groupes, donc si on fait un ajout à la main, il est annulée par Puppet ensuite. Donc on intègre que "untel sur telle machine" a un groupe supplémentaire et voilà, les choses restent clean.

Pour les cas extrêmes ou vraiment trop spécifiques, on fourni des laptops avec accès admin, mais il sont alors hors réseau (ils n'ont accès qu'à Internet).

Je ne me fais pas trop d'illusions sur le fait qu'il y a un peu de shadow IT, qu'il y a des compilos installés dans les homedirs, des extensions VSCode mal fichues.

Mais si les choses sont pas trop mal fichues au départ, c'est tout à fait possible de travailler en tant que dev sans avoir accès au root sur ta machine.

Oui, je crois qu'on peut dire ça, mais pas tout à fait.

La population qui a choisi Linux est très majoritairement sur des métiers tech, comme les personnes qui s'occupent de serveurs Linux en premier lieu (que ce soit les archis de plateformes, les ingés, les SREs…), il y une partie de développeurs, aussi, et sans doute quelques autre métiers, mais plus rare.

D'ailleurs, il y a beaucoup de personnes des métiers de la tech sur Windows et Mac aussi (les 85% restants ne sont pas des équipes "non-tech", sinon bonjour le rendement ;)).

Pour résumer, je dirais que autant sur Windows et Mac, on trouve une population relativement hétérogène, on a sur Linux une sur-représentation des métiers techniques d'informatique.

Précédemment, j'ai bossé dans une entreprise (bien plus petite, 200 personnes), dans laquelle tous les ordis étaient sur Debian, sauf ceux de la compta et des graphistes (4 personnes en tout).