Je valide complètement l’argument de la compatibilité. Pour autant je prends comme exemple Debian Buster, il y a des liens symboliques de /bin et /sbin vers /usr/bin et /usr/sbin, à terme /bin et /sbin disparaîtront. Preuve qu’on peut modifier des choses (en laissant le temps) et qu’il est évidemment nécessaire de le faire.
Cet article prend effectivement sa source dans un cas d’entreprise de moyenne taille.
Sur des projets d’informatique de gestion ou d’informatique décisionnelle il est courant que plusieurs acteurs interviennent et qu’une mauvaise décision sécuritaire soit tolérée en raison des avantages fonctionnels et business qu’elle procure. De plus la communication entre pairs est parfois mal vécue car personne n’aime qu’on lui explique ce qu’il doit faire.
Quels seraient les cas où ça pourrait arriver ? Je veux dire dans le cadre d’une entreprise.
Y’en a encore qui mettent leur serveur de BDD sur une IP publique ?
Sur des petits projets, c’est tout sur le même serveur donc pas exposé, sur des projets plus gros, y’a forcément de quoi faire une infra un minimum réfléchie non ?
Je connais pas du tout Common Lisp (je ne suis pas développeur)
Ça à l’air intéressant, si jamais tu as des ressources qui vont dans le sens de Common Lisp et de la longévité (projet, manifeste…) hésite pas, ça m’intéresse !
En la communauté du Common Lisp, les choses sont vraiment à l’inverse; des logiciels développés y a 10 ou 20 ans sont toujours couramment utilisés. Là on peut trouver des bibliothèques qui sont “finies”, je trouve que ça change vraiment d’air comparé à l’état qu’on voit dans les autres communautés de langue.
Tout à fait. Je l’ai honnêtement zappé lors de la rédaction et je me demande si ce n’est pas une réaction d’autodéfense de mon cerveau. À dire vrai, j’ai rédigé cet article et l’ai à peine relu (il est truffé de coquilles) : ça m’a
permit de canaliser la tempête dans mon cerveau et de réfléchir façon canard en plastique, au lieu de m’agiter ou désespérer.
Merci pour l’article, je ne connaissais pas GrapheneOS.
Dans tous les cas, la sécurité sur le mobile est une vaste blague. Toute personne avec un minimum de bagage sécurité sait que cet outil n’est pas sécurisée à la hauteur de ce qu’il devrait être pour héberger des mots de passe ou accéder à des services sensibles (banque).
Personnellement je ne m’en sers que pour les services de bases (messagerie, appel, internet sur des sites d’actualités, calendrier) et rien de plus. Et pourtant j’ai un Lineage d’installé à jour avec chiffrement du disque mais cela ne suffit pas selon moi.
Je suis d’accord avec l’auteur concernant l’IPHONE, c’est cher mais au moins tu as un produit de qualité avec un véritable suivi au niveau de la sécurité. Très peu d’autres constructeur peuvent se vanter de la même chose.
S’il y a eu un accès distant, les frappes du clavier ou la visualisation de l’écran ont peut-être été enregistrées. Donc le mot de passe du trousseau de clés Firefox a pu être compromis, ainsi que le chiffrement GPG (clé privée récupérée et phrase de passe aussi). Il vaut mieux révoquer et changer tout cela. Il vaut mieux aussi repartir d’un nouveau système d’exploitation installé à neuf.
C’est en partie un positionnement juste, mais en partie le témoin d’une situation hautement problématique je pense.
Pour faire une analogie, qui aurait l’idée de dire qu’il faut systématiquement conteneuriser Debian au motif qu’il n’en n’a pas audité le code ? Et sur quoi ? Parce que rapidement il va y avoir un pb de récursivité. (hurd?)
J’ajouterai un autre exemple dans le même esprit:
apt update
Sous debian (ailleurs je sais pas) quand il y a des mises à jour, ça affiche un message disant de faire
apt —list-updates
pour les voir (ou un truc de genre, je suis sur mon téléphone).
Ne serait-ce pas plus malin de poser la question pour éviter d’avoir à taper la commande ?
Mais, pareil, y’a des chances que ça fasse planter des scripts. Mais quelle purge…
Salute,
Je valide complètement l’argument de la compatibilité. Pour autant je prends comme exemple Debian Buster, il y a des liens symboliques de /bin et /sbin vers /usr/bin et /usr/sbin, à terme /bin et /sbin disparaîtront. Preuve qu’on peut modifier des choses (en laissant le temps) et qu’il est évidemment nécessaire de le faire.
Tcho !
Et c’est sans compter sur les DB accessibles de l’extérieur et non protégées (ou avec les identifiants par défaut).
je t’informe : ça arrive tout le temps.
Ouais les contraintes de la prod, on fait des trucs moches pas par plaisir mais parce qu’on nous demande de le faire.
Tcho !
Cet article prend effectivement sa source dans un cas d’entreprise de moyenne taille. Sur des projets d’informatique de gestion ou d’informatique décisionnelle il est courant que plusieurs acteurs interviennent et qu’une mauvaise décision sécuritaire soit tolérée en raison des avantages fonctionnels et business qu’elle procure. De plus la communication entre pairs est parfois mal vécue car personne n’aime qu’on lui explique ce qu’il doit faire.
Quels seraient les cas où ça pourrait arriver ? Je veux dire dans le cadre d’une entreprise.
Y’en a encore qui mettent leur serveur de BDD sur une IP publique ?
Sur des petits projets, c’est tout sur le même serveur donc pas exposé, sur des projets plus gros, y’a forcément de quoi faire une infra un minimum réfléchie non ?
Je connais pas du tout Common Lisp (je ne suis pas développeur)
Ça à l’air intéressant, si jamais tu as des ressources qui vont dans le sens de Common Lisp et de la longévité (projet, manifeste…) hésite pas, ça m’intéresse !
Merci pour le partage. J’ai vraiment un problème de son : celui-ci part vers un son métallique puis revient !
En la communauté du Common Lisp, les choses sont vraiment à l’inverse; des logiciels développés y a 10 ou 20 ans sont toujours couramment utilisés. Là on peut trouver des bibliothèques qui sont “finies”, je trouve que ça change vraiment d’air comparé à l’état qu’on voit dans les autres communautés de langue.
Tout à fait. Je l’ai honnêtement zappé lors de la rédaction et je me demande si ce n’est pas une réaction d’autodéfense de mon cerveau. À dire vrai, j’ai rédigé cet article et l’ai à peine relu (il est truffé de coquilles) : ça m’a permit de canaliser la tempête dans mon cerveau et de réfléchir façon canard en plastique, au lieu de m’agiter ou désespérer.
Donc des ad blockers, un pi-hole, et, en fait, pas aller sur le site du monde c’est bien aussi.
Oui, ça aurait été amusant mais j’ai déjà galéré à trouver les RGB… Merci pour ton commentaire :-)
Merci pour l’article, je ne connaissais pas GrapheneOS.
Dans tous les cas, la sécurité sur le mobile est une vaste blague. Toute personne avec un minimum de bagage sécurité sait que cet outil n’est pas sécurisée à la hauteur de ce qu’il devrait être pour héberger des mots de passe ou accéder à des services sensibles (banque).
Personnellement je ne m’en sers que pour les services de bases (messagerie, appel, internet sur des sites d’actualités, calendrier) et rien de plus. Et pourtant j’ai un Lineage d’installé à jour avec chiffrement du disque mais cela ne suffit pas selon moi.
Je suis d’accord avec l’auteur concernant l’IPHONE, c’est cher mais au moins tu as un produit de qualité avec un véritable suivi au niveau de la sécurité. Très peu d’autres constructeur peuvent se vanter de la même chose.
Étonnant qu’il n’y ait pas de rainbow hat surtout qu’il s’agit de penetration :D Article très intéressant!
S’il y a eu un accès distant, les frappes du clavier ou la visualisation de l’écran ont peut-être été enregistrées. Donc le mot de passe du trousseau de clés Firefox a pu être compromis, ainsi que le chiffrement GPG (clé privée récupérée et phrase de passe aussi). Il vaut mieux révoquer et changer tout cela. Il vaut mieux aussi repartir d’un nouveau système d’exploitation installé à neuf.
FreezeGun est pratique pour faire ça.
En tout cas apt install python-request au 31 juillet 2020 n’aurait produit pas le même résultat.
J’ai pris le temps d’ouvrir un thread ici si ça vous intéresse : https://discuss.python.org/t/improving-risks-and-consequences-against-pytosquatting-on-pypi/5090
C’est en partie un positionnement juste, mais en partie le témoin d’une situation hautement problématique je pense.
Pour faire une analogie, qui aurait l’idée de dire qu’il faut systématiquement conteneuriser Debian au motif qu’il n’en n’a pas audité le code ? Et sur quoi ? Parce que rapidement il va y avoir un pb de récursivité. (hurd?)