TilK a écrit 163 commentaires

Pour la cafetière, y a une MIB SNMP pour contrôler son état:
https://tools.ietf.org/rfc/rfc2325.txt

Cela m'a l'air bien plus standard que d'étendre HTTP.

Le défenseur des droits n'est pas une association, mais est une autorité administrative indépendante (AAI) dont l'existence est inscrite dans la Constitution. Ce statut unique lui garantit une véritable autonomie pour agir. Son représentant, Jacques Toubon, ne reçoit d'instructions de personne – ni du gouvernement, ni de l'administration, ni d'un groupe de pression. Il ne peut pas non plus être jugé pour des opinions ou des actes liés à ses fonctions, ce qui lui garantit une vraie liberté d'action.

(cf. leur site web)

Tu peux contacter le défendeur des droits :
https://www.defenseurdesdroits.fr/fr/institution/competences/lutte-contre-discriminations

A priori, le poste est ouvert par une filiale américaine (VEOLIA North America), qui a quelques soucis avec la loi Française.

De mon coté, j'ai déjà eu 2 pièces défectueuses (C'était deux vitres issues de la même boite, sur un tramway pour mon fils). Par contre, le service client est réellement super efficace :
https://www.lego.com/fr-fr/service/replacementparts?chosenFlow=1

On rentre le numéro de la boite, on cherche les briques en questions, on donne une petite explication du défaut et dans la semaine, DHL vient livrer les nouvelles briques gratuitement.

Lego possède plusieurs catégories pour les adultes. Ce qui ressemble le plus à des nanoblocks semble être la gamme Lego architecture.

Mais c'est clairement hors de prix :
https://shop.lego.com/fr-FR/category/architecture

Après, il existe aussi la gamme Lego mindstorm ev3 où l'on peut trouver de nombreux capteurs, moteurs (officiels ou non) et faire de la programmation dessus.

Bon, je me suis tapé l'article, et voila petit résumé pas trop technique :

• Les fournisseurs d'accès au Canada communiquent beaucoup sur la bande passante et pas beaucoup sur la latence.
• Ils cherchent donc à privilégier la bande passante sur le "ping".
• Leurs routeurs sont configurés de cette façon.
• Quand tu surfes, ton impression de vitesse d'affichage de la page dépend beaucoup plus des latences sur le réseau que de ta bande passante. 
• Il propose de rajouter un composant sur la ligne pour ralentir ton débit mais diminuer ta latence. Le fameux "dos d'âne" ou ralentisseur pour câble.

Après, j'ai l'impression qu'en France, certains opérateurs pensent aux joueurs et proposent déjà des modes pour améliorer le ping (Fastpath ou Patate chez free, le profil "Jeux" chez SFR…) et que cela fait longtemps qu'il n'y a plus de course à la plus grosse bande passante en ADSL (au final le réseau est le même, et donc il n'y a rien à comparer). Donc je ne sais pas si c'est vraiment efficace ou si ce n'est pas déjà implémenté .

Il pourrait y avoir une autre possibilité :

Leur base pourrait contenir ton mot de passe hashé (pour l'authentification) ainsi qu'une version chiffrée en utilisant comme clef la réponse à ta question secrète (utilisé lorsque l'on perd son mdp).

De cette façon, le mot de passe n'est pas stocké en clair, ni la réponse à ta question secrète (qui au niveau sécurité est aussi importante), et ils ne peuvent pas retrouver ton mot de passe sans une intervention de ta part (livraison de la réponse à la question secrète).

On pourrait rajouter également un sel à ton mot de passe pour valider légèrement ta réponse à la question secrète : lorsque l'on décode ton mot de passe avec la réponse, si la solution ne contient pas le hash, cela veut dire que la réponse à la question secrète est fausse.

Je me doute qu'il y a pas de chances que ce soit implémenté de cette façon, mais je me demande qu'elle serait alors la sécurité de cette solution. Des idées ?

En fait, j'ai l'impression qu'il y a un peu plus de groupes de personnes :

• Toi
• Ton FAI
• Le fournisseur de service
• Les publicitaires
• L'état
• Les gens mal intentionnés non étatiques
• Les gens mal intentionnés étatiques
• …

Les données qu'elles possèdent ou qui les intéressent sont vraiment différents.

Ton FAI (et certains de ses salariés) possède comme information :

• Ton nom, ton adresse.. : appelons cela ton identité physique.
• Ton IP "publique" à chaque instant durant les X dernières années
• Une partie de ton trafic (le non sécurisé)
• La liste des fournisseurs de services et services que tu as utilisé.

Les fournisseurs de services gratuits (et leur régie publicitaire) :

• Ne possèdent pas ton identité physique (nom, prénom…) mais plutôt une identité virtuelle (login, adresse email, IP, fingerprint…) sauf si tu leur as fournit explicitement. Logiquement, ils ne sont pas intéressé par cette information, ce n'est pas utile pour afficher de la pub.
• Possèdent la liste des sites que tu as pu consulter
• Une idée approximative d'où tu te trouves.
• L'utilisation exact de leur service (recherche, amis, email envoyé et reçus…).
• Avec cela une idée approximative de ta vie privée et de tes centres d’intérêt.

Les fournisseurs de services payants :

• Possèdent logiquement des informations sur tes moyens de paiement, et donc une partie de ton identité phyisque.
• Ils possèdent aussi une idée approximative d'où tu te trouves.
• L'utilisation exact de leur service (recherche, amis, email envoyé et reçus…).
• Avec cela une idée approximative de ta vie privée et de tes centres d’intérêt lié au service.

Les publicitaires :

• Par défaut, ils ne possèdent pas grand chose.
• Ils paient juste pour que leur pub soit vue par 1000 personnes qui aiment les chatons en Franche-Compté, sans trop savoir qui ils sont.
• Si tu décides de les suivre sur les réseaux sociaux, tu partagent alors plus informations.

L'état :

• Possède beaucoup d'information sur ta vie physique (adresse, si tu es marié, où tu es né, ton salaire…)
• Légalement, ils ne possèdent rien d'autre sans action de la justice.
• Si la justice approuve, ils peuvent obtenir toutes les informations du dessus et sont capable de faire le lien entre ton identité physique et ton identité virtuelle.
• Ils peuvent savoir par exemple, que tu as recherché sur google "Comment faire disparaitre un corps" 2 jours après que ton amie n'ait plus donné signe de vie.
• On peut aussi supposer qu'il peuvent reconstituer tout le trafic https ayant transité par ta machine (en demandant le trafic chiffré au FAI, et le clefs au fournisseur de service/site web).

Les gens mal intentionnés non étatiques :

• Ne possèdent à priori rien sur toi sauf ce que tu as laissé de façon publique (transmis sur un réseau wifi public de façon non sécurisé, les informations publiques sur les réseaux sociaux…)
• Pourraient accéder à toutes les informations précédentes en payant de grosses sommes (corruptions de salariés, accès au travers de backdoor…).
• Ils peuvent aussi accéder aux informations que tu pourrais leur laisser de façon volontaire (donner accès à ton carnet d'adresse à une application "louche" sur ton téléphone, installer une application louche sur ton PC…)
• Par contre, ils peuvent accéder aux informations personnelles qu'un autre aurait publié. Par exemple, la DB d'un site de rencontres extra conjugales mal sécurisé. Et cela, tu n'y peux pas grand chose.

Les gens mal intentionnés étatiques :

• Ils possèdent déjà tout sur toi.
• Se prémunir contre ce genre de personnes est très complexe.

Au final, éviter que ton voisin sache que tu fréquentes le site fuckingblueboys.com, empêcher la justice de savoir que tu deales des armes sur le net, ou éviter que ton employeur sache que tu consultes des annonces d'emplois durant ton temps de travail, ce n'est pas du tout la même chose, et les mêmes précautions à prendre. Mais il y aussi un rapport coût/risque à prendre. Le voisin n'ira pas corrompre un salarié de ton FAI logiquement.

La loi essaye également de te protéger. Et la RGPD essaie encore d'améliorer les choses.

Thomas Jefferson a dit : « Si tu es prêt à sacrifier un peu de liberté pour te sentir en sécurité, tu ne mérites ni l'une ni l'autre. »

« This quote is often falsely attributed to Mark Twain. »
Randall Munroe

Et pour la vraie citation, voir ici ou là. Et tu verras également la piètre qualité de ta traduction.

Personnellement, je préfère celle de WikiQuote :

« Ceux qui sont prêts à abandonner une liberté fondamentale, pour obtenir temporairement un peu de sécurité, ne méritent ni la liberté ni la sécurité. »

Et cela me permet de citer encore Rundall Monroe :
« This quote was taken out of context. »

Salut,

Je suis super content que mes journaux aient fait des émules.

Après, le plus important, c'est que cela fonctionne vite et bien, et que l'utilisateur soit content.

Tout à fait,

J'ai eu un peu plus de temps pour lire l'article sur Meltdown, et je comprends que c'est différent de ce que j'avais écrit.

Spectre utilise l'Exécution_spéculative alors que Meltdown utilise l'Exécution_dans_le_désordre et le fait que la vérification des droits d'une lecture est faite en parallèle de cette lecture.

A priori, le code semble être organisé comme cela (n'hésitez pas à me contredire si je dis des conneries, c'est grandement probable) :

1. Une instruction lente qui va générer une exception
2. La lecture en mémoire d'en endroit où l'on a pas le droit d'accéder, mais qui est indépendante de l'instruction 1.
3. L'utilisation de la lecture précédente pour faire un accès dans un buffer.

A cause du "Out-of-order execution", l'instruction 2 sera exécutée avant/en même temps que l'instruction 1. La lecture de l'instruction 2 sera faite en parallèle de la vérification des droits de cette lecture. On espère que cette vérification des droits sera lente et que l'instruction 3 puisse être exécutée avant l'instruction 2. Au final, soit l'exception de l'instruction 1 est levée, soit la vérification des droits de l'instruction 2 va râler, et on va défaire les instructions 2 et 3.

Mais comme pour Spectre, les caches seront modifiés, et on peut connaitre la valeur lue au travers de ce canal caché.

Les auteurs ne sont pas arrivés à reproduire la faille entièrement sur AMD, mais ils pensent que c'est possible. AMD annonce le contraire.

Sous Linux, cela permet d'accéder en lecture à la mémoire du kernel, qui contient l'ensemble de la mémoire physique de la machine et donc la mémoire utilisée par les autres processus. Sous Windows, cela permet d'accéder à la mémoire du kernel, et une partie seulement de la mémoire physique. Cela permet de casser les containers par exemple.

PS : Pour Spectre, il existe un POC en javascript qui permet de fuiter la mémoire de Chrome :-/

En fait, non.

La solution qui semble avoir été retenue, est de séparer très fortement la mémoire du kernel et la mémoire des processus. De cette façon, il n'y a plus moyen d'accéder depuis un processus à la mémoire du kernel.

A cause de cela, à chaque appel de fonction du kernel (syscall), il est nécessaire de recharger la mémoire du kernel (avant elle était disponible), ce qui peux coûter très cher.

Les détails techniques ont été publiés par Project Zero, ici et là.

Pour les décideurs pressés, il semble y avoir 3 failles :

• Variant 1: bounds check bypass (CVE-2017-5753)
• Variant 2: branch target injection (CVE-2017-5715)
• Variant 3: rogue data cache load (CVE-2017-5754)

Les deux premières ont été nommés Spectre et la troisième Meltdown.

L'équipe a réalisé 4 PoC :

• Le premier utilisant la faille 1 permet de lire la mémoire sans sortir de son process ni de violer des privilèges. Il fonctionne sur des CPU AMD, Intel et ARM.
• Le deuxième utilisant la faille 1 permet de lire la mémoire kernel à un partir du userspace. Il fonctionne sur des CPU Intel. Pour AMD, il faut qu'il soit dans un mode non standard (Activation du BPF JIT).
• Le PoC pour la faille 2 permet, en étant root dans un guest KVM, de lire la mémoire kernel du host. Il a été testé sur CPU Intel et avec une vieille version d'un kernel debian.
• Le PoC pour la faille 3 permet de lire la mémoire kernel à partir d'un process user. Cela fonctionne sur CPU Intel et avec certaines conditions (la mémoire doit être dans le cache L1D).

Pour être franc, je n'ai pas compris tous les détails de ces PoC, mais ils semblent être toutes construits de la même façon. Je vais donc parler du premier, qui semble le plus simple à comprendre. Le PoC semble être quasiment le même mais au niveau assembleur plutôt qu'en C.

Le code en question est :

struct array {
 unsigned long length;
 unsigned char data[];
};
struct array *arr1 = ...; /* small array */
struct array *arr2 = ...; /* array of size 0x400 */
unsigned long untrusted_offset_from_caller = ...; /* >0x400 (OUT OF BOUNDS!) */
if (untrusted_offset_from_caller < arr1->length) {
 unsigned char value = arr1->data[untrusted_offset_from_caller];
 unsigned long index2 = ((value&1)*0x100)+0x200;
 if (index2 < arr2->length) {
   unsigned char value2 = arr2->data[index2];
 }
}

En gros, dans un bloc conditionnel qui sera toujours faux, une demande de lire un bit de la mémoire en faisant un débordement de buffer. Puis en fonction du résultat de la lecture, on va écrire dans un buffer accessible par l'utilisateur dans un offset différent suivant si c'est un 0 ou 1.

Dans un second temps (non montré dans le code), on va tester la vitesse de lecture de ce buffer au deux offsets. Celui dans la lecture est le plus rapide indiquera la valeur du bit lu précédemment.

Comment cela fonctionne ? En gros, le CPU va penser que le bloc conditionnel sera vrai, et donc va chercher à l'évaluer en avance de phase. C'est de l'Exécution_spéculative et cela fait gagner du temps au CPU. En fonction de la valeur lue, on va écrire la donnée dans un offset particulier d'un tableau. Cela va donc charger cette case mémoire en cache. Quand le CPU va voir que la condition est fausse, il va donc défaire les calculs qu'il a déjà fait, l'offset du tableau ne contiendra pas la valeur calculée, néanmoins il restera en cache.
Quand on cherchera a tester les temps d'accès au offsets en question, celui chargé en mémoire sera plus rapide, et donc on pourra savoir qu'elle est la valeur lue.

Ce PoC ne sert pas à grand chose, mais permet de comprendre comme la gamme de failles fonctionne.

Dans une branche qui ne doit pas être exécutée, mais que le CPU exécutera "au cas ou", on essayer d'accéder à de la mémoire qu'on ne doit pas pouvoir lire. Même si cette exécution sera défaite par la suite, on cherche un moyen de connaitre la valeur de la lecture en utilisant un canal caché (présence d'objet dans un cache par exemple).

Salut,

Pour rappel, tu es censé rajouter le prix de la TVA et des droits de douane quand tu importes des biens depuis l'extérieur de l'union européenne :
http://www.douane.gouv.fr/articles/a10753-achats-a-distance-et-envois-entre-particuliers

Tu as une exonération des droits de douane pour les achats de moins de 150 €. Pas de chance, sur Aliexpress, le prix est de 150,94 € et vu que la livraison est marquée "gratuite", tu ne peux pas diminuer ce prix. Tu dois donc payer 20% de TVA en plus et les droits de douane.

J'ai du mal à trouver le taux à appliquer dans le journal officiel :
http://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L:2016:294:FULL&from=FR
ni sur le site des douanes :
http://www.douane.gouv.fr/articles/a10798-calcul-des-droits-et-taxes-sur-les-achats-a-l-etranger#droitsetaxes
Mais disons 2%.

Ton imprimante te reviens donc à 150.94 * 1.22 = 184.15 €. Dans ce cas précis, mieux vaut se la faire expédier depuis l'Allemagne car à l'intérieur de l'UE, et donc économiser plus de 30€.

En fait, le device n'apparait pas dans la liste de systemctl :

root@orangepizero:~ # systemctl -t device
UNIT                                                                                    LOAD   ACTIVE SUB     DESCRIPTION
sys-devices-platform-audiocodec-sound-card0.device                                      loaded active plugged /sys/devices/platform/audiocodec/sound/card0
sys-devices-platform-gmac0-net-eth0.device                                              loaded active plugged /sys/devices/platform/gmac0/net/eth0
sys-devices-platform-sndhdmi-sound-card1.device                                         loaded active plugged /sys/devices/platform/sndhdmi/sound/card1
sys-devices-platform-sunxi\x2dmmc.0-mmc_host-mmc0-mmc0:0007-block-mmcblk0-mmcblk0p1.device loaded active plugged /sys/devices/platform/sunxi-mmc.0/mmc_host/mmc0/mmc0:0007/block/mmcblk0/mmcblk0p1
sys-devices-platform-sunxi\x2dmmc.0-mmc_host-mmc0-mmc0:0007-block-mmcblk0.device        loaded active plugged /sys/devices/platform/sunxi-mmc.0/mmc_host/mmc0/mmc0:0007/block/mmcblk0
sys-devices-platform-sunxi_usb_udc-gadget-tty-ttyGS0.device                             loaded active plugged /sys/devices/platform/sunxi_usb_udc/gadget/tty/ttyGS0
sys-devices-platform-uart.0-tty-ttyS0.device                                            loaded active plugged /sys/devices/platform/uart.0/tty/ttyS0
sys-devices-platform-uart.1-tty-ttyS1.device                                            loaded active plugged /sys/devices/platform/uart.1/tty/ttyS1
sys-devices-platform-uart.2-tty-ttyS2.device                                            loaded active plugged /sys/devices/platform/uart.2/tty/ttyS2
sys-devices-virtual-block-ram0.device                                                   loaded active plugged /sys/devices/virtual/block/ram0
sys-devices-virtual-block-ram1.device                                                   loaded active plugged /sys/devices/virtual/block/ram1
sys-devices-virtual-block-ram2.device                                                   loaded active plugged /sys/devices/virtual/block/ram2
sys-devices-virtual-block-ram3.device                                                   loaded active plugged /sys/devices/virtual/block/ram3
sys-devices-virtual-block-ram4.device                                                   loaded active plugged /sys/devices/virtual/block/ram4
sys-devices-virtual-block-ram5.device                                                   loaded active plugged /sys/devices/virtual/block/ram5
sys-devices-virtual-block-ram6.device                                                   loaded active plugged /sys/devices/virtual/block/ram6
sys-devices-virtual-block-ram7.device                                                   loaded active plugged /sys/devices/virtual/block/ram7
sys-devices-virtual-block-zram0.device                                                  loaded active plugged /sys/devices/virtual/block/zram0
sys-devices-virtual-block-zram1.device                                                  loaded active plugged /sys/devices/virtual/block/zram1
sys-devices-virtual-block-zram2.device                                                  loaded active plugged /sys/devices/virtual/block/zram2
sys-devices-virtual-block-zram3.device                                                  loaded active plugged /sys/devices/virtual/block/zram3
sys-devices-virtual-misc-rfkill.device                                                  loaded active plugged /sys/devices/virtual/misc/rfkill
sys-module-fuse.device                                                                  loaded active plugged /sys/module/fuse
sys-subsystem-net-devices-eth0.device                                                   loaded active plugged /sys/subsystem/net/devices/eth0

Il n'y est pas non plus dans la liste si je rajoute un --all. De ce que j'ai compris, pour certains équipement, ils n'apparaissent que s'il y a une rule udev rajoutant TAG+="systemd". Dans mon cas, de plus, le chemin du device dans l'arbre de udev dépendant du port usb dans lequel je l'avais branché. Il fallait donc prévoir tous les cas.

Salut,

J'ai parfaitement conscience que mon utilisation d'hydrogen est ridicule par rapport à ses capacités. Par contre, cette solution possède quand même des avantages :

• Le plus important : ça a fonctionné vite et bien. Au niveau d'hydrogen je n'ai eu qu'à configurer l'entrée et la sortie, et tout fonctionnait. Cela m'aurait pris plus de temps à mon avis de faire des scripts reposant sur des commandes systèmes. Et au final, j'aurais surement plus galéré avec les problèmes de latence.
• Au final, hydrogen (en tout cas cette version en ligne de commande) n'est pas vraiment lourd : 12 Mo de RAM, et 14% d'un core au maximum (10% au minimum). Ce qui donne sur la machine, avec mpd et moi qui bourrine sur les drums :
  • Memory usage: 8 % of 494MB
  • CPU : Idle 92.8%, User 5.0%, System : 2.0%
  • Finalement, mon orange pi zero à 15 euros est sur-dimensionné par rapport à cette utilisation.
• Les temps de démarrage de ces processus sont plutôt bon. C'est quasi instantané pour rbdrum2midi, et il faut compter 3 secondes pour h2cli.
• Le système est facilement extensible. On trouve des batteries Guitar hero world tour ou rock band 2, 3 ou 4, qui elles gèrent la vélocité, pour 20 à 40 € sur le bon coin. Je n'aurais juste qu'à récupérer le code des boutons de son et la croix directionnelle pour que cela fonctionne.

C'est bien cela. Rbdrum2midi génère des messages midi. J'utilise au final h2cli (qui est livré avec hydrogen) pour générer les sons à partir du midi. C'est un outil en ligne de commande qui utilise le même moteur qu'hydrogen sans en avoir l'interface graphique. Cela devrait pouvoir te servir.

En effet, c'est une piste intéressante. Je testerais demain.

En effet, la vidéo donne cette impression. Et je ne peux pas blâmer un décalage entre le son et l'image, vu que l'on entend la différence entre le bruit des baguettes sur les pads et le son derrière :)

Par contre, le ressenti en live est très différent.

Ce matin, mes enfants m'ont aussi fait part d'un problème. Quand on l'utilise en mode casque, il n'est pas possible de modifier le son de celui-ci.
Or la batterie possède deux boutons "+" et "-" sur l'avant de celle-ci (équivalent des boutons idoines d'une wiimote). Je vais donc essayer de modifier rbdrum2midi pour capturer l'état de ces boutons et modifier le volume master de alsa.

Et sinon, j'ai l'impression qu'à la place d'avoir à écrire des scripts udev, il serait possible d'utiliser un "device" systemd et de lui rattacher les deux services. Cela devrait être plus simple à gérer. Je n'ai jamais utilisé cette partie de systemd, il faut donc que j'investigue.

En effet, quand j'aurais amélioré le temps de boot, il faudrait que je mette à disposition mes rules udev, les scripts de démarrage, et pourquoi pas une image orange pi à mettre sur une carte micro sd.

Je viens de tester quelques jours barter, et je confirme que c'est très très bien.
Un petit copier coller du noms des jeux que tu as en trop, tu le synchronises avec ton compte steam, et tu as régulièrement des propositions de jeux qui t’intéressent. Pour l'instant, rien à redire.

Voila, Human resource et Hand of fate ont été envoyés.

Super, je vais aussi regarder ces deux sites.

Voila, les 3 clefs ont été envoyées par email.