Desperate Switcher

Donne moi l'heure, je te dirai qui tu es.

2012-01-23T14:39:00.003+01:00

Je suis un peu un maniaque de l'heure, et j'aime bien à l'occasion ou professionnellement vérifier que les sites Web renvoient une heure correcte dans l'entête HTTP Date. C'est bien souvent un signe intéressant (mais ni nécessaire, ni suffisant) de la qualité de l'administration d'une plateforme.

Il y a en effet de multiples raisons pour que les serveurs Web soient tenus correctement synchronisés avec l'heure légale :

L'horodatage des journaux (HTTP, mais aussi applicatifs) afin de pouvoir déboguer ou enquêter après un incident de sécurité. Il n'y a rien de plus frustrant lors d'une enquête forensique d'être obligé de jongler avec les décalages horaires de systèmes entre eux (web, firewall, base de données, ...).
Le fonctionnement des caches Web, de l'expiration des sessions et parfois de la cryptographie peut nécessiter d'avoir une horloge pas trop désynchronisée entre serveur et clients.
Il peut y avoir des nécessités légales, notamment sur les sites marchands ou bancaires.

L'examen du champ Date envoyé par le serveur doit être fait avec prudence : en effet, le RFC 2616 sur HTTP 1.1 explique que ce champ est inséré par le serveur lors de la création du document, mais pas forcément celui de son envoi. Pour être raisonnablement sûr que la date renvoyée soit bien celle de l'horloge système du serveur, il faut donc :

Demander un document dynamique, par exemple avec un paramètre variable dans l'URL ;
Positionner les entêtes Cache-Control et Pragma pour demander à un cache éventuel de récupérer le document original ;
Tester que cela fonctionne en examinant les entêtes et vérifiant que la date varie convenablement avec le paramètre !

On peut alors comparer l'heure présente dans la réponse du serveur avec celle du serveur, en essayant de tenir compte du temps de transfert du réseau et de la préparation de la requête (résolution DNS, connexion TCP). Il faut noter que le champ Date n'offre qu'une précision à la seconde. Afin de garantir des transferts les plus courts possibles, il est quand c'est possible préférable d'utiliser la méthode HEAD afin de ne lire du réseau que les entêtes de la réponse.

J'ai voulu vérifier la bonne synchronisation d'un nombre raisonnable (80) de sites français, en le faisant sur la durée (plusieurs semaines) et de manière automatisée. J'ai divisé les sites cibles en 8 catégories un peu arbitraires :

Les sites de l'Etat (Présidence de la République, ministères, assemblées) ;
Les sites des "Hautes Autorités" ou agences associées à l'Etat, florissantes depuis une dizaine d'années ;
D'autres services publics (Sécurité Sociale, Météo, ...) ;
Les sites des principaux partis politiques qui seront représentés à la prochaine élection présidentielle ;
La presse quotidienne nationale et régionale ;
Les chaînes de télévision ayant une diffusion sur la TNT ;
Les opérateurs télécoms, FAI, l'AFNIC et quelques hébergeurs parmi les plus connus (liste un peu arbitraire) ;
Les principales banques de dépôt.

Les URLs des sites sont disponibles ici en format texte.

Le programme écrit en C utilise libcurl pour les requêtes HTTP et une base de données MySQL pour le stockages des sites, des paramètres et des résultats. Le programme et la base de données utilisée (sans les résultats) sont disponibles ici en licence WTFPL.

Les résultats bruts peuvent être obtenus en interrogeant la base de données, en utilisant la requête SQL select sites.url,abs(avg(delta_time)),stddev(delta_time) from sites,results where sites.sites_id=results.sites_id group by results.sites_id order by 2. Les résultats sont bien meilleurs que ce à quoi je m'attendais : la plupart des sites ont un écart de moins de deux secondes avec l'heure du serveur effectuant les essais (lui même bien synchronisé par ntpd).

Les sites les moins précis sont donnés ci-dessous. Les écarts de temps sont donnés en millisecondes :

| left(sites.url,40) | abs(avg(delta_time)) | stddev(delta_time) |

...

| http://www.prosodie.fr/?id={TS}          |            1085.8544 |           812.5083 |
| http://www.direct8.fr/actu-info/         |            1267.8511 |          2870.3213 |
| http://www.nrj12.fr/?id={TS}             |            1446.9191 |          1429.6998 |
| http://www.liberation.fr/?id={TS}        |            1540.4272 |           933.0153 |
| http://www.has-sante.fr/portail/jcms/j_5 |            1989.6861 |          1360.3114 |
| http://www.defense.gouv.fr/?id={TS}      |            2566.4304 |          1786.1356 |
| http://www.sante.gouv.fr/?id={TS}        |            2817.6602 |          1687.9689 |
| http://www.frontnational.com/?id={TS}    |            3022.6440 |          1720.3847 |
| http://www.humanite.fr/?id={TS}          |            4042.3495 |          5538.7156 |
| http://www.csa.fr?id={TS}                |            4681.3819 |          3369.7041 |
| http://www.hadopi.fr/?id={TS}            |            5691.7120 |          5018.6053 |
| http://www.afnic.fr/?ts={TS}             |            7170.0154 |          8571.1347 |
| http://www.gandi.net/?id={TS}            |            9327.2589 |          2562.1840 |
| http://www.industrie.gouv.fr/?id={TS}    |           17408.0421 |          1659.7796 |
| http://www.banquepopulaire.fr/scripts/gr |           46421.9612 |         29731.3730 |
| https://www.lcl.fr/?id={TS}              |          138442.5890 |         15340.1387 |
| http://www.online.net/?id={TS}           |          227520.5761 |         71500.8101 |
| http://www.cnil.fr/?tsid={TS}            |          233297.6472 |        113715.0501 |

On peut remarquer que deux banques figurent parmi les sites les moins synchrones ! Deux grands hébergeurs figurent également parmi les moutons noirs, ainsi que la CNIL (233s de décalage quand même) et l'Hadopi. Tous ces sites n'utilisent probablement pas de synchronisation NTP ...

Des observations également intéressantes peuvent être faites, notamment sur le site AFNIC, ou un serveur non synchronisé (sur 2 ou 3 serveurs cachés derriere www.afnic.fr) pollue la moyenne, ainsi que cela peut être vu dans le graphe obtenu grâce à l'exportation des données :

2586 > export site 87 afnic.txt
259 results exported to afnic.txt

On peut aussi observer la dérive sur 10 jours du serveur de la CNIL, ou là aussi deux serveurs (l'un en avance de 12 secondes, l'autre de 35) se mélangent probablement :

La dérive est également importante sur le serveur Prosodie, ou visiblement une synchronisation nocturne par tâche programmée remet les choses en l'ordre (ce qui n'est pas optimal et peut causer des problèmes système puisque non monotone) :

Il sera intéressant de constater comment les sites les plus synchrones vont digérer la seconde intercalaire (leap second) qui sera insérée le 30 Juin à minuit (si tant est que le serveur effectuant la mesure la gère bien ...).

Si vous êtes un des administrateurs des sites testés et que vous désirez être enlevés de cette étude (qui va continuer encore quelques semaines), ou que vous vouliez récupérer les données brutes vous concernant, écrivez moi à timesurvey at rominet dot net .

Sponsors du G20 ??

2011-11-03T10:42:00.001+01:00

Ce matin je découvre grâce à twitter que le G20 est sponsorisé (on parle de "partenaires") par une ribambelle d'entreprises françaises , dont certaines ont du payer plus que d'autres puisqu'elles ont le statut de "soutien officiel" .

Sur le même site Web, on rappelle fort judicieusement les objectifs de la présidence française , parmi lesquels :

2 - Renforcer la régulation financière
La présidence française veillera à la mise en œuvre effective des règles décidées par le G20 pour renforcer durablement le contrôle du secteur financier. Elle s'emploiera aussi à renforcer la régulation financière dans les domaines où elle reste insuffisante, par exemple en matière de régulation du « secteur bancaire fantôme » (activité bancaire parallèle non régulée à ce jour) et d'intégrité et de transparence des marchés financiers.
6 - Agir pour le développement
Le G20, qui représente 85% de l'économie mondiale et les deux tiers de la population de la planète apparaît aujourd'hui comme une enceinte pertinente pour apporter des solutions concrètes aux problématiques du développement.

Comment peut-on être hyprocrite à ce point ? Comment ne pas voir le conflit d'intérêt gigantesque causé par la présence parmi les sponsors d'une banque, notamment connue pour son activité sur les marchés de futures ? Et parler de développement sous la bannière d'une entreprise qui vit de la privatisation de l'eau ?

Les conférences de presse officielles se feront-elles bientôt, a l'instar des sportifs, devant le panneau des sponsors ? Imagine-t-on De Gaulle, Mitterrand (pour ne citer que des personnalités françaises) venir débattre de l'avenir du monde (ou faire semblant) dans un sommet sponsorisé par Dior ou Bic ?

C'est tout simplement hallucinant (je découvre cela, peut être la dérive dure t-elle depuis des années).

On va me dire que grâce à ça, le contribuable est moins sollicité ... Je réponds que ça n'a aucune importance, et que la compromission est bien pire que l'impôt.

Comme le dit quelqu'un : "Tous dehors !".

Référé contre FAI (2)

2011-10-14T18:23:00.007+02:00

Bon, je suis allé à l'audience de délibéré, sauf que ce n'était pas dans la même salle que la dernière fois (je pense que c'était dans le bureau du juge en fait), et donc que je n'ai pu qu'écouter ce qu'ont dit les avocats à la sortie ...

Mme le Juge des référés a donc demandé aux 6 FAI de bloquer le site complet par filtrage IP ou DSN (sic).

Cette décision est tout sauf une surprise pour moi :

Le blocage par URL n'était pas possible, d'abord parce que le site n'est accessible qu'en HTTPS (argument peu développé à l'audience et pas repris dans le jugement) et, nonobstant cette particularité, parce que le filtrage par URL demanderait l'installation de systèmes DPI que les FAI affirment ne pas posséder ;
Le délit est constitué (Injures, Collectes de données personnelles) au vu de la loi (1881 pour l'injure, loi du 6 Janvier 1978 pour les données) ;
La LCEN prévoit depuis 2004 que les fournisseurs peuvent être requis dans le cas ou l'hébergeur ne peut pas l'être.

Le juge n'avait donc pas beaucoup de raisons de refuser la demande à mon sens, et donc d'imposer la mesure la plus limitée techniquement possible : bloquer l'accès complet. La mesure est temporaire, en attendant l'issue des plaintes déposées par le Ministère de l'Intérieur. Ce qui est très intéressant, c'est que le jugement reconnait que les FAI seront indemnisés pour le blocage (c'est le moment de faire développer le DPI dans les *BOX avec les sous de l'État !). Il n'y a pas d'astreinte, considérant que les FAI ne sont pour rien dans le délit initial et qu'ils sont de bonne volonté.

Bien sûr tout le monde sait que le site va changer de domaine, d'adresse IP, qu'on peut utiliser des serveurs DNS qui ne sont pas ceux du FAI, que des dizaines de mirroirs existent, qu'on peut utiliser Tor ou un proxy au Belouchistan, ... et donc que cette mesure n'empêchera pas complètement l'accès au site. Je pense simplement que le Ministère ne pouvait pas donner l'impression de laisser tomber les policiers, surtout vu les échéances à venir, et que cette préoccupation est sans doute la principale motivation de cette action.

Plusieurs questions et réflexions :

Pourquoi attaquer ces 6 FAI et pas d'autres, même s'ils sont plus petits (Nerim, FDN, ...) ?
Ce blocage n'affectera évidemment que les FAI résidentiels, les accès en entreprise ne sont, pour la plupart, pas concernés (il aurait fallu imposer un blocage IP au niveau de tous les opérateurs de transit IP en France) et je suis notamment sûr qu'il restera accessible depuis beaucoup d'administrations bien après que les FAI aient appliqué la demande ^^ ;
Je n'ai toujours pas compris pourquoi Gandi, bureau d'enregistrement du domaine, n'a pas été assigné, alors qu'il était le plus à même de faire cesser l'infraction de manière plus définitive ;
Est-ce que ce jugement peut en amener d'autres avec des requérants moins régaliens ? Pour ma part, je pense que l'effet "Streisand" déjà en cours et les contournements possibles sont de puissants freins, et je ne le pense donc pas ;
On m'a demandé si les miroirs étaient visés : la Justice a pris déjà une décision en une semaine, elle ne peut pas juger quelque chose qui est apparu hier ... Mais j'espère pour eux que les gens qui font des miroirs ont l'intelligence d'être très bien cachés et sont courageux, parce que le Ministère n'a pas l'air de plaisanter...

Une dernière réflexion personnelle : quand les gens d'un bord politique précis, élus sans discontinuité depuis 2002, disent qu'ils veulent "réguler" et "civiliser" l'Internet, et bien au final, contre toute attente, ils le font ! Ils ont certainement tort, mais ils ont une certaine légitimité pour faire la loi, et la Justice l'applique. Dans une République, le peuple fait changer la loi en élisant des députés et un exécutif, d'abord en votant, et, pour les plus courageux, en militant dans de vrais partis politiques, et pas seulement des groupes de pression ne luttant que pour "la neutralité du Net" ou "Hadopi caca ..". Quand nous aurons de nouveau compris cela, collectivement, alors beaucoup de choses iront mieux.

Référé contre les FAI.

2011-10-12T14:13:00.013+02:00

Comme je l'ai narré sur twitter, je suis allé ce matin à l'audience publique du référé intenté par Claude Guéant, Ministre de l'Intérieur contre 6 Fournisseurs d'accès internet (France Telecom Orange, SFR, Free, Numéricable, Bouygues Telecom et Darty Telecom) afin de faire interdire l'accès par leurs abonnés à certaines pages du site Copwatch.

Ce site (dont l'hébergeur est américain ainsi que le montre Spyou, et dont le domaine a été fourni par le bureau d'enregistrement français Gandi) diffuse des photos de policiers en civils, ainsi que pour certain d'entre eux, leur identité complète. Le site est clairement anti-flics, voire franchement haineux. Je n'ai pas de raison particulière d'aimer la police, ni de la détester d'ailleurs, et je trouve ces méthodes au moins aussi lamentables que les actions qu'elles prétendent dénoncer.

A vrai dire, s'il n'y avait pas eu cette assignation ni les plaintes pénales que le Ministère a formé, je pense que ce site serait passé inaperçu, au moins du grand public.

Ce qui m'intéressait, c'était de voir comment la Justice allait se débrouiller avec une énorme contradiction technique :

Afin de ne pas apparaître trop comme un censeur, le Ministre demandait le filtrage de certaines pages seulement (les pages injurieuses et celles contenant des coordonnées de policiers) ;
Le site n'est accessible qu'en HTTPS.

Même le meilleur système de DPI ne saurait résoudre directement cette équation, puisque l'analyse des URLs demandées par le navigateur nécessiterait de déchiffrer le trafic SSL et donc de pouvoir générer des certificats validés par le navigateur. Ce n'est évidemment pas impossible, l'attaque récente sur les internautes iraniens après le piratage de DigiNotar le montre, mais cela impliquerait évidemment qu'une autorité reconnue par un nombre suffisants de navigateurs, par exemple l'autorité de certification IGC/A du SGDN soit implantée dans le système DPI chez chaque FAI et génère des certificats à la volée. Inutile de dire que ce n'est pas son rôle (mais si on a des doutes on peut toujours la désinstaller de son navigateur).

Etonnament, cet argument a été peu utilisé par les avocats de la Défense, qui ont plaidé à tour de rôle. Seul l'avocat d'Orange qui a parlé en premier l'a abordé, mais en étant presque incompréhensible (dur pour moi de ne pas intervenir à ce moment, ceux qui ont travaillé avec moi voient de quoi je parle ^^).

Ils ont tous mis en avant évidemment l'impossibilité technique de filtrer par URL sans installer de coûteux systèmes DPI (qu'ils jurent tous ne pas avoir, alors qu'on sait qu'au moins pour les accès smartphone, c'est faux), et ont expliqué qu'ils pouvaient si on les forçait, filtrer par DNS ou par IP (et SFR a eu l'intelligence d'expliquer que c'était très inefficace) en utilisant le rapport rédigé par la FFTCE à l'occasion je crois de la loi LOPSI2.

L'avocat du Ministère a répondu par avance dans son exposé que ce n'était pas son problème, et que la loi LCEN de 2004 obligeait les fournisseurs d'accès à filtrer si l'hébergeur n'est pas contactable ou n'est pas facilement sanctionnable : "Peu me chaut" a-t-il répété.

En étant tellement éloigné de la réalité (je ne peux pas croire qu'aucun expert du Ministère n'a pu l'aider, j'en connais), on peut même se demander si son but final n'était pas de faire passer le message "Nous voulions filtrer seulement certaines pages, ces crétins d'informaticiens ne peuvent pas, alors maintenant tout le site est bloqué".

L'avocate du syndicat de policiers "Alliance" a tenu le même propos, en expliquant qu'un policier avait reçu une cartouche dans sa boîte à lettres et que la montée de la haine contre la Police inquiétait les fonctionnaires.

Le reste de l'audience était très intéressant, avec des différences subtiles entre les FAI :

chez Bouygues on explique qu'on peut pas filtrer l'URL mais qu'on est prêt si on le demande à faire du blocage DNS ;
chez SFR on explique qu'on est prêt à bloquer l'adresse IP du serveur ;
chez Orange on explique rien mais évidemment on est prêt à bloquer si la justice demande ;
chez Free on explique que la France n'est pas la Chine et qu'on veut pas de DPI (mais évidemment sans le dire ils mettront une route vers Null0 si on leur demande) ;
chez Darty on explique "C'est pas nous !" puisque le réseau est sous traité et que toutes les fois que la police judiciaire demande quelque chose, on se défausse (^^).

Free a eu l'intelligence de demander pourquoi GANDI n'avait pas été assigné : si les coordonnées données lors de l'enregistrement du domaine sont fausses, comme semble le penser la police, alors il viole la charte ICANN et peut être suspendu. C'est effectivement bizarre, d'autant qu'il y a des précédents et que les Registrars bloquent chaque jour beaucoup de domaines pour spam, escroquerie, malware sans aucune décision de justice !

En revanche ils étaient tous d'accord pour demander une indemnisation en cas d'ordre de blocage, et certains (SFR, Darty, Free) à passer par la case de la Question Préalable de Consitutionnalité si elle n'était pas accordée, en invoquant par exemple la Déclaration des Droits de l'Homme de 1789 (arguant le fait qu'un tiers aidant la justice doit être rémunéré). Ils étaient également tous très très mécontents de la demande d'astreinte de 2000 euros par jour de retard, en expliquant qu'ils n'étaient coupables de rien et collaboraient avec la Justice toutes les fois qu'elle le demandait ...

Le procureur après avoir expliqué que l'infraction initiale semblait constituée et que les dommages (pour les policiers visés par le site) étaient réels, a expliqué qu'il était inutile de demander une mesure ne pouvant être appliquée (le filtrage des URLs) mais qu'elle demandait un filtrage par IP ou par DNS (ce qui revient à bloquer tout le site). Elle était en revanche opposée à l'astreinte qui ne peut s'appliquer qu'en cas de mauvaise foi et de résistance, et pensait également que les FAI devaient être défrayés.

Le jugement a été placé en délibéré et sera rendu le Vendredi 14/10 (après demain) à 17h. J'essaierais d'y aller également.

Je pense que le juge va suivre le procureur (après tout la loi a été votée il y a 7 ans et elle prévoit ce cas), mais qu'on en a pas fini avec cette histoire ... Je pense que le Ministère a bien manoeuvré en demandant "le retrait de quelques pages" en sachant très bien que ce n'était pas faisable ...

Je serais les FAI, je commencerais à faire une annonce BGP bidon pour plein de /32 allant dans Null0 (enfin ils l'ont certainement déjà) et/ou une procédure pour mettre des trous noirs dans les serveurs DNS.

En attendant, le site CopWatch a déjà au moins 25 miroirs ...

Les Hackers dans l'espaaaaaaaaaaaaace !

2011-01-31T16:10:00.005+01:00

Il y a 40 ans exactement aujourd'hui, Apollo 14 était lancé vers la Lune. Alan Shepard et Edgar Mitchell devaient se poser près du cratère Fra Mauro, déjà sélectionné pour la mission précédente Apollo 13 qui se termina comme on le sait.

La mission se déroula relativement normalement jusqu'à la préparation de la descente (PDI, Powered Descent Initiation), pendant laquelle les contrôleurs de vol (notamment le GUIDO) détectèrent que l'ordinateur de bord du LM recevait un signal électrique indiquant que le bouton ABORT était enfoncé.

Ces deux boutons jouent un rôle fondamental : ils permettent au commandant de terminer la descente en cas de problème grave ne permettant pas un alunissage en sécurité : le premier effectue un abandon avec le moteur de descente, le second (ABORT STAGE) sépare l'étage de descente et allume le moteur de remontée.

Evidemment avec une indication que le bouton est enfoncé, dès le début de la descente, elle allait être arrêtée sans possibilité de continuer ... Les contrôleurs demandèrent alors à l'équipage d'effectuer la plus vieille manoeuvre de l'informatique : tapoter sur le panneau de contrôle ... Et miracle le bit correspondant (Channel 30, Bit 1) à ABORT s'effaça ... pour revenir quelques minutes plus tard : il y avait bien un faux contact (non détecté sur terre mais probablement lié à l'apesanteur) dans l'interrupteur.

Il fallait donc trouver rapidement (les trajectoires et les réserves du LEM imposaient d'atterrir apres au maximum deux orbites complètes en parking autour de la lune) une procédure afin de permettre :

d'ignorer le bouton ABORT pendant la descente ;
pouvoir effectuer un abandon manuel rapidement en cas de problème.

L'ordinateur des vaisseaux Apollo (AGC : Apollo Guidance Computer) avait été conçu et programmé par une équipe du MIT. Il était utilisé dans le CSM et dans le LM, avec des logiciels légèrement différents. C'était un ordinateur très avancé pour son temps, utilisant des circuits intégrés, équipé de 36 kilomots de 15bits de mémoire morte et 2048 mots de mémoire vive, avec une horloge de 2MHz. Il était surtout équipé d'un séquenceur temps réel et gérant des priorités, capable de se redémarrer sans perte, ce qui sauva le premier alunissage.
Il faut bien comprendre que les programmes étant stockés en ROM, il était impossible de les modifier en vol, et que la très faible mémoire vive disponible ne permettait pas d'implémenter un patch logiciel. Enfin le fonctionnement de la télémétrie ne permettait pas au MCC d'envoyer autre chose que des données de vol (principalement positions et constantes d'équations de trajectoire).

Aujourd'hui, grâce à quelques fous, il est possible de simuler l'AGC sur n'importe quel micro, et surtout les codes sources des programmes utilisés par la NASA sont disponibles (ils ont été scannés) et compilables (les programmes sont écrits dans un assembleur d'assez haut niveau). La documentation "utilisateur" est disponible pour le logiciel utilisé sur Apollo-15.

Les signaux issus des boutons ABORT sont gérés par la routine R10, appelée 4 fois par seconde, et ne sont gérés évidemment que quand un "BURN" est en cours, ce qui correspond lors de l'alunissage aux programmes P63 (Descente), P64 (Freinage final) et P66 (Vol manuel lors de l'alunissage). Pour cela, un flag LETABRT autorisant l'abandon est positionné dans la mémoire. A l'époque, tout le monde était root , y compris les astronautes, et ils pouvaient donc repositionner n'importe quel bit dans la mémoire de l'AGC : il était donc tentant de vider simplement ce flag. Malheureusement, la routine de démarrage du moteur (appellée BURNBABY) la positionne dès que le moteur est allumé : quelque soit la rapidité des astronautes, il y avait donc un risque d'une race condition si le petit bout de métal probablement dans l'interrupteur se manifestait à ce moment là ...

Heureusement, R10 effectue également un autre test : elle vérifie qu'il n'y a pas dejà un ABORT en cours en vérifiant avant de les placer dans le séquenceur que les programmes P70 ou P71 ne sont pas déjà lancés. Pour celà, elle vérifie que la variable MODREG contenant normalement le programme principal en cours n'a pas la valeur 70 ou 71.

Don Eyles, un des programmeurs du MIT, a alors eu la bonne idée de proposer un gros hack à la NASA : demander à l'équipage, après l'initiation du programme P63, lancé quelques minutes avant la descente et qui va se charger d'allumer le moteur, de changer MODREG en mémoire par 71 : ainsi la routine R10 sera bypassée. Dès que le moteur sera démarré, la variable LETABRT sera remise à 0 par l'équipage, puis MODREG repositionné sur 63.

Malheureusement rien n'est simple en informatique, et la routine BURNBABY vérifie elle même si le programme actuel est P63 : si oui, alors elle programme la mise en route à 100% du moteur après 26 secondes, et place un bit (ZOOMFLAG) indiquant que les données venant du radar d'alunissage doivent être prises en compte pour la suite des calculs de trajectoires. Avec P71 dans MODREG, pas de THROTTLE UP ni de calcul de trajectoire !

Pas grave : l'homme étant, comme disait Von Braun, « le meilleur ordinateur pouvant être mis dans un vaisseau spatial et le seul pouvant être produit par une main d'oeuvre non qualifiée », les astronautes sont capables de positionner manuellement le moteur à 100% après 26 secondes, puis de positionner rapidement ZOOMFLAG dans la mémoire de l'AGC.

La méthode finale fut donc la suivante :

Après que le programme P63 soit lancé mais avant l'allumage, placer MODREG sur 71 ;
A l'allumage du moteur, compter 26" avec un chronomètre ;
Pousser le moteur à 100% ;
Mettre ZOOMFLAG à 1 ;
Mettre LETABRT à 0;
Remettre 63 dans MODREG.

Pour cela, les astronautes ont utilisé le DSKY (clavier de l'AGC) , dont l'interface basique reposait sur la notion de VERB (action) et de NOUN (objet) ainsi VERB 01 permet d'afficher une donnée, NOUN 01 indique que c'est une adresse en mémoire qui est demandée, alors que NOUN 35 indique que l'on veut lire l'horloge.

La séquence ci-dessus est donc la suivante :

VERB 21 NOUN 01 ENTER 1010 ENTER 107 ENTER (1010 est l'adresse de MODREG, 107 = 71 en octal)
Démarrage et poussée
VERB 25 NOUN 7 ENTER 101 ENTER 200 ENTER, 1 ENTER (101 est l'adresse du mot contenant ZOOMFLAG, 200 le masque octal, 1 la valeur finale)
VERB 25 NOUN 7 ENTER 105 ENTER 400 ENTER, 0 ENTER (105 est l'adresse du mot contenant LETABRT, 400 le masque octal, 0 la valeur finale)
VERB 21 NOUN 01 ENTER 1010 ENTER 77 ENTER (remise dans MODREG de 77 = 63 en octal)

Pour remettre en place le flag LETABRT en cas d'abandon réel demandé, il suffisait donc de rentrer VERB 25 NOUN 7 ENTER 105 ENTER 400 ENTER, 1 ENTER. Cela peut prendre quelques secondes, ce qui peut suffire à tuer les astronautes en cas d'abandon très près de la lune, mais cela a été jugé comme étant un risque acceptable.

Tout se passa comme prévu, et Alan Shepard put finalement aller taper quelques balles de golf sur la lune ("Miles and miles ...").

Le fait que les astronautes puissent écraser n'importe quelle valeur dans l'AGC n'était pas forcément connu, et cela a d'ailleurs posé problème lors du retour d'Apollo 11 quand Michael Collins, en oubliant de taper un NOUN a écrasé (temporairement) les valeurs envoyés par la plate-forme inertielle (descendre à 158:20:40).

Je ne suis pas sûr du tout qu'aujourd'hui un contournement serait aussi facile à implémenter sur un système d'exploitation moderne (et donc plus sécurisé) et des programmes utilisant des langages de haut niveau.

L'exploration des logiciels d'Apollo et leur simulation est en tout cas passionnante, notamment parce qu'elle montre comment programmer dans un environnement restreint, et il faut remercier les tarés qui ont scanné le code source et l'ont sauvé de l'oubli.

Apollo Surface Journal : http://www.hq.nasa.gov/office/pao/History/alsj/frame.html
Apollo Flight Journal : http://history.nasa.gov/afj/
Virtual AGC : http://www.ibiblio.org/apollo

Sleep Proxy

2010-10-29T11:53:00.009+02:00

Cet article a été rédigé initialement pour la NewsLetter HSC.

Les administrateurs réseaux vigilants observent des changements incessants de correspondance Adresse IP/Adresses MAC dans un réseau Ethernet contenant de nombreux Macintosh sous OSX 10.6.

Ce symptôme est causé par l'activité du "Sleep Proxy Server" présent sur les versions récentes de MacOS X (10.6) et des équipements Apple AirPort et TimeCapsule.

Il a pour but de permettre aux Macs proposant des services (SSH, Prise de contrôle à distance, partage de fichiers AFP ou SMB) de pouvoir passer en veille en l'absence d'activité, mais de revenir sur le réseau quand un autre équipement a besoin de lui.

Le fonctionnement repose sur le protocole Bonjour (appellation Apple du Multicast DNS) et sur l'élection d'un "Sleep Proxy" sur le réseau (un équipement ou un Mac OS X 10.6 avec l'option "Internet Sharing" activée), qui va maintenir une liste des systèmes et des services disponibles, puis, lors de leur passage en veille, répondre _à leur place_ aux requêtes ARP, récupérer le premier paquet de la connexion IP demandée, et s'il correspond à un service présent, envoyer un paquet Wake On Lan au système endormi.

La réponse aux requêtes ARP par le système proxy (qui envoie également des gratuitous ARP quelques secondes apres le passage en veille du système proxié) provoque évidemment une détection par les outils tels qu'ArpWatch ou dans les journaux des systèmes. Elle est également détectée par les fonctionnalités de "DHCP Snooping" des équipements réseaux.

Ci-dessous une trace prise sur un système FreeBSD :


Oct 28 10:13:13 fw kernel: arp: 192.70.106.117 moved from 00:16:cb:8b:8a:45 to 00:25:4b:a7:ea:f6 on vlan0
Oct 28 10:16:34 fw kernel: arp: 192.70.106.117 moved from 00:25:4b:a7:ea:f6 to 00:16:cb:8b:8a:45 on vlan0
Oct 28 13:17:50 fw kernel: arp: 192.70.106.117 moved from 00:16:cb:8b:8a:45 to 00:25:4b:a7:ea:f6 on vlan0
Oct 28 13:41:15 fw kernel: arp: 192.70.106.117 moved from 00:25:4b:a7:ea:f6 to 00:16:cb:8b:8a:45 on vlan0

00:16:cb:8b:8a:45 est l'adresse réelle de la machine 192.70.106.117, 00:25:4b:a7:ea:f6 est celle du Mac élu "Sleep Proxy" (192.70.106.76), qui a généré la trace suivante dans ses journaux :


Oct 28 10:16:31 removed mDNSResponder[18]: Waking host at en0 192.70.106.117 H-MAC 00:16:CB:8B:8A:45 I-MAC 00:16:CB:8B:8A:45 for 33 HSC?s\032MacBook\032Pro\03215"._ssh._tcp.local. SRV 0 0 22  HSCs-MacBook-Pro-15.local.

Le passage en veille du système à 10:13 génère le trafic suivant (les paquets IPv6 ne sont pas montrés) :

Recherche du Sleep Proxy et réponse :

10:13:00 192.70.106.117 -> 224.0.0.251  MDNS Standard query PTR _sleep-proxy._udp.local, "QM" question 10:13:00 192.70.106.76 -> 224.0.0.251  MDNS Standard query response PTR 50-37-71-72 MBP XYZ._sleep-proxy._udp.local

Annonce par le système de son passage en veille par DNS Cache Flush :

10:13:07 192.70.106.117 -> 224.0.0.251  MDNS Standard query response SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _ssh._tcp.local PTR HSC\342\200\231s MacBook Pro 15"._ssh._tcp.local TXT SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _sftp-ssh._tcp.local PTR HSC\342\200\231s MacBook Pro 15"._sftp-ssh._tcp.local AAAA, cache flush fe80::216:cbff:fe8b:8a45 PTR,cache flush HSCs-MacBook-Pro-15.local A, cache flush 192.70.106.117 PTR, cache flush HSCs-MacBook-Pro-15.local AAAA, cache flush 2001:7a8:1155:0:216:cbff:fe8b:8a45 PTR, cache flush HSCs-MacBook-Pro-15.local

En examinant les TTL dans ce paquet, on verrait que les services sont annoncés avec une durée de vie d'une heure et 15 minutes.

Vérification par le Sleep Proxy que la machine ne répond plus :

10:13:11 192.70.106.76 -> 224.0.0.251  MDNS Standard query response SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _ssh._tcp.local PTR HSC\342\200\231s MacBook Pro  15"._ssh._ tcp.local TXT SRV, cache flush 0 0 22 HSCs-MacBook-Pro-15.local TXT, cache flush PTR _sftp-ssh._tcp.local PTR HSC\342\200\231s MacBook Pro 15"._sftp-ssh._tcp.local A, cache flush 192.70.106.117

Envoi des "Gratuitous ARP" afin de prévenir le réseau (les commutateurs et machines ayant gardé l'adresse MAC de 192.70.106.117) que l'adresse change (le changement est d'ailleur détecté par Wireshark) :

10:13:13 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request) (duplicate use of 192.70.106.117 detected!)
10:13:14 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request) (duplicate use of 192.70.106.117 detected!)
10:13:16 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request) (duplicate use of 192.70.106.117 detected!)

Le réveil à 10:16 lors d'une demande de connexion SSH depuis la machine 192.70.106.104 s'effectue ainsi :

Recherche de l'adresse MAC de 192.70.106.117 :

10:16:31 00:26:b9:e9:89:15 -> ff:ff:ff:ff:ff:ff ARP Who has 192.70.106.117? Tell 192.70.106.104

Réponse par le Sleep Proxy 00:25:4b:a7:ea:f6

10:16:31 00:25:4b:a7:ea:f6 -> 00:26:b9:e9:89:15 ARP 192.70.106.117 is at 00:25:4b:a7:ea:f6

Début de connexion SSH vers l'adresse MAC du sleep Proxy :

10:16:31 00:26:b9:e9:89:15 > 00:25:4b:a7:ea:f6, 192.70.106.104.33353 > 192.70.106.117.22: Flags [S], seq 4137326916

Paquet Wake On Lan envoyé sur le réseau par le sleep proxy :

10:16:31 00:25:4b:a7:ea:f6 -> ff:ff:ff:ff:ff:ff WOL MagicPacket for 00:16:cb:8b:8a:45 (00:16:cb:8b:8a:45), password 00:00:00:00:00:00

Réveil de la machine en veille, requête DHCP et envoi de Gratuitous ARP pour mettre à jour tout le monde :

10:16:34      0.0.0.0 -> 255.255.255.255 DHCP DHCP Request  - Transaction ID 0x2550f3c9
10:16:34 00:16:cb:8b:8a:45 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 192.70.106.117 (Request)
10:16:34 00:16:cb:8b:8a:45 -> ff:ff:ff:ff:ff:ff ARP Who has 169.254.255.255?  Tell 192.70.106.117
10:16:34 192.70.106.117 -> 224.0.0.2    IGMP V2 Leave Group 224.0.0.251

Suite de la connexion SSH vers la machine réveillée (répétition du SYN vers l'adresse MAC réelle, résolution ARP dans l'autre sens, puis réponse) :

10:16:34 00:26:b9:e9:89:15 > 00:16:cb:8b:8a:45, 192.70.106.104.33353 > 192.70.106.117.22: Flags [S], seq 4137326916
10:16:34 00:16:cb:8b:8a:45 -> ff:ff:ff:ff:ff:ff ARP Who has 192.70.106.104?  Tell 192.70.106.117
10:16:34 00:26:b9:e9:89:15 -> 00:16:cb:8b:8a:45 ARP 192.70.106.104 is at 00:26:b9:e9:89:15
10:16:34 192.70.106.117 -> 192.70.106.104 TCP 22 > 33353 [SYN, ACK] Seq=1107555458 Ack=4137326917

Le fait que le système en veille se réveille environ toutes les heures pour signaler au Sleep Proxy qu'il est encore connecté au réseau génère même en l'absence d'autre activité des basculements d'adresse MAC détectés par les systèmes ou les sondes de détection d'intrusion.

On peut s'interroger sur la fiabilité, la sécurité et la maintenabilité de tout ce système spontané dans un réseau comportant de nombreuses machines.

Références :

Wikipedia : http://en.wikipedia.org/wiki/Sleep_Proxy_Service
Une discussion sur une liste Sans : http://lists.sans.org/pipermail/unisog/2009-September/028169.html
Apple (mais l'article n'est pas clair sur le fait que des MacOS peuvent être Proxy) : http://support.apple.com/kb/HT3774
Le code source du Sleep Proxy, voir notamment la procédure mDNSCoreReceiveRawPacket qui répond aux ARP et filtre les connexions provoquant un réveil : http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-214.3.2/mDNSCore/mDNS.c

GERAAARD !

2010-10-20T16:03:00.005+02:00

Gérard a grandi et il fait de magnifiques présentations !

"Le pinard ca devrait etre obligatoire !"

Avec la technologie .NET ...

2010-10-14T20:36:00.003+02:00

... il devient difficile de faire ses courses !

On se téléphone et on se fait une bouffe ?

2010-10-11T17:28:00.004+02:00

Pas besoin d'aller aux Assises de la Sécurité discuter de la vie privée, du méchant Facebook et des horribles risques que les irresponsables employés font courir à l'entreprise en se connectant aux réseaux sociaux : il suffit d'y envoyer une machine et de sniffer le multicast du WIFI public pour savoir qui y était.

Merci aux Macintosh, iPhone, iPad et aux technologies Apple envoyant régulièrement le nom de machine (et parfois les services ouverts dans des Query SRV) à la terre entière.

Bug Bug Bug

2010-10-07T09:47:00.005+02:00

En allant sur
http://www1.euro.dell.com/fr/fr/domicile/Ordinateurs-de-bureau/inspiron-zino-hd-410/pd.aspx?refid=inspiron-zino-hd-410&s=dhs&cs=frdhs1&ref=dthp , on comprend qu'on a intérêt à être rapide pour trouver des pannes sur son Dell ZINO.

Et les gars on est en 2010 !

2010-10-05T13:46:00.003+02:00

Quand on a des dizaines de millions de clients, on se débrouille pour avoir des infrastructures DNS qui marchent :

Tracing to www.sfr.fr[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ d.ext.nic.fr [fr] (2001:0500:002e:0000:0000:0000:0000:0002) Not queried
|\___ d.ext.nic.fr [fr] (192.5.4.2)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ c.nic.fr [fr] (2001:0660:3006:0004:0000:0000:0001:0001) Not queried
|\___ c.nic.fr [fr] (192.134.0.129)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
| \___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
|\___ a.nic.fr [fr] (2001:0660:3005:0003:0000:0000:0001:0001) Not queried
|\___ a.nic.fr [fr] (192.93.0.129)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ f.ext.nic.fr [fr] (194.146.106.46)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ e.ext.nic.fr [fr] (2a00:0d78:0000:0102:0193:0176:0144:0006) Not queried
|\___ e.ext.nic.fr [fr] (193.176.144.6)
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| |\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
| \___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
|\___ d.nic.fr [fr] (2001:0678:000c:0001:0000:0000:0000:0001) Not queried
|\___ d.nic.fr [fr] (194.0.9.1)
| |\___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *
| |\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
| \___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * * *
|\___ g.ext.nic.fr [fr] (2001:0500:0014:6039:00ad:0000:0000:0001) Not queried
\___ g.ext.nic.fr [fr] (204.61.216.39)
|\___ ns2.sfr.fr [sfr.fr] (84.96.147.2) * Got authoritative answer
|\___ ns2.9services.com [sfr.fr] (84.96.147.1) * * *
\___ ns1.9services.com [sfr.fr] (84.96.72.129) * * *

ns2.sfr.fr (84.96.147.2) www.sfr.fr -> 80.125.163.172

Une réponse sur une trentaine d'interrogations, et ca dure depuis au moins 11h ce matin ...

No Line On The Horizon

2009-03-05T07:36:00.002+01:00

Christine Lagarde a déclaré que le gouvernement faisait "tout ce qui est nécessaire et possible pour maintenir la signature de la France, pour maintenir la notation triple A", qui constitue la meilleure note de solvabilité délivrée par les agences de notation.

Rappelez moi qui nous a mis dans la mouise, déjà ?

Lolggle

2009-01-31T15:47:00.004+01:00

WTF :

/o\ Oh my god, they killed THE INTERNET !

Leap Second

2008-12-16T09:09:00.013+01:00

Le 31 Décembre 2008 aura 86401 secondes. Enfin pour nous ce sera le 01/01/2009 à 01h00 : nous avons perdu à Waterloo et l'heure du méridien de Greenwich est devenu la base de l'UTC.

Vérifiez bien le 31 Décembre que vos serveurs NTP annoncent la leap second à venir (la sortie de la commande rv de ntpq doit montrer une valeur non nulle).

1176 at@khany:~> ntpq -n -c rv assID=0 status=4664 leap_add_sec, sync_ntp, 6 events, event_peer/strat_chg, version="ntpd 4.2.4p4@1.1520-o Fri Mar 7 20:24:07 UTC 2008 (1)", processor="i686", system="Linux/2.6.24-22-generic", leap=01, stratum=3, precision=-19, rootdelay=17.985, rootdispersion=107.325, peer=42101,

La très bonne page Wikipedia sur cet événement dont on avait perdu l'habitude, mais il semble que la terre recommence à ralentir :
http://en.wikipedia.org/wiki/Leap_second.

Le passage de la précédente Leap Second il y a 3 ans : http://www.at.usenet-fr.net/leap/ .

Alors ça c'est fait ...

2008-07-14T19:54:00.001+02:00

J'ai causé dans le poste en expliquant pourquoi l'Internet allait pas mourir demain :
http://www.france-info.com/spip.php?article160201

Debian/OpenSSL Debacle

2008-05-15T21:24:00.004+02:00

Parce qu'il vaut mieux en rire :

Velib \o/

2007-08-29T08:54:00.000+02:00

Bon mon quartier est envahi de nouveaux panneaux de pub, a tel point que ca en devient difficile à comprendre ...

On commence par une vue sur le carrefour Saussure/Pereire en venant de Pont Cardinet:

Un autre de l'autre coté qui masque aux voitures un panneau _assez_ important ...

Un gros plan sur l'espèce de monstre qui vient d'être installé ...

Une vision globale du carrefour ...

Etrange, Etrange, juste à coté il y a ça \o/

Mais ca ne marche pas /o\

On tourne la tête et encore deux autres ...

Tout cela aurait-il un rapport ?

Edit : GoogleMap:

View Larger Map

WTF !

2007-03-27T21:43:00.000+02:00

L0l le 21e siecle:

Ah les upgrades !

2007-02-13T18:34:00.000+01:00

Il y a quelques années, un upgrade d'Itunes qui faisait un rm -rf sans trop de précaution avait bien fait rire dans les chaumières, en particulier chez les vieux unixiens arrogants programmant en shell.

Ce qui vient de m'arriver lors d'un upgrade de iTerm est moins gênant mais tout aussi troublant :

Plein d'espoir et sûr de mes backups, j'ai cliqué Yes. Je n'ai pas vu d'effet spécial. Évidemment ce n'est arrivé que la première fois. Vous auriez fait quoi, vous ?

Batterie, crash et automount

2007-01-25T09:35:00.000+01:00

Bon, passons sur le fait que ma 2e batterie en 9 mois passe soudainement de 40 à 0% et que donc le système meurt sans prévenir ni même le temps de passer en veille.

Problème, lors du crash, j'avais une partition chiffrée montée, avec la commande suivante: hdiutil attach /home/at/crypto-container.dmg -stdinpass -mountroot /crypt (oui pour des raisons historiques de liens un peu partout dans mon $HOME, /Volumes j'en veux pas)

Passons sur le fait que depuis un passage 10.4.7->10.4.8 ca me monte en plus de la vraie partition chiffrée un ridicule /crypt/Boot OSX correspondant au secteur du IMG que je ne me rappelais pas avoir créé quand j'ai initialisé l'image.

Le problème dont je veux causer, c'est qu'il reste un /crypt/volumeamoi non vide (il y a un sale fichier .automounted sans doute créé par les bidules-on-sait-pas-ce-quils-font-mais-il-faut-pas-les-arreter) dedans, et que donc hdiutil monte très intelligement le disque sur /crypt/volumeamoi2 . Tres pratique quand le mail arrive et veut aller dans /crypt/volumeamoi/Mail/inbox .

Ethernet et veille

2007-01-03T08:48:00.000+01:00

Bonne année 2007 à tous les désespérés !

Environ une fois sur 50, quand le mac sort de veille, en0 reste inactif, obligeant à y retourner un petit instant ... (oué je sais j'ai qu'à faire du wifi, ethernet c'est pour les hasbeen).

Peut être est-ce que c'est ça qui le gêne avant de passer en veille, j'ai du enlever le cable trop tôt:

1011 root@khany:~> egrep -i '(Yukon|System Wake|System SafeSleep)' /var/log/system.log
Jan  3 08:26:38 khany kernel[0]: AppleYukon - en0 link is down
Jan  3 08:42:17 khany kernel[0]: System SafeSleep
Jan  3 08:42:17 khany kernel[0]: System Wake
Jan  3 08:45:08 khany kernel[0]: System SafeSleep
Jan  3 08:45:08 khany kernel[0]: System Wake
Jan  3 08:46:00 khany kernel[0]: AppleYukon - en0 link active, 10-Mbit, full duplex, flow control disabled

Retourner se coucher n'est peut être pas une mauvaise idée finalement.

X11

2006-11-20T14:22:00.000+01:00

Le serveur X11 se bloque régulièrement (mais évidemment pas de manière systématique) si on scrolle un peu vite vers le haut dans OpenOffice.Org , mais aussi dans rxvt ou d'autres applications. Je suis très étonné parce que je ne trouve pas de trace de de bug chez d'autres gens, mais c'est très très pénible de devoir faire Ctrl+S après chaque § écrit ...

Je suis sûr que ce n'est pas un bug OO.org:
- d'abord je l'ai déjà vu dans rxvt,
- ensuite le symptôme est que toutes les applications X11 sont bloquées, y compris les menus du haut, y compris la création d'une autre fenêtre...
- de toute manière un serveur graphique ne devrait pas se bloquer sur la réception d'une requête client ...

J'étais en train de radariser mais bugreport.apple.com m'a pété à la gueule..

Edit: comme je me méfie de ce serveur j'avais intelligement copié mon bug dans un terminal ... C'est donc le #4845847.

DNS

2006-11-09T09:07:00.000+01:00

Pourquoi tant de haine ? Pourquoi MacOS-X a t'il décidé que si je n'avais pas de route par défaut, je n'avais pas envie d'avoir un DNS ? Pourquoi cette merde de lookupd et DNSclient ne se met en marche que quand le système a une route par défaut ? Hein pourquoi ?

Le pire étant que le DNS que j'utilise est sur 127.0.0.1, bien entendu.

Update X11

2006-11-06T08:27:00.000+01:00

La récente mise à jour de X11 fait planter OpenOffice au démarrage. Je ne suis visiblement pas le seul.

Bien joué ! Je travaille comment moi maintenant ?

Edit: le problème est causé par 5 polices TTF (de la famille Vera) qui sont corrompues dans l'archive, et qu'il suffit de récupérer ailleurs. Bon. Mais le plus drôle, c'est ça.

Oui vous avez bien lu, un @&!=$# chez Apple a probablement transporté des fontes TTF binaires par FTP en mode ASCII.

Vieilleries

2006-10-24T20:48:00.000+02:00

Quelques vieilleries vues pendant ces quelques mois qui font tache dans un OS du XXIe siècle:

* Un vieil IKE de fin 2000 dans lequel AES s'appelle encore Rijndael ....

1016 at@khany:~> sudo racoon -vF
Foreground mode.
2006-10-24 20:39:54: INFO: main.c:176:main(): @(#)racoon 20001216 20001216 sakane@kame.net

* Des BPF dont les descripteurs de fichiers ne supportent pas select() : il n'y a pas de moyen simple d'appeler libpcap seulement quand on est sûr qu'il y a un paquet, ce qui ne facilite pas l'écriture d'applications d'écoute réseau un peu malignes (c'est dans FreeBSD depuis 4.3).

* Un SMBFS qui ne supporte pas le passage direct en SMB sur le port 445 et impose donc aux serveurs d'avoir NetBios sur TCP alors que c'est en voie d'abandon partout. Pas de signature de paquet non plus (alors que l'utilitaire smbclient livré supporte ces deux fonctions).