Un autre "inconvénient", mais intrinsèquement lié à la sécurité de la Yubikey, c'est qu'il n'est pas possible d'en faire un backup, donc si l'objet physique est perdu ou détruit, on perd ses accès.
Il faut en être bien conscient et toujours prévoir une solution de secours. Typiquement, ça sera une autre Yubikey, stockée ailleurs, et/ou des codes de récupération imprimés et stockés en sécurité.
La cible concernant Polyfil est probablement aussi le marché Chinois, parce qu'en Chine, beaucoup d'ordinateurs ont de vieux navigateurs, à cause d'outils web qui ne fonctionnent que sur d'anciennes versions de navigateurs, comme IE 6.
Pas forcément, c'est pas nécessaire d'en avoir besoin pour l'avoir inclus dans son site. Il suffit d'utiliser un outil genre Wordpress, et d'ajouter un thème ou plugin qui inclus Polyfill pour être vulnérable. Ça concerne énormément de sites (j'ai vu passer le chiffre de 100k), même si la grosse majorité n'en a probablement jamais eu besoin.
Probablement pas pour activer la CVE-2024-3094, il faut avoir une clef particulière.
C'est pas la question.
Le fait est, aucun logiciel n'est infaillible, et si on a moyen d'ajouter un niveau de protection indépendant du logiciel de base, ça permet d'éviter d'être vulnérable si un jour la défense principale tombe.
Après, il faut aussi mettre dans la balance la complexité supplémentaire et la facilité d'utilisation, et décider en fonction. C'est une question de compromis.
Le port knocking, ça aurait protégé si la tentative de backdoor via liblzma avait réussi, ou en cas de 0-day sur openssh.
C’est une sécurité supplémentaire qui ne sert probablement à rien en temps normal, parce qu’il y a en effet des protections plus efficaces, mais quand ces protections ont une faille, c’est toujours mieux d’avoir autre chose pour limiter les dégâts.
Bref, faire de la défense en profondeur, avec plusieurs éléments indépendants.
/48 ? Oserai-je te demander lequel est-ce ? C'est pas un grand publique si ?
Non, effectivement, c'est un micro-FAI local géré par un pote, les FAIs grand public vont plutôt proposer des /56 pour les particuliers.
D'après mes calcules, le mien me confie un /63, ce qui est déjà bien suffisant pour mon utilisation.
Un /63, c'est vraiment pas beaucoup, ça te donne seulement 2 LANs, à moins de bidouiller pour utiliser des LANs plus petits que /64, mais c'est pas une bonne idée. D'ailleurs, si c'est ce que tu essayes de faire, ça expliquerait le fait que SLAAC ne marche pas, c'est prévu pour fonctionner sur un /64.
Si je comprend bien, tu n'utilise aucune adresse en fc00::/7 ou fe80::/10 (je comprend plus trop la différence pour le coups) et chacune des machines est joignable via mamachine.mondomaine.tld = IPv6 GUAs ? Donc si je fais un ping mamachine.mondomaine.tld ca passe ?
L'adresse fe80::/10, c'est du link-local, on en a besoin de toute façon. Par contre effectivement, pas de fc00::/7, j'ai uniquement des adresses 2001:…., globalement routables. Et oui, un ping monserveur.domaine.tld fonctionne depuis n'importe où.
Pour la sécurité, j'ai évidemment un firewall qui bloque tout par défaut, et je dois ouvrir explicitement chaque port que je veux exposer, c'est pas plus risqué que de l'IPv4 au final. Et seules les machines de ma DMZ ont des ports ouverts, avec le trafic dans le sens DMZ => LAN bloqué.
Pour la vie privée, je suis identifiable par mon préfixe (et par mon ip fixe en v4), donc voilà, ça sera limité dans tous les cas. Mes clients supportent tous les Privacy Extension de SLAAC (RFC 4941) et changent régulièrement leur IP sortante.
Un /56 suffit largement pour un usage personnel, ça permet d'avoir 256 LANs distincts, il faudrait vraiment avoir une utilisation bien spécifique pour utiliser plus que ça. Comme on dit, c'est pas la taille qui compte, c'est le fait que ça soit fixe.
OpenWRT, c'est très bien, très complet, flexible, activement développé, et surtout, c'est conçu pour tourner sur du matos router avec peu de ressources. À mon avis, tu gagnerais pas grand chose à essayer de monter ton propre truc à la main.
Niveau matos, j'utilise un Turris Omnia. Ils utilisent leur propre OS, mais c'est juste une surcouche d'OpenWRT. Le hardware est relativement puissant et bien fourni en RAM pour un routeur, ça me permet de faire tourner 2-3 services directement sur le routeur, dans des containers LXC.
J'ai la chance d'avoir un provider qui me délègue un préfixe fixe (un /48), donc ça me permet d'exploiter tout le potentiel d'IPv6 de façon simple. J'ai aussi une IPv4 fixe. Je dois (malheureusement) encore garder de l'ipv4 pour le matériel qui ne supporte pas un réseau IPv6-only, sinon je l'aurais complètement supprimé.
Du fait que mon préfixe est sur 48 bits, j'ai donc 65536 sous-réseaux (/64) disponibles. J'en utilise 4 : le LAN normal, une DMZ pour les services qui doivent être accessibles depuis internet, un réseau pour les invités et le dernier pour les adresses des clients VPN distants (Wireguard). Ça permet d'organiser les choses proprement et simplement.
Mon router utilise OpenWrt, l'IPv6 est parfaitement supporté, je n'ai eu aucun soucis à ce niveau.
Du fait que mon préfixe ne change jamais, je n'utilise pas d'ULA, uniquement des GUAs. Pour mes différents services (imprimante, NAS, BitTorrent, etc), j'assigne des IPs statiques et j'ai des entrées DNS publiques, y compris pour ce qui est uniquement à usage interne. Pas besoin de split-horizon DNS ou autre bricolage. Pour le reste, c'est du SLAAC, et ça roule. J'ai également demandé et obtenu de mon FAI une délégation pour gérer moi-même le reverse DNS sur mon préfixe.
Dans l'idée de pouvoir un jour complètement me passer d'IPv4, j'ai aussi mis en place du NAT64, aucun problème à signaler, ça fait le job.
Pour moi, le gros avantage de ma config, c'est que j'ai pas à jongler entre IP interne et externe, et gérer du mappage de port. Tout a une IP routable (et une entrée DNS publique), et ensuite, c'est juste du contrôle d'accès avec les règles du firewall. Pour quand je suis à l'extérieur, mon FAI mobile ne propose malheureusement pas d'IPv6, mais j'ai une config Wireguard qui me permet d'avoir quand même accès à tous mes services IPv6-only.
Par contre, ça marche bien parce que j'ai un préfixe qui ne change pas. Si ça n'était pas le cas, ça rendrait le truc beaucoup plus compliqué.
Sauter un bound check (vérification que i est entre 0 et t.len() quand on fait t[i]) dans une boucle appelée des millions de fois, quand on est sûr que l'indice est bien dans les bornes.
C'est très souvent faisable sans passer par unsafe.
Le compilateur va générer un bound check uniquement dans les cas où il ne peut pas déterminer à la compilation si l'accès risque d'être hors bornes. Si on ajoute une vérification explicite qui lui permet d'être sûr qu'aucun accès hors bornes n'est possible, il n'y aura pas de bound check.
Une autre façon est de modifier la boucle pour utiliser un itérateur, quand c'est possible.
Le point "Les entreprises participantes sont informées directement par la Poste (y c. date de validité = date du déménagement)" semble indiqué que ces entreprises sont informées au préalable. Comment est-ce que la Poste sait à qui communiqué l'info ? Je n'ai pas trouvé l'explication.
Tout à fait. Et le problème va encore être amplifié à mesure que les nouveaux modèles seront entrainés avec du texte généré par AI. On risque d'avoir un problème de dégénérescence progressive dû à une diminution de la qualité des sources.
Évidemment, il ne faudrait en théorie entrainer ces modèles qu'avec du texte écrit par des humains, mais en pratique, c'est très difficile à faire.
calibre et le plugin sont libres à 100%, mais il s'agit d'un plugin non-officiel, utilisation à tes risques. Je l'utilise depuis plusieurs pour pouvoir transférer les livres de ma bibliothèque sur ma liseuse Kobo, aucun problème à signaler.
Thorium est mixte. Le gros du lecteur est libre (BSD 3-clause), mais la partie qui gère le DRM est un blob non libre. À toi d'en tirer les conclusions que tu veux. Pour le code source, c'est par ici : https://github.com/edrlab/thorium-reader
Il y a eu un autre type de rendu intermédiaire qui n'est pas mentionné dans la dépêche, utilisé entre autres par Alone in the Dark (sorti en 1992). Ici, le personnage, les ennemis et les objets sur lesquels on peut agir sont en vraie 3D avec un rendu temps réel, et les décors sont précalculés (et donc gérés comme de simples images 2D), avec des positions de caméra fixes.
À l'époque, l'animation des personnages était une vraie révolution, avec des mouvements parfaitement fluides de modèles 3D.
Dire que c'est juste un jouet, c'est se méprendre complètement sur les buts du projet.
Wireguard ne cherche pas à être une solution clé en main pour du VPN d'entreprise. Le but est de fournir un protocole robuste et efficace, ainsi qu'une API pour permettre à des outils externes de fournir les fonctionnalités avancées. On trouve par exemple Tailscale, qui propose une solution complète avec toutes les fonctionnalités que tu mentionnes. Il y aussi pas mal de projets libres, avec différents niveaux d'avancement.
Bon courage pour prouver le moindre préjudice individuel de la disponibilité de ton numéro de tel associée à ton nom (plus ou moins réel) et seulement de ça.
Il n'y a pas que ça. Pour certains comptes, on a aussi le lieu de domicile, l'employeur et la date de naissance. En recoupant avec d'autres informations (publiques ou issues d'autres fuites), on commence à avoir de quoi monter une usurpation d'identité.
Un serveur derrière un NAT, c'est pas forcément limité aux particuliers, c'est aussi très courant sur de l'hébergement pro en datacenter, en particulier si on utilise une solution basée sur des containers style Kubernetes.
La vraie question, c'est pas pourquoi Mozilla et les autres décident de supprimer le support de FTP, c'est plutôt : pourquoi en 2021 ce protocole est-il encore utilisé ? Il aurait dû disparaitre il y a déjà au moins 20 ans…
Pour rappel, la première RFC pour ce protocole date de 1971, c'est encore plus vieux que TCP/IP ! Et contrairement à d'autres protocoles, il n'a pas fondamentalement évolué depuis.
Le problème fondamental est l'utilisation de deux connexions : une pour les commandes, une pour les données. Pour que ça fonctionne sans friction, il faut partir du principe que chaque machine connectée a une adresse IP publique et qu'il n'existe pas de firewall. Dès le moment où on introduit du NAT ou un firewall, il faut commencer à bricoler, et ça devient rapidement très laid. En gros, on ne peut faire du simple port forwarding comme pour 99% des protocoles existants, il faut que le firewall supporte explicitement FTP pour pouvoir modifier les paquets au vol et ouvrir des ports dynamiquement. Et pour que ça marche, il faut que le firewall puisse inspecter les paquets, donc si on veut du SSL, il faut que ça soit aussi géré par le firewall (je pense que c'est une des principales raisons qui font que FTPS n'a jamais vraiment décollé).
On a de nombreuses alternatives bien meilleures depuis au moins vingt ans. Le protocole aurait dû être considéré comme obsolète et commencer à disparaitre à ce moment-là. Et qu'en 2021, sa suppression dans un browser fasse débat me dépasse complètement…
Par rapport à Oracle : principalement le prix. Pour une grosse installation, le prix des licences Oracle est ridiculement élevé, typiquement un ordre de grandeur au-dessus de l'équivalent en SQL Server.
Par rapport à PostgreSQL : comme déjà mentionné, c'est le choix "naturel" quand on a déjà un environnement Microsoft ou qu'on développe en .Net, tous les outils sont conçus pour fonctionner ensemble et s'intègrent facilement. On a aussi un ensemble de fonctionnalités avancées disponibles en standard qui n'existent que sous forme d'outils externes pour PostgreSQL (au niveau de la réplication et haute disponibilité, par exemple, ou pour les données géographiques). Et pour les installations plus petites, il y a une version "Express", gratuite. Elle est évidemment très limitée (en particulier, il y a une limite sur la taille maximale de la db), mais ça reste suffisant dans beaucoup de cas.
Pour avoir travaillé sur SQL Server, je dois dire que c'est un plutôt bon produit, que ça soit niveau fonctionnalités, stabilité, performance ou facilité d'utilisation.
Je ne suis pas spécialiste en crypto et pour moi, OCB, c'est autre chose, mais quand on mentionne "mode d'opération authentifié", je pense immédiatement à GCM.
Est-ce que OCB a des avantages concrets et importants par rapport à GCM qui peuvent justifier de le préférer à ce dernier ? En faisant une recherche rapide, j'ai trouvé deux petites choses : plus simple à implémenter et un peu plus résistant à une réutilisation de nonce avec une même clé. Ça me semble assez faible comme arguments.
Mac OS 9 n'est pas un ancêtre de Mac OS X, même lointain. Si on voulait faire une métaphore familiale, ça serait plutôt un beau-frère ou un cousin par alliance.
Les deux systèmes n'ont rien en commun techniquement, leur lien de parenté est purement contractuel.
Il y a un très gros risque d'insérer des données pourries sans s'en rendre compte immédiatement, et c'est ensuite la misère à corriger.
Le CSV, c'est la fausse bonne idée par excellence, le truc qui a l'air simple mais qui ne l'est pas du tout dès qu'on tombe sur un cas non prévu initialement.
[^] # Re: Yubikey
Posté par Buf (Mastodon) . En réponse au journal ultimatum de github pour passer au 2FA. Évalué à 9.
Un autre "inconvénient", mais intrinsèquement lié à la sécurité de la Yubikey, c'est qu'il n'est pas possible d'en faire un backup, donc si l'objet physique est perdu ou détruit, on perd ses accès.
Il faut en être bien conscient et toujours prévoir une solution de secours. Typiquement, ça sera une autre Yubikey, stockée ailleurs, et/ou des codes de récupération imprimés et stockés en sécurité.
[^] # Re: Au sujet de l'obscurité
Posté par Buf (Mastodon) . En réponse au journal Les toqueurs ont la tactique . Évalué à 4.
C'est pas forcément cacher, mais ignorer jusqu'à ce que ça ait été exploité de façon catastrophique, ça compte ?
https://www.propublica.org/article/microsoft-solarwinds-golden-saml-data-breach-russian-hackers
[^] # Re: Même rengaine
Posté par Buf (Mastodon) . En réponse au journal polyfill.io est contaminé. Évalué à 7.
Pas forcément, c'est pas nécessaire d'en avoir besoin pour l'avoir inclus dans son site. Il suffit d'utiliser un outil genre Wordpress, et d'ajouter un thème ou plugin qui inclus Polyfill pour être vulnérable. Ça concerne énormément de sites (j'ai vu passer le chiffre de 100k), même si la grosse majorité n'en a probablement jamais eu besoin.
[^] # Re: Secret bien gardé
Posté par Buf (Mastodon) . En réponse au journal Les toqueurs ont la tactique . Évalué à 4.
C'est pas la question.
Le fait est, aucun logiciel n'est infaillible, et si on a moyen d'ajouter un niveau de protection indépendant du logiciel de base, ça permet d'éviter d'être vulnérable si un jour la défense principale tombe.
Après, il faut aussi mettre dans la balance la complexité supplémentaire et la facilité d'utilisation, et décider en fonction. C'est une question de compromis.
[^] # Re: Secret bien gardé
Posté par Buf (Mastodon) . En réponse au journal Les toqueurs ont la tactique . Évalué à 4.
Le port knocking, ça aurait protégé si la tentative de backdoor via liblzma avait réussi, ou en cas de 0-day sur openssh.
C’est une sécurité supplémentaire qui ne sert probablement à rien en temps normal, parce qu’il y a en effet des protections plus efficaces, mais quand ces protections ont une faille, c’est toujours mieux d’avoir autre chose pour limiter les dégâts.
Bref, faire de la défense en profondeur, avec plusieurs éléments indépendants.
[^] # Re: Mon expérience concernant IPv6 sur mon réseau local
Posté par Buf (Mastodon) . En réponse au journal Ma vie, mon œuvre, mon réseau local. Évalué à 3.
Non, effectivement, c'est un micro-FAI local géré par un pote, les FAIs grand public vont plutôt proposer des /56 pour les particuliers.
Un /63, c'est vraiment pas beaucoup, ça te donne seulement 2 LANs, à moins de bidouiller pour utiliser des LANs plus petits que /64, mais c'est pas une bonne idée. D'ailleurs, si c'est ce que tu essayes de faire, ça expliquerait le fait que SLAAC ne marche pas, c'est prévu pour fonctionner sur un /64.
L'adresse fe80::/10, c'est du link-local, on en a besoin de toute façon. Par contre effectivement, pas de fc00::/7, j'ai uniquement des adresses 2001:…., globalement routables. Et oui, un
ping monserveur.domaine.tldfonctionne depuis n'importe où.Pour la sécurité, j'ai évidemment un firewall qui bloque tout par défaut, et je dois ouvrir explicitement chaque port que je veux exposer, c'est pas plus risqué que de l'IPv4 au final. Et seules les machines de ma DMZ ont des ports ouverts, avec le trafic dans le sens DMZ => LAN bloqué.
Pour la vie privée, je suis identifiable par mon préfixe (et par mon ip fixe en v4), donc voilà, ça sera limité dans tous les cas. Mes clients supportent tous les Privacy Extension de SLAAC (RFC 4941) et changent régulièrement leur IP sortante.
[^] # Re: Mon expérience concernant IPv6 sur mon réseau local
Posté par Buf (Mastodon) . En réponse au journal Ma vie, mon œuvre, mon réseau local. Évalué à 8.
Un /56 suffit largement pour un usage personnel, ça permet d'avoir 256 LANs distincts, il faudrait vraiment avoir une utilisation bien spécifique pour utiliser plus que ça. Comme on dit, c'est pas la taille qui compte, c'est le fait que ça soit fixe.
OpenWRT, c'est très bien, très complet, flexible, activement développé, et surtout, c'est conçu pour tourner sur du matos router avec peu de ressources. À mon avis, tu gagnerais pas grand chose à essayer de monter ton propre truc à la main.
Niveau matos, j'utilise un Turris Omnia. Ils utilisent leur propre OS, mais c'est juste une surcouche d'OpenWRT. Le hardware est relativement puissant et bien fourni en RAM pour un routeur, ça me permet de faire tourner 2-3 services directement sur le routeur, dans des containers LXC.
# Mon expérience concernant IPv6 sur mon réseau local
Posté par Buf (Mastodon) . En réponse au journal Ma vie, mon œuvre, mon réseau local. Évalué à 7. Dernière modification le 10 juin 2024 à 09:54.
J'ai la chance d'avoir un provider qui me délègue un préfixe fixe (un /48), donc ça me permet d'exploiter tout le potentiel d'IPv6 de façon simple. J'ai aussi une IPv4 fixe. Je dois (malheureusement) encore garder de l'ipv4 pour le matériel qui ne supporte pas un réseau IPv6-only, sinon je l'aurais complètement supprimé.
Du fait que mon préfixe est sur 48 bits, j'ai donc 65536 sous-réseaux (/64) disponibles. J'en utilise 4 : le LAN normal, une DMZ pour les services qui doivent être accessibles depuis internet, un réseau pour les invités et le dernier pour les adresses des clients VPN distants (Wireguard). Ça permet d'organiser les choses proprement et simplement.
Mon router utilise OpenWrt, l'IPv6 est parfaitement supporté, je n'ai eu aucun soucis à ce niveau.
Du fait que mon préfixe ne change jamais, je n'utilise pas d'ULA, uniquement des GUAs. Pour mes différents services (imprimante, NAS, BitTorrent, etc), j'assigne des IPs statiques et j'ai des entrées DNS publiques, y compris pour ce qui est uniquement à usage interne. Pas besoin de split-horizon DNS ou autre bricolage. Pour le reste, c'est du SLAAC, et ça roule. J'ai également demandé et obtenu de mon FAI une délégation pour gérer moi-même le reverse DNS sur mon préfixe.
Dans l'idée de pouvoir un jour complètement me passer d'IPv4, j'ai aussi mis en place du NAT64, aucun problème à signaler, ça fait le job.
Pour moi, le gros avantage de ma config, c'est que j'ai pas à jongler entre IP interne et externe, et gérer du mappage de port. Tout a une IP routable (et une entrée DNS publique), et ensuite, c'est juste du contrôle d'accès avec les règles du firewall. Pour quand je suis à l'extérieur, mon FAI mobile ne propose malheureusement pas d'IPv6, mais j'ai une config Wireguard qui me permet d'avoir quand même accès à tous mes services IPv6-only.
Par contre, ça marche bien parce que j'ai un préfixe qui ne change pas. Si ça n'était pas le cas, ça rendrait le truc beaucoup plus compliqué.
[^] # Re: Gestion mémoire etc.
Posté par Buf (Mastodon) . En réponse au journal PullRequest d'une application en Rust. Évalué à 3.
À propos de
unsafe, quand tu dis :C'est très souvent faisable sans passer par
unsafe.Le compilateur va générer un bound check uniquement dans les cas où il ne peut pas déterminer à la compilation si l'accès risque d'être hors bornes. Si on ajoute une vérification explicite qui lui permet d'être sûr qu'aucun accès hors bornes n'est possible, il n'y aura pas de bound check.
Une autre façon est de modifier la boucle pour utiliser un itérateur, quand c'est possible.
[^] # Re: Ben oui mais en fait non
Posté par Buf (Mastodon) . En réponse au journal Où il est question de données personnelles (bis). Évalué à 3.
Ça semble un peu plus compliqué que ça. Voici la page qui décrit la prestation : https://www.post.ch/fr/reception/demenagement/annonce-de-demenagement
Le point "Les entreprises participantes sont informées directement par la Poste (y c. date de validité = date du déménagement)" semble indiqué que ces entreprises sont informées au préalable. Comment est-ce que la Poste sait à qui communiqué l'info ? Je n'ai pas trouvé l'explication.
[^] # Re: L'encrassement des sources de l'apprentissage de l'IA ?
Posté par Buf (Mastodon) . En réponse au journal Les dangers des traductions et résumés automatiques par IA : un exemple. Évalué à 2.
Tout à fait. Et le problème va encore être amplifié à mesure que les nouveaux modèles seront entrainés avec du texte généré par AI. On risque d'avoir un problème de dégénérescence progressive dû à une diminution de la qualité des sources.
Évidemment, il ne faudrait en théorie entrainer ces modèles qu'avec du texte écrit par des humains, mais en pratique, c'est très difficile à faire.
[^] # Re: Calibre
Posté par Buf (Mastodon) . En réponse au journal Les DRM, ma liseuse et moi, le retour. Évalué à 5.
calibre et le plugin sont libres à 100%, mais il s'agit d'un plugin non-officiel, utilisation à tes risques. Je l'utilise depuis plusieurs pour pouvoir transférer les livres de ma bibliothèque sur ma liseuse Kobo, aucun problème à signaler.
Thorium est mixte. Le gros du lecteur est libre (BSD 3-clause), mais la partie qui gère le DRM est un blob non libre. À toi d'en tirer les conclusions que tu veux. Pour le code source, c'est par ici : https://github.com/edrlab/thorium-reader
# Alone in the Dark
Posté par Buf (Mastodon) . En réponse à la dépêche Le rendu 3D, rétrospective. Évalué à 8.
Il y a eu un autre type de rendu intermédiaire qui n'est pas mentionné dans la dépêche, utilisé entre autres par Alone in the Dark (sorti en 1992). Ici, le personnage, les ennemis et les objets sur lesquels on peut agir sont en vraie 3D avec un rendu temps réel, et les décors sont précalculés (et donc gérés comme de simples images 2D), avec des positions de caméra fixes.
À l'époque, l'animation des personnages était une vraie révolution, avec des mouvements parfaitement fluides de modèles 3D.
[^] # Re: Simple comme...
Posté par Buf (Mastodon) . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à 6.
Dire que c'est juste un jouet, c'est se méprendre complètement sur les buts du projet.
Wireguard ne cherche pas à être une solution clé en main pour du VPN d'entreprise. Le but est de fournir un protocole robuste et efficace, ainsi qu'une API pour permettre à des outils externes de fournir les fonctionnalités avancées. On trouve par exemple Tailscale, qui propose une solution complète avec toutes les fonctionnalités que tu mentionnes. Il y aussi pas mal de projets libres, avec différents niveaux d'avancement.
[^] # Re: Un passage qui règle le problème énergétique mais pas plus ?
Posté par Buf (Mastodon) . En réponse au journal Ethereum prépare son passage de Proof of Work à Proof of Stake. Évalué à 4.
Un autre article intéressant sur le sujet, qui arrive en gros à la même conclusion : https://davidgerard.co.uk/blockchain/2022/08/20/proof-of-stake-is-better-than-proof-of-work-but-ethereums-merge-wont-fix-any-other-problem-with-cryptocurrency/
[^] # Re: Pénible
Posté par Buf (Mastodon) . En réponse au journal La goutte. Évalué à 4.
Ah non, Pluto, c'est le chien de Mickey. L'ami de Mickey, c'est Dingo.
[^] # Re: Pas fuité et quelques mois dans la même phrase, et notion de préjudice
Posté par Buf (Mastodon) . En réponse au journal Rejoignez la plainte groupée contre Facebook. Évalué à 6.
Il n'y a pas que ça. Pour certains comptes, on a aussi le lieu de domicile, l'employeur et la date de naissance. En recoupant avec d'autres informations (publiques ou issues d'autres fuites), on commence à avoir de quoi monter une usurpation d'identité.
[^] # Re: FTP aurait dû disparaitre il y a déjà bien longtemps...
Posté par Buf (Mastodon) . En réponse au journal Firefox met fin au FTP. Évalué à 4.
Un serveur derrière un NAT, c'est pas forcément limité aux particuliers, c'est aussi très courant sur de l'hébergement pro en datacenter, en particulier si on utilise une solution basée sur des containers style Kubernetes.
[^] # Re: FTP aurait dû disparaitre il y a déjà bien longtemps...
Posté par Buf (Mastodon) . En réponse au journal Firefox met fin au FTP. Évalué à 5.
Le serveur peut également être derrière du NAT, et là, le mode passif n’aide en rien.
# FTP aurait dû disparaitre il y a déjà bien longtemps...
Posté par Buf (Mastodon) . En réponse au journal Firefox met fin au FTP. Évalué à 10.
La vraie question, c'est pas pourquoi Mozilla et les autres décident de supprimer le support de FTP, c'est plutôt : pourquoi en 2021 ce protocole est-il encore utilisé ? Il aurait dû disparaitre il y a déjà au moins 20 ans…
Pour rappel, la première RFC pour ce protocole date de 1971, c'est encore plus vieux que TCP/IP ! Et contrairement à d'autres protocoles, il n'a pas fondamentalement évolué depuis.
Le problème fondamental est l'utilisation de deux connexions : une pour les commandes, une pour les données. Pour que ça fonctionne sans friction, il faut partir du principe que chaque machine connectée a une adresse IP publique et qu'il n'existe pas de firewall. Dès le moment où on introduit du NAT ou un firewall, il faut commencer à bricoler, et ça devient rapidement très laid. En gros, on ne peut faire du simple port forwarding comme pour 99% des protocoles existants, il faut que le firewall supporte explicitement FTP pour pouvoir modifier les paquets au vol et ouvrir des ports dynamiquement. Et pour que ça marche, il faut que le firewall puisse inspecter les paquets, donc si on veut du SSL, il faut que ça soit aussi géré par le firewall (je pense que c'est une des principales raisons qui font que FTPS n'a jamais vraiment décollé).
On a de nombreuses alternatives bien meilleures depuis au moins vingt ans. Le protocole aurait dû être considéré comme obsolète et commencer à disparaitre à ce moment-là. Et qu'en 2021, sa suppression dans un browser fasse débat me dépasse complètement…
[^] # Re: pourquoi SQL server
Posté par Buf (Mastodon) . En réponse au journal SQL Server sous Linux : enjeux de sécurité. Évalué à 3.
Par rapport à Oracle : principalement le prix. Pour une grosse installation, le prix des licences Oracle est ridiculement élevé, typiquement un ordre de grandeur au-dessus de l'équivalent en SQL Server.
Par rapport à PostgreSQL : comme déjà mentionné, c'est le choix "naturel" quand on a déjà un environnement Microsoft ou qu'on développe en .Net, tous les outils sont conçus pour fonctionner ensemble et s'intègrent facilement. On a aussi un ensemble de fonctionnalités avancées disponibles en standard qui n'existent que sous forme d'outils externes pour PostgreSQL (au niveau de la réplication et haute disponibilité, par exemple, ou pour les données géographiques). Et pour les installations plus petites, il y a une version "Express", gratuite. Elle est évidemment très limitée (en particulier, il y a une limite sur la taille maximale de la db), mais ça reste suffisant dans beaucoup de cas.
Pour avoir travaillé sur SQL Server, je dois dire que c'est un plutôt bon produit, que ça soit niveau fonctionnalités, stabilité, performance ou facilité d'utilisation.
# Par rapport à GCM?
Posté par Buf (Mastodon) . En réponse au journal OCB serait-il toujours protégé par des brevets ?. Évalué à 5.
Je ne suis pas spécialiste en crypto et pour moi, OCB, c'est autre chose, mais quand on mentionne "mode d'opération authentifié", je pense immédiatement à GCM.
Est-ce que OCB a des avantages concrets et importants par rapport à GCM qui peuvent justifier de le préférer à ce dernier ? En faisant une recherche rapide, j'ai trouvé deux petites choses : plus simple à implémenter et un peu plus résistant à une réutilisation de nonce avec une même clé. Ça me semble assez faible comme arguments.
[^] # Re: Pertinence ?
Posté par Buf (Mastodon) . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 10.
Mac OS 9 n'est pas un ancêtre de Mac OS X, même lointain. Si on voulait faire une métaphore familiale, ça serait plutôt un beau-frère ou un cousin par alliance.
Les deux systèmes n'ont rien en commun techniquement, leur lien de parenté est purement contractuel.
[^] # Re: [HS] et comment héberges-tu tes mails ?
Posté par Buf (Mastodon) . En réponse au journal Les adresses mail personnelles et les comptes en lignes. Évalué à 2.
Pour moi, c'est un VPS chez Gandi, avec Exim pour la partie SMTP et Dovecot pour l'IMAP.
[^] # Re: Il est où le problème dans le CSV ?
Posté par Buf (Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 4.
Il y a un très gros risque d'insérer des données pourries sans s'en rendre compte immédiatement, et c'est ensuite la misère à corriger.
Le CSV, c'est la fausse bonne idée par excellence, le truc qui a l'air simple mais qui ne l'est pas du tout dès qu'on tombe sur un cas non prévu initialement.