Pinaraf a écrit 3682 commentaires

Ha ben ça juste boote, c'est mieux, non ? :)

Désolé pour le temps de réponse, j'ai été très négligent avec ce journal et j'ai manqué de temps à y consacrer (boulots, maladie, tout ça tout ça)

«ma carte mère n'a pas le nécessaire pour sauvegarder un kernel panic hélas» : les cartes mères de serveurs ont un espace mémoire disponible, exposé en ACPI, qui permet au système de stocker des données en cas de crash.
Cf https://lwn.net/Articles/434821/

Sinon la clé est générée par le noyau pour vérifier sa compatibilité avec certaines normes de sécu (du FIPS…). Je n'ai pas creusé plus.

Yep, j'ai hâte, pour le moment je démarre ma machine en patchant à l'éditeur hexadécimal le .ko des derniers noyaux debian (c'est plus rapide d'écrire au bon endroit b8f2ffffffc3 que de recompiler le noyau, quand même).

Ouais mais ils sont quand même assez ouverts sur l'ajout de nouvelles fonctionnalités pour pouvoir réimplémenter les extensions. Donc compatibles Chrome mais aussi avec des fonctionnalités bonus.
De toute façon au bout d'un moment ils ne pouvaient plus trop avancer sans devoir casser cette partie là du navigateur. Et la majorité des utilisateurs a choisi depuis longtemps les performances contre l'extensibilité, donc pour rester vivant Firefox n'avait plus trop le choix…

Merci pour ce projet !
Une question que je me pose par rapport au projet NERF : que devient là dedans l'ACPI ? Est-ce-que l'OS 'client' peut s'en passer en utilisant à la place des mécanismes comme le device tree d'OpenFirmware ? Ou le noyau Linux remplaçant l'UEFI fournit-il ses propres tables ACPI et cie à l'OS ? Ou l'ACPI reste-t-il sans intervention du noyau Linux embarqué dans le NERF ?

J'ai pas dit que je n'avais que des rudiments de C, j'ai dit qu'il faut que des rudiments pour comprendre le code impacté :)
Pour le processus de développement du noyau, j'ai copié depuis moi-même y'a 7 ans… https://linuxfr.org/users/pied/journaux/de-l%C3%A9criture-dun-pilote-linux-pour-un-gadget-suite

Beaucoup d'outils dépendent encore d'iptables. iptables et nftables ne peuvent pas être utilisés en même temps.
Et la stabilité de nftables est très récente, c'est que depuis Debian stretch que le paquet est dans stable.
Mais effectivement, ça promet de changer beaucoup de choses, il était plus que temps !

Je ferai ça dans un prochain journal alors, quand j'aurai commencé à vraiment exploiter SELinux pour castrer des applications dangereuses…
Par rapport à nftables : it works… Et ça fait plaisir d'avoir un ensemble qui soit lisible et qui gère à la fois IPv4 et IPv6.

Ho la belle boulette… Faut plus que je rédige de journaux le soir, merci.

Toutes mes excuses, j'ai oublié les liens…

Pour le bug OCaml/Intel : http://ocamllabs.io/general/2017/06/26/IntelHyperThreadBug.html

Pour les failles de sécu, on en a vu plusieurs, comme la memory sinkhole de 2015.

Heu, non, Java uniquement. Je viens d'explorer toute l'archive pour vérifier, c'eut été une nouveauté intéressante.

J'ai déjà été très agréablement surpris par Pdfium, intégré dans chromium. Je pense qu'il gérait les formulaires de procuration correctement.

Continuons sur la petite parenthèse avec quelques anecdotes alors :)

Il y a deux ans, chez mon employeur, j'avais eu la flemme de configurer l'impression avec CUPS, donc j'imprimais mes documents en faisant un cat ficher.pdf | nc 1.2.3.4 631 (je ne suis plus sûr du port). La plupart des imprimantes acceptent ça sans broncher. Sauf une qu'il y avait, une Xerox de je ne sais plus quel modèle, qui me faisait des blagues lors de l'impression de certains documents, en particulier chargés graphiquement (par exemple les cartes d'approche aéronautiques) : l'impression se lançait, le documen commençait à être imprimé, puis une stack trace de l'interpréteur était écrite sur la feuille…

Et plus récemment, un ami m'a montré un bulletin reçu de sa commune l'avertissant du passage d'une course à pied, avec un "voir le plan au verso". Et au verso, un message de trois lignes indiquant une erreur de l'interpréteur PCL dans le module KERNEL…

L'impression c'est très compliqué. Tu as le choix entre :
- une chaine d'impression basée sur du PostScript, langage terriblement compliqué et horrible à implémenter (j'ai lu des estimations à 5 ans pour une personne). C'est par contre "universel".
- une chaine d'impression basée sur du PDF, assez compliqué à implémenter également, notamment avec l'intégration d'un interpréteur ECMAScript pour gérer vraiment toute la norme. C'est la chaine la plus courante sous Linux/MacOS, mais ça ne passe pas sous Windows.
- une chaine d'impression basée sur du XPS ou de l'OXPS… vous vous souvenez la différence entre Office Open XML avant et après la standardisation ? c'est la même idée… avec donc une chaine implémentée que par Microsoft, un format à base de fichiers XML dans un fichier zip, des fichiers de police altérés avec un xor pour qu'on ne les récupère pas telles quelles (véridique)

Dans le monde du libre nous avons 3 principaux moteurs de rendu de PDF :
- poppler, dérivé de xpdf, utilisé par evince/okular,
- pdf.js, utilisé par Firefox,
- pdfium, dérivé/libéré de Foxxit je crois, utilisé par chrome/chromium.

Il y a des projets pour utiliser pdfium dans d'autres contextes que simplement chrome, notamment des "bindings" Qt pour pdfium qui pourraient être utilisés par Okular.

Hello

Je peux pas laisser passer ce message sur ce site.
3D Secure/SecureCode est un protocole reposant sur un ensemble d'éléments.
Les éléments les plus techniques sont le MPI (Merchant Plug In), installé chez le commerçant ou chez son fournisseur de solutions de paiement, le directory server (un annuaire) et l'ACS, Access Control Server.
L'ACS héberge notamment la page web "de la banque" qui affiche le formulaire où saisir le code reçu par SMS ou la date de naissance du chat ou je ne sais quel critère d'authentification.

Et 3D Secure est un protocole compliqué et onéreux à faire certifier. Donc banques et commerçants sous-traitent.
Et, au moins en france, toutes nos banques ont choisi de sous-traiter chez Atos. Yay.
Mais ça ne veut pas dire que 3D Secure est opéré par Atos, juste que toutes les banques françaises mettent leurs oeufs dans le même panier. Rassurez vous… Dans la chaine, y'a des serveurs de Visa et Master Card qui restent sous juridiction US, ne crions pas à une victoire patriotique trop tôt. Une transaction non-3D Secure peut être inconnue des États-Unis, une transaction 3D-Secure non.

En tout cas, bravo Atos pour l'échec critique !

Tout à fait, la capture d'écran me paraissait assez claire : on y voit en hexadecimal le logo de Stern Pinball.
Cf un futur journal pour les détails sur ce fichier :)

Merci, je regarderai.

Pour le moment, je prévoyais de m'amuser avec mon éditeur hexadécimal…

J'ai joué avec les contrastes pour que ça soit lisible… Sur la toute droite c'est l'éditeur hexadécimal qui affiche les offset, au milieu les valeurs en hexa et à droite décodées en ascii…

Et j'oublie le principal dans la question… dans le giga, 99% des données c'est vraiment les données du jeu (image.bin). Je n'ai pas encore analysé, mais il y a probablement :
- toutes les vidéos en 4/16 couleurs sans aucune forme de compression
- tous les sons, sans aucune compression
- toutes les polices, sans aucune compression (je me répète ?)

J'ai parcouru un peu le fichier à l'éditeur hexadécimal et ça ressemble vraiment à du stockage sous cette forme (on voit des formes se dessiner en de-zoomant)
Mais sans aucune forme de compression, une vidéo de 128x32 pixels, en disons 4 couleurs, 30 FPS… déjà 240 kB par seconde. Juste quand tu gagnes une extra-ball, t'as une vidéo de ~5 secondes, donc l'extra coûte 1200 kB. Et des animations sur cet écran, il y en a beaucoup beaucoup.
Et si on ajoute à ça les fichiers sonores, on part sur du volumineux, nécessairement.

Après si ça se trouve, les sons sont en MP3 dégueu, les images compressées à mort, les polices dans d'autres fichiers… mais j'y crois pas :)

Alors dans l'archive d'un giga, il n'y a pas tout le système (!!). Il n'y a pas le shell par exemple, donc les scripts ne risquent pas de marcher.

Tout est sur une carte SD, mais où était le fun de prendre la carte SD pour la brancher sur un PC plutôt que d'analyser le contenu de l'archive ? :) (plus sérieusement, j'ai préféré jouer avec le flipper que l'ouvrir pour le moment, et en plus comme ça vous pouvez «reproduire»)

Sinon quelques chaines intéressantes extraites de la mise à jour :
- GCC: (Sourcery CodeBench Lite 2014.05-29) 4.8.3 20140320 (prerelease)
- /scratch/maciej/arm-linux-2014.05-rel/obj/glibc-2014.05-29-arm-none-linux-gnueabi-i686-pc-linux-gnu/default/csu/abi-note.o

Ça semble correspondre à un usage de ça : https://sourcery.mentor.com/GNUToolchain/release2795
Ils auraient sûrement à gagner à utiliser buildroot, j'enverrai peut-être mon CV pour leur proposer de l'aide :)

J'ai hâte de voir si tu arrives à décompiler le image.bin, on pourrait imaginer changer les règles du flipper !

Je pense pas que les règles seront dans le image.bin hélas, à mon avis ça sera plutôt dans l'exécutable game à côté… Ça m'étonnerait qu'ils utilisent un système de script pour le jeu… Mais c'est à suivre…

Et sinon c'est le modèle de gauche sur la photo, le «pro».

Alors, dans les changelogs, y'a :
1) correction de bugs ou de fautes sur les messages (et il en reste… ils doivent pas avoir de correcteur sur leur éditeur)
2) ajout de nouvelles fonctionnalités…

Cf. http://f0727d06e1d39b514478-a613b39d02a32124478c749a23d19af0.r44.cf5.rackcdn.com/ghostbusters-1_13-README.txt

On n'est pas sur un flipper mécanique, y'a un gros écran de DEL avec au moins un endroit où tu déclenches des jeux interactifs, sans bille, à contrôler au flipper

J'ai oublié de le préciser : le flipper n'est pas connecté à internet, y'a pas de prise réseau… Donc même si ils avaient utilisé OpenSSL 0.9 j'aurais pas critiqué.
Et donc l'outil de communication, imposé dans ma boite hélas, c'est Zoom…

En rust ça compile pas :

error: bitshift exceeds the type's number of bits, #[deny(exceeding_bitshifts)] on by default
 --> src/main.rs:3:9
  |
3 |     a = a >> 64;
  |         ^^^^^^^

error: aborting due to previous error

Tu veux rire un peu ? Regarde ton mail en texte brut, ils ont fait une erreur à l'envoi (en tout cas sur celui que j'ai eu)

Le même mail :
- en texte brut : « You are receiving this email because you are one of the customers where our team was able to identify data that was leaked due to the bug and stored in one of these third party caches. »
- en HTML : « Your domain is not one of the domains where we have discovered exposed data in any third party caches. »

Donc les plus barbus avec mutt et cie (ou avec un lecteur de mail configuré pour le texte brut) vont paniquer, pour les autres c'est bon rien de grave…

Ouais, t'as de la chance, tu aurais pu recevoir « You are receiving this email because you are one of the customers where our team was able to identify data that was leaked due to the bug and stored in one of these third party caches.»
Beaucoup moins fun…