®om a écrit 458 commentaires

Je trouve que ce billet de blog de moxie0 répond très bien à la question : https://signal.org/blog/the-ecosystem-is-moving/

Perso, j'ai quelques contacts qui utilisent Jabber. Sinon j'utilise aussi XMPP pour la communication 1-to-1 sur Slack au boulot, ça permet d'avoir le chiffrement OTR.

blog.rom1v.com

Est-ce que le rapport contraintes/gains est si favorable que ça

Ça va dépendre de la pondération que l'on donne à ces contraintes et à ces gains. À quel point veut-on éviter les undefined behaviors ou les problèmes de sûreté mémoire, sachant que les éliminer dès la compilation augmente drastiquement la sécurité globale des applications? Ça va dépendre des applications, des personnes, de l'époque (on est plus attentif à la sécurité si les attaques se font plus nombreuses et causent davantage de dégâts)…

Mais je te rejoins, parfois les borrowing rules peuvent sembler trop contraignantes.

Pourtant, le langage lui-même a plein d'avantages, à tel point qu'on pourrait parfois envie d'avoir un Rust-like qui serait Rust privé des borrowing rules (donc on pourrait avoir plusieurs références mutables simultanément, sans avoir recours à des blocs unsafe) et les durées de vie… Ce ne serait plus Rust, évidemment, mais peut-être que ça pourrait répondre à un besoin.

blog.rom1v.com

Quand je vois la liste des difficultés que tu dresses pour cette réécriture, […] je ne veux absolument pas passer à Rust

C'est vrai que les borrowing rules sont assez contraignantes pour la conception d'une application. En contrepartie, elles offrent un certain nombre de garanties à l'exécution, ce qui élimine toute une classe de bugs potentiels (et de failles de sécurité).

Je crois que le truc qui m'a le plus choqué, c'est le paragraphe «Infinité indéfinie» qui explique que Rust fait de la merde mais à la fin, la conclusion, c'est que «les garanties de sûreté de Rust sont très fortes»

Oui, à part ce bug (de LLVM), en pratique c'est vraiment le cas. Quand j'ai retravaillé sur un projet C++ après, ça m'a fait tout drôle d'avoir un segfault à l'exécution.

un langage qui […] me refile une météorite

Pour nuancer, note que le comportement est également indéfini en C++:

#include <iostream>

void infinite(int value) {
    while (value != 0) {
        if (value != 1) {
            value -= 1;
        }
    }
}

int main() {
    infinite(42);
    std::cout << "end" << std::endl;
    return 0;
}

Sans optimisations :

$ clang++ ub.cpp -o ub && ./ub
^C                    (infinite loop, interrupt it)

Avec optimisations :

$ clang++ -O1 ub.cpp -o ub && ./ub
end

blog.rom1v.com

Merci. Si quelqu'un veut bien changer le lien dans le post… :)

blog.rom1v.com

je trouve l'initiative intéressante et surtout, je ne connais pas d'équivalent chez les grands noms du smartphone (Samsung, Huawei, etc…).

Pour les Nexus/Pixel, Google fournit également les blobs nécessaires pour builder AOSP:

Sur un Nexus 5, ça marche très bien. Sur Nexus 5X ou Pixel, ils ne fournissent pas tout ici, du coup il faut passer par android-prepare-vendor pour générer le vendor/ qui-va-bien dans ton arbre AOSP avant de builder.

blog.rom1v.com

Ma Debian dit le contraire : apt ;-)

blog.rom1v.com

sudo apt update && sudo apt upgrade

Et paf.

blog.rom1v.com

Il n'y a pas que les liens qui sont illégaux chez Pôle Emploi :
La CGT a enquêté : « 1 offre d’emploi sur 2 est illégale sur pole-emploi.fr ! »

blog.rom1v.com

// test.c
#include <stdio.h>

int main() {
    long i = 1;
    long x = i >> 64;
    long y = 1 >> 64;
    if (x != y)
        printf("undefined behavior spotted\n");
    return 0;
}

$ gcc -w test.c -o test && ./test
undefined behavior spotted
$ gcc -w -O1 test.c -o test && ./test

blog.rom1v.com

Le besoin initial est très spécifique : pour déployer automatiquement des devices (installer des applis, configurer le téléphone, etc.), on veut éviter d'utiliser le wifi (c'est moins pratique à configurer et quand il y a beaucoup de devices c'est pas l'idéal).

Mais il y a d'autres usages plus "généraux".

Par exemple, en entreprise, on n'est pas toujours sur le même réseau par câble ou par wifi. Il m'est déjà arrivé plusieurs fois que le serveur auquel une application Android doit accéder soit sur le réseau filaire, inaccessible par wifi.

Certes, il est parfois possible de partager la connexion en créant un point d'accès wifi, mais d'une part ce n'est pas toujours facile (je suis sous Debian stable avec XFCE, NetworkManager ne propose pas l'option, ou alors je l'ai ratée), et d'autre part ça n'est pas possible avec un PC fixe sans carte wifi.

Après, j'ai lu ici et là d'autres cas d'usage, que je liste en vrac :

• ne payer qu'un seul accès dans certains hôtels qui facturent l'accès wifi en fonction du nombre de devices connectés ;
• sniffer à partir du pc toutes les adresses auquel un device se connecte ;
• utiliser une tablette dont le wifi est cassé…

Il y en a sans doute d'autres.

L'usage est bien sûr moins courant que le tethering (partager la connexion du téléphone pour le PC), mais ça peut servir dans certaines situations…

blog.rom1v.com

La page de download de Telify indique :

Updated: October 23, 2012

blog.rom1v.com

Moi, mon candidat préféré, c'est François Bervas :
https://www.youtube.com/watch?v=u9ok7_LOA6E

Il a l'air bon !

blog.rom1v.com

Vos phrases manquent de :

blog.rom1v.com

Bonjour Zenitram,

Ha ça, c'est toujours joli c'est "juste à" qui sont la raison pour laquelle Teamviewer et compagnie ont des utilisateurs (ils répondent au besoin, eux, et ne réclament pas de lancer une incantation vaudou).
Continuez avec ces "juste à" rigolos :), car c'est tout sauf "juste à".

Le "juste à" était à comparer à la même connexion VNC ou SSH "dans le bon sens" : celui qui dépanne se connecte à la machine d'un novice. Dans le sens normal, c'est alors au novice d'ouvrir ses ports sur le routeur. En inversant la connexion, c'est moins compliqué pour lui : une commande à copier. Ce n'est pas rien à faire, mais c'est moins pire.

Avec Teamviewer aucune des machines n'a besoin d'être accessible publiquement.

Je n'ai jamais prétendu que ce que je proposais concurrençait TeamViewer en terme de commodité. D'ailleurs, je n'ai pas parlé de TeamViewer.

Je trouve juste intéressant de partager une technique pour se connecter à un serveur SSH ou VNC derrière un NAT, rien de plus.

blog.rom1v.com

Pour établir des connexions inversés, j'ai justement écrit un billet avant-hier: Serveur-client.

Du côté utilisateur, il a juste à lancer une commande socat que tu lui donnes (en plus du serveur SSH/VNC/whatever selon ce que vous voulez utiliser).

Bien sûr, il faut qu'une machine que tu contrôles soit accessible publiquement (mais au moins c'est pas celui que tu aides qui n'y connaît rien qui doit configurer ça).

blog.rom1v.com

Pour savoir exactement ce qu'il se passe quand git rencontre une collision dans différents cas:
http://stackoverflow.com/a/34599081/1987178

blog.rom1v.com

http://shattered.io/

The SHAttered attack is 100,000 faster than the brute force attack that relies on the birthday paradox.

Je n'ai d'abord pas compris comment il était possible de réussir en n'étant que 100000 fois plus rapide.

Un SHA1 a une longueur de 160 bits. Avec le paradoxe des anniversaires, on peut espérer en force brute trouver une collision en à peu près 2⁸⁰ hashes (une bonne approximation est de prendre la racine carrée du nombre de possibilités). Donc ça revient à tester toutes les combinaisons d'une variable de 80 bits. Infaisable.

Mais même 100000 fois plus rapide, ça ne fait gagner que ~17 bits (ln(100000)/ln(2)) :

$ echo 'l(100000)/l(2)' | bc -l
16.60964047443681173951

Donc ça fait quand même plus de 2^63. C'est toujours infaisable.

Mais ils précisent :

This attack required over 9,223,372,036,854,775,808 SHA1 computations.

Ce nombre est exactement 2^63.

Donc ils ont calculé presque 2⁶⁴ hashes. C'est dingue, je pensais qu'il était matériellement impossible de calculer n'importe quelle fonction pour toutes les valeurs possibles d'une variable de 64 bits.

Je vais donc revoir mes règles de pouce approximant la frontière entre le possible et l'impossible à la hausse.

---

PS : comment écrire 2⁶⁴ en markdown sur linuxfr sans manger l'espace ou mettre en exposant le caractère qui suit ?
Voici ce que j'ai essayé :

• 2^64. donne 2^64.
• 2^64^. donne 2^64.
• 2^{64}^. donne 2^{64}.
• 2^64 hashes. donne 2⁶⁴ hashes.
• 2^64 h. donne 2⁶⁴ h. ← ça fonctionne, mais ce n'est pas ce que je veux écrire.
• …

EDIT : Pour 2^64 hashes., le problème ne se produit que lors de la prévisualisation, une fois posté, ça fonctionne ;-)
Il y a d'autres différences entre la prévisualisation et la version postée, par exemple 2^{64}^..

blog.rom1v.com

il y a aussi des gens qui savent mieux faire du design que les développeurs

Je plussoie. Je suis développeur.

blog.rom1v.com

Coïncidence, j'étais justement en train de lire le RFC793 quand je suis tombé sur ce journal.

La section 3.3 explique pourquoi synchroniser les numéros de séquence:

  Initial Sequence Number Selection

  The protocol places no restriction on a particular connection being
  used over and over again.  A connection is defined by a pair of
  sockets.  New instances of a connection will be referred to as
  incarnations of the connection.  The problem that arises from this is
  -- "how does the TCP identify duplicate segments from previous
  incarnations of the connection?"  This problem becomes apparent if the
  connection is being opened and closed in quick succession, or if the
  connection breaks with loss of memory and is then reestablished.

  To avoid confusion we must prevent segments from one incarnation of a
  connection from being used while the same sequence numbers may still
  be present in the network from an earlier incarnation.  We want to
  assure this, even if a TCP crashes and loses all knowledge of the
  sequence numbers it has been using.  When new connections are created,
  an initial sequence number (ISN) generator is employed which selects a
  new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
  bit clock whose low order bit is incremented roughly every 4
  microseconds.  Thus, the ISN cycles approximately every 4.55 hours.
  Since we assume that segments will stay in the network no more than
  the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
  hours we can reasonably assume that ISN's will be unique.

  For each connection there is a send sequence number and a receive
  sequence number.  The initial send sequence number (ISS) is chosen by
  the data sending TCP, and the initial receive sequence number (IRS) is
  learned during the connection establishing procedure.

  For a connection to be established or initialized, the two TCPs must
  synchronize on each other's initial sequence numbers.  This is done in
  an exchange of connection establishing segments carrying a control bit
  called "SYN" (for synchronize) and the initial sequence numbers.  As a
  shorthand, segments carrying the SYN bit are also called "SYNs".
  Hence, the solution requires a suitable mechanism for picking an
  initial sequence number and a slightly involved handshake to exchange
  the ISN's.

  The synchronization requires each side to send it's own initial
  sequence number and to receive a confirmation of it in acknowledgment
  from the other side.  Each side must also receive the other side's
  initial sequence number and send a confirming acknowledgment.

    1) A --> B  SYN my sequence number is X
    2) A <-- B  ACK your sequence number is X
    3) A <-- B  SYN my sequence number is Y
    4) A --> B  ACK your sequence number is Y

La section 3.4 parle de la connexion simultanée (puis détaille un échange):

3.4.  Establishing a connection

  The "three-way handshake" is the procedure used to establish a
  connection.  This procedure normally is initiated by one TCP and
  responded to by another TCP.  The procedure also works if two TCP
  simultaneously initiate the procedure.  When simultaneous attempt
  occurs, each TCP receives a "SYN" segment which carries no
  acknowledgment after it has sent a "SYN".  Of course, the arrival of
  an old duplicate "SYN" segment can potentially make it appear, to the
  recipient, that a simultaneous connection initiation is in progress.
  Proper use of "reset" segments can disambiguate these cases.

C'est rigolo, j'ai justement demandé par mail hier à Stéphane Bortzmeyer si ce cas de connexion simultanée existait en réalité. Je colle sa réponse (je pense qu'il ne m'en voudra pas, même si un mail est censé être privé), qui indique justement que ça peut se produire avec un port source fixe:

Two processes which issue active OPENs to each other at the same
time will be correctly connected.

Existe-t-il quelque chose qui ressemble à ce que dit cette dernière
phrase dans le monde actuel?

Oui. Évidemment, en mode client-serveur moderne (le serveur a un port
destination fixe bien connu, le client un port source aléatoire), cela
n'arrive jamais. Mais si les deux utilisent un port source fixe (ce
que faisait le DNS au début, et que BGP a fait pendant encore plus
longtemps), cela peut arriver que deux machines commencent la session
presque en même temps (BGP est un bon exemple car il n'est pas
client-serveur).

Et tu donnes dans ce billet un exemple concret. Merci, ça tombe très bien :)

blog.rom1v.com

https://github.com/git/git.github.io/pull/185

blog.rom1v.com

Ah oui, merci beaucoup!

Le bouton "rss" de firefox n'était pas activé car il n'y a pas de <link rel="alternate" type="application/rss+xml" href="…" />

Du coup, j'ai regardé la vidéo sur git-series ça a l'air bien sympa. Merci.

blog.rom1v.com

Plus d'infos sur Git Rev News, les archives, l'URL à donner à manger à votre lecteur RSS, … ici : https://git.github.io/rev_news/rev_news/.

C'est une page HTML.

blog.rom1v.com

il sera toutefois dépourvus de quelques fonctionnalités comme la gestion des DRM

Si l'on considère que les DRM sont une anti-fonctionnalité, cela signifie que c'est une version améliorée?

blog.rom1v.com

curl http://folkswithhats.org/fedy-installer -o fedy-installer && chmod +x fedy-installer && sudo ./fedy-installer && sudo fedy

Exécuter en root un truc téléchargé d'une source inconnue en http… C'est une blague?

blog.rom1v.com

+1

Par contre, vu qu'on parlait de l'initialisation des constructeurs en C++, on parlait bien de déréférencer "en C/C++", pas au niveau du binaire généré.

blog.rom1v.com