barmic 🦦 a écrit 5211 commentaires

En effet je me suis laissé avoir par le fait que la solution recommandée n'est qu'un petit encart dans la page que tu pointe. Je trouve vraiment bizarre comme façon de le présenter…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le projet demande à vérifier la signature gpg du fichier que tu as téléchargé. C'est le truc dont on parle.

À noter que ça fait partie de leur procédure de téléchargement. C'est pas une option mise dans un coin comme beaucoup d'autres projets.

Ils sont vraiment propre sur la sécurité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour bien comprendre le coup de gueule, il faut savoir que de plus en plus de projets "modernes" donnent comme instructions d’installations officielles des variantes autour de ce curl … | sudo bash, à tel point que cette méthode se banalise et n’est plus considérée comme problématique.

C'est largement plus compliqué que ça. Si un projet ne te file pas de moyen de vérifier les binaires qu'il te file, un curl | sh ou un plouf.<extension_de_paquet_de_ta_distribution_préféré> sera pareil (sauf si ta distribution refuse d'installer des paquets non signés, ce qui n'est pas le cas de Debian, ses dérivées ni d'arch si je ne m'abuse).

Bref oui ça pose un problème de sécurité, mais non ça n'est pas une question de commande.

Ici en l'occurrence le projet upstream propose quelque chose qui a l'air propre c'est dommage de l'outrepasser.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Même si l’étape de vérification du script n’est pas explicitement citée avec ces deux commandes, elle n’est plus rendue impossible.

C'est donc une question de principe plus qu'autre chose. On a beaucoup dis que curl … | sh - c'est mal donc, il ne fait pas l'écrire, même si ce ne sont que des circonvolutions autour ?

Si le problème c'est de faire la vérification ça ne coûte rien de mettre un :

aria2c "https://…"
# vérifier la signature comme indiqué ici : https://
sh plouf.sh

Soit la question de la vérification est importante et on la met en évidence, soit OSEF.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu peux partager un dossier en upload uniquement. Ça crée un lien les gens peuvent envoyer directement

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Qu'en est il de l'utilisation de ce langage dans le monde du libre ?

Beaucoup de projet dans les fondations eclipse et apache utilisent ce langage par exemple.

Un éditeur que je connais bien as récemment basculé sur openjdk, bon cela ne concernait que l'outil d'installation mais quand même …

Je ne comprends pas ce que tu sous-entend ?

OpenJDK est un projet libre. C'est l'implémentation de référence du JDK et du langage Java. Ils ne fournissent que du code. Il y a des intégrateurs qui sont là pour compiler et mettre à disposition des build. On pense beaucoup aux nouveaux comme Amazon Corretto, mais debian fourni son propre build depuis un paquet d'années, RedHat aussi. L'une des distributions les plus en vogue actuellement (et agnostique de ta distribution linux ou de ton OS) est adoptopenjdk. Le changement qui a eu lieux récemment c'est qu'Oracle n'a plus sa propre implémentation, mais qu'il ne fourni plus qu'une distribution d'OpenJDK.

« Plus que » il faut voir ce qu'on entends par fournir une distribution (ça marche aussi pour linux ou LaTeX par exemple) :

• construire et créer les paquets pour la cible que tu cherche
• suivre les mises à jour et les rendre disponibles ASAP
• éventuellement fournir des choses en plus (ajouter des outils, fournir plus ou moins de documentation avec)
• faire tout le suivi de sécurité (est-ce que tu suit simplement la ligne upstream ou est-ce que tu fourni du support plus long terme comme RedHat le fait sur ses paquets ?)

Selon l'intégrateur que tu choisi se travail peut être fais gratuitement (comme Debian) ou payant (comme RedHat avec RHEL).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La plupart des gens sont maintenant incapables de s'orienter avec une carte en papier, encore moins sans carte, et se retrouvent complètement perdus sans leur téléphone. C'est pour moi plus une régression qu'un progrès.

La plupart des créations de notre histoire en rendant possible ce qui était impossible avant rendent aussi facile ce qui était compliquée auparavant. Ça rend une capacité bien moins importante pour ceux qui n'avait pas un besoin si compliqué que ça.

• la roue a réduit les distances
• l'imprimerie et tout ce qui s'en ai suivi jusqu'à l'informatique a tué l'écriture manuscrite et encore plus la calligraphie
• …

Ça rend aigris ceux qui ont ses compétences si elles ne sont plus nécessaires. On perds en prestige ou en ayant travaillé pour avoir une tel compétence on aime pas la voir perdre en valeur.

L'argument classique du « imagine tu n'a plus cette innovation ? », ça marche aussi avec toutes les autres (une roue peut casser, on peut ne plus avoir le droit de faire décoller les avions, les pannes électriques ça existe,…), mais l'expérience montre que c'est plutôt marginal. On considère ses technologies comme importantes et on fait ce qu'il faut pour les maintenir.

Ce n'est pas pour autant que c'est bien, mais je pense pas que l'on ai assez de recul pour savoir si c'est bien ou pas. Là où pour l'agriculture, on a déjà une meilleure vision ;)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est pas une bonne idée. Il est difficile de faire des sauvegardes cohérentes via des volumes docker par exemple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Donc oui, on évite de se faire contaminer

Justement, un masque type chirurgical n'est pas une protection pour celui qui le porte, tu peux te faire contaminer. Il est une protection pour les autres.

T'a quand même coupée ma phrase alors que la seconde proposition était associée avec une conjonctions de coordination en gras…

Édition : ma phrase voulait dire qu'aujourd'hui on doit tous chercher à ne pas contaminer. C'est ce qu'on fait quand on tousse dans notre coude par exemple. C'est ce que font ce genre de masque.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il n'est utile qu'au malade (bon ici on peut supposer que beaucoup soient à risque, y compris sans le savoir).

On en est définitivement plus à chercher à savoir qui est malade ou pas. C'est tout le principe du confinement : on se considère comme contagieux par défaut et on fait le maximum pour ne pas être vecteur de contamination. Donc oui, on évite de se faire contaminer et de contaminer.

Utiliser ce qu'on peut pour éviter les projections ne paraît pas plus ridicule/inutile que de tousser dans son coude.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

celui la merite d'etre regardé

Il a le mérite d'avoir eu du succès ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Euh… non. Porteur sain tant qu'on a pas de difficulté respiratoire. Des vecteurs de contamination sans besoin d'aller en réanimation.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui mais avec l'absence de test, on fait aussi bien de tous se considérer comme porteur sain.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il faut surtout regarder le nombre de morts (puisque là les données sont fiables).

On a aussi une autre stats qui devrait être fiable : le nombre de personnes ayant développées des complications au point d'être en réa, mais qui sont guéries. Tant que nos hôpitaux ne sont pas (ou pas trop) en surcharge, c'est une valeur qui doit être mesurée.

Si on arrête d'essayer de savoir qui a ou n'a pas le virus. Non seulement c'est compliqué, mais c'est pas hyper utile et qu'on base les calculs sur le nombre de complications, on peut déjà en tirer des choses. Il faut faire attention par contre au fait que la guérison est probablement plus lente que le décès.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne sais pas si c'est ce que nous allons utilisé mais merci sincèrement et bon courage pour gérer le surplus de charge sur vos serveurs !

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça me fait penser à une discussion qu'on a eu : c'est trompeur de parler de ligne éditoriale sur linuxfr car il n'en a pas. Il peut avoir un ou plusieurs thèmes, mais une ligne éditoriale demande un statut différent. Ça sous-entendrait que l'équipe est responsable du contenu (légalement entre autre) et placerait les contributeurs dans un rôle de pigistes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Cela ne s'improvise pas et demande de l'habitude mais quand l'équipe est prête et bien organisée, cela roule bien.

On essaie de s'y préparer, mais ça va globalement être de l'improvisation. On est loin d'être prêt.

De toute façon s'organiser pour autoriser le télétravail a de nombreux avantages.

Ça j'en ai aucun doute.

Merci pour ton retour :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Nous utilisons Zoom pour les vidéo-conférence et le partage d'écrans principalement.

J'avais oublié cet outil. J'en avais entendu beaucoup de bien.

Pour le partage de code avec intellij, il y a une issue dans laquelle on peut voir que beaucoup son demandeur avec cette pandémie. Moi aussi je l'attends, je n'utilise pas vscode

Oui je l'ai vu, mais elle est super vielle cette entrée.

Merci pour le lien je vais potasser ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu parle d'Hangout pro j'imagine ?

Faire un point en visio le matin. Ça fait un point de synchro et ça permet de planifier sa journée. En général toutes les questions en suspend sont traitées à ce moment puis ensuite on est tranquille pour le reste de la journée.

J'aurais eu tendance à le faire en audio, mais ok.

Faire le chiffrage en visio et le répartir sur plusieurs jours. J'ai eu des sessions de trois heures de chiffrage et ça chauffe bien les oreilles. C'est mieux de faire quelques stories par jour.

Merci pour l'idée.

Ne pas hésiter à s'appeler en visio sans prévenir.

J4aurais tendance à faire l'exact inverse. Demander par IM avant de préempter quelqu'un.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Après, c'est aussi possible que ça reste très rare et que mon avis soit biaisé parce que j'ai justement creusé les forums pour aller chercher ce genre de problèmes.

Hé même sans ça, les gens pour qui ça fonctionne ne le disent pas forcément.

Mais ok, moi je n'ai jamais eu le problème (après il sert l'énorme majorité du temps en lecture seulement) et ça fait longtemps que je ne m'en sert plus.

Ils pourraient, mais, à ma connaissance, ce n'est pas comme ça qu'ils fonctionnent. Ils ont un mode de fonctionnement qui ressemble plutôt à une base de données, mais sans la même qualité d'implémentation. Le fichier est ouvert en permanence pendant que le logiciel tourne, souvent avec un second fichier qui sert de verrou (« lock-file »). Les écritures ne se font pas séquentiellement du début vers la fin, mais en sautant d'un endroit à un autre. Ils n'ont pas de journal d'écriture qui permet de repartir en cas de problème. Ils pourraient utiliser sqlite3 plutôt que le format de fichiers kdbx… mais ils ne le font pas.

C'est dommage je pensais que c'était vraiment un cas d'usage qu'ils avaient pris en compte. J'aurais même pas était choqué qu'ils utilisent un fichier en append only et qu'au bout d'un certains volumes ou nombre d'entrées inutiles, ils fassent une étape de compactage. Les écritures aléatoire + la couche de chiffrement ne doivent vraiment pas aider…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'ai pas fais de vérification mais pour que des logiciels de synchronisation aient une chance de fonctionner il faut qu'ils traquent les close et move via inotify plutôt que de faire la copie bêtement. Si non tu ne peux pas non plus t'en servir pour les fichiers LibO par exemple et ça commence à être problématique car c'est un peu leur cas d'usage principale.

De l'autre côté des logiciels comme keypass peuvent limiter fortement les risques. En manipulant correctement leur fichier, ils presque n'y appliquer que des opérations automatiques.

Même avec tout ça, il faut qu'ily ait une copie incorrecte qui se passe sans avoir de copie correcte quelques secondes plus tard. C'est possible, mais ça réduit encore les risques.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Alors quelqu'un qui vient juste pour dire un lapidaire : "vos commentaires sont affligeants", il faut pas non plus s'étonner qu'il soit accueilli assez froidement. C'est pas une question de usage linuxfrienne, mais bien de politesse/bien séance tout court.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

« Je suis une sur deux - j'ai eu de la chance, j'ai eu le bon viol »

J'ai vu passer la citation plus d'une fois.Probablement du fait que c'est sorti de son contexte, je n'ai aucune idée de ce que ça signifie. Le coté putassier de la citation me pousse à ne pas cliquer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une image c'est identifiée par un hash cryptographique de son contenu. Ça peut te permettre de valider une image et de t'assurer qu'elle n'est pas modifiée. L'intérêt du truc c'est d'avoir une chaîne de construction stable. Tu parle d'une chaîne de confiance plus longue, ça n'est pas vraiment le cas :

• version distrib' : upstream → distribution
• version docker : upstream → repository docker (des fois c'est l'upstream eux-même qui produisent l'image)

Que tu utilise une distribution validée ou une autre tu es sûr d'avoir la même chaîne de construction.

Pour utiliser ça, il suffit de déclarer ainsi :

FROM gcc@sha256:fa369b0da44afd4fe92e20559b55627556621221b9659ed6dc370924b98568dc

Tu peux aussi ne pas faire confiance au docker hub et configurer ton docker pour ne jamais aller chercher chez lui tes images. À la place tu peux avoir ton propre dépôt ou en choisir d'autres (j'imagine que ça ne te fais pas particulièrement confiance, mais les cloud providers exposent leur propre dépôt généralement, gitlab en expose un par projet aussi).

C'est probablement pas parfait, mais ça fait tout de même le taff.

Après il n'est pas obligatoire de faire son build dans docker. Tu peux avoir le même résultat en gardant que la dernière partie en en faisant le build là où tu as envi.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et la confiance est très difficile à établir : "FROM gcc" ou "FROM ubuntu", qui me dit que ça ne fait pas autre chose que ce que c'est sensé faire ?

Je ne comprends pas ta critique ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll