BFG a écrit 897 commentaires

Il prend en exemple

Moi aussi je peux prendre des exemples. J'ai recruté/géré un certain nombre d'hommes et de femmes dans la tech, Et parmi les personnes incompétentes que j'ai eues à licencier/couper la période d'essai, ce type de réaction débile (voire d'autres types de connerie, genre violence) venait des hommes.

Sur le modèle de https://web3isgoinggreat.com/

Le site semble promouvoir les cryptomonnaies et web3.

Youtube Shorts c'est une idée à Google, pas du tout une copie de Tik Tok. Mais bien sur…

Google essaye d'attirer le plus de monde possible, dans un but marchand. Parfois avec des tactiques non seulement déloyales, mais qui plus est illégales.

Mastodon cherche probablement à attirer des utilisateurs aussi, mais je doute que ça soit dans une logique de s'enrichir. Mastodon ne bénéficie pas d'un semi-monopole sur lequel s'appuyer pour essayer d'asphyxier ses concurrents.

Numerama l'a présenté comme un clone de twitter

Communication non-officielle et clairement putaclic.

La doc de mastodon fait le parallèle à plusieur reprise

Elle dit :

In practical terms: Imagine if you could follow an Instagram user from your Twitter account and comment on their photos without leaving your account. If Twitter and Instagram were federated services that used the same protocol, that would be possible.

Non, ils expliquent le principe de la fediverse, ils ne disent pas être équivalents à twitter.

Et le blog officiel de mastodon présente très clairement mastodon comme une alternative en tapant sur twitter pour conclure sur « venez nous rejoindre sur mastodon ».

Ce n'est pourtant jamais dit que c'est équivalent. Le message aurait très bien pu être « twitter c'est mal, utilisez les emails », sans que le message ait pour autant été « twitter = email ». Mais les messages ambiants disant « twitter = mastodon » font qu'on interprète aisément (à tort à mon avis) cet article de blog comme impliquant le même message.

Le gens ne préfèrent pas donner leur vie privée à des GAFAM, ils ont juste aucune offre alternative

Mais alternative à quoi ? Les gens ont bien accepté twitter en premier lieu sans se dire que c'était une alternative à autre chose ? S'ils ne veulent pas mastodon (qui n'est pas un équivalent) et qu'ils ne veulent que twitter, qu'ils gardent twitter, en acceptant les inconvénients de twitter (donner sa vie privée).

On vous propose de manger des haricots rouges. Vous en mangez. Vous en mangez à toutes les sauces. Un lanceur d'alerte qui travaille à la NSA apprend au monde que les haricots rouges donne des flatulences et que c'est un problème. Vous vous indignez de l'odeur, mais vous aimez les haricots rouges. Des personnes un peu hippies vous proposent de manger des lentilles, qui n'ont pas ce problème. Vous ne voulez pas goûter les lentilles car vous aimez manger vos haricots rouges tous les jours.
Un beau jour, un scandale alimentaire éclate, tous les fabricants de haricots rouges mettent de l'huile de moteur dans leurs boites de conserves ! Vite, vous courrez acheter une boite de lentilles dont vous avez entendu que c'est un aliment alternatif, et tous vos voisins font de même. Mais ça n'a pas le même goût, vous aimez moins. Ça ne marche carrément pas pour préparer un chili, au diable le dahl ! Et les lentilles sont vite en rupture de stock. Vous vous dites « les lentilles ne sont pas une alternative viable aux haricots rouges dans mon chili », et vous retournez, mécontent, manger vos haricots rouges à l'huile de moteur.

Je ne connais pas l'opinion de la communauté des devs de mastodon donc mon avis ne concerne pas mastodon en particulier mais de manière générale les logiciels décrits (par quiconque, pas forcément par les créateurs eux-même) comme « alternatives libres ».

je me pose la question maintenant qu'on sort de la théorie si les outils alternatifs ont été prévus et conçus pour gérer ce pourquoi ils sont sensés être faits (ou alors il va falloir arrêter de parler d'alternative à Twitter comme c'est affiché depuis des années).

Qui a dit qu'ils étaient une alternative, équivalente en tous points, à utiliser de manière interchangeable en cas de repli massif des utilisateurs d'un service propriétaire ? En tout cas, le site officiel ne mentionne pas « twitter ».

Mastodon ne doit rien aux gens qui se plaignent que c'est plus difficile, coûteux, etc.

Vous allez répondre « on ne peut pas prendre le libre en alternative sérieuse s'il n'y a pas de garantie », mais il n'y a aucune garantie non plus pour une plateforme comme twitter, comme ça a été prouvé magistralement par les décisions prises par la (nouvelle, mais peu importe) direction.

si l'accueil n'est pas à la hauteur ils vont revenir vers l'offre initiale et n'en partiront plus, échaudés

Au moins, ils auront testé d'autres logiciels, et leur décision aura été prise en connaissance de cause qu'ils préfèrent donner leur vie privée à des GAFAM (ainsi que tous les problèmes qu'on connait à twitter) du moment qu'ils peuvent continuer d'utiliser la plateforme qui leur est familière.

Mon avis personnel est que mastodon est suffisamment différent pour qu'on ne dise pas que c'est un équivalent mais un nouveau réseau social, même s'il peut présenter des similitudes avec twitter. De là, il faut repartir de zéro, penser différemment, voire s'investir, accepter que ça n'est pas pareil, que l'arrivée massive d'utilisateurs n'est pas forcément prévue et donc être tolérant. Si on veut un équivalent strict sans accepter la différence, autant passer son chemin tout de suite et retourner sur twitter.

C'est pas un sujet si simple, car certaines images (par exemples des images de bases) doivent plutôt rester sur root. Par contre un service qui tourne, probablement pas.

En effet, mais il y a peu d'images de base comparé au nombre d'images d'applications, et les images d'applications passant par un utilisateur non-privilégié sont une minorité (je ne pense même pas arriver à en citer une). Par défaut également, tous les capabilities sont conservées, et bien peu d'images les désactivent.

Il y a bien sûr le problème des mises à jour qui fait l'objet de ce journal, et très peu d'images que j'ai rencontrées sur dockerhub sont reconstruites fréquemment pour avoir les paquets du système à jour. Aucun moyen facilitateur n'est fourni pour le faire. Quelques exemples ont été donnés ici pour employer une CI/CD dans ce but, mais ce ne sont que des solutions « maison » et ce n'est même pas ne serait-ce qu'évoqué dans la documentation de docker concernant les bonnes pratiques.

Sur un autre sujet de qualité, qui ne concerne pas la sécurité, mais qui a été mentionné dans les commentaires : le poids des images. Il existe des moyens pour faire des images finales minimales comme le multi-stage build mais c'est relativement peu utilisé dans les faits. Voir par exemple monicahq/docker#109 et docker-library/php#1324 où la balle est renvoyée entre une appli et l'image de base utilisée.

Le problème c'est que ça sera soit pas assez en cache, soit trop en cache, car tu dépends d'une ressource externe.

Si à un instant T tu construis l'image, le RUN apt-get … sera bien lancé la première fois. Le lendemain, tu refais un docker build pour reconstruire l'image ? Perdu, le RUN est en cache donc aucune mise à jour ne sera faite. Une astuce pourrait être d'inclure une règle qui vérifie s'il y a eu des mises à jour, comme ADD http://security.debian.org/debian-security/dists/stable/updates/Release.gpg /tmp/peuimporte

message supprimé

Ensuite, j'utilise SELinux. Au taf, c'est directement dans la plateforme (Openshift), chez moi, c'est directement dans l'OS, les conteneurs ne tournent pas en root autant que possible. Le but est d'éviter les sorties du conteneur trop facile en cas d'execution dans le conteneur.

Peux-tu m'en dire plus ?

Ensuite, je prends pas n'importe quel image, et je fait mes propres images ou mes propres déploiements.

J'essaye donc de faire mes images et d'automatiser la recompilation via une CI, en utilisant les paquets de la distro autant que possible.

Je comprends que ça serait le plus propre, mais c'est ce que j'aurais aimé éviter.

L'exemple de Debian est un bon cas, car je ne connais pas la situation maintenant, mais avant, c'était un peu bizzare.

C'est intéressant, j'étais loin de m'en douter, surtout que la page dockerhub arbore fièrement l'indication « Docker Official Image », mais qui, en y regardant de plus près, signifie :

Docker Official Images are a curated set of Docker open source and drop-in solution repositories.

Il faut donc comprendre « officielle à docker » et non « officielle au projet conteneurisé »…

fournir une image pour la prod. Ce ne sont pas les même politique de sécurité, paquets installé, bonne pratiques. Et ce n'est pas forcément facile de savoir ce qu'une image vise comme objectif

et (du commentaire au dessus)

Et Dockerhub vise plus à avoir tout le monde pour des questions de croissances que de devoir faire un choix, donc tu as effectivement plein de trucs douteux.

Oui, les mises à jour ne sont qu'un problème parmi d'autres (par exemple, l'utilisation de root dans la majorité des images de dockerhub). Il y a un problème de qualité générale et en effet c'est difficile de trier le bon grain de l'ivraie. J'essayais d'en corriger une partie avec peu d'efforts (pour ne pas avoir à passer du temps à faire moi-même un dockerfile complet correct pour chaque logiciel que je veux déployer).

Fedora a tenté de pousser ça, des conteneurs basés sur Fedora utilisant les paquets et avec des standards et une gestion des versions. Ça n'a pas trop décollé que je sache.

Par curiosité, il y a un lien qui documente ça ?

C'est sans doute mort. Les devs de logiciel se sont lancés sur docker en se disant "ça va éviter de faire le taf des distributions", mais c'est une connerie, ça évite pas les distributions du tout, ça obscurcit le tout.

Ok, j'aurais espéré que le problème était déjà résolu quelque part et que ce n'était que de la méconnaissance de ma part…

Je pense que je vais tenter mon idée de bricolage imparfait, voir si c'est réalisable déjà. Pour une image donnée, démarrer un nouveau conteneur de l'image dockerhub (mais sans entrypoint), faire les mises à jour dedans, puis le docker commit pour figer une nouvelle image locale. Cela devrait pouvoir être rendu suffisamment générique pour fonctionner avec toutes les images basées sur les distributions courantes. On pourrait alors mettre ça dans un crontab. Bien sûr, ne pas oublier de relancer ses conteneurs après ça.

Pour aller plus loin, on pourrait remplacer localement l'image originale avec son tag pour ne pas avoir à modifier nos docker-compose.yml existants. Ça ne résistera pas à un docker pull, mais en bricolant encore un peu plus, on pourrait sûrement sauvegarder l'état quelque part et ne faire que des mises à jour incrémentales plutôt que repartir de l'image présente sur dockerhub à chaque fois (et alléger le crontab).

Il existe pleins d'outils pour faire des scan d'image docker (qui vont lire le dpkg status) et détecter celles avec des failles de sécurités.

Je ne cherche pas à scanner mais à corriger les problèmes.

Ça te donne la liste d'image à reconstruire.

Je ne veux pas reconstruire les images à partir du dockerfile, ce sont des images externes que j'utilise, que je n'ai pas créées moi-même. Je veux un moyen de mettre à jour les distributions des images présentes sur dockerhub.

Ou plus simplement, avoir une image de base qui le fait sur laquelle les autres images se basent.

C'est ce que je dis dans le journal :

De toute manière, les images de base (comme debian:stable) ne sont pas elles-mêmes reconstruites à chaque mise à jour de sécurité.

Et

Mais sinon, tu dois quasiment avoir toujours un apt-get update au début de ton dockerfile sinon, tu ne pourras pas installé de paquet vu que tu n'aura pas le cache des images.

Je ne manipule aucun dockerfile, et je ne souhaite aucunement le faire, j'utilise uniquement des images existantes dans un docker-compose.yml.

Un système traditionnel non-conteneurisé n'aurait pas tous ces défauts.

Je ne comprends pas trop ce que tu veux dire, dans les deux cas il faut faire des mises à jour.

Oui, sur un système non-conteneurisé, je fais les mises à jour de la distribution. Sur un système conteneurisé, je n'ai plus la main sur la distribution, et en pratique les images présentes sur dockerhub, même si elles faisaient les mises à jour à la construction de l'image, et bien ça serait à la date de la construction de l'image uniquement, pas chaque jour.

Est-ce vraiment une surprise ?

Beaucoup de gens pensent que microsoft a changé depuis un certain temps. VSCode est pris en exemple de leur nouvelle ouverture et nombreux sont les dév sensibles au libre qui s'en servent en pensant qu'il n'y a pas là de contradiction. Microsoft fait bien sa publicité et convainc suffisamment pour que des personnes insoupçonnables en fassent la promotion. Il convient alors de rappeler la vérité qui n'est pas forcément l'information qui est recopiée partout.

In short, this is what Microsoft did:

• Created VSCode and made it the best and open-source IDE that everyone would jump to first.
• Make a proprietary free distribution of it, along with proprietary free extensions for the various languages.
• Make those extensions the best version possible and slow down focus on open source ones, often deprecating them.
• Now you have to use the closed form of VSCode to have the best experience by quite a bit.
• Everyone else using VSCode as a platform can't keep up because Microsoft fractured their community—and your VSCode product is now just an ad for a similar Microsoft product that doesn't have all the papercuts.

que je trouve quand même plus avancés que Markdown

Markdown ne possède pas de tableaux du tout (à part en insérant du HTML brut). CommonMark ne corrige pas ce problème non plus. Ce sont quelques implémentations éparses qui proposent des tableaux, avec des syntaxes subtilement différentes.

Ça catalyse parfaitement tout ce pourquoi Markdown est très mauvais :
- trop simpliste, ne permet même pas des choses courantes comme des tableaux
- pas assez normé, fragmentation extrême, les implémentations sont incompatibles les unes avec les autres, CommonMark est là pour aider, mais uniquement sur la syntaxe de base qui est elle même mal normée

Un exemple de liste qui ne produit pas le même résultat partout :

foo:
- bar


Voir babelmark pour les résultats

Même CommonMark est instable et change trop d'une version à l'autre, cf une différence non-négligeable entre 0.28 et 0.29.

En soi, on peut dire qu'un « document markdown » est en fait très lié à une seule implémentation de rendu, celle choisie par celui ou celle qui a édité le document. En soi, markdown désigne bien trop de choses différentes. On devrait plutôt parler par exemple de « document Gitlab Markdown » ou « document CommonMark 0.30 », et ensuite veiller à ne pas tenter de le faire rendre sur une autre implémentation, sous peine d'avoir un rendu très mauvais.

Les clefs USB de sécurité sont déjà "impossibles à cloner", à ma connaissance. Qu'apporte cette nouvelle technologie, à part nécessiter de coûteux lecteurs optiques, quand un simple port USB suffit pour l'existant ?

1) Perso je n'en connais aucun. Je ne suis pas certain du tout d'en connaître un par ami interposé. Donc la preuve n'est pas évidente pour tous …

C'est même l'inverse. Je connais personnellement des devs Cobol, et ils ne sont pas du tout payés plus que des devs non-Cobol (parfois même moins), en France en tout cas.

http://antirez.com/news/124

Les relevés PDF de ma banque ont un rendu raté aussi, je vais essayer d'appliquer la technique pour trouver le problème, merci !

Pourquoi le système actuel serait-il plus adapté pour empêcher la prolifération des candidats ?

Parce qu'ils n'ont tout simplement aucune chance.

Un candidat inconnu au bataillon n'aura pas beaucoup plus de chance d'être élu.

(et la pétition ne se cantonne pas à l'élection présidentiel, même si elle le vise particulièrement, très certainement d'un point vue calendrier).

Très certainement aussi car c'est la plus problématique.

Ce n'est pas vraiment un filtrage. Cela n'empêche pas les gens de se présenter. Ce n'est qu'une aide qui intervient a postériori, et sous conditions.

C'est donc un filtrage, car beaucoup de candidats potentiels hésiteront sûrement à se présenter s'ils doivent engager des frais non-négligeables pour "rien".

J'ajouterai que cette pétition vise à faire étudier ce système et le faire discuter. Il est dommage de rejeter une initiative intéressante de but en blanc sous prétexte qu'on vient de penser à un problème auquel il existe peut-être (déjà ?) une solution.

Pourquoi le système actuel serait-il plus adapté pour empêcher la prolifération des candidats ? Il y a quand même des filtrages, comme une condition de 500 signatures minimum, un non-remboursement de certains frais si le nombre de votes recueilli est trop faible (à adapter), etc.

J'en profite pour signaler une pétition déposée sur le site du Sénat (qui utilise France-Connect). On est malheureusement encore loin des 100000 signatures requises pour qu'elle soit inscrite à un ordre du jour sénatorial…

Un PDF généré il y a 25 ans se lit et s'imprime toujours pareil de nos jours.

Pourtant, les relevés de ma banque au format PDF ont un rendu différent selon le lecteur utilisé (par exemple avec Okular ou Evince).