votre avatar Abonné

jotak

est avec nous depuis le 31 janvier 2008 ❤️

Bio

Développeur chez Red Hat (OpenShift...)

Masto: @[email protected]

322 commentaires

Le 04/12/2023 à 23h 05

J'avoue que ... On voudrait faire un écran de fumée qu'on ne s'y prendrait pas autrement. Mais bon, ça arrive "très très concrètement", donc tout va bien.

Le 03/12/2023 à 19h 54

Je suppose qu'effectivement, comme dans tout comité de standardisation , on se retrouve à devoir garder des archaïsmes et des fausses bonnes idées parceque certains y sont maladivement attachés.

Le CVSS est un format qui clairement est un peu parti dans tous les sens: on est passé d'un outil tentant de mesurer la gravité d'une vulnérabilité à un outil tentant de faire de la contextualisation et à servir de moyen pour faire de l'analyse de risque chez le client.

A cette dernière fin, on a ajouté et maintenu certains paramètres qui n'ont rien à voir ou ne devraient n'avoir rien à voir avec le score final d'une vulnérabilité, ce sont les valeurs "pense-bête" qu'on retrouve dans les valeurs supplémentaires.

Pour en revenir à l' "exploit maturity", il s'agit d'une métrique difficile à évaluer, et dont l'impact serait de minimiser le CVSS sur base d'informations non-fiables et pouvant varier rapidement. Dans la mesure où les fournisseurs ne veulent pas se risquer à évaluer cette métrique et préfèrent travailler sur base du scénario le plus pessimiste, on peut se demande pourquoi un tel champ existe, il aurait dû être éliminé comme les autres attributs temporels.

Dans le standard cvss, on a les valeurs de type "supplemental", qui n'impactent pas le score mais peuvent être utilisées par les utilisateurs pour stocker des informations complémentaires, cet endroit puisqu'il existe, serait la bonne place pour une notion comme la maturité de l'exploit.

Reste que l'ensemble des valeurs "supplemental" peuvent ressembler à une tentative de faire de la gestion de risque pour l'utilisateur, mais pour moi ça reste beaucoup trop insuffisant pour un contexte de grande entreprise est cela tente de mettre à plat un modèle qui devrait être plus adapté (dans une modèle relationnel, ces éléments seraient des attributs sur le lien entre une vulnérabilité et les contextes multiples où elle s'applique, tout comme les scores environnementaux)

Si je suis ce que tu dis, tu devrais voir d'un bon œil les distinctions entre les notes B/BT/BE/BTE, qui répond précisément à cette problématique de vouloir tout/trop intégrer. Les entreprises ayant une gestion du risque suffisamment élaborée peuvent se focaliser sur le score B en l'intégrant à leur propres analyses. Ça n'en rend pas moins les autres scores utiles à d'autres personnes dans d'autres situations ? Il me semble justement que l'approche modulaire/multiscore proposée permet d'adresser des use cases différents de façon assez transparente.

Le 03/12/2023 à 09h 14

J'ai pas lu tous les détails sur le site de FIRST, mais c'est tout de même une spec conçue avec pas mal d'acteurs du milieu (cf https://www.first.org/cvss/v4.0/specification-document#Appendix-A---Acknowledgments) donc j'imagine que les points soulevés ont été abondamment discutés. Il y a forcément des imperfections mais vu de l'extérieur, on ne mesure pas toujours l'ensemble des cas de figure, et pour les concepteurs il s'agit bien souvent de faire le moins mauvais choix.

Il y a aussi une FAQ sur le site, qui répond peut-être à certains points soulevés, ex. sur le "pourquoi c'est au consumer de remplir telle métrique" https://www.first.org/cvss/v4.0/faq#Why-is-this-the-responsibility-of-the-consumer-and-not-the-provider-vendor

(ah, les liens ne sont pas cliquables?)

Le 03/12/2023 à 09h 11

C'est vrai que l'article dénote une forme de point de vue, mais c'est normal puisqu'il s'agit d'une analyse et non d'une page de manuel. Je ne suis pas d'accord sur tout mais le mérite du texte est indéniable.

Personnellement, j'ai tendance à voir le CVSS 4.0 comme une amélioration même si je trouve, par exemple, que le Remediation Level aurait toute sa place dans 'base' et 'environnemental' et qu'"exploit maturity" aurait du disparaître car c'est une métrique dont l'évaluation est objectivement difficile et qui peut mener à des sous-évaluations de la menace.

J'ai pas lu tous les détails sur le site de FIRST, mais c'est tout de même une spec conçue avec pas mal d'acteurs du milieu (cf https://www.first.org/cvss/v4.0/specification-document#Appendix-A---Acknowledgments) donc j'imagine que les points soulevés ont été abondamment discutés. Il y a forcément des imperfections mais vu de l'extérieur, on ne mesure pas toujours l'ensemble des cas de figure, et pour les concepteurs il s'agit bien souvent de faire le moins mauvais choix.

Il y a aussi une FAQ sur le site, qui répond peut-être à certains points soulevés, ex. sur le "pourquoi c'est au consumer de remplir telle métrique" https://www.first.org/cvss/v4.0/faq#Why-is-this-the-responsibility-of-the-consumer-and-not-the-provider-vendor

Le 02/12/2023 à 07h 34

C'est intéressant d'avoir ce point de vue, et en même temps, c'est pas un peu gonflé d'accuser NVD de re-scoring lorsque délibérément on choisit de ne pas utiliser le framework qui normalise les scores?
D'autre part ça me paraît aussi plus sain que la note fournie par les mainteneurs puisse être challengée, et pas nécessairement reprise aveuglément

Le 11/11/2023 à 21h 03

“Flock en stock” 👌
Très bonne chose ces dessins/montages, pour renforcer l’identité du site

Le 07/11/2023 à 08h 10

1000 bravos pour la transparence et le côté participatif, c’est trop rare aujourd’hui de voir ça

Le 21/10/2023 à 20h 56


Pensez-vous que nous devrions limiter ou arrêter certaines thématiques ?
YOLO



Devrions-nous au contraire renforcer certaines thématiques ou en lancer de nouvelles ?
YOLO



Nos articles sont-ils souvent trop longs ?
YOLO



Faut-il rouvrir la salle B4 ?
Hein?




Autrement dit: faîtes vous plaisir, moi ça me va. Je préfère des articles écrits par passion / d’après vos centres d’intérêts, que sur commande en suivant juste le sens du vent.
Bon évidemment, faut de l’argent qui rentre, donc des lecteurs. Mais YOLO.

Le 16/10/2023 à 11h 46

Suite au prochain épisode dans 5 à 10 ans

Le 02/10/2023 à 16h 52

Les ingénieurs de google qui publient les CVE devraient peut-être discuter avec les ingénieurs de google qui publient des white-papers sur les transparence en sécurité ? Genre comme ici: https://www.securityweek.com/google-proposes-more-transparent-vulnerability-management-practices/

Le 26/09/2023 à 05h 45

Je suis pas très bon en message d’au-revoir, alors juste : merci pour tout!! 😘

Le 18/09/2023 à 22h 04

La légalité pose question :





À moins qu’ils fassent machine arrière, on peut parier qu’il y aura des procès et enquêtes

Le 18/09/2023 à 20h 33

Unity réfléchirait désormais à capper leur ponction selon les revenus générés par les développeurs : arstechnica.com Ars Technica



Ça se rapprocherait finalement du modèle de l’unreal engine, en un peu plus usine à gaz tout de même.

Le 13/09/2023 à 17h 57

J’allais le dire :-)
Visiblement la sécurité y est prise à la légère



https://fosstodon.org/@north/111057335768073441

Le 30/08/2023 à 17h 19

Ce que je note aussi c’est qu’il a fallu plus d’un an à la cnil pour réagir, alors que la violation de ses propres principes est ici plus que manifeste

Le 24/08/2023 à 17h 50

C’est du code de test, donc pas du code mort (?)

Le 24/08/2023 à 16h 31

Oui, mais c’est quoi l’intérêt de les mettre sur un GitHub public ?

Je saisis peut-être pas bien la question : pour du code open-source sur github, le repo va contenir les tests unitaires (ou autres), et doit pouvoir fonctionner en autonomie.
Pour répondre à @SebGF: si comme tu proposes les tests dépendent d’un gestionnaire de secrets ça complexifie la mise en place de l’environnement (y compris sur chaque machine de dev qui voudrait lancer localement les tests) et je ne suis pas sûr de voir le bénéfice au final



Précision : je ne parle pas d’un environnement de test persistant, mais bien d’un environnement qu’on setup et shutdown à la volée pour le test

Le 24/08/2023 à 14h 19

Il peut y avoir plein de raisons… Par exemple, pour tester une communication en mtls, il va falloir fournir des fakes certifs/clés

Le 23/08/2023 à 23h 26

J’ai des secrets (fake) dans mes tests unitaires, est-ce que je fais partie de ces “1 développeur sur 10” mauvais élève selon eux?

Le 21/07/2023 à 15h 08


manhack a dit:


“Zero Trust” parce que Gigamon n’aurait pas accès à ce qui serait déchiffré, contrairement aux utilisateurs de sa ou ses solutions ?…


Même si c’est le cas ça implique de faire confiance en leur solution : d’une part qu’elle soit bien intentionnée, et d’autre part qu’elle n’ait aucune faille :-) En déchiffrant SSL autrement que pour le destinataire légitime, on augmente la surface d’attaque et on introduit un tiers supposément de confiance.




Sinon, je note qu’à défaut de mettre en avant ses solutions de SSL Decryption (bonne pioche, merci !), la VO de leur CP ne met pas WhatsApp en avant, mais titre sur le fait que “Nearly One Third of Security Breaches are Going Undetected by IT and Security Professionals” & relève que “70 percent lack visibility into encrypted data, a number that rises to 79 percent in Germany”…


Non pas que ça m’étonne (c’est du marketting malheureusement classique), mais employer le terme “lack of visibility” quand la question posée était “quelle est votre visibilité sur les données chiffrées”, ce n’est pas du tout neutre: bien sûr qu’on n’a pas de visibilité sur les données chiffrées … mais en même temps, est-ce que ce n’est pas un peu le but??

Le 21/07/2023 à 06h 25

D’ailleurs je trouve ça assez gonflé de parler de zero-trust en faisant de l’observabilité basée sur du déchiffrement SSL. C’est à peu près le contraire du zero-trust. (Trust nobody.. except me)

Le 21/07/2023 à 05h 34


« Il en va de même pour le trafic chiffré ; il est possible que les organisations négligent de reconnaître le danger majeur que ces données peuvent représenter, malgré les études qui ont montré que 93% des logiciels malveillants se cachent derrière un chiffrement. »


Quand j’ai lu ça je me suis dis non, ils vont quand même pas recommander d’éviter TLS?



En fait non, c’est pour vendre leur solution qui “déchiffre ssl”




With its Active Visibility, Gigamon could decrypt SSL traffic (https://en.m.wikipedia.org/wiki/Gigamon)


J’imagine que s’ils tapent si fort sur WhatsApp & co, c’est que ces protocoles échappent à leur surveillance

Le 20/07/2023 à 20h 55

Ravi de voir cette mouture tant attendue
Un truc qui me manque dans thunderbird jusque là, c’est la possibilité de synchroniser mes configs sur plusieurs installations, comme firefox sync. Par exemple, pour les filtres de messages, c’est relou de devoir propager ça manuellement entre mon laptop boulot et mon fixe, par exemple. J’avais entendu qu’ils bossaient là dessus pour supernova, est-ce que c’est dedans, du coup?

Le 19/07/2023 à 20h 25

Il faudrait décerner une médaille à la frange crypto-libertarienne pour l’ensemble de son œuvre, championne pour faire parler d’elle et attirer des capitaux en brassant du vent.



Puis on mettrait une éolienne derrière chaque libertarien, pour qu’ils servent quand même à quelque chose.

Le 19/07/2023 à 20h 13


(reply:2143546:Stéphane Bortzmeyer)


Web4? :non: Tu as un train de retard, l’avenir est dans le web5 https://coinacademy.fr/actu/crypto-jack-dorsey-projet-web5/

Le 17/07/2023 à 05h 38

Suite de l’histoire : Alma linux annonce se lancer et faire une “vraie” distro rhel-compatible basée sur centos stream, et plus un simple clone : https://almalinux.org/blog/future-of-almalinux/

Le 13/07/2023 à 06h 28


ragoutoutou a dit:


Pas tout à fait exact : en aval de centos streams, le code est restabilisé recontrôlé et potentiellement enrichi avec des backports spécifiques et des patches dédiés (pour des questions de stabilité ou de sécurité)… par exemple suite à un problème observé chez un client …


Mais si: bien sûr que RHEL est stabilisée, mais les patchs apportés pendant cette stabilisation sont versés sur l’upstream. C’est ce qui est expliqué dans le post que j’avais cité plus haut, et également dans le blog de redhat:




“When we develop fixes for issues in RHEL, we don’t just apply them to RHEL - they are applied upstream first, to projects like Fedora, CentOS Stream or the kernel project itself, and we then backport them.”


Ce côté “stable” de RHEL comparé à Streams ne provient que d’une chose: du cycle de release. Pas du code.




ragoutoutou a dit:


Une preuve simple à comprendre: comment Centos streams peut-il être l’upstream de RHEL quand, par exemple, Centos Streams 8 se retrouve EOL en mai 2024 alors que RHEL 8 aura encore des mises à jour jusqu’en 2029 …



En mai 2027, Il en sera de même pour RHEL 9.x qui continuera en phase de support 2 tandis que Centos Streams 9 s’arrêtera net.


Alors, je n’ai pas trouvé écrit noir sur blanc ce qui se passera en 2024 ou 2027, mais je ne vois pas en quoi ça changerait, et il ne faut pas confondre code source et releases. Le EOL de Streams signifie qu’il n’y aura plus de builds et de release. Mais la base de code étant la source de RHEL, elle va continuer à vivre, et pourra donc aussi être utilisée par les rebuilds - je ne vois pas pourquoi redhat changerait le process de build de RHEL à cause du EOL de Streams. Si c’était le cas en effet ce serait négatif pour l’open-source et le modèle poussé par redhat, mais je ne vois pas d’indice disant que ça fonctionnerait autrement après l’EOL de Streams.





Bref, il y a encore beaucoup de confusion .. ce qui n’est pas étonnant vu les erreurs qu’on peut lire partout. Cet article de nextinpact aussi en comporte quelques unes - j’en ai signalées hier mais pour l’instant je ne vois aucune modif de l’article. Ce que je relève:




“Les sources de CentOS Stream plus difficiles d’accès”


C’est faux: ce sont les sources du “vieux” centos (qui étaient jusque là maintenues pour les rebuilds) qui sont concernées.




“en verrouillant un peu plus CentOS Stream”


C’est faux: on confond ici CentOS Stream et RHEL. CentOS Stream n’est pas verrouillé. La polémique porte sur RHEL.




“Plus précisément, il faut cette licence pour accéder à tout ce qui est reversé par Red Hat dans le code de CentOS Stream, y compris les mises à jour de sécurité”


C’est encore faux: la licence permet d’accéder aux SRPMs de RHEL. Les sources “upstream”, qui sont celles de CentOS Stream, restent 100% accessibles. Et ce sont essentiellement les mêmes, y compris pour les mises à jour de sécurité, ou dans le cas spécifique d’un embargo, à la fin de la période d’embargo.



Il faut bien comprendre que la différence entre CentOS Stream et RHEL ne vient pas des sources (à part des éléments cosmétiques), mais bien du cycle de release et du support.

Le 12/07/2023 à 20h 32

Sur le plan purement juridique, je rejoins en fait le commentaire #20 sur le fait que le GPL est un peu trop fantasmée.



Sur le plan purement personnel, je considère que Red Hat fait une erreur. Surtout au niveau communication en considérant les rebuilds comme du pillage sans valeur ajoutée. Ce qui en soit est mensonger, insultant, et opposé au principe même du logiciel libre. Quand j’ai lu ce post de blog chez Red Hat, je me suis demandé s’ils ne découvraient ce qu’est le logiciel libre.



Et ça c’est une grosse erreur de mon point de vue car ça braque aussi les clients. Comme je disais dans mon précédent message, je connais des gros comptes qui ne veulent pas RHEL car ils ne veulent pas payer de license. Quand CentOS 8 a été flinguée et transformée en CentOS Stream, l’étude d’un remplaçant a été faite. Et la confiance en Red Hat était déjà très fragilisée. Cette confiance est encore plus fragilisée aujourd’hui et toute la famille Red Hat est désormais, sauf exception, absente des catalogues IT dans les secteurs où je preste.



Tu me diras que ça ne changera pas grand chose vu qu’ils se limitaient au strict nécessaire pour le besoin de RHEL. Ben y’a des décisions considérant ne plus vouloir utiliser leurs produits et ça devient désormais une clause bloquante pour un choix de solution si l’éditeur dit ne supporter que RHEL. A la suite de l’arrêt de CentOS, on a passé du temps à tester et qualifier les rebuilds pour s’assurer que le standard OS soit poursuivi avec tout le socle technique de la DSI. Ces travaux sont de nouveau à refaire.



Ce qui amène à un autre résultat : la stratégie de plusieurs DSI où je travaille est de s’orienter en priorité sur du Cloud-native application, donc du PaaS, et garder la VM pour du legacy. Ce changement imposé par Red Hat n’a fait qu’accélérer la volonté d’arrêter de faire de la VM pour ne plus avoir à maintenir un socle OS. Et le socle OS, bah maintenant c’est Ubuntu uniquement.



Et ça je trouve que c’est dommage car malgré quelques pieds dans le tapis dans son histoire, Red Hat a toujours eu de ma fenêtre une réputation positive. Depuis peu, c’est l’inverse que je constate et elle est rangée dans la même catégorie que Oracle ou IBM. Des entreprises avec qui on ne veut généralement pas travailler.

Je suis d’accord sur l’erreur de com et la mauvaise appréciation de la valeur des rebuilds. C’est certainement impossible de déterminer quelle est cette valeur pour redhat: est-ce que ça détourne de RHEL ou au contraire amène vers RHEL - et dans quelles proportions? Va savoir… J’ai vu passer des argumentaires sur reddit où la valeur était mesurée en fonction du nombre de contributions sur l’upstream (code, doc, …), et de ce point de vue elle était quasi nulle. Évidemment ce n’est qu’une partie de l’équation, sûrement négligeable même, comparé au fait d’habituer les utilisateurs à l’écosystème redhat. Donc on ne peut pas dire qu’il n’y a pas de valeur dans les rebuilds du point de vue de redhat, et à ce titre je n’ai pas bcp aimé non plus cette com. Qu’il y ait de la frustration de la part de certains de voir leur travail repris / réétiqueté pour peut-être en plus perdre des parts de marché, ça peut se comprendre occasionnellement (c’est humain), mais c’est le jeu de l’open-source et redhat n’est pas un nouveau venu dans ce domaine, c’est juste un sentiment qu’on doit savoir réprimer en tant que contributeur.



Maintenant, comme je disais, les rebuilds ne sont pas morts pour autant et sont encouragés à utiliser les “vraies” sources, celles de centos stream. RHEL est buildé via ces sources, donc n’importe quel linux peut faire de même, à partir des mêmes commits. D’ailleurs je serais curieux de savoir si c’est ce que Suse compte faire, ce serait une bonne nouvelle.



Pour l’autre point que tu soulèves, la stabilité : je connais mieux la théorie que la pratique, mais l’idée à la base de Stream est justement d’améliorer la stabilité et limiter les mauvaises surprises, notamment lors des upgrades : plutôt que de faire un saut dans l’inconnu à chaque major/minor, on est capable de tester via Stream plus ou moins en permanence et donc mieux anticiper les problèmes et remonter du feedback plus vite. J’imagine pour ça de déployer du rhel ou rocky/alma en prod, et stream sur certains environnements de test. Après, je fais ni de la prod ni du linux, j’ai sûrement une vue incomplète des choses…

Le 12/07/2023 à 17h 00

Sachant que la GPL 2.0 ne spécifie rien qu’autre que “machine readable source code (…) on a medium customarily used for software interchange”.



Même si Red Hat a un passif de mesures borderline avec la GPL, ça sert à rien de pinailler sur des détails comme celui-ci.

Oui si on s’en tient strictement au respect de la GPL, mais ce qui me chagrine c’est le ressentiment qu’on voit ici, alors qu’en définitive je trouve que c’est un mauvais procès qui est fait dans la mesure où les sources utilisées pour builder RHEL restent bel et bien 100% open.



Je pense surtout qu’il y a eu des maladresses de com dans la façon de considérer les rebuilds (et je vais glisser un petit disclaimer ici: je bosse pour redhat (pas dans cette branche, pas dans les linux - et je ne sais rien de plus là dessus que ce que je lis dans la presse) mais je reste très attaché aux questions sur l’open-source - et d’autant plus regardant sur les changements de politiques de la boite).
Quand on s’en tient à regarder les process de build, honnêtement, cette décision a du sens: on supprime un repo qui n’avait a priori plus d’utilité pour redhat, et qui était juste gracieusement maintenu pour les rebuilds. La question d’un point de vue entreprise était bel est bien de savoir si ces rebuilds aident ou desservent redhat. J’imagine, pas simple à répondre. Évidemment d’un point de vue communauté, la question ne se pose pas dans ces termes, et la fermeture des repos apparaît forcément défavorable. Sauf que: redhat veut pousser la communauté vers centos stream. Non pas que les utilisateurs, mais les rebuilds également: ça signifie que les rebuilders doivent (selon redhat) prendre stream comme source, et avec un peu de chance, du fait d’en être plus proche, y contribuer. Je ne sais pas si ça en prendra le chemin …. pas sûr vu les déclarations des uns et des autres. Mais toujours est-il que ces questions sont finalement assez loin des procès en “closed-source” faits à redhat.

Le 12/07/2023 à 16h 10

Quoi, tu vas me dire qu’ils ont mis fin à cette tradition?
https://www.computerworld.com/article/2748700/red-hat-defends-kernel-code-obfuscation.html

C’est assez drôle, de sortir un article datant de 2011 dans lequel il est reproché à redhat de fournir les sources dans un gros tarball plutôt que dans git … alors que c’est précisément le contraire aujourd’hui (et ce qu’on lui reproche, il faut croire qu’on aime reprocher tout et son contraire) : maintenant avec centos stream toutes les sources sont dispo en mode “upstream first”, bien au propre dans git, avec l’historique qui va bien.

Le 12/07/2023 à 14h 22

Centos Stream <> RedHat enterprise linux … c’est proche mais ce n’est pas pareil. Rien que le noyau tel que fourni dans RHEL incorpore déjà un nombre élevé de patches non-documentés par rapport à Centos Stream, redhat ayant décidé de rendre ses mises à jour les moins lisibles possibles pour ses concurrents (et accessoirement ses utilisateurs)

Tu as des sources de ce que tu avances?
Le workflow pour patcher RHEL, c’est de patcher centos stream et attendre que ça “redescende” vers RHEL. À ma connaissance, les seules exceptions sont les CVE sous embargo (où, pour des raisons de sécurité, les patchs sont faits en secret donc pas sur un repo public - il sont reversé sur le public dès que l’embargo prend fin) - et des éléments cosmétiques genre logo de redhat etc.

Le 12/07/2023 à 12h 39

Voilà un post qui résume beaucoup mieux les changements fait par redhat, que toutes les interprétations qu’on a pu lire ici et là: https://lists.fedoraproject.org/archives/list/[email protected]/message/XM6BNUHKI3EKTDEXAAVE3JBPCG3BPUJC/



tl;dr: ce que ça change vraiment pour les rebuilders? c’est qu’ils vont devoir rebuild from source (ou trouver des alternatives) plutôt que simplement récupérer les SRPM jusque-là gentiment fournis par les ingénieurs redhat uniquement pour eux. Est-ce que les sources restent librement accessibles? Oui: c’est centos stream, qui reste 100% libre. C’est là: https://gitlab.com/redhat/centos-stream

Le 04/07/2023 à 17h 48

Les SPF & co ne devraient pas poser de problème tant qu’on contrôle les deux côtés? Pour le moment j’ai pas activé ça, mais si je le fais je peux whitelister mon domaine émetteur, si je ne dis pas de bêtises

Le 04/07/2023 à 16h 50

Je profite de cet article pour faire un petit retour d’expérience : j’avais 2 domaines chez gandi, chacun avec des mails. La future facture gandi s’avérant salée je décide de passer 1 de mes domaines chez infomaniak, et pour mes mails restant chez gandi je vais les remplacer par des mails sur mon domaine infomaniak et une redirection côté gandi. Voilà la théorie :-)



Le transfert vers infomaniak s’est bien passé, y compris pour les adresses mail transférées.
Maintenant, là où ça coince : la redirection vers des adresses mail de mon domaine chez infomaniak ne fonctionnent pas (l’idée c’est une redirection de “[email protected]” vers “[email protected]”). Les mails envoyé à cette adresse renvoient un “Undelivered Mail Returned to Sender” avec du “unknown user” dedans … Et pourtant j’ai vérifié d’envoyer un mail directement à mon adresse infomaniak => ça marche; ou encore de faire une autre redirection vers une adresse complètement différent => ça marche aussi … un peu comme si côté gandi, au niveau de la redirection, ça continuait de chercher le recipient en local et pas en externe, sans avoir réalisé que le domaine avait bougé.



Bref, tout ça pour dire, je contacte le support des deux côtés:




  • Côté Gandi, réponse relativement rapide, je reçois des infos intéressantes, mais malheureusement après deux échanges on se défausse en disant “allez voir avec infomaniak” (ce qui pour l’instant me laisse perplexe, j’ai le sentiment que le problème est côté gandi)

  • Côté Infomaniak j’attends encore une réponse, après ~48h



Je considère que la qualité du support reste primordiale et peut complètement justifier un prix plus élevé, le plus gros souci avec les dernières annonces chez gandi c’est surtout la tarification des mails … faire une redirection me semblerait être un bon compromis si on ne veut pas lâcher totalement gandi, encore faut-il qu’elles fonctionnent …

Le 26/06/2023 à 21h 04

J’avais pas tilté de suite que les 4,79€ par mois étaient PAR ADRESSE MAIL … lol ils espèrent franchement garder du monde?
Alala
Présentement en train de tester infomaniak … pas l’intention de payer 350€/an pour mes 6 pauvres adresses :-)

Le 21/04/2023 à 08h 15

Sans critiquer l’initiative (bien au contraire), mais quand on lit ça :




Ce n’est qu’en incorporant des pratiques de sécurité dès la conception que nous mettrons fin au cercle vicieux de création et d’application de correctifs


… avouez qu’il y a de quoi rire. C’est quand même extrêmement naïf, même les applis “secure by design” ne sont pas exemptes de failles, espérer que les clients/utilisateurs n’aient plus à se soucier de patcher paraît illusoire.

Le 21/04/2023 à 08h 03

Est-ce qu’on a une idée de la proportion de devs pourqui l’éthique compte vs ceux qui n’en ont rien à faire ?

Le 31/03/2023 à 02h 39

heu.
c’est pas une mutuelle ma MGEN ? moi je parle bien de cassies de sécu. Genre quand j’étais militaire et madame au régime général. Et actuellement à la CPR (caisse de sécu SNCF) et madame au général ben faut choisir.

Non mgen c’est aussi une caisse secu, pour l’enseignement et la recherche si je dis pas de bêtises. Je suis dans le même cas que wanou2, l’un cpam l’autre mgen, enfants rattachés aux deux

Le 27/03/2023 à 06h 58

L’occasion de s’intéresser à l’histoire de Fairchild Semiconductor, avant les débuts d’Intel :
https://fr.m.wikipedia.org/wiki/Fairchild_Semiconductor

Le 22/03/2023 à 03h 45

Ne pas se tromper, il faut savoir utiliser un pattern lorsque c’est adapté. Trop souvent certains devs apprennent un pattern te se mettent à le coller de partout.



On utilise les “anciens decorators” (<TS 5.0), va falloir que l’on regarde ce que ca donne de migrer en 5.0
C’est bien adapté quand tu veux te faire des compositions complexes (ici, composition spécifique à chaque website à parser)



En tout cas je te rejoins sur le fait que nombreux sont ceux qui jugent un langage seulement par la lib qu’ils ont eu à utiliser. Moi en tout cas j’aime bien le TS. Je recommande fortement de jouer avec Svelte en mode TS c’est bien plaisant :)

C’est une question de préférence avant tout. Ce que tu fais avec des annotations peut très bien être fait sans. Perso je préfère l’explicite à l’implicite ; savoir exactement quand et comment une fonction dépend d’une autre d’un simple coup d’oeil. Les annotations produisent du code avec beaucoup de choses un peu cachées sous le capot, perso je n’aime pas je préfère la mécanique visible, mais encore une fois c’est question de goût

Le 21/03/2023 à 21h 00

Hmm on peut avoir à peu près la même chose en java, n’est -ce pas? 🙃 J’ai déjà vu ce genre de chose plus d’une fois
Les génériques c’est sympa, mais on n’est pas forcé d’en abuser 😉

Le 21/03/2023 à 20h 52

Les devs java ont aussi RxJava, c’est comme RxJs, c’est juste une lib, libre à chacun de l’utiliser ou pas. Ce n’est pas du tout inhérent à Typescript.



Sinon, les décorateurs… :cartonjaune:
J’aurais préféré ne pas voir ça dans es/typescript. J’espère que ça ne deviendra pas mainstream et que ça reste cantonné à une “typologie” de projet, type angular. TS a apporté une forme de maturité à l’écosystème javascript sans imposer nécessairement l’approche que je trouve lourde/lourdingue d’un angular, et qui me rappelle en fait Java EE par certains côtés.

Le 16/03/2023 à 16h 57


Les unités systemd ont maintenant un temps d’extinction de 45 secondes


Merci!

Le 15/03/2023 à 06h 43

C’est déjà le cas, en fait. Quand gab, le réseau social d’extrême droite, a voulu rejoindre le fediverse en 2019, il s’est retrouvé bloqué par à peu près toutes les instances. Ça fonctionne à la modération, avec des blocages plus ou moins radicaux

Le 02/03/2023 à 22h 04

Moi ce que j’en dis, c’est que ça va être le boxon quand il faudra gérer ces timezones lunaires dans les logiciels. Comme si les timezones terrestres donnaient déjà pas assez de peine.

Le 22/02/2023 à 18h 08

À mon avis ces algos des assureurs rentrent totalement de le cadre de cette étude, c’est bien d’ “IA” dont il s’agit.

Le 13/02/2023 à 09h 27

Je ne serais pas étonné que le taux de télétravail soit déjà très élevé chez github déjà avant cette annonce, c’est assez courant dans ce type de boîte.
Ceci dit, ce qui est nouveau c’est que les gafam poussent dans cette direction. Post-covid, la tendance chez eux était plutôt au “return to office”.



À part ça.. j’ose pas imaginer le chaos que ce serait dans le monde du logiciel si github/gitlab commençaient à se dégrader. Tellement de projets reposent dessus (pas uniquement pour git, qui a l’avantage d’être facilement migrable, mais aussi pour la gestion de projet, code review, issues, CI …). Et ça ne concerne pas que l’open-source.
On n’en est pas là bien sûr, mais c’est juste une petite réflexion que je me faisais.

Le 31/01/2023 à 07h 45

Gros respect pour ce pur produit open-source qui traverse les âges.
Peut-être l’occasion de rappeler que le projet repose sur les dons : https://www.gimp.org/donating/

Le 31/01/2023 à 03h 58

Ce que je ne comprends pas parmi ceux qui réfutent la faille : si vous trouvez normal qu’un utilisateur privilégié ait accès à votre vault en clair, dans ce cas, pourquoi s’embêter avec un pass manager+master password? C’est le même niveau de sécurité qu’un fichier plain text, en clair, stocké dans un emplacement non accessible aux utilisateurs lambda (mais toujours accessible à un utilisateur privilégié)

Le 31/01/2023 à 03h 45

Il n’aura pas fallu longtemps : voilà un script qui exploite la faille, via les partages SMB: github.com GitHub

1 2 3 … 6 7