Ben mon vieux!
Plus on avance dans les billets plus on est stupéfait.
ça laisse penser que toute cette vague de magasins d'application (pour extensions, logiciels, formats de paquets style Snap, Appimages, … voire Docker) est dangereuse. À part compiler soi-même, rien ne vaut un dépôt géré par une distribution.
Même en lisant tout soi-même, on a l'exemple tout récent du trou dans openssh créé au travers de la liblzma. Il faudrait être un génie pour pouvoir certifier tout ça.
Pour Emacs, je pense que Lisp est rédhibitoire, donc, ça permet déjà de filtrer la qualite des attaques. Je plaisante, bien sûr.
Pour Vim, je ne sais pas, mais pour Emacs, chez moi, il tourne dans un namespace avec les ports http rediriges vers un proxy transparent, qui ne laisse passer que gnu.elpa.org et melpa.org.
Donc à moins d'être soucieux de sa sécurité, ce n'est pas gagne.
Je me demande si c'est possible avec vim ou Emacs.
Absolument car ce sont aussi des interpréteurs de code.
Les problèmes d'attaques de la chaîne d'approvisionnement (ça sonne moins bien qu'en anglais) des environnements de développements est un problème qui touche tout le monde et tous les langages, proprios ou libres.
Naturellement dans une société humaine, on a envie de faire confiance par défaut, et c'est normal, car on bascule vite dans la paranoïa, les biais, la haine et l'obscurantisme si on traite tout comme s'il nous voulait du mal.
Dasn le cas d'un IDE c'est difficile de trouver une solution universelle à part dans la frugalité si on veut rester dans le modulaire.
Posté par Psychofox (Mastodon) .
Évalué à 4.
Dernière modification le 12 juin 2024 à 12:21.
Dépendances s'appliquent bien aux librairies tierce partie utilisées par le logiciel que tu développes, peut-être moins à l'outillage. Dans le cas d'un IDE par exemple, la même équipe peut avoir des développeurs utilisant vscode, vim, emacs et intellij sans que l'un ou l'autre en soit une dépendance forte.
attaques de la chaîne d'approvisionnement (ça sonne moins bien qu'en anglais)
Boh, il suffit de lire 3-4 docs de l'ANSSI et tu t'habitues :). Hier j'ai regardé une petite présentation dans laquelle l'orateur parlait de gigue réseau. Ça faisait plusieurs années que je n'avais pas entendu ce mot, ça m'a fait plaisir de le retrouver !
On est tellement habitué à lire (et écrire, parfois) des docs en anglais qu'on peut avoir l'impression qu'il n'y a pas d'équivalent assez précis en français, et que l'expression anglaise est plus subtile ou porteuse de sens, alors que souvent non. On peut se référer au québecois dans certains cas.
Il y en a un que je trouve pas évident, c'est "endpoint" qui désigne l'extrémité d'un réseau, dans le sens "un truc connecté au réseau pour communiquer sur ce réseau". Ça peut être un ordi, une montre, un pacemaker ou un sextoy…
# Faut tout lire et jeter au feu VSCode
Posté par orfenor . Évalué à 10.
Ben mon vieux!
Plus on avance dans les billets plus on est stupéfait.
ça laisse penser que toute cette vague de magasins d'application (pour extensions, logiciels, formats de paquets style Snap, Appimages, … voire Docker) est dangereuse. À part compiler soi-même, rien ne vaut un dépôt géré par une distribution.
[^] # Re: Faut tout lire et jeter au feu VSCode
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 6.
Un dépôt « géré » surtout. Là c’est juste une chambre d’enregistrement.
Je n’ai pas été étonné par la « nouvelle »…
[^] # Re: Faut tout lire et jeter au feu VSCode
Posté par lolop (site web personnel) . Évalué à 6.
Tu compiles quoi toi-même ? Des sources récupérées sur github, gitlab, sourceforge etc…
Sauf à tout lire et certifier, ça devient difficile, avec toutes les couches et libs empilées, de savoir sur quoi est bâti le château de sable.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Faut tout lire et jeter au feu VSCode
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 7.
Même en lisant tout soi-même, on a l'exemple tout récent du trou dans openssh créé au travers de la liblzma. Il faudrait être un génie pour pouvoir certifier tout ça.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Faut tout lire et jeter au feu VSCode
Posté par orfenor . Évalué à 3.
C'était pour inclure les ports des BSD et autres recettes Gentoo, Arch, LFS, etc.
# VSCode vs vim vs Emacs
Posté par cg . Évalué à 6.
L'exploit est du niveau d'une macro Word (du même éditeur), mais c'est joli en terme de quantité :).
Je me demande si c'est possible avec vim ou Emacs. Les modules .vim et .el sont du code, après tout. Existe-t-il des gardes-fous pour ces éditeurs ?
[^] # Re: VSCode vs vim vs Emacs
Posté par Zenitram (site web personnel) . Évalué à 8.
Ne pas être utilisé par des personnes "rentables".
[^] # Re: VSCode vs vim vs Emacs
Posté par cg . Évalué à 1.
J'ai trop le seum je suis pas rentable :'(
[^] # Re: VSCode vs vim vs Emacs
Posté par Andre Rodier (site web personnel) . Évalué à 5.
Pour Emacs, je pense que Lisp est rédhibitoire, donc, ça permet déjà de filtrer la qualite des attaques. Je plaisante, bien sûr.
Pour Vim, je ne sais pas, mais pour Emacs, chez moi, il tourne dans un namespace avec les ports http rediriges vers un proxy transparent, qui ne laisse passer que gnu.elpa.org et melpa.org.
Donc à moins d'être soucieux de sa sécurité, ce n'est pas gagne.
Pour Vim, je ne sais pas.
[^] # Re: VSCode vs vim vs Emacs
Posté par Lutin . Évalué à 5.
NeoVim peut être configuré en LUA, il doit y avoir moyen de faire des trucs folklo avec ça.
[^] # Re: VSCode vs vim vs Emacs
Posté par Psychofox (Mastodon) . Évalué à 5.
Absolument car ce sont aussi des interpréteurs de code.
Les problèmes d'attaques de la chaîne d'approvisionnement (ça sonne moins bien qu'en anglais) des environnements de développements est un problème qui touche tout le monde et tous les langages, proprios ou libres.
Naturellement dans une société humaine, on a envie de faire confiance par défaut, et c'est normal, car on bascule vite dans la paranoïa, les biais, la haine et l'obscurantisme si on traite tout comme s'il nous voulait du mal.
Dasn le cas d'un IDE c'est difficile de trouver une solution universelle à part dans la frugalité si on veut rester dans le modulaire.
[^] # Re: VSCode vs vim vs Emacs
Posté par BAud (site web personnel) . Évalué à 2.
chaîne de dépendances ?
[^] # Re: VSCode vs vim vs Emacs
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 12 juin 2024 à 12:21.
Dépendances s'appliquent bien aux librairies tierce partie utilisées par le logiciel que tu développes, peut-être moins à l'outillage. Dans le cas d'un IDE par exemple, la même équipe peut avoir des développeurs utilisant vscode, vim, emacs et intellij sans que l'un ou l'autre en soit une dépendance forte.
[^] # Re: VSCode vs vim vs Emacs
Posté par cg . Évalué à 4.
Boh, il suffit de lire 3-4 docs de l'ANSSI et tu t'habitues :). Hier j'ai regardé une petite présentation dans laquelle l'orateur parlait de gigue réseau. Ça faisait plusieurs années que je n'avais pas entendu ce mot, ça m'a fait plaisir de le retrouver !
On est tellement habitué à lire (et écrire, parfois) des docs en anglais qu'on peut avoir l'impression qu'il n'y a pas d'équivalent assez précis en français, et que l'expression anglaise est plus subtile ou porteuse de sens, alors que souvent non. On peut se référer au québecois dans certains cas.
Il y en a un que je trouve pas évident, c'est "endpoint" qui désigne l'extrémité d'un réseau, dans le sens "un truc connecté au réseau pour communiquer sur ce réseau". Ça peut être un ordi, une montre, un pacemaker ou un sextoy…
# Dans le même esprit
Posté par cg . Évalué à 4.
Au niveau de ZSH avec l'extension oh-my-zsh, on peut exécuter du code en entrant dans un répertoire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.