cg a écrit 2082 commentaires

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).

Alors pas à ce point quand même :).

Les installs sont automatisées à 95%, et il reste peu de manips à faire par le support¹ qui s'occupe des installations. La gestion des certificats, du chiffrement, etc… Tout cela est automatisé, mais en effet on a du développer le code pour le faire, là ou avec d'autres systèmes c'est "piles incluses".

Nous utilisons Puppet pour gérer les configurations. C'est un outil merveilleux qui propose des abstractions permettant de gagner du temps pour des trucs simples comme dire "je veux que tel paquet soit installé", par exemple, et qui permet de développer assez "bas niveau", et il y a une forge qui permet d'installer des modules tiers. Mais ce n'est pas tout à fait un MDM super intégré comme pourrait l'être InTune ou WorkspaceOne.

Le fait que Puppet soit à mi-chemin entre un langage de programmation et un MDM fait qu'on doit développer plus de code pour avoir le même process sur Ubuntu que sur Windows ou MacOS. Par exemple, stocker les mots de passe de récup BitLocker, ça se fait tout seul avec WorkspaceOne sur Windows. Pour Ubuntu, on a du tout coder nous-même (gestion des expirations, envoi dans un stockage sécurisé).

L'autre truc, c'est que des outils commme Puppet, Ansible, Chef, Salt, sont inter-distribs. Et donc parfois ça ratisse plus large sur les cas communs entre les distribs, mais moins précis.

J'imagine que nous sommes face au paradoxe d'avoir un système ouvert : il y a mille et une façons de faire, et dans notre cas, on le "paye" pas plus de travail (qui reste agréable, je ne m'en plains pas :)).

Les PCs sous Windows utilisent un PIN et/ou Windows Hello (empreinte digitale, reconnaissance faciale ?) pour BitLocker, je crois. La grosse différence est qu'on a choisi de ne pas utiliser la puce TPM pour les ordis Linux, mais ça pourrait changer, en complément de la Yubikey (ces jetons servent à d'autres choses dans le SI, donc de toutes façons on en a besoin).

Pour LinkedIn, c'est sans doute fait aussi, mais je n'y suis pas inscrit :p.

C'est vrai, encore faut-il savoir quoi mettre dans sa recette au tofu, car seul, le tofu, ce n'est pas très savoureux.

Et donc explorer et s’entraîner à faire des recettes, c'est bien :).

Là ou je travaille, on propose aux employé·es des Macs, des PCs Windows et des PCs Linux (sur Ubuntu). L'entreprise a une pile de certifications (ISO27K1, SOC2, SOC3, PCI-DSS, SecNumCloud, HDS, et j'en passe…).

Les configs Ubuntu subissent - et passent - ces certifications. Toutefois, pour arriver à un résultat satisfaisant pour ces certifs, il faut faire beaucoup de durcissement de configs. On trouve pas mal de méthodes pour appliquer plein de réglages de sécurité, notamment le CIS Benchmark, avec Ansible, Puppet/Openvox, du pur shell, OpenSCAP…

Ce qui est certain, c'est qu'il faut faire le travail trois fois (doc, développement des confs, temps d'audit…), une fois par OS. Ce supplément de travail n'est pas forcément à la portée de toutes les entreprises, c'est un peu un luxe qu'il faut apprécier à sa juste valeur (et que j'apprécie au quotidien, même si perso j'aurais tendance à ne pas proposer de Macs car on ne peut pas interchanger entre Windows et Linux).

Merci, je ne connaissais pas l'existence des microVMs, je vais regarder ce truc, ça a l'air très chouette.

Oui, et la licence de maintenance de Windows 10 est payante aussi. Ce que je veux dire, c'est que le coût est surtout sur le matériel (les 15 millions cités), et dessus, MS ne gagne pas grand chose : le coût de maintenance de W10 est remplacé par la licence W11. L'alternative aurait été de passer sur un autre OS. Si tu veux du support, tu prendre par exemple RHEL ou Ubuntu Pro… Payants tous deux aussi. Mais surtout, un tel changement de planifie plusieurs années en avance, et là-dessus, l'État s'est bien planté.

Ce qui me gêne c'est que l'article laisse entendre que le changement d'ordi est une manne pour Microsoft - après, je n'ai pas accès à l'article complet, c'est peut-être développé plus loin.

Certes, il y a le coût des licences Windows, mais les ordis qui seront rachetés ne seront probablement pas de marque Microsoft. Ça va profiter à Lenovo, Terra ou que sais-je, pas tellement à Microsoft, non ?

En effet, il y a plusieurs hypothèses (suicide, accident, meurtre), et l'argumentaire de Jack Copeland se tient plutôt bien. Mais cela reste de la spéculation de sa part, la version officielle restant le suicide.

La dépression latente d'une personne, effet à long terme d'un procès et d'un traitement chimique dégradant, n'est pas à exclure non plus.

Mais peut-être que quand on consacre une partie de sa vie à un héros, on développe un biais, et qu'une faiblesse dans le mental de Turing ne s'intègre pas bien dans la vision qu'on s'en fait. Ceci est une pure spéculation trollesque de ma part d'ailleurs, on ne saura sans doute jamais :).

Je le fais remarquer, mais je ne te le fais par remarquer, rien de perso :).

Oui tristement un Tech bro, mais j'ai l'impression qu'il a vrillé quand il a du retourner au Danemark. Bref, peu importe.

On marque traditionnellement la fin de la Préhistoire par l’apparition de l'écriture.

Toutefois, le mécanisme de passer de la mémoire vive volatile à la mémoire externe pérenne existe bien avant l'écriture, les gribouillis sur les murs à la Préhistoire en témoignent.

Je pense que c'est Papersway, qui est mentionné un peu plus haut. D'après la description, ça fonctionne pour sway et i3.