Pour l'animation vectorielle, je te conseille pas Synfig, mais plutôt glaxnimate qui est excellent et produit des animations très légères (comparé à Synfig). L'interface est très proche d'Inkscape, ce qui est un vrai plus.
Liste des erreurs:
1. Payload dans MQTT non typé (et pas forcément JSON)
2. Authentification forte: à partir de MQTTv5 pour une version non basée sur utilisateur/mot de passe
3. AMQP n'est pas similaire à MQTT. C'est un protocole de messagerie, et pas de transfert de paquets avec résilience
4. Les versions MQTT sont rétrocompatibles car la session est taggué par la version du protocole utilisé, ce qui veut dire qu'un broker MQTTv5 peut dialoguer avec un client MQTT v3.1.1. Après, un client MQTTv5 ne peut qu'implémenter MQTTv5 et pas MQTTv3.1.1 (principalement pour des raisons de ressources, pas de difficultés particulières pour supporter une version précédente). Les brokers MQTTv3.1.1 uniquement sont de plus en plus rares et difficilement gérable pour une flotte IoT.
5. MQTT est n'est pas un service de messagerie (car il ne stocke pas les messages, tout au plus le dernier). C'est un service de transfert de paquets avec résilience (c'est à dire avec des garanties sur la livraison d'un paquet et ou d'un état d'un système).
Une des avancées majeure de MQTTv5 c'est la possibilité ajouter des propriétés aux paquets. Dans ces propriétés, on trouve la possibilité de déclarer la taille maximale d'un paquet que le client déclare supporter (contrairement à MQTT v3.1.1 qui autorisait un paquet de 250Mo à transiter), mais également les méthodes d'authentifications supportés (type négociation SSH), le type des données transmises, etc…
Pour envoyer une image, il suffit simplement de définir le payload sur les octets de l'image encodée. Soit tu décides que le topic/sujet sur lequel tu envois ces paquets est associé à un type MIME et dans ce cas, c'est fini, soit tu autorises différents type et dans ce cas, tu ajoutes une propriété Content Type avec le type MIME (de telle façon à ce que le client puisse décoder le flux).
En C++ récent, le code devient très vite cryptique, d'autant plus qu'il faut contourner les interprétation fallacieuse du standard par les différents compilateurs.
Pour cela, il y a cppinsights.io qui explique comment un meta programme est interprété (compris) par le compilateur.
Cela permet d'écrire du code template plus robuste, plus complet et plus lisible parfois.
Le payload MQTT est complètement libre, ce n'est pas forcément du JSON. Tu peux y mettre du binaire (pour l'OTA ou pas) ou ce que tu veux. Tu n'es pas du tout obligé d'encoder en base64 des images pour les transmettre.
MQTT existe en différentes version, la 3.1 et la 5 sont actuellement les plus utilisées. La version 5 permet des authentification forte (c'est à dire type Diffie Helman, sans le fâcheux username/password qui doit être stocké en dur dans le client, donc hackable facilement). Il gère également les propriétés sur chaque packet, ce qui permet de réaliser beaucoup plus de chose que la version 3.
Pour les clients MQTT, je te recommande eMQTT5 qui est un client MQTTv5 en C++ pour l'embarqué, type ESP32, (mais fonctionnant également sur Linux / OSX / Windows) et très léger (moins de 80kB sur x86, et 17kB sur Xtensa).
Il possède également un parseur de packet MQTT ce qui est très pratique pour déboguer une communication qui échoue.
De plus à la différence des autres protocoles, MQTT impose au broker de stocker l'état d'un client et d'éxécuter ses dernières volontés en cas de déconnexion, ce qui est super pratique pour l'IoT (qui peut ainsi s'assurer d'avoir un status "connecté/déconnecté" fiable) et permet aussi de récupérer sa session lors d'un connexion ultérieure (pratique pour le roaming, ip changeante, etc…)
Aucun des autres protocoles ne permet ceci (ou alors, c'est en plus, non standard).
Le fonctionnement sur Hellobank / BNP est identique, voire moins sécurisé, vu qu'ils demandent le mot de passe du compte avant d'envoyer le SMS (il n'y a pas de petites économies, hein?)
Ce qui me rends dingue, c'est qu'il n'y a pas de moyen d'éviter cette daube.
Comment un informaticien peut coder ça, sérieux ?
Une simple capture du HTML + CSS et c'est le paradis du phishing.
1. Tu proposes un site bidon avec de la vente de produit pas moins cher que d'habitude.
2. Puis tu demandes de payer avec ta CB. Avec les 4 premiers numéro de la CB, tu identifies que la CB provient du réseau BNP.
3. Tu balances une fausse iframe avec les bons logos et autre DOM/CSS que tu as capturé, et une iframe (inaccessible, dans la marge) sur le site d'Hellobank/BNP pour capturer les formulaires enregistrés (l'identifiant du compte n'est pas codé, il est en clair).
4. L'utilisateur va entrer son mot de passe de connexion. Avec l'identifiant capturé dans l'iframe plus le mot de passe de l'utilisateur, tu te loggues sur Hellobank.
5. Hellobank/BNP va détecter que ce n'est pas la même origine que d'habitude et va donc t'envoyer un SMS avec un code de connexion.
6. Tu demandes à l'utilisateur sur le deuxième page de l'iframe le code reçu.
7. L'utilisateur va entrer le code, forcément (même si le montant de l'achat n'est pas spécifié, car quoi, lui ne sait pas comment doit être le SMS).
8. Voilà, tu peux donc accéder au compte de l'utilisateur. Lui pomper ces données et ses sous.
9. Si tu veux pousser le vice encore plus, tu envoies un pseudo message d'erreur à l'utilisateur dans la troisième page de l'iframe, avec un bouton pour qu'il demande le renvoi du code reçu. (Forcément, aucune banque n'accepte de retaper un code, c'est supposé être du one-shot)
10. L'utilisateur va très probablement cliquer sur le bouton. Parallèlement tu procèdes à un vrai achat pendant ce temps, vu que tu as tout ce qu'il te faut (mot de passe + code SMS entré par l'utilisateur, cette fois pour le "vrai" achat).
11. Voilà, l'utilisateur va recevoir un mail légitime de la banque lui indiquant qu'il a dépensé X€ chez machin chose.
Toi, t'as gagné un accès direct sur son compte pour 3 mois.
C'est franchement donner le bâton pour se faire battre à ce niveau.
Disons que Docker et les interfaces réseau, c'est un peu deux ennemis jurés. Dès que tu sors des 2 modes dans la doc (nat et proxy), t'es mort. Cloonix, c'est un peu plus fluide pour ça, à ce que j'ai compris (pas testé donc).
Aussi, docker propose bien plus que ce que Cloonix propose, notamment avec ses dépôts d'images. Le corolaire, c'est que le moindre conteneur est souvent énorme, vu que la majorité des utilisateurs se prennent pas la tête à le configurer au minimum de ce qu'il faut et démarre d'un Ubuntu ou un Alpine. Avec Cloonix, vu que c'est à la mano, je pense que tu ne mets rien en plus que nécessaire.
Auriez vous un exemple où un algorithme a été cassé du jour au lendemain avec un retour à 0 de la sécurité de l'algorithme ?
Pour moi, et je me trompe probablement, lorsqu'une faille est découverte, la sécurité diminue, mais ne passe pas à 0 d'un coup. Par exemple, le SHA1 qui a été "forgé/dupliqué" une première fois par Google en 6 mois de calcul et qui est maintenant attaquable en 2 mois sur des fermes de serveurs. Ce n'est pas top, c'est sûr, mais ce n'est pas comme si un principe mathématique nouveau rendait le hash réversible.
Ce qui laisse du temps au développeurs de changer leur fusil d'épaule.
AMHA, l'agilité cryptographique c'est important, mais seulement sur un set très limité d'algorithme et qui reste limité (genre 3 algos possibles, si un devient moins fiable, on le "deprecate" en le remplaçant par un autre et qui ne peut être utilisé que pour le décodage).
Posté par xryl669 .
En réponse à la dépêche Débuter avec SolveSpace.
Évalué à 4.
Dernière modification le 15 septembre 2021 à 10:34.
FreeCAD a fait d'énormes progrès concernant sa stabilité (mais c'est pas encore 100% parfait). J'arrive à modéliser des pièces vraiment complexes sans qu'il ne crashe ou me jette sur une fonction qu'il n'arrive pas à appliquer (ce qui n'était pas le cas avec la version 0.19).
Il est pas encore au niveau d'un Solidworks, mais il est très proche d'un OnShape.
Bientôt il devrait y avoir la correction du bug le plus pénible à mon sens: le topological naming issue qui est en passe d'être résolu.
C'est fondamental pour pouvoir vraiment parler de modéliseur paramétrique. Ainsi, si tu changes une variable sur une fonction en bas du stack (par exemple, la longueur d'un segment, ou le rayon d'un cercle), il ne casse plus toutes les fonctions suivantes.
Quand à la logique d'utilisation, c'est pareil pour tous les logiciels, il faut apprendre, puis après ça devient intuitif.
Solvespace est assez intuitif, il a des fonctions en plus que FreeCAD dans son sketcheur (notamment la possibilité d'appliquer une rotation multiplicative sur n'importe quel segment/curve) mais je me suis souvent retrouvé bloqué par le manque de fonctions "haut niveau".
En réalité, la seule énergie fondamentale provient de la seule force que nous ne comprenons pas complètement: la gravité
En effet, c'est uniquement que sous l'effet de la gravité que les conditions de pression (et donc de température) permettent la fusion nucléaire dans le soleil.
Le fait que le rayonnement électromagnétique du soleil nous parvienne et qu'il suffise à générer suffisamment d'énergie pour tous nos besoins n'est qu'une sorte d'anomalie, de résidu de la réaction de fusion. Nous pouvons tous vivre que parce que la réaction nucléaire de fusion n'est pas parfaite. On a une sacrée chance!
Si la masse du Soleil était encore plus grande, elle capturerait ses propres photons et nous n'aurions plus rien à voir/recevoir.
C'est également la gravité qui permet l'autre source d'énergie renouvelable non lumineuse: les marées. Pour ce faire, la Lune cède une partie de son énergie potentielle (colossale, il est vraie) à chaque marée, ce qui l'éloigne de la Terre un peu chaque jour.
La fission, les "énergies fossiles", la fusion, ne sont pas renouvelable. Seule la gravité (qui n'est pas une force, mais une déformation de l'espace, d'après la théorie de la relativité) est renouvelable.
Il existe, en gros, 3 moteurs de CSG en open source actuellement. OpenCascade (OCCT) utilisé dans FreeCAD, OpenSCAD (qui est plus une sorte de POVRay du CAD) et Solvespace.
Du point de vue fonctionnalités, OCCT est plus utilisé car il a de nombreux outils/plugins (import/export, résolution des shells en solid, support du STEP214 en natif, etc…), mais ses limitations sont aussi son point faible, par exemple, il ne sait pas calculer l'intersection d'une surface NURBS avec une autre, ou supporter des contraintes géométriques sur des NURBS.
À noter que ce genre de calcul est extrêmement difficile (à leur décharge) car le nombre de cas particulier est très important. Il est possible que ça s'améliore dans le futur cependant.
Solvespace est utilise, quand à lui, son propre moteur CSG qui est vraiment très rapide et puissant. Il n'utilise pas des NURBS et au contraire, garde la représentation des surfaces sous forme polynomiale. Lorsque la résolution des contraintes n'est pas possible avec des solutions analytiques, il se défausse sur des solutions par approximations (comme Parasolid). Ce qui signifie que le résultat des fonctions présenté est très souvent le meilleur possible, mais que le nombre et type des fonctions est limité (par exemple, pas d'extrusion suivant une interpolation de profils, ou de sweep paramétrique etc…)
Enfin, il reste OpenSCAD. Honnêtement, je ne le connais pas bien, et la manière de modéliser dans OpenSCAD reste trop différente de ma manière de voir les pièces en 3D par fonctions successives.
C'est faux. KDE Connect utilise un protocole IP. C'est tout.
Le support bluetooth natif n'a, à ma connaissance, jamais fonctionné (et sans intérêt AMHA) donc pas vraiment développé ni supporté. Je l'ai compilé au début avant de me rendre compte qu'il ne servait à rien. Donc la version officielle fonctionne parfaitement.
Par contre, vu que c'est de l'IP et qu'il y a, par défaut le support de PAN (IP sur Bluetooth) dans Linux et sur les smartphones (Android sûr, iOS je ne sais pas), faire fonctionner KDE Connect est un jeu d'enfant. Tu actives la couche IP, partage via Bluetooth sur le smartphone (donc pas besoin de changer l'AP WIFI ou autre), et tu t'y connectes avec ton Linux, c'est fait.
Il y a même un tutoriel plus haut avec des screenshots.
Non, avec KDE Connect tu peux utiliser du bluetooth aussi, c'est pas très compliqué, c'est même expliqué ici. KDE Connect, c'est un peu une tuerie en comparaison. Il te permet de passer les fichiers, le presse papier, d'utiliser le téléphone comme un touchpad remote, d'utiliser le clavier de ton PC sous Android, et j'en passe.
Honnêtement, du point de vue utilisateur lambda, c'est la meilleure alternative OS pour smartphone.
Simplement… ça marche. Pas de complexité, pas besoin d'être un XDA addict pour l'installer, on suit l'installeur fourni, on clique là et là, on appuie sur les 2 boutons demandés et zou, c'est installé.
Ensuite, l'environnement, c'est du Ubuntu. C'est un peu fisher price, mais ça fonctionne.
Le gestionnaire de fichier est assez limité par rapport à l'excellent MiXplorer sur Android (notamment pour les connections réseaux, type SMB/CIFS ou SFTP) mais bon, rien n'empêche de lancer un terminal et de faire un sshfs (à part pour Mme Michu).
Les applications fonctionnent globalement bien. Et puis le fait qu'il n'y ait pas 150 000 applications pour la calculatrice ou la lampe torche dans le store, c'est vraiment bien.
En Golang, la classe IP est par défaut en IPv6, il faut instancier la classe IPv4 pour avoir du IPv4, donc c'est normal que la recherche pour IPv6 ne retourne rien.
C'est exactement le contraire dans mon cas. Libreoffice est plus que nul pour supporter du OOXML, dès qu'il y a un schéma, une table, des colonnes, du suivi des modifications, etc.. (tout ce qui fait la "force" de word), il foire et en plus, il casse le fichier. Impossible d'avoir une ancre qui fonctionne au passage Word => LO => Word (et ça, c'est le cas depuis au moins 10 ans, le bug rapporté étant classé en "pas le même modèle de document donc irréalisable")
OO en revanche supporte toutes ces fonctions (même s'il n'a pas encore d'interface graphique pour éditer cela) et ne casse pas le document. Bref, si on m'envoie un docx je peux l'ouvrir, le lire, le modifier (mais pas tout… pour l'instant) et le renvoyer sans que mon correspondant ne sache quel logiciel j'ai utilisé.
Si je fais la même opération avec LO, le document est cassé, le correspondant est furieux (car seul "word" et un bonne dose d'huile de coude est nécessaire à sa réparation).
Après, c'est pas certifié ISO trucmuche, mais perso, c'est pas l'ISO qui me nourri, c'est mon travail et le temps à réparer les erreurs de LO, c'est du temps perdu pour moi.
MD5, c'est le futur, c'est rapide, peut être pas autant qu'un bon CRC-32, mais bon, il faut quand même que l'ordinateur rame un peu lorsqu'il signe un very important mail sinon l'utilisateur pensera que c'est bidon le cryptage.
Désolé pour la réponse tardive. Haraka n'est pas un serveur mail classique comme Procmail. C'est un outil de pre-processing de mail. Il y a des dizaines de fonctions pour préprocesser les mails qui entrent, les filtrer, les aliases, les modifier, etc…
Tu peux par exemple, passer un filtre anti-spam (classique) mais dans ce cas, activer le mode tarpit qui va mettre très longtemps à répondre (genre 1 octet par seconde), et ainsi retarder fortement le spammeur. Tu peux faire les alias comme j'ai indiqué, faire du DKIM verify avec action paramétrable si ça échoue, du DKIM sign, …
L'une des options intéressantes c'est de récupérer les mails pour les stocker en BDD, pour faire un service mail qui n'utilise pas les classiques IMAP mais au contraire JMAP ou autre. Bref, c'est une boite à outils, à toi de faire une application avec.
C'est un peu l’œuf et la poule ici malheureusement.
On a d'un côté Weboob qui a déjà fait un travail colossal pour unifier des interfaces très différentes entre les banques, et de l'autre une équipe qui fait un travail très prometteur mais qui a décidé de faire tout (le travail) dans le browser.
Résultat, soit il faut tout réimplémenter les "konnectors" dans l'API Cozy (c'est à dire ré-écrire weboob qui est en python en JS), soit faire un gros hack dans Weboob (c'est à dire faire un serveur HTTP en python avec une API, et écrire un "konnector" dans Cozy pour cette API). Mais ça veut dire configuration des comptes via ligne de commande… pas très user friendly.
Le travail de Budget Insight, c'est justement ça: une API au dessus de Weboob. Si Cozy rendait open-source leur connecteur avec cette API, alors un développeur qui la réimplémenterait en open-source mettrait Budget Insight sur la paille (je pense que c'est pas très cool vu le travail fourni par BI).
Honnêtement, je trouve que les choix qui ont été fait amènent à une situation de deadlock où les deux alternatives (tout réimplémenter, banque par banque ou faire un konnector vers une API http serveur Weboob) sont mauvaises.
J'ai installé une instance Cozy pour l'application Cozy Bank et j'ai été super déçu de me rendre compte que les connecteurs vers les banques ne sont pas fonctionnels ou disponibles pour l'auto hébergé.
Pour moi, si c'est pour avoir un n-ième fournisseur d'agrégateur bancaire propriétaire, j'utilise l'une de mes banques, elles proposent toutes la fonction maintenant.
Personnellement, vu le problème des a+b@domain.com qui ne sont, ni privés (n'importe quel programmeur peut décider de supprimer tout ce qui est entre + et @ pour avoir l'email source), ni acceptés partout, je suis tombé sur la solution open source Haraka.
Ça marche très bien. On peut choisir le format de la redirection (par exemple a.b@domain.com qui eux, sont acceptés partout, ou simplement b@siteinconnu.domain.com).
Ça ne consomme rien en ressources, et on peut faire des tas d'analyses, rejet des spams etc…
[^] # Re: Logiciel fantastique !
Posté par xryl669 . En réponse à la dépêche Inkscape 1.2 vient de sortir avec tout plein de bonnes choses dedans. Évalué à 9.
Pour l'animation vectorielle, je te conseille pas Synfig, mais plutôt glaxnimate qui est excellent et produit des animations très légères (comparé à Synfig). L'interface est très proche d'Inkscape, ce qui est un vrai plus.
[^] # Re: Pas mal d'erreurs dans l'article
Posté par xryl669 . En réponse à la dépêche Transmission de données de capteurs via internet. Évalué à 2. Dernière modification le 31 mai 2022 à 10:25.
Liste des erreurs:
1. Payload dans MQTT non typé (et pas forcément JSON)
2. Authentification forte: à partir de MQTTv5 pour une version non basée sur utilisateur/mot de passe
3. AMQP n'est pas similaire à MQTT. C'est un protocole de messagerie, et pas de transfert de paquets avec résilience
4. Les versions MQTT sont rétrocompatibles car la session est taggué par la version du protocole utilisé, ce qui veut dire qu'un broker MQTTv5 peut dialoguer avec un client MQTT v3.1.1. Après, un client MQTTv5 ne peut qu'implémenter MQTTv5 et pas MQTTv3.1.1 (principalement pour des raisons de ressources, pas de difficultés particulières pour supporter une version précédente). Les brokers MQTTv3.1.1 uniquement sont de plus en plus rares et difficilement gérable pour une flotte IoT.
5. MQTT est n'est pas un service de messagerie (car il ne stocke pas les messages, tout au plus le dernier). C'est un service de transfert de paquets avec résilience (c'est à dire avec des garanties sur la livraison d'un paquet et ou d'un état d'un système).
Une des avancées majeure de MQTTv5 c'est la possibilité ajouter des propriétés aux paquets. Dans ces propriétés, on trouve la possibilité de déclarer la taille maximale d'un paquet que le client déclare supporter (contrairement à MQTT v3.1.1 qui autorisait un paquet de 250Mo à transiter), mais également les méthodes d'authentifications supportés (type négociation SSH), le type des données transmises, etc…
Pour envoyer une image, il suffit simplement de définir le payload sur les octets de l'image encodée. Soit tu décides que le topic/sujet sur lequel tu envois ces paquets est associé à un type MIME et dans ce cas, c'est fini, soit tu autorises différents type et dans ce cas, tu ajoutes une propriété Content Type avec le type MIME (de telle façon à ce que le client puisse décoder le flux).
[^] # Re: Cas d'usage
Posté par xryl669 . En réponse à la dépêche Compiler Explorer a 10 ans. Évalué à 3.
En C++ récent, le code devient très vite cryptique, d'autant plus qu'il faut contourner les interprétation fallacieuse du standard par les différents compilateurs.
Pour cela, il y a cppinsights.io qui explique comment un meta programme est interprété (compris) par le compilateur.
Cela permet d'écrire du code template plus robuste, plus complet et plus lisible parfois.
# Pas mal d'erreurs dans l'article
Posté par xryl669 . En réponse à la dépêche Transmission de données de capteurs via internet. Évalué à 10. Dernière modification le 25 mai 2022 à 12:16.
Le payload MQTT est complètement libre, ce n'est pas forcément du JSON. Tu peux y mettre du binaire (pour l'OTA ou pas) ou ce que tu veux. Tu n'es pas du tout obligé d'encoder en base64 des images pour les transmettre.
MQTT existe en différentes version, la 3.1 et la 5 sont actuellement les plus utilisées. La version 5 permet des authentification forte (c'est à dire type Diffie Helman, sans le fâcheux username/password qui doit être stocké en dur dans le client, donc hackable facilement). Il gère également les propriétés sur chaque packet, ce qui permet de réaliser beaucoup plus de chose que la version 3.
Pour les clients MQTT, je te recommande eMQTT5 qui est un client MQTTv5 en C++ pour l'embarqué, type ESP32, (mais fonctionnant également sur Linux / OSX / Windows) et très léger (moins de 80kB sur x86, et 17kB sur Xtensa).
Il possède également un parseur de packet MQTT ce qui est très pratique pour déboguer une communication qui échoue.
De plus à la différence des autres protocoles, MQTT impose au broker de stocker l'état d'un client et d'éxécuter ses dernières volontés en cas de déconnexion, ce qui est super pratique pour l'IoT (qui peut ainsi s'assurer d'avoir un status "connecté/déconnecté" fiable) et permet aussi de récupérer sa session lors d'un connexion ultérieure (pratique pour le roaming, ip changeante, etc…)
Aucun des autres protocoles ne permet ceci (ou alors, c'est en plus, non standard).
# Même bateau avec BNP/Hellobank
Posté par xryl669 . En réponse au journal BPCE et les paiements avec authentification à deux facteurs. Évalué à 3. Dernière modification le 09 mai 2022 à 17:15.
Le fonctionnement sur Hellobank / BNP est identique, voire moins sécurisé, vu qu'ils demandent le mot de passe du compte avant d'envoyer le SMS (il n'y a pas de petites économies, hein?)
Ce qui me rends dingue, c'est qu'il n'y a pas de moyen d'éviter cette daube.
Comment un informaticien peut coder ça, sérieux ?
Une simple capture du HTML + CSS et c'est le paradis du phishing.
1. Tu proposes un site bidon avec de la vente de produit
pasmoins cher que d'habitude.2. Puis tu demandes de payer avec ta CB. Avec les 4 premiers numéro de la CB, tu identifies que la CB provient du réseau BNP.
3. Tu balances une fausse iframe avec les bons logos et autre DOM/CSS que tu as capturé, et une iframe (inaccessible, dans la marge) sur le site d'Hellobank/BNP pour capturer les formulaires enregistrés (l'identifiant du compte n'est pas codé, il est en clair).
4. L'utilisateur va entrer son mot de passe de connexion. Avec l'identifiant capturé dans l'iframe plus le mot de passe de l'utilisateur, tu te loggues sur Hellobank.
5. Hellobank/BNP va détecter que ce n'est pas la même origine que d'habitude et va donc t'envoyer un SMS avec un code de connexion.
6. Tu demandes à l'utilisateur sur le deuxième page de l'iframe le code reçu.
7. L'utilisateur va entrer le code, forcément (même si le montant de l'achat n'est pas spécifié, car quoi, lui ne sait pas comment doit être le SMS).
8. Voilà, tu peux donc accéder au compte de l'utilisateur. Lui pomper ces données et ses sous.
9. Si tu veux pousser le vice encore plus, tu envoies un pseudo message d'erreur à l'utilisateur dans la troisième page de l'iframe, avec un bouton pour qu'il demande le renvoi du code reçu. (Forcément, aucune banque n'accepte de retaper un code, c'est supposé être du one-shot)
10. L'utilisateur va très probablement cliquer sur le bouton. Parallèlement tu procèdes à un vrai achat pendant ce temps, vu que tu as tout ce qu'il te faut (mot de passe + code SMS entré par l'utilisateur, cette fois pour le "vrai" achat).
11. Voilà, l'utilisateur va recevoir un mail légitime de la banque lui indiquant qu'il a dépensé X€ chez machin chose.
Toi, t'as gagné un accès direct sur son compte pour 3 mois.
C'est franchement donner le bâton pour se faire battre à ce niveau.
[^] # Re: Vous connaissez le logo de sudo?
Posté par xryl669 . En réponse à la dépêche Sudo 1.9.9 et Opendoas 6.8.2. Évalué à 10.
Très probablement lié à ça. Très drôle.
[^] # Re: Docker a la mano ?
Posté par xryl669 . En réponse à la dépêche Cloonix et les conteneurs. Évalué à 2.
Disons que Docker et les interfaces réseau, c'est un peu deux ennemis jurés. Dès que tu sors des 2 modes dans la doc (nat et proxy), t'es mort. Cloonix, c'est un peu plus fluide pour ça, à ce que j'ai compris (pas testé donc).
Aussi, docker propose bien plus que ce que Cloonix propose, notamment avec ses dépôts d'images. Le corolaire, c'est que le moindre conteneur est souvent énorme, vu que la majorité des utilisateurs se prennent pas la tête à le configurer au minimum de ce qu'il faut et démarre d'un Ubuntu ou un Alpine. Avec Cloonix, vu que c'est à la mano, je pense que tu ne mets rien en plus que nécessaire.
[^] # Re: X25519
Posté par xryl669 . En réponse à la dépêche Sortie de la version 1.0.0 de age. Évalué à 1.
Auriez vous un exemple où un algorithme a été cassé du jour au lendemain avec un retour à 0 de la sécurité de l'algorithme ?
Pour moi, et je me trompe probablement, lorsqu'une faille est découverte, la sécurité diminue, mais ne passe pas à 0 d'un coup. Par exemple, le SHA1 qui a été "forgé/dupliqué" une première fois par Google en 6 mois de calcul et qui est maintenant attaquable en 2 mois sur des fermes de serveurs. Ce n'est pas top, c'est sûr, mais ce n'est pas comme si un principe mathématique nouveau rendait le hash réversible.
Ce qui laisse du temps au développeurs de changer leur fusil d'épaule.
AMHA, l'agilité cryptographique c'est important, mais seulement sur un set très limité d'algorithme et qui reste limité (genre 3 algos possibles, si un devient moins fiable, on le "deprecate" en le remplaçant par un autre et qui ne peut être utilisé que pour le décodage).
[^] # Re: Information importante sur le moteur
Posté par xryl669 . En réponse à la dépêche Débuter avec SolveSpace. Évalué à 4. Dernière modification le 15 septembre 2021 à 10:34.
FreeCAD a fait d'énormes progrès concernant sa stabilité (mais c'est pas encore 100% parfait). J'arrive à modéliser des pièces vraiment complexes sans qu'il ne crashe ou me jette sur une fonction qu'il n'arrive pas à appliquer (ce qui n'était pas le cas avec la version 0.19).
Il est pas encore au niveau d'un Solidworks, mais il est très proche d'un OnShape.
Bientôt il devrait y avoir la correction du bug le plus pénible à mon sens: le topological naming issue qui est en passe d'être résolu.
C'est fondamental pour pouvoir vraiment parler de modéliseur paramétrique. Ainsi, si tu changes une variable sur une fonction en bas du stack (par exemple, la longueur d'un segment, ou le rayon d'un cercle), il ne casse plus toutes les fonctions suivantes.
Quand à la logique d'utilisation, c'est pareil pour tous les logiciels, il faut apprendre, puis après ça devient intuitif.
Solvespace est assez intuitif, il a des fonctions en plus que FreeCAD dans son sketcheur (notamment la possibilité d'appliquer une rotation multiplicative sur n'importe quel segment/curve) mais je me suis souvent retrouvé bloqué par le manque de fonctions "haut niveau".
[^] # Re: s/progrès/innovation/
Posté par xryl669 . En réponse au journal Rendez moi mon futur!. Évalué à 1.
En réalité, la seule énergie fondamentale provient de la seule force que nous ne comprenons pas complètement: la gravité
En effet, c'est uniquement que sous l'effet de la gravité que les conditions de pression (et donc de température) permettent la fusion nucléaire dans le soleil.
Le fait que le rayonnement électromagnétique du soleil nous parvienne et qu'il suffise à générer suffisamment d'énergie pour tous nos besoins n'est qu'une sorte d'anomalie, de résidu de la réaction de fusion. Nous pouvons tous vivre que parce que la réaction nucléaire de fusion n'est pas parfaite. On a une sacrée chance!
Si la masse du Soleil était encore plus grande, elle capturerait ses propres photons et nous n'aurions plus rien à voir/recevoir.
C'est également la gravité qui permet l'autre source d'énergie renouvelable non lumineuse: les marées. Pour ce faire, la Lune cède une partie de son énergie potentielle (colossale, il est vraie) à chaque marée, ce qui l'éloigne de la Terre un peu chaque jour.
La fission, les "énergies fossiles", la fusion, ne sont pas renouvelable. Seule la gravité (qui n'est pas une force, mais une déformation de l'espace, d'après la théorie de la relativité) est renouvelable.
[^] # Re: Information importante sur le moteur
Posté par xryl669 . En réponse à la dépêche Débuter avec SolveSpace. Évalué à 2.
Non je ne connaissais pas. Super cool, merci!
# Information importante sur le moteur
Posté par xryl669 . En réponse à la dépêche Débuter avec SolveSpace. Évalué à 10.
Il existe, en gros, 3 moteurs de CSG en open source actuellement. OpenCascade (OCCT) utilisé dans FreeCAD, OpenSCAD (qui est plus une sorte de POVRay du CAD) et Solvespace.
Du point de vue fonctionnalités, OCCT est plus utilisé car il a de nombreux outils/plugins (import/export, résolution des shells en solid, support du STEP214 en natif, etc…), mais ses limitations sont aussi son point faible, par exemple, il ne sait pas calculer l'intersection d'une surface NURBS avec une autre, ou supporter des contraintes géométriques sur des NURBS.
À noter que ce genre de calcul est extrêmement difficile (à leur décharge) car le nombre de cas particulier est très important. Il est possible que ça s'améliore dans le futur cependant.
Solvespace est utilise, quand à lui, son propre moteur CSG qui est vraiment très rapide et puissant. Il n'utilise pas des NURBS et au contraire, garde la représentation des surfaces sous forme polynomiale. Lorsque la résolution des contraintes n'est pas possible avec des solutions analytiques, il se défausse sur des solutions par approximations (comme Parasolid). Ce qui signifie que le résultat des fonctions présenté est très souvent le meilleur possible, mais que le nombre et type des fonctions est limité (par exemple, pas d'extrusion suivant une interpolation de profils, ou de sweep paramétrique etc…)
Enfin, il reste OpenSCAD. Honnêtement, je ne le connais pas bien, et la manière de modéliser dans OpenSCAD reste trop différente de ma manière de voir les pièces en 3D par fonctions successives.
[^] # Re: QoS
Posté par xryl669 . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 3.
Non
[^] # Re: Bon point pour le bluetooth
Posté par xryl669 . En réponse à la dépêche Publication de Textoter 0.51. Évalué à 1. Dernière modification le 06 avril 2021 à 09:51.
C'est faux. KDE Connect utilise un protocole IP. C'est tout.
Le support bluetooth natif n'a, à ma connaissance, jamais fonctionné (et sans intérêt AMHA) donc pas vraiment développé ni supporté. Je l'ai compilé au début avant de me rendre compte qu'il ne servait à rien. Donc la version officielle fonctionne parfaitement.
Par contre, vu que c'est de l'IP et qu'il y a, par défaut le support de PAN (IP sur Bluetooth) dans Linux et sur les smartphones (Android sûr, iOS je ne sais pas), faire fonctionner KDE Connect est un jeu d'enfant. Tu actives la couche IP, partage via Bluetooth sur le smartphone (donc pas besoin de changer l'AP WIFI ou autre), et tu t'y connectes avec ton Linux, c'est fait.
Il y a même un tutoriel plus haut avec des screenshots.
[^] # Re: Bon point pour le bluetooth
Posté par xryl669 . En réponse à la dépêche Publication de Textoter 0.51. Évalué à 5.
Non, avec KDE Connect tu peux utiliser du bluetooth aussi, c'est pas très compliqué, c'est même expliqué ici. KDE Connect, c'est un peu une tuerie en comparaison. Il te permet de passer les fichiers, le presse papier, d'utiliser le téléphone comme un touchpad remote, d'utiliser le clavier de ton PC sous Android, et j'en passe.
# De toutes les alternatives testés, c'est quand même la meilleure
Posté par xryl669 . En réponse à la dépêche Systèmes d'exploitation pour téléphones — partie 5 : Ubuntu 🖥️📲. Évalué à 3.
Honnêtement, du point de vue utilisateur lambda, c'est la meilleure alternative OS pour smartphone.
Simplement… ça marche. Pas de complexité, pas besoin d'être un XDA addict pour l'installer, on suit l'installeur fourni, on clique là et là, on appuie sur les 2 boutons demandés et zou, c'est installé.
Ensuite, l'environnement, c'est du Ubuntu. C'est un peu fisher price, mais ça fonctionne.
Le gestionnaire de fichier est assez limité par rapport à l'excellent MiXplorer sur Android (notamment pour les connections réseaux, type SMB/CIFS ou SFTP) mais bon, rien n'empêche de lancer un terminal et de faire un sshfs (à part pour Mme Michu).
Les applications fonctionnent globalement bien. Et puis le fait qu'il n'y ait pas 150 000 applications pour la calculatrice ou la lampe torche dans le store, c'est vraiment bien.
[^] # Re: IPv6 ?
Posté par xryl669 . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 6.
En Golang, la classe IP est par défaut en IPv6, il faut instancier la classe IPv4 pour avoir du IPv4, donc c'est normal que la recherche pour IPv6 ne retourne rien.
[^] # Re: Une catastrophe pour l'interopérabilité
Posté par xryl669 . En réponse à la dépêche Dixième anniversaire d’ONLYOFFICE et nos actualités : nouveaux connecteurs, version 5.5.3. Évalué à 3.
C'est exactement le contraire dans mon cas. Libreoffice est plus que nul pour supporter du OOXML, dès qu'il y a un schéma, une table, des colonnes, du suivi des modifications, etc.. (tout ce qui fait la "force" de word), il foire et en plus, il casse le fichier. Impossible d'avoir une ancre qui fonctionne au passage Word => LO => Word (et ça, c'est le cas depuis au moins 10 ans, le bug rapporté étant classé en "pas le même modèle de document donc irréalisable")
OO en revanche supporte toutes ces fonctions (même s'il n'a pas encore d'interface graphique pour éditer cela) et ne casse pas le document. Bref, si on m'envoie un docx je peux l'ouvrir, le lire, le modifier (mais pas tout… pour l'instant) et le renvoyer sans que mon correspondant ne sache quel logiciel j'ai utilisé.
Si je fais la même opération avec LO, le document est cassé, le correspondant est furieux (car seul "word" et un bonne dose d'huile de coude est nécessaire à sa réparation).
Après, c'est pas certifié ISO trucmuche, mais perso, c'est pas l'ISO qui me nourri, c'est mon travail et le temps à réparer les erreurs de LO, c'est du temps perdu pour moi.
# SHA-1 c'est nul. Utilisez MD5
Posté par xryl669 . En réponse à la dépêche SHA-mbles : une collision à préfixes choisis sur SHA-1. Évalué à 1.
MD5, c'est le futur, c'est rapide, peut être pas autant qu'un bon CRC-32, mais bon, il faut quand même que l'ordinateur rame un peu lorsqu'il signe un very important mail sinon l'utilisateur pensera que c'est bidon le cryptage.
[^] # Re: API de trading
Posté par xryl669 . En réponse à la dépêche Sortie de Cassandre, un cadriciel pour développer votre propre « trading bot ». Évalué à 4.
Vu le code, ça semble orienté vers de la crypto-monnaie uniquement.
[^] # Re: Solution simple avec Haraka
Posté par xryl669 . En réponse à la dépêche SimpleLogin, un outil open source pour protéger nos adresses de courriel. Évalué à 0.
Désolé pour la réponse tardive. Haraka n'est pas un serveur mail classique comme Procmail. C'est un outil de pre-processing de mail. Il y a des dizaines de fonctions pour préprocesser les mails qui entrent, les filtrer, les aliases, les modifier, etc…
Tu peux par exemple, passer un filtre anti-spam (classique) mais dans ce cas, activer le mode tarpit qui va mettre très longtemps à répondre (genre 1 octet par seconde), et ainsi retarder fortement le spammeur. Tu peux faire les alias comme j'ai indiqué, faire du DKIM verify avec action paramétrable si ça échoue, du DKIM sign, …
L'une des options intéressantes c'est de récupérer les mails pour les stocker en BDD, pour faire un service mail qui n'utilise pas les classiques IMAP mais au contraire JMAP ou autre. Bref, c'est une boite à outils, à toi de faire une application avec.
[^] # Re: Comment accéder à ses données
Posté par xryl669 . En réponse à la dépêche Des nouvelles de Cozy. Évalué à 1.
C'est un peu l’œuf et la poule ici malheureusement.
On a d'un côté Weboob qui a déjà fait un travail colossal pour unifier des interfaces très différentes entre les banques, et de l'autre une équipe qui fait un travail très prometteur mais qui a décidé de faire tout (le travail) dans le browser.
Résultat, soit il faut tout réimplémenter les "konnectors" dans l'API Cozy (c'est à dire ré-écrire weboob qui est en python en JS), soit faire un gros hack dans Weboob (c'est à dire faire un serveur HTTP en python avec une API, et écrire un "konnector" dans Cozy pour cette API). Mais ça veut dire configuration des comptes via ligne de commande… pas très user friendly.
Le travail de Budget Insight, c'est justement ça: une API au dessus de Weboob. Si Cozy rendait open-source leur connecteur avec cette API, alors un développeur qui la réimplémenterait en open-source mettrait Budget Insight sur la paille (je pense que c'est pas très cool vu le travail fourni par BI).
Honnêtement, je trouve que les choix qui ont été fait amènent à une situation de deadlock où les deux alternatives (tout réimplémenter, banque par banque ou faire un konnector vers une API http serveur Weboob) sont mauvaises.
J'ai installé une instance Cozy pour l'application Cozy Bank et j'ai été super déçu de me rendre compte que les connecteurs vers les banques ne sont pas fonctionnels ou disponibles pour l'auto hébergé.
Pour moi, si c'est pour avoir un n-ième fournisseur d'agrégateur bancaire propriétaire, j'utilise l'une de mes banques, elles proposent toutes la fonction maintenant.
[^] # Re: Bientôt 2 ans d'adoptions
Posté par xryl669 . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 5.
C'est déjà le cas, tu peux l'activer dans les options (ce que j'ai fait, ça marche nickel)
# Solution simple avec Haraka
Posté par xryl669 . En réponse à la dépêche SimpleLogin, un outil open source pour protéger nos adresses de courriel. Évalué à 4.
Personnellement, vu le problème des
a+b@domain.comqui ne sont, ni privés (n'importe quel programmeur peut décider de supprimer tout ce qui est entre + et @ pour avoir l'email source), ni acceptés partout, je suis tombé sur la solution open source Haraka.Ça marche très bien. On peut choisir le format de la redirection (par exemple
a.b@domain.comqui eux, sont acceptés partout, ou simplementb@siteinconnu.domain.com).Ça ne consomme rien en ressources, et on peut faire des tas d'analyses, rejet des spams etc…
J'ai fait un tutoriel pour l'installer:
https://steemit.com/mail/@xryl669/forwarding-email-to-your-domain-to-your-personal-email-box-anti-challenge-1
# Tu connais Symbiflow ?
Posté par xryl669 . En réponse à la dépêche k1g1 : le premier FPGA Libre…. Évalué à 1.
Ça bouge pas mal côté FPGA et Opensource ces derniers temps.
Projet de "GCC" du FGPA: (par reverse engineering des architectures & outils)
https://symbiflow.github.io/
Nouveau FPGA (chinois) pas cher:
https://hackaday.com/2019/11/03/the-5-fpga/