Carnet de notes

Catégorie : Technique

  • [Vidéo] Public key cryp­to­gra­phy – Diffie-Hell­man Key Exchange

    J’ai déjà vu l’ex­pli­ca­tion des pein­tures, mais là on va plus loin, et l’ex­pli­ca­tion de Diffie-Hell­man est juste excel­lente.

  • [Lecture] Most soft­ware already has a “golden key” back­door: the system update

    Réflexions à partir d’un article sur Ars Tech­nica

    Q: What does almost every piece of soft­ware with an update mecha­nism, inclu­ding every popu­lar opera­ting system, have in common?

    A: Secure golden keys, cryp­to­gra­phic single-points-of-failure which can be used to enable total system compro­mise via targe­ted mali­cious soft­ware updates.

    Mine de rien, la plupart de nos appa­reils modernes ont un système de mise à jour, souvent auto­ma­tique. Celui qui détient les clefs peut injec­ter ce qu’il veut, ou simple­ment attendre que vous le fassiez vous-même en croyant mettre à jour.

    On parle de Google, Samsung, Apple, Nokia, Micro­soft et les autres. Des gens parfois recom­man­dables, toujours avec leurs propres inté­rêts.

    On parle aussi des États qui, offi­ciel­le­ment ou non, auraient pu avoir accès à ces clefs. Main­te­nant qu’on connait un peu PRISM et l’éten­due des griffes USA, et l’en­vie de la plupart des pays de les imiter, par la force ou par la loi, ce n’est pas rien.

    On parle ensuite de tous les indi­vi­dus qui ont pu avoir accès à ces clefs et les faire fuiter, volon­tai­re­ment ou non.

    This problem exists in almost every update system in wide use today. Even my favo­rite opera­ting system, Debian, has this problem. If you use Debian or a Debian deri­va­tive like Ubuntu, you can see how many single points of failure you have in your update authen­ti­city mecha­nism with this command:

    sudo apt-key list | grep pub | wc -l

    For the compu­ter I’m writing this on, the answer is nine. When I run the apt-get update command, anyone with any one of those nine keys who is sitting between me and any of the webser­vers I retrieve updates from could send me mali­cious soft­ware and I will run it as root.

    Et si je fais rela­ti­ve­ment confiance à la PKI de Apple, Google et Micro­soft, c’est bien moins vrai pour la plupart des indi­vi­dus isolés derrière les logi­ciels open source.

    Person­nel­le­ment mon Debian perso fait confiance à 14 clefs, certaines proba­ble­ment mal sécu­ri­sées, d’autres parta­gées par plusieurs acteurs, et proba­ble­ment toutes sans le niveau de sécu­rité d’un Apple face aux incur­sions des États.

    La sécu­rité c’est défi­ni­ti­ve­ment trop compliqué pour le monde réel dès qu’il s’agit de se proté­ger contre les très gros acteurs.

    Je ne suis même pas certain que ces très gros acteurs le puissent entre eux. La France utilise des postes sous Micro­soft Windows pour l’ar­mée. Même les postes sous Debian, à ma connais­sance la France n’a pas son armée de déve­lop­peur pour faire une revue de tout le code source et le compi­ler eux-même (et même là, on tombe sous le problème du compi­la­teur qui a lui-même une porte déro­bée qu’il repro­duit dans ce qu’il compile, ça s’est déjà vu dans l’his­toire). En cas de vrai conflit, nous sommes tota­le­ment à genoux.

  • La langue des signes et Paris Web racon­tés par une licorne

    Une des choses dont je suis le plus fier vis à vis de Paris-Web, c’est l’ar­ri­vée de la langue des signes et de la vélo­ty­pie.

    Les inter­prètes LSF font un boulot magni­fique au milieu d’un trou­peau de geeks qui parlent en fran­glais plein de jargon et d’acro­nymes, à toute vitesse. En octobre dernier l’équipe a proposé à une de ces inter­prètes de racon­ter comment ça se passe de l’in­té­rieur. C’est une des trois confé­rences à ne pas manquer de cette édition, et elle est pour vous en vidéo :

    Confé­rence LSF from Paris-Web on Vimeo.

    Il s’agit d’un gros budget, pour quelques uns. Ce n’est pas facile tous les ans et à chaque fois que c’est un peu tendu je suis certain que la ques­tion revient sur la table. Pour autant à chaque fois ça tient, même quand il y a un défi­cit.

    Pour moi c’est dans les valeurs de l’évé­ne­ment mais c’est aussi une façon de montrer par l’exemple qu’on peut tenter d’in­clure tout le monde.

  • [Lecture] How we run design critique sessions

    Lu sur le web :

    Recently, we totally chan­ged our design critique sessions. After care­fully analy­zing what was wrong with our previous format, we esta­bli­shed the follo­wing pillars for our design critique sessions:

    1. It’s called Things That Rock
    2. It happens every week
    3. Everyone shows some­thing
    4. No prepa­ra­tion needed
    5. 10 minutes per person
    6. Critique comes in the form of ques­tions
    7. The session ends by a vote

    Let’s go over each point in more details.

    — chez Blabla­car

    Inté­res­sant. On rejoint un peu le système des revues de pair mais avec une autre approche, moins systé­ma­tique et plus bran­chée sur comment parta­ger l’ex­pé­rience pour s’en­ri­chir. J’aime beau­coup l’idée qu’en montrant ce qui fonc­tionne on finit par monter le niveau d’exi­gence.

    Qui fait quelque chose de simi­laire côté déve­lop­pe­ment ? Tout ce que j’ai vu finit par tour­ner dans des présen­ta­tions de tech­nos et moins dans le « voilà ce que j’ai fait ».

  • [Lecture] On a testé fonc­tion­nel­le­ment notre app JS

    Lu sur le web :

    L’uti­lité des tests fonc­tion­nels pour les appli­ca­tions web n’est plus à démon­trer (comment ça, vous ne testez pas encore vos apps ?). Malheu­reu­se­ment, tout ne peut pas être tota­le­ment testé fonc­tion­nel­le­ment, ou de façon aisée : je pense par exemple au player chez nous, un compo­sant stra­té­gique mais pauvre­ment testé fonc­tion­nel­le­ment de par sa nature un peu hybride (mélange de flash et de JS). Dans tous les cas, pour ce qui peut l’être, nous sommes parti­sans dans l’équipe Cytron d’user sans mesure (ou presque !) de cet outil de manière à être le plus zen possible au moment d’ap­puyer sur le bouton “deploy”.

    — chez M6 Web

    Inté­res­sant, mais à deux moments j’ai l’im­pres­sion de tâton­ne­ments, de tests qui peuvent échouer sans raisons et qu’on relance pour s’as­su­rer que ça passe. Je trouve ça assez risqué comme approche. Ai-je mal compris ?

    il nous arri­vait que le compor­te­ment “hover” ne soit pas déclen­ché, mettant en échec la suite du test. Nous avons donc changé notre manière d’ef­fec­tuer le rollo­ver : on répète l’ac­tion grâce au waitUntil tant que l’éle­ment devant appa­raître au hover n’est pas visible

    Pourquoi l’évé­ne­ment n’est-il pas déclen­ché ? Et l’uti­li­sa­teur risque-t-il d’avoir le même bug ?

    Elle permet de stocker dans un fichier texte la liste des scéna­rios en échec pour les relan­cer ensuite afin de véri­fier qu’ils le sont réel­le­ment.

    Des faux posi­tifs ? Et si parfois le test échoue alors qu’il ne devrait pas, il y a-t-il un risque qu’il réus­sisse alors qu’il ne devrait pas ? Combien de fois le relan­cer pour être certain du résul­tat ?

    Le retour d’ex­pé­rience est extrê­me­ment inté­res­sant, mais ça laisse un goût de bidouille qu’il serait préfé­rable de corri­ger avant de consi­dé­rer la solu­tion comme stable.

  • [Lecture] Refac­to­ring a Docker­file for image size

    Lu sur le web :

    There’s been a welcome focus in the Docker commu­nity recently around image size. Smal­ler image sizes are being cham­pio­ned by Docker and by the commu­nity. When many images clock in at multi-100 MB and ship with a large ubuntu base, it’s greatly needed.

    — sur Repli­ca­ted

    J’aime bien l’ap­proche de l’ar­ticle, qui tient plus à reti­rer le super­flu qu’à partir sur des confi­gu­ra­tions peu stan­dard. Main­te­nant, qu’y gagne-t-on ?

    L’es­pace disque est-il vrai­ment un enjeu majeur aujourd’­hui par rapport au temps qu’on y passe et à la perte éven­tuelle de souplesse ?

    Le système de système de fichier par couche devait mutua­li­ser les télé­char­ge­ments et les espaces de stockage. Ai-je mal compris ?

  • Amazon’s custo­mer service back­door

    Wow. Just wow. The atta­cker gave Amazon my fake details from a whois query, and got my real address and phone number in exchange. Now they had enough to bounce around a few services, even convin­cing my bank to issue them a new copy of my Credit Card.

    — Amazon’s custo­mer service back­door

    Rien de neuf, on a déjà vu des récits de comptes twit­ter pira­tés et de commandes VPC rerou­tées, voire de vraies usur­pa­tions d’iden­tité. C’est désor­mais à chaque fois via de l’in­gé­nie­rie sociale.

    Les ques­tions « secrètes » sont de la bonne blagues et un peu de culot accom­pa­gnés d’un télé­phone permettent d’à peu près tout savoir via votre famille ou vos amis. Les supports tech­niques de vos diffé­rents pres­ta­taires ont telle­ment d’in­for­ma­tions sur vous qu’ils sont des cibles privi­lé­giées.

    De fil en anguille, en récu­pé­rant un bout chez l’un, un autre bout chez l’autre, on peut remon­ter jusqu’à avoir quelque chose de fort.

    Peu de solu­tions. Très peu de gens sont prêts à se faire éjec­ter de leurs services et de leurs données s’ils ont simple­ment changé d’adresse et oublié de la mettre à jour, ou perdu leur mot de passe de l’an­cien compte email, etc. Les service de support client ne font que ce que tout le monde attend.

  • Compo­ser paral­lel install plugin

    Bench­mark Example
    288s -> 26s

    — hirak/pres­tis­simo, compo­ser paral­lel install plugin

    Non testé, mais je me dis qu’il y a peu de chances que ça fasse du mal

  • No, You Don’t Need To Struggle Testing React

    Writing tests in such an envi­ron­ment need to satisfy two rules:

    1. Writing specs should take the least amount of time possible.
    2. Each spec should test as much code as possible.

    Now I’ve proba­bly already lost half of you reading this. « Each spec should test as much as possible? How do you isolate failures?” Yeah, yeah, I agree, but at the end of the day, the only purpose of my testing suite is to make sure that the little CircleCI dot on Github turns red whene­ver I merge a brea­king change.

    — Stephen Grider

    C’est voir un seul côté du miroir, et au travers de lunettes de soleil.

    Le test auto­ma­tisé n’est pas là que pour l’in­té­gra­tion conti­nue. Il est aussi là pour prou­ver que le code qu’on a produit corres­pond bien à ce qui est souhaité. Il est aussi là pendant le déve­lop­pe­ment pour ne pas faire du pas à pas et du test manuel encore et encore jusqu’à ce que ça semble fonc­tion­ner. Il est là pour permettre à un tiers de comprendre et repro­duire.

    Je n’ai rien contre le fait d’avoir un scéna­rio avec plusieurs asser­tions – qui est le fond du billet cité – mais avec des tests les plus gros possibles, on loupe la moitié des objec­tifs. Pire : on se créé une jolie dette tech­nique pour quand on aura quelque chose à chan­ger. Au lieu de reti­rer ou modi­fier quelques tests bien précis, on a un gros truc qui passe au rouge, qu’on va devoir modi­fier au risque d’obli­té­rer des cas limites.

  • Intro­duc­tion to Post­greSQL physi­cal storage

    Should you know about how Postgres handle the physi­cal storage? Maybe not, but knowing how it works can be useful if you need to inves­ti­gate some problems.

    — Rachid Belaid

    C’est long mais excellent. J’ai­me­rais en lire plus des comme ça.