Quels sont les news du cloud et du DevOps en ce mois de mars 2023 ?
On va parler aujourd'hui de GitHub et de GitLab.
On va faire un petit retour sur la convention CACEDE France.
On va parler aussi de secrets exposés sur GitHub.
Et enfin, on va parler d'une petite faille de sécurité,
puisque c'est notre petite faille du jour.
Et reste bien jusqu'à la fin pour avoir nos petites sélection d'outils.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes,
abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bienvenue à toi chers compagnons, dans ce nouvel épisode d'actu DevOps,
ton émission de veille cloud DevOps mensuelle.
Ce soir pour en parler avec moi, j'ai René, bonsoir René.
Bonsoir à toutes et tous.
Et il y a aussi Nicolas, bonsoir Nicolas.
Salut à toutes.
Et bonsoir Damir.
Salutations.
Et on va pouvoir commencer justement à parler de news.
Mais avant, il y a la traditionnelle section du courrier des auditrices et auditeurs.
Et aujourd'hui, j'aimerais te lire un message que Olivier M nous a laissé
sur le forum des compagnons du DevOps.
Alors Olivier nous dit en rapport avec l'épisode sur la stack Docker en production.
Il nous dit très bon podcast, très intéressant.
Il a un peu l'eau à la bouche avec nomade qu'il ne connaissait pas, seulement de nom.
Et il pense que ça mériterait un épisode de podcast à lui tout seul pour aller plus loin.
Écoute, merci Olivier.
Comme tu l'as vu, on discute sur le forum justement pour savoir comment est-ce qu'on va faire Nicolas Damir.
Et moi, on n'a pas balancé pas le d'idées.
Mais je pense qu'on va continuer, on trouvera une solution.
Justement, vous quelle est votre avis là-dessus sur qu'est-ce qu'on devrait faire
un épisode de podcast, un meet-up sur la chaîne YouTube.
Je sais que vous avez déjà exprimé sur le forum, mais pour notre auditeur qui ne va pas sur le forum.
Moi je pense que j'étais un des premiers à m'exprimer là-dessus.
Moi je pense que ce serait plus d'adapter un meet-up pour peut-être le faire découvrir aux gens.
C'est vrai que ça nous tient intéressant.
Pour moi, il n'y a pas forcément comparables à cube, ce qui ne fait pas, ce n'est pas pour les mêmes besoins.
Mais ça reste quand même intéressant.
Je pense d'avoir un moment ou un espace, on découvre un peu cet outil sans forcément le comparer aux autres directement.
Parce que ce n'est pas le but pour moi.
L'objectif, c'est plus de découvrir et de voir de quoi il est capable.
Donc un meet-up serait le plus adapté à mon sens.
Et de mon côté, je pense que faire un podcast dessus, ça pourrait être intéressant, comme on le fait là.
Mais commencer à introduire le fait de pouvoir avoir des invités sur un thème spécifique.
Et comme ça, on pourrait débattre à 2 ou 3.
Ça pourrait être sympa.
On est à la vie sur la question.
C'est sûr que c'est super intéressant.
Après, je pense qu'avoir une espèce de petite live-démos, ça peut être cool.
Donc, est-ce que dans un podcast, ça peut s'inscrire ?
Je ne sais pas.
Je ne sais pas, mais je pense que les gens apprécieraient de voir un petit peu l'outil en action.
Je pense aussi qu'on peut faire intervenir des gens en dehors.
Par contre, ça ne nécessiterait qu'on revoit un peu l'organisation de notre podcast.
Si tu ne le sais pas, cher auditeur, nous enregistrons les deux épisodes en même temps, actuellement, radio DevOps.
Et donc, ça ne nous prend qu'une soirée par mois pour te fournir deux épisodes.
Et j'avoue que je ne sais pas encore trop comment faire.
Je pense qu'on va en discuter et qu'on trouvera une solution.
On peut même faire les deux aussi.
Oui, René, tu voulais...
Oui, en fait, je pense que le format du live, un peu comme on fait, je pense qu'il ferait très pas mal.
Ou tu aurais Nicolas, je pense, qui pourrait s'exprimer, discuter, montrer des choses.
Et éventuellement avoir après peut-être des intervenants qui viennent poser des questions.
Ou via le chat.
Je pense que c'est assez vivant.
Et en plus, je pense que ça te donne une visibilité assez grande.
J'en peux suivre si ça les intéresse.
Oui, on peut faire un format libre antenne sur Nomad, justement, en effet, avec des invités.
C'est une bonne idée, René.
Ecoute, je pense qu'on va en parler avec Nicolas et puis on va trouver une solution.
Carrément, mais on peut peut-être aussi demander aux auditeurs ce qui, eux, les intéresse.
On peut-être confinira par faire plusieurs formats.
Du coup, tu l'as compris, chère auditeur, laisse-nous un message sur Apple Podcast, Podcast Addict, ou YouTube, ou même sur le forum pour nous dire ce que tu veux.
Comme ça, on le saura, pour moi, si tu préfères un podcast, un live, autre chose.
Dis-nous tout là-dessus et inondes-nous de messages.
À chaque fois, je le demande, mais c'est parce que c'est tellement dur.
Je sais que vous êtes nombreux à nous suivre, mais vous laissez pas forcément tous des messages.
Alors, Danier, tu vas nous parler du Kubernetes Community Days France qui vient de se dérouler et où on s'est croisé rapidement.
C'est ça.
Pour une fois, je ne vous parle pas d'un incident ou d'un rex sur un sujet critique.
J'ai pris une news un peu plus légère pour changer.
Donc, effectivement, à l'heure où je vous parle, c'était semaine dernière, donc c'était le 7 mars.
Il y avait le KCD France qui s'est déroulé pour sa première édition, donc KCD pour Kubernetes et France, parce que c'était en France.
Effectivement, il n'avait jamais eu pour l'instant.
Donc, si vous avez déjà entendu ce nom, si vous vous dites quelque chose, c'est assez normal.
Les KCD, je ne vais pas dire le nom, mais les événements KCD, c'est quelque chose d'assez récurrent un peu partout sur la Terre.
Et il y en a eu dans plusieurs pays ou grandes villes qui ont été dédiés.
L'ensemble, il est un peu soutenu par la CNCF, donc la CloudNative Foundation, qui va permettre à des associations locales de faire ces événements-là.
Et les organisés eux-mêmes, la CNCF, ne l'organisent pas directement.
C'est des associations locales qui le font, mais eux vont plus s'occuper de les référencer, etc.
Et du coup, cette année, pour l'après-en-fin, on a eu une en France, et c'était plutôt cool.
En tout cas, moi, j'ai beaucoup apprécié.
Donc, c'était assez classique, donc il y avait, on va dire, trois composantes.
Globalement, les tolles, que le plus classique, qui étaient réparties dans trois salles,
on avait du coup des stands avec différentes marques et différentes sociétés.
On peut retrouver du trafic, du GitLab, du DataDog, et je ne citerai pas d'autre chose, parce que ça va faire beaucoup.
Mais en tout cas, vous pouvez les retrouver sur les différents stands, discuter un peu, échanger avec eux.
Donc, ça, c'était assez classique, mais ça marche toujours bien.
Et il y avait aussi un espace communautaire, où il y avait, du coup, plusieurs personnes qui font partie de la communauté tech francophone,
avec lesquelles on pouvait échanger, ce qui était plutôt une bonne idée.
Et du coup, tout ça, c'était au centre Pompidou, donc à Paris.
Et c'était pour moi, la première fois que je voyais une conférence en centre Pompidou,
je dois avouer que c'est, je pense, une des salles les plus agréables que j'ai eu, à un niveau conférence.
Moi, si je dois comparer avec un événement récent, qui était l'événement d'OVH,
qui était à la cité des sciences, tout comme l'événement Leac, qui est depuis quelques années à cité des sciences,
c'est beaucoup plus fermé, beaucoup plus tassé, on se sent un peu plus à l'étroit.
Là, en fait, le fait d'être dans le centre Pompidou, on se sentait vraiment plus libre,
on pouvait vraiment mieux se déplacer, on était quand même 1000 personnes, à peu près, il me semble, 1000 participants.
Donc, on pouvait un peu plus se déplacer, discuter librement sans qu'il y ait trop de bruit, etc.
Donc ça, c'était assez agréable, l'organisation était vraiment au top, malgré du coup la grève,
qui est venue un peu au dernier moment, encore, chambouler un peu ce projet qui était plutôt complexe.
Mais malgré ça, ça s'est très bien passé, il y a eu beaucoup de monde, les sessions étaient très intéressantes,
niveau conférence, je n'en ai pas vu énormément, je dois avouer que petit à petit, moi en conférence,
je vais en voir 2, 3, mais je vais plus pour discuter, parce que comme dans beaucoup de conférences,
tout sera disponible en replay, donc on pourrait les regarder tranquillement chez soi.
Et du coup, j'en ai quand même vu pas mal, j'ai pas vu de conférences non-tech,
donc ça, je trouvais ça un peu cool d'avoir des conférences orientées techniques,
et pour le coup, il y avait certaines qui n'étaient pas trop basiques,
il n'y avait pas que des conférences basiques, il y avait plutôt des conférences à chercher,
ce que j'apprécie beaucoup, parce que c'est vrai que ces derniers temps,
j'ai l'impression qu'on avait quand même un gros pourcent de talk dans beaucoup de conférences
qui étaient assez basiques, et des fois ça faisait l'intérêt de sentir des choses un peu plus avancées.
Donc là, c'était assez intéressant, et du coup, voilà, je n'ai pas spécialement d'autres choses à dire,
donc on sait qu'il va y avoir normalement, en tout cas, on parle déjà d'une deuxième édition l'année prochaine,
donc ce qui serait top, et peut-être que s'il n'y a pas grève,
ça serait vraiment d'aimal chance d'avoir une grève deux années de suite,
mais s'il n'y a pas grève, ça permettra d'autres personnes qui n'ont pas pu s'y rendre d'y aller.
En tout cas, moi je vous la conseille, je remercie d'ailleurs au passage,
si certains des organisateurs nous écoutent, je les remercie,
je les fais ici pour cette première édition qui était clairement une réussite,
et si vous vous souhaitez voir certains des replays, ils vont être mis en ligne assez prochainement,
donc je pense courant sous le moitié, si je m'y incompris,
donc vous ne vous faudra pas hésiter à aller les voir.
Et comme je vous ai fait Christophe, on s'est croisé assez rapidement,
j'étais allé pas gauche à droite notamment, et du coup, t'en as plutôt pensé quoi ?
Alors oui, moi aussi, j'ai croisé beaucoup de monde à droite à gauche,
il y a plein de personnes qui suivent la chaîne YouTube ou le podcast qui sont venus me parler,
puisque moi j'étais dans l'espace communautaire comme tu le dis.
Alors j'en ai pensé beaucoup de bien, comme tu le dis, en effet,
l'organisation était vraiment très bonne, malgré des quelques problèmes qu'ils ont eu,
je trouve qu'ils ont très très bien géré.
Mention spéciale sur la gestion de la bouffe,
parce que les précédentes conférences où je suis allé,
c'était compliqué, puisque c'est tout le temps des buffet ou autres,
et donc les gens s'agglutinent devant, et tu te retrouves à soit pas avoir à manger, soit...
Et là, en l'occurrence, tu avais trois types de repas,
végétarien, poisson ou viande, tu passais,
tu prenais ton sac et tu allais pouvoir manger n'importe où,
dans le centre, et en effet, on ne se marchait pas dessus,
et ça aussi, c'était super agréable.
Moi, j'ai des souvenirs des DevOpsRex qui se passaient au Grand Rex,
alors j'aime beaucoup le Grand Rex, je trouve que c'est un endroit merveilleux,
mais par contre, on évite à l'étroit, et là, clairement, on n'était pas à l'étroit.
Alors, par contre, je ne vous ai même pas imaginé le coup pour la conférence de louer un espace pareil,
mais vraiment, on sentait que c'était un salon pour professionnels,
et pas juste une conférence où on se croisait pour voir des talks,
et comme tu le disais, il y avait beaucoup d'exposants,
et du coup, moi, comme j'ai assisté, en fait,
moi, je vais passer pratiquement ma journée dans l'espace communautaire,
je n'ai pas d'incompréhension, j'ai assisté à aucune conférence,
sauf celui du début, parce qu'il y avait Solomon Hike sur la chaîne,
et je ne voulais pas le rater, mais sinon, j'en ai vu aucune,
et du coup, j'en ai profité pour faire des tours à droite, à gauche, sur les divers stands,
et y avait, on a dénombré plus de 40 stands,
un truc comme ça, enfin plus de 30 stands, c'est sûr,
je pense qu'on a atteint les 40 stands,
et j'ai pu discuter avec pas mal de monde.
je découverts notamment une distribution Linux, Read Only,
bref, il y a plein de trucs dont je ne sais pas si je vais parler sur la chaîne.
Et sinon, le point noir pour moi c'était l'espace communautaire,
parce que même si l'idée était vraiment bien, comme il n'avait pas vraiment été annoncé sur le programme,
il a été annoncé juste sur l'Incudine en fait,
ce qui fait qu'on s'est retrouvé, il n'y avait pas grand monde dans cet espace-là,
et il y avait les tables rondes, parce que moi j'ai été invité pour participer à une table ronde,
il y avait 4 tables rondes, et je pensais naïvement que sur ces tables rondes là,
il y aura un public et qu'on pourrait répondre aux questions du public après la table ronde,
mais en fait non, c'était juste une captation vidéo des tables rondes,
je trouvais que ça manquait d'interactivité avec les gens pour l'espace communautaire,
mais pour en avoir à discuter avec les organisateurs et organisatrices,
c'est quelque chose qui vont potentiellement améliorer pour la prochaine édition,
en tout cas pour une première, c'était vraiment super.
Nicolas, je ne sais pas si tu étais, en tout cas on ne s'est pas croisé si tu étais.
Non, j'ai à la fois un mois un peu chargé,
et à la fois, Kubernetes, c'est pas trop ma cam, vous l'avez compris, je suis plutôt Hécorp,
mais je sais que j'ai croisé un auditeur de Radio DevOps,
donc Fred, si tu m'entends, à la Picon, parce que là, c'était plutôt là où j'étais le mois précédent.
Mais c'est cool qu'il y a des confes comme ça qui viennent en France aussi,
parce que c'est ce qui fait vivre l'écosystème,
et c'est une occasion pour discuter des sujets avec nos pères,
et si j'avais une confe à Chicorpe en France, je pourrais y croiser des gens comme moi,
mais après, ça m'arrive d'aller dans des confes qui ne sont absolument pas dans mon domaine de compétences directes,
parce que c'est un bon moyen de s'ouvrir l'esprit et de rencontrer des gens.
Venez toi, je ne t'ai pas croisé, donc je pense que tu n'étais pas, sinon on se serait vu.
Non, non, je ne suis pas allé, ce n'était pas forcément évident de justifier,
ça avait l'air chouette de ce que j'ai vu à travers un petit peu les tweets qui sont passés, etc.
C'était une journée, par contre, il me semble, c'était assez court.
C'était une journée.
Il y a très peu de confes qui durent plus que d'une journée,
de manière globale, les seuls que j'ai fait, elles durent une journée.
Il y a quand même deux, trois, il y a le Fosdem qui est sur un week-end,
il y a le hack, c'est sur deux jours aussi maintenant.
Il y a plusieurs confes qui ont fait ça, notamment aussi, je pense,
pour essayer d'étaler un peu les salles, éviter de trop agglutiner les gens.
Mais c'est vrai que deux jours, c'est un peu plus compliqué pour ceux qui n'habitent pas directement sur la région.
Et là, c'est l'organisateur qui va parler.
Commencer par une seule journée, c'est quand même beaucoup plus simple,
parce qu'il y a plein de problèmes logistiques.
En général, ça se prépare une journée à l'avance.
Et donc, il faut louer un lieu pour une journée en plus.
Et je ne sais pas comment ils sont financés,
mais ça permet de réduire le risque d'avoir qu'une seule journée.
Et probablement que les prochaines éditions, ça va grandir avec quelques journées en plus.
Je pense qu'on verra que ça dépend si du lieu,
comme tu dis, ça met beaucoup de contraintes.
C'est des fois dur d'avoir un lieu cool pour deux jours.
Et des fois, je préfère une confe qui est bien organisée dans un lieu sympa,
une journée qui est allée sur deux jours, entre guillemets,
ce qui, des fois, permet pas d'avoir les bons lieux, si j'ose dire.
Mais on va voir ce que va donner, comme Christophe disait.
L'espace communautaire, c'est vrai que moi, je ne suis pas trop allé,
parce que c'était un peu isolé, il n'y avait pas grand monde.
Et c'est vrai que c'est un peu...
Moi, je me bat d'un peu en tout sens,
parce que je discute avec pas mal de personnes,
mais un peu aléatoires, si j'ose dire.
C'était pas organisé.
Mais dans l'espace communautaire,
beaucoup de gens étaient rendus en petit groupe de 1 ou 2,
donc, bah, tu n'avais pas forcément envie de les voir,
parce que tu avais peur d'éranger de moi.
Je prends l'exemple, tu vois, toi, tu es dans l'espace communautaire,
je ne suis pas venu de parler,
parce que je me dis, bah, il est déjà avec quelqu'un,
dans le doute, je ne vais pas déranger.
Mais c'est vrai que, du coup, ça, c'est un problème qui existe aussi.
Mais d'ailleurs, je passe le bonjour au gens du Meetup SRE,
qui était aussi dans l'espace communautaire,
ils sont toujours très cool.
Oui, et je voulais rajouter un truc.
Moi, typiquement, je ne suis pas sur place contrairement à Damir.
J'ai fait trois heures de train.
Mais en fait, ce que j'ai fait,
c'est que je suis venu le lundi,
et je suis reparti le vendredi,
et j'ai regroupé en fait plusieurs événements en même temps,
parce que, du coup, je faisais un déplacement professionnel.
Lundi, je suis passé à Lyon,
j'ai rencontré quelqu'un.
Mardi, je suis allé à Cassé des France.
Mercredi, jeudi, on a fait un POC Porteneur avec l'Hydra.
Et vendredi, je me suis re-arrêté à Lyon
pour parler de GitLab dans un incubateur de start-up.
Du coup, ça m'a fait une semaine de déplacement.
Je ne ferai pas ça tous les jours,
mais ça permet justement de limiter les déplacements
et d'être déjà sur place.
Et je n'ai été pas trop impacté par la grève mine de rien.
Bon, alors on va parler du sujet suivant,
et c'est moi qui m'école.
Je vais vous donner des nouvelles de GitHub et GitLab.
Alors, la première, c'est GitHub,
qui va renforcer la sécurité avec la double authentification.
Alors, depuis le 13 mars,
GitHub a déjà commencé le déploiement de la double authentification,
et il va nous forcer la main,
pour ceux qui n'auraient pas déjà activé,
car en fait, il ne peut pas se changer ça du jour au lendemain
sur les plus de 100 millions de comptes.
Donc, il le fait petit à petit jusqu'à la fin de l'année.
Il commence par les petits groupes d'utilisateurs,
et va progressivement obliger l'intégralité de ces utilisateurs
à activer cette fameuse double authentification.
Pour rappel, la double authentification,
pour ceux qui ne le savent pas,
c'est que vous utilisez un device qui n'est pas votre utilisateur mot de passe,
et vous avez un token unique qui dure pas longtemps,
ou alors vous avez une clé, etc.
Mais, mes chers amis vont pouvoir en parler justement, juste après.
Alors, donc, si tu reçois un email de GitHub,
ne t'inquiète pas, c'est normal,
il va falloir que tu l'active la double authentification.
De toute façon, c'est beaucoup mieux pour toi.
Deuxième news, le 2 mars,
GitHub a annoncé que le prix de la licence premium augmentait.
Alors, pour rappel, GitHub propose trois licences.
La frie qui est gratuite,
la premium à 19$ par utilisateur et par mois,
et la ultimètre à 99$ par utilisateur et par mois.
Donc la frie, ça correspond à GitHub, Open Source et Core.
La version premium, elle passe de 19 à 29$ par mois
par utilisateur, soit 50% d'augmentation.
Alors, GitHub justifie sa décision par plusieurs choses.
La première, c'est que depuis 2018,
ils ont ajouté plus de 400 fonctionnalités
sur l'ensemble de cycles de vie de la livraison logicielle
dans GitHub.
Bon, moi, je pense surtout que c'est une décision
pour éviter d'aggraver les pertes de la société,
parce qu'en effet, ce matin,
alors aujourd'hui, on est le 14 mars quand on enregistre le podcast,
et ce matin, on a appris que GitHub avait perdu
30% de sa capitalisation en bourse.
Et c'est principalement dû à la publication
de ses résultats financiers,
parce que malgré un chiffre d'affaires en croissance de 68%,
typiquement, j'aimerais bien faire ça, mais bref.
La société GitHub enregistre encore des pertes de 38,7 millions de dollars,
soit grosso modo, 26 centimes par action.
Ce qu'il faut savoir, c'est que l'an dernier,
il y avait une perte de plus importante de 45,8 millions de dollars,
soit 32 centimes par action.
GitHub essaye donc par là de réduire les pertes.
En plus, alors je ne l'ai pas noté dans ma news,
mais on sait qu'en plus,
GitHub a licencié comme beaucoup de boîtes de latex le mois dernier.
Alors pour rappel aussi,
GitHub propose des comptes gratuits pour les équipes de moins de 5 personnes.
C'est une décision qu'ils ont pris l'an dernier, je crois, de mémoire.
Au-delà, il faut prendre une licence premium.
Ça veut dire qu'à partir de 6 personnes,
ça coûtera 174 dollars par mois,
soit grosso modo, 2,08 dollars par an.
Donc pour les équipes de cette taille
qui n'ont pas besoin d'une licence premium,
il y a plusieurs solutions.
Soit vous allez chez GitHub,
vous savez ce que j'en pense,
soit vous hébergiez votre propre GitLab,
avec tout ce qui va avec,
soit vous allez vers une offre info gérée
ou un SaaS qui se base sur GitLab Core.
Vous avez la possibilité, soit vous passez à la caisse.
Voilà les petites news de nos chers forges logiciels.
Et du coup, je voudrais savoir ce que vous en pensez
de ces deux petites news que j'ai compilé en lune
parce que ça parlait des forges.
Alors déjà, on pourrait dire qu'il y a aussi d'autres alternatives
à GitHub et GitLab.
Pour des tout petits projets,
il y a GitI qui est très bien,
qui s'auto-hébergent assez facilement.
Et puis, pour les plus hard à core gamer,
vous pouvez installer votre Git vous-même.
Et tout gérer avec des petits scripts, etc.
Pour l'avoir fait, c'est faisable.
Après, le fait d'avoir le code dans le browser,
c'est quand même super sympa.
Et il ne faut pas oublier que GitLab,
c'est une entreprise qui développe un produit open source.
Et là, on voit bien le problème du financement de l'open source.
Et c'est toujours super délicat.
Et là, on voit aussi la problématique d'avoir une entreprise
côté en bourse où quand il y a des actions qui sont revendues,
et là, je pense que ce n'est pas forcément que dû au fait des résultats.
Je pense que comme il y a une petite récession qui se profite,
il y en a qui ont récupéré de l'argent parce qu'ils se sont dit,
on ne voit pas en gagner là.
Donc voilà.
Et c'est vraiment dommage pour eux.
Mais c'est la vie des startups, on va dire.
Mais c'est pour ça que c'est important que quand vous utilisez un produit,
si vous voulez qu'il reste, prenez des abonnements.
Moi pour Docker, j'ai pris un abonnement Docker,
même si j'en ai pas totalement l'utilité.
Au moins, ça permet de financer le Docker Hub.
Et même si j'utilise pas forcément la plateforme Docker,
au moins je suis content d'avoir le Docker Hub qui est maintenu
parce que c'est la plateforme que je préfère pour aller chercher mes images Docker.
Mais bon, est-ce que tu as quelque chose, une autre vision à porter, René ?
Non, je pense que tu as un peu tout dit.
Après, c'est vrai que les augmentations 50%,
là par exemple, ça calme un peu.
C'est un peu brutal, je pense.
Voilà, je trouve que peut-être qu'il devrait avoir un plan intermédiaire,
entre le gratuit et peut-être celui à 19.
Est-ce que je peux le rebondir juste sur ce que tu viens de dire René ?
Il faut savoir qu'avant, il y avait un plan à 4 euros par mois et par utilisateur
et que GitLab l'a supprimé parce qu'il n'était pas assez rentable.
D'accord, donc ils ont dû quand même réfléchir au truc.
Ils ont pu réfléchir au truc, je pense.
Après, il y a d'autres alternatives, il y a froguite.
Voilà, peut-être que ce sera une bonne nouvelle pour toi, Christophe.
Tu veux peut-être récupérer des utilisateurs.
Du coup, si je peux rebondir là-dessus, c'est vrai que c'est un peu dommage.
Et ce que je trouve un peu moche quand même, c'est d'avoir en même temps,
ils vont passer en RID Online et compte les projets dans lesquels il y a plus de 5 personnes en privé.
Et en même temps, ils augmentent les prix.
Je trouve que le combo, il est un peu moche quand même de faire les deux 6 rapprochés.
Moi, en tant que client, dommage qu'il y ait clients de GitLab.
Et on me dit, on va te fermer des projets, donc tu dois prendre un abonnement.
Donc, je vais prendre un abonnement, c'est quand même accepter une économie de l'accès.
Moi, je ne suis pas forcément fan dans tous les cas de l'économie d'accès.
Mais enfin, t'es une entreprise, on te dit tu vas faire, tu vas prendre un abonnement chez nous.
Et en même temps, ils me disent, là il va augmenter de 50%.
Donc, tu te dis quand même pour le futur, qu'est-ce qui me garantit qu'il va pas augmenter de 50% entre 3 à moins quand je vais tout migrer chez eux.
Donc, pour moi, ce côté-là, il n'est pas rassurant pour beaucoup d'entreprises.
Et ce que je crains qui va se passer, c'est très simple.
C'est que beaucoup d'entreprises, elles vont faire, elles ne vont pas aller chez des hébergeurs ou autres.
Elles vont faire une VM, elles vont installer GitLab au omnibus de sué, elles mettront un jour peut-être.
Elles vont faire des backups peut-être, elles vont le monitorer peut-être.
Donc, je crains vraiment que c'est ça qui va arriver.
On va avoir de plus en plus d'instances GitLab un peu dans la nature, comme ça, pop à gauche à droite qui ne seront pas maintenues.
Ça va être un risque de sécurité. Alors, je suis peut-être un peu pessimiste et un peu chiant de penser ça.
Mais je vois mal les entreprises en fait avoir toujours confiance dedans et se dire, bah ouais, je vais payer.
Bon, ce n'est pas grave, ça augmente de 50%, ça augmente peut-être dans deux mois de 50% aussi.
Ça fait quand même une somme sur tout que c'est par utilisateur, donc ça va quand même assez vite.
Je pense que beaucoup, enfin le calcul de, je prends un VPS pas cher.
Après, pour remonder un peu sur GitHub, je trouve ça plutôt cool, qui force la double authentification.
C'est vrai qu'on en parle quand même assez souvent, mais il faut quand même le rappeler, il faut toujours,
on est surtout nous qui sommes dans un tech, utiliser un gêchard de mot de passe, utiliser la double authentification.
L'aéclé code sur l'application, que ça soit free opet, je crois que c'est le nom OTP,
ou avec Google Authentificator, si vous n'êtes pas argique à Google.
Mais faites ça, si ça vous fait chier d'avoir un code, mettez-vous une UBiki ou une autre clé,
il y a plein de modèles, moi je suis UBiki parce que c'est seul avec les cas, j'ai 0 soucis et il y a une pgp-card dessus.
Mais en tout cas, utiliser ça, il n'y aura plus de problème, vous appelez juste sur le bouton de votre clé quand vous avez une authentification.
Ça se fait automatiquement, ça sécurise vos comptes, c'est pas infaillible, mais ça rajoute beaucoup de sécurité.
Et ça couplaît un mot de passe avec des mots de passe solides et surtout différents sur tous les sites.
Vous avez déjà une sécurité qui est au-delà de beaucoup de personnes.
Donc là-dessus, non c'est une très bonne chose, surtout quand je vais encore reparaître sécurité,
parce que je n'ai pas parlé d'incident de sécurité dans la première news, donc je me rattrape.
Surtout quand on voit qu'aujourd'hui, les supply chain attacks, c'est-à-dire,
les attaques qui vont faire de l'injection de code dans les dépenses et des choses comme ça sont en train d'augmenter,
et qu'aujourd'hui, le piratage d'un grande github, notamment pour un contributeur,
ce n'est pas seulement un danger pour lui, mais ça devient un danger pour toutes les sociétés qui vont utiliser des dépenses,
le cas d'il est maintenant, où il a la possibilité de faire des comites de manière plus directe.
Ça me paraît important de forcer ça, parce que c'est un axe aujourd'hui qui est trop vital pour beaucoup d'entreprises.
Du coup, je vais finir par dire ce que j'en pense.
Alors, comme tu l'as dit, je suis en raccord avec toi.
Activer la double authentification.
On n'attendait pas qu'on vous force et activez-le partout.
Moi, typiquement, je la force, parce que comme on est sur githlab, je peux forcer la double authentification dans les groupes.
Et donc tous les membres de l'IDRA, ils doivent mettre leur double authentification,
parce qu'on gère du code, et du code, c'est sensible,
surtout du code d'infrastructure.
Donc, activer la double authentification, c'est important.
Et pas que sur vos forges, activez-le partout.
Pour ce qui est de githlab, je comprends qu'il faille faire entrer des sous,
surtout que githlab, grandit, grandit, grandit, en fait, ils sont en face d'investissements massifs depuis des années,
parce que je suis allé voir leurs pertes.
Elles ne sont pas si catastrophiques que ça, parce qu'elles ont tendance à se résorber, mais elles sont là.
Et alors, par contre, le cours de bourse, il a pris une claque, parce que je crois qu'ils sont entrés en bourse à 105 dollars,
et aujourd'hui, c'est plutôt faisant l'entour de 30-35 dollars l'action.
Ça veut dire qu'ils ont eu beaucoup d'entrée d'argent, mais que les gens, ils pensent que le cours d'introduction
n'était pas trop par rapport à ce que vous, githlab, je vous laisse faire vos propres projections.
Je suis d'accord avec, je crois que c'est Damir qui a dit que l'augmentation de 50%, c'est un peu beaucoup.
Non, enfin, vous l'avez, vous avez été plusieurs à lire.
Je trouve aussi que c'est beaucoup, surtout en effet, de manière très rapprochée avec les équipes de cinq personnes.
C'est vrai que ça fait cher.
En même temps, je fais partie des gens qui pensent qu'on doit payer pour l'utilisation de ce qu'on fait,
de nos outils professionnels, et que ce n'est pas si cher que ça, surtout vu les fonctionnalités qu'a portent githlab.
Après, c'est vrai que si on n'en a pas besoin, ça se fait partie des choses, et on va ailleurs.
Comme je disais juste, le problème, ce n'est pas tant le prix, je pense.
C'est le fait que le prix augmente d'un coup, et moi, de moi, perso, je te prends un autre exemple,
car à un avoir, demain, j'ai un abonnement téléphonique qui me dit,
pour des raisons de limitation, on va limiter le forfait internet à 10 Giga.
Et on me dit, si jamais tu veux plus, et tu veux continuer de faire internet,
il faut que tu payes le forfait d'au-dessus.
Et que le forfait d'au-dessus, en même temps, il fait plus de 50%,
je ne vais plus s'hésiter que si le forfait n'est pas augmenté.
Parce que dans ma tête, je vais me dire, s'il est augmenté, il va continuer d'augmenter.
Donc moi, j'aurais moins confiance dans une dépense que je maîtrise pas mensuellement.
Je suis d'accord.
Moi, je pense qu'en fait, et on est en train de le voir avec plein de plateformes,
y compris le plateformé SVOD, etc., on est en train de sortir un petit peu de l'internet gratuit.
Je pense qu'on va aller vers une économie de l'internet,
ou en tout cas, les produits pros vont avoir tendance à avoir un prix.
Et je pense que GitHub va aussi revenir sur sa décision de offrir les...
Je ne sais pas si vous vous rappelez, mais à une époque chez GitHub,
il n'y avait pas les comptes privés gratuits.
Il fallait payer pour avoir des comptes privés.
Et je pense que GitHub va potentiellement revenir dessus.
Maintenant, GitHub a fait le move, a priori, GitHub va y aller,
puisque d'ailleurs, GitHub et Microsoft, donc ils peuvent en effet financer,
mais ils ne vont peut-être pas pouvoir financer des cent...
Enfin, pendant des lustres.
Et moi, ça me fait penser aussi que ces grosses infrastructures énormes,
ça a un certain coût et il va falloir qu'on les paye.
Je ne sais pas comment ça va se passer à l'avenir,
mais en tout cas, je pense qu'on va avoir de plus en plus d'alternatives qui vont émerger,
et qui va y en avoir pour tout le monde.
Alors, sur le côté gratuit de GitHub pour les risques privés,
je ne suis pas sûr qu'ils l'enlèvent,
parce que ça leur donne un avantage concurrentiel.
Et c'est toujours la même chose.
Plus t'attire les utilisateurs chez toi, plus ils ont envie de rester.
Surtout qu'il y a des habitudes.
C'est passer de GitHub à GitHub, c'est aussi du l'euroque l'inverse.
Donc...
Je vais un peu...
Je vais un peu juste plus loin là-dessus, et une ouverture peut-être.
Est-ce que GitHub est vraiment en compétition avec GitHub et dans la même situation?
Je ne pense pas.
GitHub, il se voit plus comme une plateforme sociale aujourd'hui,
où chaque développeur a son profil et ça doit aussi se promouvoir.
Moi, typiquement, quand on me demande mon profil, on va dire,
je ne vais pas donner mon GitHub, je donnerai mon GitHub,
parce qu'il y a plus de choses dessus, il y a plus de visibilité, etc.
Et typiquement, je pense que c'est aussi un strat de Microsoft
d'avoir une galaxie de choses.
En fait, c'est une stratégie globale.
Ce n'est pas GitHub qui doit être spécialement rendable.
C'est un ensemble de briques qui doivent être rendables.
Aujourd'hui, tu es un développeur,
tu es un jeune développeur, tu arrives globalement,
tu vas prendre du VS Code, ou tu es un DevOps, tu me l'as.
Tu as un DevOps, tu vas prendre du VS Code, tu vas prendre du GitHub,
tu vas peut-être avoir une pub, tu vas prendre de l'azur.
Au final, tu es full stack Microsoft.
Et c'est là-dessus qu'ils vont arriver à faire des bonnes intégrations
et tout, et en fait, soutenir leur offre.
Moi, je pense qu'ils voient plus les choses comme ça.
En plus, tu prends l'option CodePilot,
ou je ne sais plus comment s'appelle,
la I qui te permet de générer ton code,
qui a priori va chercher plus ou moins dans les ripos privés aussi.
Oui, alors c'est vrai que chez GitHub et chez GitHub aussi,
il y a des ventes additionnelles, notamment les minutes de CI.
Les minutes, chez GitHub, j'ai vu ça tout à l'heure,
les minutes d'utilisation de VS Code en ligne,
je ne sais pas comment les appellent,
CodeSpace, puisque tu as un certain nombre de minutes gratuites,
mais au-delà, il faut payer.
Donc, c'est à voir, je suis d'accord avec Damir,
GitHub et GitHub n'ont pas la même philosophie,
ce n'est pas le même objectif.
GitHub, c'est vraiment un réseau social pour Dev.
GitHub, pour moi, c'est vraiment un produit pour les pros,
et donc, ils ont tous les deux leur identification.
Et bien justement, comme on parle de GitHub,
ah non, avant ça, petit mémo.
Si tu aimes ce podcast et que tu veux t'assurer
qu'il continue longtemps, le meilleur moyen, c'est de nous soutenir.
Et tu peux nous soutenir en faisant plusieurs choses.
La première, c'est en partageant le podcast,
en en parlant autour de toi.
La deuxième, tu peux nous faire un don sur Libérapay,
tu trouveras le lien en description,
ou alors tu peux aller sur soutenir.com.
Et justement, on parlait de GitHub.
Nicolas, tu vas nous parler de secrets qui ont été révélés.
Oui, alors de secrets, c'est à partir du moment
où tu vas le publier sur un repo public de GitHub.
Je ne sais pas si on peut continuer à appeler ça un secret.
Mais en tout cas, c'est la société Guild Guardian,
qui a un logiciel en sas qui permet de scanner les repos
pour aller récupérer tous les secrets.
Pas dans le but de les utiliser,
mais de vous rapporter le fait que vous avez mis des secrets.
Et le principe de leur solution, c'est qu'elle va aller scanner
jusqu'à chaque comite.
Donc même si vous corrigez le secret en l'enlevant dans le comite d'après,
il va bien aller regarder tous les comites pour vérifier
s'il n'y a pas un secret qui traîne.
Et si vous êtes utilisateur du produit,
il va vous dire attention, là il y a un secret dans tel comite, etc.
Et après, on peut aller soit l'enlever,
mais de toute façon, ça ne sert à rien, il a déjà niqué.
Soit le considérer comme résolu,
parce que vous l'avez supprimé, changé, renouvelé, etc.
Ce qui est intéressant, c'est qu'ils ont révélé le fait
qu'ils avaient détecté 10 millions de nouveaux secrets.
Et c'est bien des nouveaux, c'est pas il y a 10 millions de secrets,
c'est qu'il y en a 10 millions de plus que l'année d'avant, en 2022.
Sur GitHub, donc a priori tous les ripos publics.
Donc je trouve que c'est quand même très très inquiétant.
Et ça permet de révéler deux choses, c'est que des gens font les erreurs,
c'est humain, c'est normal, mais ça veut dire que la plupart des gens
n'ont pas d'outils du type précomite pour aller regarder ces outils-là.
Je crois que René avait déjà parlé d'un de ces outils-là,
et je ne sais plus si c'était Guilgordian ou un autre.
Mais vous avez plein d'outils qui permettent de scanner vos ripos
pour voir si vous avez des secrets qui traînent.
Et je pense que c'est peut-être la bonne résolution à prendre
l'année 2023 déjà bien entamée, mais essayer de mettre ça
en production assez rapidement, militer dans vos équipes
pour mettre des choses comme ça en place.
Parce qu'un secret comme ça équilique, ça peut être une catastrophe.
Mais si c'est un secret qui permet d'envoyer un mail
sur une plateforme de test, ce n'est pas un problème.
Si c'est la MasterTee d'AWS, le gentil va vous mettre
à mineur de Bitcoin, le méchant va vous supprimer toute votre plateforme.
Voilà. Donc je pense qu'il faut bien avoir en tête ce risque-là.
Donc on a déjà protégé GitHub en mettant de la double authentification,
protégé GitHub en mettant du scan de secret.
Est-ce que tu mets ça en place toi, Damir, sur tes projets ?
Oui, en j'avais mis du pré...
C'est pas spécialement un pré-commit, c'est un outil pour rappel
qui permet de déclencher des actions avant de faire votre comit.
Et si jamais des actions invalides, c'est genre une genre de mini-sci,
si jamais ça tombe en erreur, votre comit n'est pas fait,
il va corriger, vous allez devoir corriger et là vous allez pouvoir comit.
Il y a un module qui permet de détecter certains secrets, pas tous,
ce n'est pas non plus magique.
Peut-être qu'on aura une solution, un base dia-vertueuse
qui scannera tout ce qu'on fait en comit et qui nous sauvera la vie.
J'y crois moyen, mais c'est un peu triste que ça augmente autant.
Que ça augmente avec le nombre de comit, etc.
Ça ne me paraît pas déconnant mais qu'il y a un pic aussi gros.
Ouais, c'est un peu triste entre guillemets.
Chez KWS, faisaient aussi des scans à une époque, je ne sais pas si c'est
encore le cas, mais faisaient des scans sur les ripos publics
et désactivé les clés quand on y est voyant dans les ripos publics.
Il est désactivé automatiquement parce qu'il se disait,
bah s'il a fuité, c'est pas bon.
Je pense qu'il y a aussi quelque chose qui est important à dire,
c'est aussi l'importance du coup de l'IAM pour revenir à mon...
c'est mon auralésienne je pense.
Dans les cas là, dans le sens où il faut toujours faire du last privilege,
essayer d'avoir le moins de droit possible si jamais vous avez besoin d'imaginer
d'une token pour pousser des images d'occurre, vous lui donnez juste le droit
de pousser des images d'occurre dans le repository qu'il a utilisé.
Vous n'avez pas du tout de la faute les droits de faire, je ne sais pas,
des créations utilisateurs ou des choses comme ça.
C'est chiant, c'est contraignant, vous avez posé des questions,
vous allez des fois galérer un peu dessus, mais vous allez éviter
beaucoup de problèmes en fait.
Et dernière chose, pour moi ça me conforte dans une idée,
c'est qu'il faut éviter au maximum du CD token.
Et que pour moi, des tokens, ça devrait être quelque chose qui petit à petit disparait.
Et c'est un peu une des plus grandes frustrations que j'ai aujourd'hui,
parce que là je travaille pas mal sur du cloud français depuis quelques mois,
maintenant quasiment un an, et je pense que ce qui manque le plus,
c'est cette capacité d'IAM chez AWS ou cgcp, des services accounts,
de déléguer en fait la suggestion de rotation de token, etc.
Et de ne pas pouvoir dire cette machine, je veux qu'elle ait tel droit,
j'ai pas envie de gérer les tokens, c'est une horreur.
Franchement, tous les jours, ça va rajouter une brique,
rajouter des problèmes de notre côté, et moi ça me fait chier.
C'est aussi pour ça que je trouve que des services comme AWS,
c'est ça, ça doit être beaucoup plus cher, rien que pour ça,
honnêtement je trouve la différence, elle vaut presque le coup au juste pour ça.
Et c'est assez dommage entre guillemets qu'on n'ait pas d'alternatives viable là-dessus.
C'était un peu ma digression, on va dire,
pour revenir un peu dans le sujet, toi, Roné,
t'en penses quoi du coup de ces stats ?
Je pense que vous avez quasiment tout dit,
c'est vrai que c'est dommage que ça augmente,
alors que c'est quand même des choses qui sont assez connues aujourd'hui,
et qu'il y a pas mal d'outils pour s'emprémunir.
Et voilà, je voulais juste rajouter un petit truc,
c'est que pour nettoyer les ripos, effectivement,
quand on a le lien secret dans un ripo, il suffit pas de faire un nouveau commit qui enlève le secret,
forcément il a été historisé.
Donc il y a des outils, il y en a un qui est fait par GitHub qui s'appelle BFGripoCleaner,
et voilà qui permet de faire, on va dire,
de nettoyer les secrets qui auront pu être commités par erreur de manière assez simple.
Et bien moi, il y a un truc que je ne comprends pas,
c'est pourquoi est-ce qu'on laisse des secrets sur des dépôts publics ?
C'est un truc que j'ai, ça me dépasse moi.
Autant sur les dépôts privés, je me dis, on se dit,
il est privé donc peut-être que je peux liquer un secret,
et bon, même là, c'est...
Mais là, sur les dépôts publics, je sais pas,
j'avoue, le cas d'usage, je ne le comprends pas.
C'est beaucoup des erreurs, moins de ce que j'avais vu,
j'avais regardé un peu, j'avais regardé un peu à une époque
où on avait cette problématique là dans une boîte,
et justement, j'essaye un peu de vente de mettre du prix commit partout.
Le plus gros truc qui arrive le plus souvent, c'est,
bah, t'as un dev qui teste quelque chose,
ça ne marche pas, il veut tester en local,
il va mettre des tokens du coup dans le fichier directement
parce qu'il ne sait pas forcément où il faut l'exposer, etc.
Donc dans le doute, il va le mettre dedans en se disant, je ne vais pas le commit.
Au final, c'est commit, ou sinon, ce qui arrive aussi souvent,
c'est des guitigneurs qui ne sont pas complets.
Donc du coup, ils oublient le point token,
ou le truc qui a été fait pour faire du local,
et là, du coup, c'est commit.
Mais bon, ça, c'est malheureusement un classique,
et d'ailleurs, un truc très con,
mais moi, ce que je fais pour éviter ça quand je débug en local,
c'est que moi, je n'utilise pas, sans que je sois un demote passe,
je me mets des fichiers bruts avec des exports dedans de mes tokens,
et en fait, j'ai 10 rangs qui me l'aude automatiquement
les bons tokens en fonction de mon environnement,
et c'est automatiquement mis dans les guitigneurs chez moi.
Donc du coup, je ne vais jamais commit ce fichier,
et en plus, dans tous les cas, même si je le commit,
entre guimesses, c'est dans mon gestion de mot de passe.
Mais il faut avoir le réflexe de le faire,
et ça, ce n'est pas encore le cas de beaucoup de monde malheureusement.
C'est vrai.
Et du coup, remplissez vos guitigneurs,
mettez en place des hooks de pré-commit,
soit avec pré-commit, soit avec d'autres,
et surtout, si vous liquiez vos secrets,
révoquez-les, échangez-les, et puis voilà.
Mais du coup, Danire, tu veux dire
que les développeurs ne lisent pas chaque ligne de commit ?
Ah si, si, les développeurs font toujours un quitte à tirer paix,
c'est bien connu.
Sinon plus sérieusement,
une fois que votre secret alité n'enlevé pas,
ça ne sert à rien.
Il vaut mieux bien faire le travail pour qu'il soit révoté,
et laisser-le en public, vous en foutez,
il a déjà alité.
Si une personne mal intentionnée doit le récupérer,
c'est déjà fait.
Oui, ça aussi.
Si jamais un secret a dit que ça te fait très bien le rappeler,
il est mort, ne nous jugez plus,
qu'il soit efficace, pareil pour une clé.
Vous avez une clé privée calique,
la clé est morte, vous supprimez tous les pères
de clé publique qui vont avec.
Oui, parce que ce n'est pas parce que ça a disparu de votre hippo,
que ça a totalement disparu d'internet,
parce qu'il y en a qui scannent les hippos
pour récupérer les committressants.
C'est le principe d'un secret.
Si le secret n'est pas connu que de vous,
c'est plus un secret.
Exactement.
Je vous propose qu'on passe à la suite,
et puisqu'on parle de l'IQ et autres,
c'est le bon moment pour parler de failles de sécurité,
et à Céronnet qui s'y colle cette fois.
Oui, failles de sécurité,
ce n'est pas trop ma spécialité, on va dire,
mais je pense que l'intérêt de cette faille-là,
c'est que je l'ai vécu un petit peu de l'intérieur.
Je travaille sur le projet OpenStack,
qui est un projet d'infrastructure à un service open source,
et donc développé upstream sur Internet.
Il y a eu quelqu'un qui a signalé une faille,
et la faille est assez rigolote,
c'est dans QMU Image Converteur.
Si on tweaked un petit peu l'image RAW de l'image,
alors que je ne dis pas de bêtises,
c'est l'image de type VMWare, VMDK.
Si on tweaked un petit peu cette image de départ,
on peut arriver en utilisant QMU Image Converteur,
est-ce que l'image destination,
qui est censée être la conversion de l'image du VMDK
vers une image d'un autre type,
contient des fichiers du système.
Il y a un problème du construire avec une image pas valide,
mais qui contient potentiellement des fichiers
qui ont été pris sur le système
sur lequel QMU Image Converteur a tourné.
Par ce bieland, on peut récupérer des secrets,
notamment sur OpenStack,
on peut récupérer les accès à la database,
une faille qui est quand même pas forcément hyper facile à exploiter,
mais ça peut quand même se faire.
C'est aussi un petit peu pour rebondir par rapport à ce qu'on disait,
c'est-à-dire que la gratuité des logiciels open source,
il faut voir que ce qui m'a impressionné,
je ne pense pas que tout le monde
se rend compte du travail qui a à mettre en place
pour gérer ce genre de choses.
Dans les notes de l'épisode,
j'ai partagé un petit peu le process
qui est mis en place pour gérer ce genre de cas-là,
et donc de l'arrivée du signalement de la faille
par quelqu'un qui a trouvé un comportement défaillant,
jusqu'à un certain nombre d'étapes,
de l'analyse de cette faille,
savoir si il y a des qualifications,
si elle est vraiment valide,
quel composant elle touche,
l'ouverture d'une potentielle CVE,
la création d'un fixe,
et jusqu'à l'information
de tous les downstreams,
tous les fabricants qui peuvent utiliser ce produit-là.
Et voilà, je pense que ce document,
je vais essayer d'aller un peu vite,
mais je voulais un peu le mentionner
parce que je pense que c'est une bonne source d'inspiration
pour les gens qui font de l'édition logicielle
ou même dans une société classique,
où on peut avoir par exemple des gens qui remontent des failles
pour avoir un procès et s'inspirer de ça
pour gérer ce type de cas-là.
Et voilà, pour l'avoir vécu de l'intérieur,
un petit peu, mon sentiment,
c'est que je pense que peu de gens s'en compte
du travail que ça demande,
et c'est quelque chose qui est relativement lourd.
Et pourquoi je voulais en parler,
je voulais insister un petit peu,
c'est que ça ne peut pas s'improviser,
et il faut vraiment avoir mis quelque chose en place,
une équipe dédiée pour potentiellement gérer
des gens qui ont cette fonction
de gérer ce type de problématique,
et effectivement un procès, etc., à suivre.
Voilà, donc c'était un petit peu pour parler de ça.
Et j'espère que les gens seront intéressés
et ils vont voir un petit peu ce document
pour essayer de se préparer à ce type de choses.

Qu'est-ce que ça vous inspire ?
Je trouve que c'est super bien que ça soit décrit publiquement,
parce qu'effectivement, je pense que, à la fois,
pour une personne qui rapporte un problème
et qui voit que ça n'avance pas,
il y a plein de choses qui se font en tâche de fond,
et pour avoir déjà rapporté un problème de sécurité,
c'est pas corrigé le lendemain.
C'est parce qu'il y a plein d'étapes,
dont des tests de non-régression,
et potentiellement aller regarder,
voir si ça a pas des impacts sur le reste du programme,
parce que finalement, au-delà de la régression,
il peut y avoir d'autres problèmes de sécurité connexe,
tant qu'à faire, autant tout corrigé d'un seul coup.
Juste un petit truc pour ajouter,
une des probléatiques peut-être que les gens ne voient pas aussi,
c'est que nous, par exemple,
il y a souvent plusieurs versions du produit qui tournent en parallèle,
et donc il y a toute la notion de back-port,
du fix sur l'ensemble des branches,
des différentes versions qui peuvent tourner,
et ce n'est pas forcément très bien à l'affaire.
Voilà, donc vraiment du beaucoup de boulot derrière ce genre de choses.
Moi, j'avoue que je suis admiratif,
parce que j'ai jamais eu affaire à ce genre de problèmes,
et je ne sais pas comment je verrai ça arriver,
si j'avais à gérer ça,
mais j'imagine que, en plus,
la coordination entre les multiples équipes,
ça prend pas mal de temps.
Donc je ne vais pas dire plus de choses que ça.
Demir, toi, tu as un avis ?
Non, mais c'est cool d'avoir un retour là-dessus,
c'est vrai que c'est quelque chose d'important,
et les failles entre guillemets de sécurité,
c'est quand même les choses un peu les plus difficiles à gérer,
comme tu sais, il faut back-port un peu
sur les différents environnements qu'il doit être supporté,
il faut le déployer quand même relativement rapidement,
ce n'est pas une feature qui peut attendre,
qui peut être décalée trop non plus.
Donc c'est vraiment quelque chose à part,
et qui est intéressant à gérer.
Et comme tu le dis, ça montre aussi qu'il faut soutenir
les projets open source pour ça,
pour qu'il permette de vivre et de continuer à être maintenu là aussi.
C'est une qualité de l'open source,
c'est que globalement, c'est plutôt bien suivi
les projets open source.
Donc non, ça est super intéressant.
Oui, il faut soutenir le logiciel libre et le contenu libre,
et ça me permet justement de rappeler à toi,
cher auditeur, qui nous écoute que ce podcast
est un podcast diffusé en contenu libre,
enfin en licence libre, puisqu'il est en CC.
Et ça, ça veut dire que tu peux le prendre,
prendre des bouts, le modifier, le partager.
Donc utilise-le, partage-le, modifie-le,
faisant ce que tu veux.
Il faut par contre que tu nous identifies.
Et si en plus tu peux venir nous dire un petit moment,
disons, j'ai utilisé ce bout de votre podcast,
ce sera super pour nous.
Et bien on arrive à la traditionnelle section des outils.
Et René nous a encore dégoté un petit outil.
René, je te laisse la parole.
Oui, alors en fait j'en avais dégoté deux mais j'en ai cédé un.
Oui, donc moi mon petit outil, c'est un outil qui s'appuie
sur Pyton, qui s'appuie sur Black.
Black en fait c'est un formateur pour formater le code Pyton.
Et que je vous recommande d'utiliser, alors il y en a d'autres.
Celui-là est pas mal mais il y en a potentiellement d'autres.
Et du coup ça évite un petit peu les internes discussions
de comment le code doit être formaté, etc.
Le problème de la problématique c'est que parfois
sur certains projets qui sont là depuis longtemps,
on ne peut pas appliquer Black partout,
les gens ne sont pas forcément d'accord, etc.
Et donc Black Macchiato c'est un tout petit module
qui permet d'appliquer Black que sur une portion d'un fichier,
une petite portion, donc ça se peut s'intégrer facilement
dans un éditeur, etc.
Et donc faire entre guillemets la mise en forme que d'une seule partie
et donc pas changer partout dans tout un fichier.
Et voilà, j'ai besoin de ça il n'y a pas très longtemps
et je trouve que c'est très pratique si vous avez ce type de cas
où vous ne pouvez pas faire du formatage un peu massif
pour différentes raisons.
Vous voulez réagir sur ce tout petit-là ?
Non, c'est cool parce qu'effectivement Black est utilisé au quotidien.
La première fois qu'on l'utilise,
ça fait un big bang dans le projet
parce que je ne comprends pas,
tu as modifié que deux lignes, tous les autres trucs,
c'est juste de la mise en forme.
Ah oui, oui, oui.
Donc je crois qu'on en avait déjà parlé dans un épisode
le big bang dans un projet
quand on met un outil comme un linter ou un formateur
parce que ça modifie tout.
Et non, ça a l'air cool après moi,
je dois vous avouer que depuis quelque temps
je suis en train d'aller sur la pente de go
plutôt que de piton.
Donc ça me concerne peut-être un peu moins actuellement.
Moi je reste fidèle au bâch.
Mais j'en parlerai à Arthur.
C'est pas vraiment comparable, mais...
Je vais plus en que ça à nouveau là-dessus.
C'est parce que je fais autre chose que du code dans ma vie
et malheureusement je ne peux plus apprendre
de langage de développement.
Après, c'est quand même une pratique
et justement beaucoup venu du go
avec goFMT, de mettre un formateur
un peu systématique et d'éviter les discussions.
Et ça existe aussi pour bâche et à l'HFMT
qui existe.
Moi je conseille après.
Je nette ces deux petits outils en plus,
ils apparaîtront dans les notes de l'épisode
et tu as cédé ton deuxième outil à Nicolas, je crois.
Oui, parce que pour une fois que j'en avais trouvé un,
René a été plus rapide que moi à le mettre
mais il me l'a gentiment cédé juste avant
pendant la préparation du podcast.
Et donc comme les lineteurs, c'est très important
parce qu'il faut que je vous vérifiez la cohérence
du code avant de le connerter.
Et bien le problème de ces outils là, c'est qu'en général c'est lent.
Surtout quand c'est écrit en piton.
Je ne vais pas rentrer dans le débat piton s'élant,
les autres langages sont plus rapides.
Par contre, il y a une expérimentation qui a été faite
pour la partie lint.
Donc si vous utilisez, alors c'est PyFlakes
qui vérifie que votre code piton
et respecte bien le PEP 8, etc.
et quelques autres trucs de mise en forme.
Donc Ruff a été implémenté en piton
et il est 150 fois plus rapide que Flake 8 sur Mac
et 25% plus rapide si vous avez réussi
à bidouiller Flake pour activer le multiprocessing.
Et derrière tout ça, je crois que c'est intéressant
parce que ça s'installe quand même
comme un package piton normal.
Vous faites un PIP install Ruff.
Mais il me semble que ça utilise
la nouvelle possibilité qu'on a de pouvoir mettre
du rust dans votre code piton.
Je ne sais pas, ça fait combien de temps
qu'on peut le faire déjà ce truc-là, René ?
Ça fait un petit moment.
Il y a un projet rust qui s'appelle PyO3
qui permet de faire des bindings de pitons vers rust.
Il y a un autre projet dont je ne me souviens pas tout de suite
mais que je vais retrouver
qui permet justement de faire un petit peu la plomberie
pour compiler le rust comme il faut, etc.
Et je pense que ça a quelques années
mais voilà, ça commence à arriver
à un niveau de maturité qui est plutôt pas mal.
Il fallait qu'on parle de rust dans cet épisode.
Vous êtes accorragibes tous les deux ?
C'est histoire de ne pas rester rouillé.
Christophe et en PLS, un petit tip sur le passage.
Quand vous faites un PIP install et que ça vous dit
que rust ne peut pas être compilé
ou d'autres langages au passage,
vous pouvez mettre à jour votre version de PIP
puisque on a la possibilité d'installer des trucs déjà précompilés
et du coup, c'est même encore plus rapide d'installer.
Et le petit outil qui fait...
Ça s'appelle maturine,
un petit outil qui fait entre guillemets la plomberie
pour installer le module rust.
C'est assez facile à faire.
Pour avoir un petit peu expérimenté,
c'est quelque chose qui se fait relativement facilement.
Parfait, merci René.
J'espère que tu mettrais le lien dans les notes de l'épisode
parce que je ne suis pas sûr de le trouver.
En tout cas, il est temps d'aller vers notre clôture
et moi, j'ai mon dernier petit message à donner à notre cher auditeur.
Viens discuter avec nous sur le forum des compagnons.
Viens nous dire ce que tu penses de cet épisode et des autres évidemment.
Viens surtout discuter de plein d'autres sujets
parce qu'on discute énormément.
On a déjà plus de mille.
On a dépassé les 1300 et j'espère bien qu'on va être plus de 2000 à la fin de l'année.
Je vais donc laisser la parole d'Amir pour son petit mot de la fin
qui va lui-même faire passer la parole à un de nos chers co-animateurs.
Merci du coup de nous avoir écoutés.
J'espère que ça vous a donné plein d'envie d'aller en conf
et de mettre plein de scannes partout pour vos secrets
et de faire plus attention à ça d'être plus précautionnés.
Donc merci à vous et je passe la parole du mot de la fin à Nicolas.
Merci.
La sécurité c'est important.
Acheter des Ubiqui, installer des Google Authenticator
et d'autres si vous n'aimez pas Google.
Vous en avez qui sont intégrés dans vos gestionnaires de mode pass.
Mettez bien des modes pass différents partout, etc.
Et je vais passer la parole à René.
Je vais rester très classique en vous souhaitant.
On espère que vous avez aimé cet épisode
et puis n'hésitez pas à nous faire part de vos retours
et notamment sur le forum des compagnons.
Je vous souhaite et je vous donne rendez-vous pour la prochaine fois.
Merci d'avoir écouté Radio DevOps.
N'oublie pas de noter l'épisode, plus la note sera élevée
et plus il sera mis en avant dans les applications.
Tu peux aussi le partager, ça nous aidera à le diffuser
et à rendre le mouvement plus visible.
Si tu as envie de discuter du mouvement,
alors rejoins-nous dans la communauté des compagnons du DevOps.
A bientôt.
La balade aux diffusions des compagnons du DevOps est produite par Lidra.
...