Le 03/04/2024 à 18h 26

Après Heartbleed l'industrie avait lancé la CII pour financer des projets open-source, mais ils se sont focalisé sur les projets directement liés à la sécurité (Heartbleed / openssl ayant focalisé l'attention).

Là, on voit bien qu'il faut une approche différente. Les attaquants ont certainement cherché des cibles du style "la petite lib d'xkcd", ie. le petit truc utilisé massivement (dont par certains packaging de sshd, cœur du problème ici) mais maintenu par un hobbyiste plus ou moins démotivé. C'est exactement ce genre de shortlist que l'industrie doit aussi faire de son côté: identifier toutes ces libs peu maintenues mais très utilisées. Et peut-être redonner vie à la CII...

Le 03/04/2024 à 09h 05

En l'occurrence l'attaque réduisait intentionnellement la portée aux .deb et .rpm, certainement pour éviter aux hackers d'avoir à "gérer" trop de familles *nix. Il faut voir que si pour une raison x ou y le build génère des problèmes non anticipés (par exemple car non testé sur un système donné par le hacker) ça risque de mettre tout son travail de sape à l'eau.

Le 02/04/2024 à 23h 24

d'autant que ce n'est pas le code de test qui est incriminé, mais les fichiers data, donc encore moins le genre de truc qu'on va auditer scrupuleusement (du moins jusqu'à aujourd'hui)

Le 02/04/2024 à 23h 17

Mais il existe du coup peut-être des portes dérobées dans d'autres paquets qui elles, n 'ont pas eu la chance d'être trouvées...

Le 03/04/2024 à 07h 44

Discord est déjà un enfer de bruits et de popups en tout genre, hâte de voir ce que ça va donner avec de la pub en plus 🤣

Le 29/03/2024 à 07h 33

Seulement voilà, la première est payante et la seconde ne sait travailler qu’en texte brut.

Le 22/03/2024 à 11h 38

Alibaba s'est tout de même mangé 2.8 milliards d'amende en Chine pour pratiques monopolistiques, et maintenant sous le coup d'un plan de scission.

Le 16/03/2024 à 08h 46

On peut voir le verre à moitié plein, sinon: il ne reste plus grand chose à nous dérober, c'est plutôt positif!

Le 24/01/2024 à 19h 38

Perso j'ai ressorti mon atari st pour mon fils qui voulait voir à quoi ça ressemblait. L'émulation ne m'intéresse pas, mais ressortir des vieilleries ça a un certain charme... Le tac-tac-tac du lecteur de disquettes, le "insert disk 4", tout ça 🙂
J'étais surpris de voir qu'il fonctionne assez bien, certaines disquettes doivent être abîmées mais j'ai à peu près un jeu sur deux qui marche (déception je voulais relancer ishar 3 mais ça veut pas 😭)

Le 11/12/2023 à 21h 00

J'y connais pas grand chose, mais le précédent article sur le PIIEC, et les infos que j'ai pu lire sur le site de la commission eu, donnaient en effet l'impression d'un investissement long et rigide, très planifié, pas franchement en phase avec l'industrie tech. Et d'y voir les usual suspects atos/orange aux premiers rangs renforce l'idée d'une énième pompe à argent public qui se dessine... J'espère juste avoir tort.

Le 08/12/2023 à 21h 43

on va pas se plaindre de voir une nouvelle tête au milieu des usual suspects :-)

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

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

(ah, les liens ne sont pas cliquables?)

Le 03/12/2023 à 09h 11

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 :

• https://law.stackexchange.com/questions/95495/unity-installation-fees-and-retroactive-unilateral-pricing-changes


• https://twitter.com/Rahulahoop_/status/1702354325404627455/photo/1

À 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 : https://arstechnica.com/gaming/2023/09/report-unity-considering-revenue-based-fee-caps-self-reported-install-numbers/

Ç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

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? 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

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

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

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

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

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