vv222 a écrit 925 commentaires

Je ne vois qu’une seule explication plausible : les joueurs acharnés de Factorio finissent tous par monter une usine automatisée Turing-complete. Puis à installer un serveur SSH sur ladite usine pour la contrôler depuis une autre partie de Factorio.

Quand je pense que de mon côté je ne suis même pas fichu d’y mettre en place une basique ligne de chemin de fer…

Au passage ils parlent de risque sur les comptes avec mot de passe faible

Je n’ai eu qu’une lecture rapide du document, mais je vois surtout des recommandations d’utilisation d’authentification par clé.

Je suis peut-être un admin un poil parano, mais de l’authentification SSH par mot de passe (autrement que sur un réseau local sûr) ça me fait froid dans le dos rien que d’y penser.

Si c'est juste pour faire moins de bruit dans les logs tu peux faire du port knocking.

J’imagine que le changement de port a plus de succès tout bêtement parce que sa mise en place se limite à changer une valeur dans la configuration de OpenSSH.

Moi c'est la question inverse que je me pose : pourquoi en changer ?

Je ne vois qu’une raison valable : pour avoir moins de "bruit" dans les logs. Mais ça ne concerne donc que ceux qui ont souvent à mettre le nez dans leurs logs SSH.

Ici je l’ai aussi passé sur un port non-standard, mais c’est avant tout pour avoir une opportunité de jouer avec le tarpit Endlessh (qui est donc lui sur le port 22).

Ah bah je revenais justement sur les commentaires de cette dépêche pour partager les derniers mails échangés via debian-devel-games, ça fait plaisir de voir que j’ai été doublé par celui qui bosse effectivement sur le sujet ;)

Ça m'intéresserait de savoir si d'autres l'on activée, et si c'était facile pour eux, histoire de déterminer si c'est moi qui m'étais mal débrouillé…

J'utilise l'hibernation sur quelques unes de mes machines nomades (toutes des Debian stable) depuis un tas d'années, sans difficulté particulière. Je passe pour ça par les commande s2disk ou s2both fournies par le paquet uswsusp.

Je ne me souviens pas avoir dû configurer quoi que ce soit avant que ça fonctionne.

À savoir que ce ne sera probablement plus une option valable à partir de Debian Bullseye, cf. #954061 - RM: uswsusp—RoQA; Dead upstream, unmaintained.

Joli bug destructeur en effet. Heureusement avec une portée limitée, plus grand monde n'utilise de fichier de swap aujourd'hui et probablement encore moins une RC du noyau Linux (même si elles ont tendance à être solides comme le rappel également Linus).

Pour ma part j’aurais été bien embêté si ça n’avait pas été repéré par cette RC. Je n’utilise que des fichiers de swap, système que je trouve bien plus simple et souple que les partitions dédiées.

Heureusement, je ne teste pas les RC du noyau. Sinon j’aurais moyennement apprécié la surprise ;)

Gaffe, comme précisé un peu plus tôt, cette version n’arrivera probablement pas dans les dépôts de Debian Sid avant la sortie de Debian Bullseye en version stable.

Quand la nouvelle mouture sera-t-elle dans les dépots debian (testing/sid)?

Probablement pas avant la sortie en stable de Debian Bullseye, qui est la priorité actuelle des mainteneurs et développeurs Debian. Elle arrivera peut-être avant ça dans la pseudo-branche experimental, mais mieux vaut ne pas trop compter là-dessus.

Tu peux garder un œil sur ce ticket si tu veux être au courant de l’activité de ce côté : #983408 - New upstream release 0.0.24

Benoît Sibaud nous a proposé il y a quelques jours un journal détaillant la compilation de cette nouvelle version de 0 A.D. sur Debian Buster, pour ceux qui souhaitent la tester sans attendre son inclusion aux dépôts Debian : Compilation de 0.A.D Alpha 24 pour Debian Buster

Une commande très pratique que j'ai adopté depuis peu de temps quand je construis des paquets depuis les sources sur Debian : mk-build-deps (fourni par devscripts).

Un exemple tout bête :

mk-build-deps 0ad
apt install ./0ad-build-deps_0.0.23.1-5_all.deb

Le gros avantage étant le nettoyage simplifié quand on veut se débarrasser de toutes ces bibliothèques de développement :

apt autoremove 0ad-build-deps

P'tite astuce pour le numéro de version :
0.0.23 < 0.0.24~ < 0.0.24

Tu peux mettre ce que tu veux derrière ce ~, chiffres comme lettres.
Un exemple classique serait par exemple : 0.0.24~rc1.

Sur LinuxFR même, pourtant pas un repaire du fan-club des GAFAM, tu es donneur de leçons si tu n'utilises pas de téléphone portable. Tu t'attaques à un logiciel libre si tu qualifie Chromium ou VS Code de cheval de Troie. Tu n'as pas besoin de pertinence des résultats si tu utilises un autre moteur de recherche que Google.

Quelqu'un ici a déjà chopé des virus ?

Pas à ma connaissance en tous cas.

Comme on cause beaucoup des e-mails comme vecteur, je pense que mon habitude de n'afficher les mails qu'en mode texte participe à me protéger. Beaucoup d'astuces dans les pièges par e-mail semblent reposer sur les possibilités des mails en HTML, et la version texte est souvent bien moins travaillée.

Pas possible par exemple en mode texte d'afficher un lien https://site-legit.tld/login qui pointe en fait sur http://site-malveillant/piège. Ce qui est une technique que j'ai vu utilisée plus d'une fois, et pas que pour des attaques : c'est aussi le fonctionnement des services d'e-mailing marketing (Mailchimp, Mailjet, etc.) pour compter les clics sur les liens.

Après je ne suis probablement pas une cible intéressante, je ne me rappelle même plus de la dernière fois où j'ai eu un faux mail Gandi ou OVH me demandant de vite vite vite payer pour un domaine ou serveur qui expire. Alors que pour des assos à qui je donne des coups de main, c'est quelque chose que je vois encore de temps en temps.

À savoir que je suis aussi sur un serveur mail auto-hébergé (postfix), avec un anti-spam (rspamd), qui est configuré de manière assez stricte. Donc je soupçonne qu'une bonne partie des mails foireux qui me seraient adressés n'arrivent en fait jamais jusque dans ma boîte de réception.

Merci pour le pointeur, si j'ai des réactions je les posterai sur ce fil de forum ;)

Franchement, si la seule fonctionnalité payante de GitLab qui te manque est remplaçable par une tâche cron, utilise l’édition libre et gratuite avec ta tâche cron en supplément. Aucun risque de mauvaise surprise côté évolution des tarifs, de licence à modifier parce que tu as un utilisateur à ajouter, ou de changement quelconque des conditions d’utilisation.

Vu les tarifs des différentes éditions pour entreprise, ce serait vraiment dommage de payer ça juste pour économiser un petit script et une ligne dans un crontab ;)

Pour ma part j’utilise la version libre (et gratuite) depuis quelques années avec toute une équipe (une poignée de développeurs réguliers, et une quinzaine de contributeurs plus ponctuels), et si j’en avais la possibilité j’aurais plutôt tendance à en retirer des fonctionnalités plutôt que de chercher à en ajouter… Mais c’est pour du développement communautaire de logiciel libre, sans aucune structure derrière (ni entreprise, ni association), donc nos besoins semblent bien différents de ce que tu décris ici.

la seule fonctionnalité non disponible dans la version community que j'utilise, c'est la possibilité de créer un dépôt sous GitLab, qui soit le clone d'un dépôt externe ou pull mirroring

C’est justement là que tu ne respectes pas la licence ;)
Je cite le passage en question :

This software and associated documentation files (the "Software") may only be
used in production, if you (and any entity that you represent) have agreed to,
and are in compliance with, the GitLab Subscription Terms of Service, available
at https://about.gitlab.com/terms/#subscription (the “EE Terms”), or other
agreement governing the use of the Software, as agreed by you and GitLab,
and otherwise have a valid GitLab Enterprise Edition subscription for the
correct number of user seats.

L’exception donnée plus loin ne concerne clairement que le développement de GitLab lui-même, et les tests liés à son développement :

Notwithstanding the foregoing, you may copy and modify
the Software for development and testing purposes, without requiring a
subscription.

En gros c’est une exception permettant de participer au développement de GitLab EE sans pour autant devoir en acheter une licence d’utilisation. Ce qui ne semble pas être le cas d’utilisation que tu décris.

---

Après je ne cause pas du côté moral de ce que tu fais, à titre personnel ça ne me touche pas du tout ;)
Mais sois bien conscient que sur le plan légal tu n’es pas dans les clous.

Euh, pourquoi ce serait à moi de proposer une alternative à Twitch ? Ou à un système de traitement de texte synchronisé ? (pour ma part ces deux machins peuvent disparaître sans aucune alternative, sans pour autant me manquer)

Et surtout, pourquoi je devrais avoir une réponse à chacune de ces questions avant d’être autorisé à critiquer le système actuel ? Je ne suis ni à l’origine d’un de ces services, ni consommateur de ceux-ci, et surtout je ne vais pas me lancer dans de longues études d’architecture logicielle pour obtenir un quelconque "certificat d’expertise" qui m’autoriserait à critiquer les solutions en place.

Ce n’est pas tout à fait ce que je dis.

Ce que je pense (et est sûrement discutable) est que ces GAFAM sont indélogeables dans tout ce qui touche aux services en ligne, ils ont trop d’avance et d’emprise dans ce domaine. Par contre il y a peut-être une chance pour d’autres acteurs du côté des applications natives, il suffit de voir VLC dans le domaine de la lecture de vidéo, ou GIMP et Krita pour la manipulation d’images, ou encore Blender dans la 3D…

Je suis incapable de citer un acteur similaire dans les services en ligne qui ne soit pas directement un GAFAM, une succursale d’un GAFAM, ou dépendant de l’infrastructure d’un GAFAM.

Ton lecteur vidéo, ton MUA, etc mettent quoi en place pour la sécurité ?

Facile : mon lecteur vidéo ne sert qu'à lire des vidéos, mon client mail ne sert qu'à lire et envoyer des mails. La surface d'attaque et plus globalement les possibilités de failles sont immensément réduites par rapport à un navigateur Web qui se prend pour un OS complet.

VLC n'a pas besoin de savoir traiter une pièce-jointe malicieuse, pas plus que Thunderbird n'a besoin de bloquer une éventuelle vidéo piégée.

Ce serait quoi une solution du coup ?

Mettre fin au "tout Web", au profit des applications natives.

Le navigateur Web est devenue une telle faille de sécurité ambulante uniquement parce que tout passe par lui, s'il ne servait qu'à "afficher des pages Web" on n'aurait pas besoin de toutes ces bidouilles pour tenter de reboucher la passoire.

Je ne souhaite pas qu'on chercher à réparer les navigateurs Web, ça me semble une cause perdue, mais qu'on réduise leur impact global dans notre utilisation des outils informatiques. En bonus ça donnerait une bonne claque au pouvoir démesuré des GAFAM et autres vendeurs loueurs de nuages.

Je présume que tu parle du fait de proposer des API pour interagir avec le matériel ?

Non ;) (enfin, si, ça fait partie de ce que je dénonce, mais ce n'en est qu'un point de détail)

Je parle de la dérive en cours depuis bien plus longtemps que ça de tout faire via le navigateur Web. Sorti de quelques "geeks", c'est même la seule application native à tourner sur le système.

C'est fini GNU/Linux, on est maintenant sur Firefox/GNU/Linux ou Chrome/GNU/Linux. Et c'est dans ce Firefox ou ce Chrome que tournent toutes nos applications.

Un antivirus sur les postes de travail Linux me paraît de plus en plus nécessaire.

Je veux bien te croire, mais il va falloir pour ça expliquer comment tu en arrives à ce constat.

Ce n'est pas une solution, mais un emplâtre sur une jambe de bois.

Je ne parlais pas pour l'instance officielle de GitLab, mais pour les instances auto-hébergée.

Le message auquel tu réponds n'évoquait que l'instance gitlab.com, d'où la confusion ;)