Glandos a écrit 1403 commentaires

Oui, effectivement, l'écran d'accueil est très sommaire. Il ne s'appelle pas BLISS pour rien.

Mais comme tout le reste, il est possible de le changer. Après, c'est la foire des applications… Donc j'ai aucun conseil à donner.

D'autres ont déjà répondu mais oui, le problème, c'est la chaîne d'intégrité.

Aujourd'hui, si on se retrouve face à des bibliothèques malicieuses sur NPM, c'est parce qu'elles ne sont pas signées. yarn.lock et package-lock.json font heureusement de la vérification d'intégrité, mais sur une version donnée. Attention, ce problème existe également avec du typosquatting sur PyPI et RubyGems.

Le gestionnaire de paquets de ma distribution utilise des signatures pour ce genre de choses. S'ils se font pirater, oui, c'est perdu pour moi, à tous les niveaux. Mais il est plus facile de « voler » un nom de domaine (voire simplement de le perdre) que de pénétrer la sécurité de Debian/Ubuntu/RedHat et n'importe quelle grosse distribution.

export PYENV_ROOT="$HOME/.pyenv"

😞

Ça aurait été tellement bien dans ~/.local/share/ avec des binaires dans ~/.local/bin. Alors oui, ça semble possible de le faire, mais par défaut, ça crée un énième répertoire, dommage.

Après, moi, je râle gratuitement contre tout ce qui me demande curl | bash

C'est vrai que c'est une bonne nouvelle. Les courriels depuis les serveurs Microsoft seront mieux sécurisés.

Mais maintenant, on peut leur demander d’accepter les messages en provenance des serveurs qui ont mis en place tous ces mécanismes ?

Hé ben, c'est le complément : https://linuxfr.org/users/milo/liens/pegasus-mail-et-gmail-le-probleme-oauth2

Je découvre ça sur l'article de la FSFE :

In contrast, the situation in Germany is quite the opposite. AusweisApp2 is the German identification app, which is available in F-Droid, Debian and many other Free Software repositories.

Car oui, on peut faire de la transparence pour établir un lien de confiance avec les citoyens. Ça me semble fou qu'il faille l'expliquer aux politiciens.

Oui et non. Je laisse les professionnels en parler : https://aide.trainline.fr/article/215-verification-3d-secure

À part rendre l'achat plus pénible, la vérification 3DSecure ne change pas grand chose pour vous. Elle est là pour protéger le commerçant, car c’est à lui de rembourser les victimes en cas d’utilisation frauduleuse d’une carte bancaire. Avec ou sans 3DS, la transaction sera toujours aussi sécurisée pour vous.

« Je suis avocat en brevets depuis plus de 30 ans et je suis un ancien examinateur de brevets de l'Office américain des brevets et instructeur de révision du barreau des brevets, donc je suis un fervent partisan du système des brevets », a déclaré Smith à l'OSI par e-mail. « En tant que personne qui a également travaillé comme avocat open source pendant plus de 20 ans, je suis également un fervent partisan d'un domaine public robuste. Lorsque j'ai découvert pour la première fois le procès contre GNOME, j'ai lu le brevet en cause et, comme beaucoup d'autres, j'ai conclu que ce brevet était invalide et n'aurait jamais dû être accordé. J'ai donc fait en sorte que l'objet de ce brevet soit remis dans le domaine public, où il a toujours appartenu ».

Intéressant, de la part d'un interne au système, de combattre ces abus.

Je voterai pour https://candybox2.github.io/ pour convaincre les gens qu'on peut faire des trucs chouettes en texte simple.

Autre question de béotien : la faille ne serait-elle pas plutôt dans systemd que dans Linux ?

C'est même dans networkd plutôt. systemd en tant que gestionnaire des processus n'est pas impacté. En tout cas, c'est ce que je lis.

Oui, le partage inégal est demandé, et c'est pas simple de l'afficher … simplement ! On veut garder la simplicité de IHateMoney, mais je crois qu'on va finir par faire cette fonctionnalité.

Par contre, j'ai essayé la démo de Tirelire, et je vois un comportement que j'aime bien : ajouter les utilisateurs lors de l'ajout d'une facture. C'est gênant si je vole / copie cette manière de faire ? L'avantage est que c'est contextuel : on ajoute une facture, et paf, on déclare tous les gens dedans.

Je crois que c'est la même demande que https://github.com/spiral-project/ihatemoney/issues/523

Je n'ai pas réagi dans le ticket ouvert sur GitHub, mais quelle que soit la décision à prendre niveau interface utilisateur, ce qui est sûr, c'est que c'est un gros changement côté modèle de données.

Rien n'est impossible bien sûr :)

L'envoi par courrier électronique, c'est un peu avoir trouvé un remède pire que le mal. Le transport et le stockage est très coûteux en ressources, probablement plus que le papier recyclé des caisses.
Ce papier génère des déchets dans nos poubelles, certes, mais là, c'est mettre les déchets dans la poubelle du voisin.

Ça fait longtemps qu'on aurait pu avoir des solutions, à base de code barre unique. D'ailleurs, les grosses sociétés de distributions ont déjà ça sur leur ticket, elle ne s'embête pas à lire le texte à la main. Qui n'a pas déjà ramené un truc chez LeroyMerlin ou Castorama ?

Faudra créer nanodnf, avant l'apparition de femtodnf.

C'est toujours décevant de voir la confusion entre peur et confiance…

Visible aussi sur https://y.com.sb/watch?v=wqn3gR1WTcA

John Oliver explique dans son émission Last Week Tonight le commerce des data brokers. Je pense que le lectorat le connaît plutôt pas mal, mais il rappelle que ce marché est complètement non régulé aux États-Unis.

Et dans le final, il se dit que la seule chose qui peut motiver les sénateurs à changer la loi, c'est de leur montrer que ça les touche eux aussi. Donc son équipe a acheté des profils de personnes autour de Washington DC, et affiché des publicités. Les personnes qui cliquent sur les publicités sont « ferrées » et cataloguées avec le plus grand nombre de détails possibles.

Alors oui, il ne fait pas de révélation fracassante (dommage, hein ?), mais je trouve le procédé louable. On verra bien si ça change un truc.

Pourquoi j'ai pas fait un journal moi ?

Quand bien même on aurait accès au code source, il faudrait être capable de l'interpréter.

Et en plus, ça se base sur des systèmes chaotiques, dont l'évolution est impossible à prévoir sur le long terme sans une précision infinie quant aux données de départ.

J'crois qu'on peut s'brosser.

On peut essayer de comparer nos bulletins de vote à ceux des USA alors.

l'intelligence est dans la CB.

Je serais tatillon : l'intelligence est dans le boîtier, mais le secret est dans la puce de la CB.

Deux choses importantes :
- scp utilise sftp par défaut
- un algorithme d'échange de clé potentiellement résistant aux attaques par ordinateur quantique est utilisé par défaut

Y a sûrement d'autres trucs, mais vous croyez que j'ai tout lu ? Et si c'était le cas, vous croyez que j'aurais tout compris ?

La version en Rust est plus rapide chez moi :

coreutils on  main is 📦 v0.0.13 via 🦀 v1.57.0 ⏰6s491ms[32] ❯ /usr/bin/yes | pv > /dev/null
^C,3GiO 0:00:03 [5,25GiB/s] [            <=>                         

coreutils on  main is 📦 v0.0.13 via 🦀 v1.57.0 ⏰17s327ms❯ ./target/release/yes | pv > /dev/null
^C52GiO 0:00:08 [19,1GiB/s] [                                <=>                                                            

C'est peut-être lié aux options de compilation de ma Debian, va savoir…

Préparatifs:

/tmp ❯ touch ahah
/tmp ❯ chmod +x ahah

Et c'est parti

/tmp ❯ hyperfine "./ahah" "/bin/true"
Benchmark #1: ./ahah
  Time (mean ± σ):       1.4 ms ±   0.3 ms    [User: 0.4 ms, System: 0.1 ms]
  Range (min … max):     1.0 ms …   4.8 ms    1409 runs

  Warning: Command took less than 5 ms to complete. Results might be inaccurate.
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark #2: /bin/true
  Time (mean ± σ):       0.1 ms ±   0.1 ms    [User: 0.2 ms, System: 0.0 ms]
  Range (min … max):     0.0 ms …   1.2 ms    3048 runs

  Warning: Command took less than 5 ms to complete. Results might be inaccurate.
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  '/bin/true' ran
   17.52 ± 25.03 times faster than './ahah'

Donc en fait, ça marche plus vite avec un gros fichier. Va savoir pourquoi.

Je crois même qu'il n'est pas spécifique à une banque. Si je ne me trompe pas (merci de me corriger sinon), il implémente un protocole de génération de jeton de validation à base :
- d'un secret (le code de la carte)
- d'un périphérique physique (la puce de la carte)
- d'un code initial (fourni par le vendeur/boutique/créancier)

Et le jeton final permet, par des algorithmes cryptographiques, de valider que le code initial a bien été validé par le possesseur de la carte.

Baobab (a.k.a. Disk Usage Analyzer) is written in Vala. Vala does not have access to a great ecosystem of libraries, and the tooling has left something to be desired. Rust, however, has a flourishing library ecosystem and wonderful tooling. Rust also has great GTK bindings that are constantly improving. By rewriting Baobab in Rust, I will be able to take full advantage of the ecosystem while improving the performance of it’s main function: analyzing disk usage.

Je ne connais pas Vala, donc j'ai du mal à me prononcer, mais est-ce une décision pour dire Vala est une tentative ratée ? Attention, je ne veux pas être médisant, le chemin du succès est pavé d'échecs, et il est impossible de savoir qui brillera à l'avenir. Par exemple, on aurait eu du mal à prévoir la cote de popularité actuelle de Perl il y a 20 ans…

Alors je n'ai pas de sources, mais ça fait partie de la DSP2 qui introduisait et « normalisait » l'usage d'un deuxième facteur d'authentification, notamment pour les paiements, mais avec la contextualisation. Ça veut dire que lors de l'envoi du jeton, il doit y avoir les détails de la transaction associée. Et ça, ce n'est pas possible avec T-OTP, puisqu'il n'y a que le jeton, il ne peut pas y avoir le montant, le bénéficiaire, etc.