Samedi passé, la vidéo youtube du court métrage Sintel a été bloqué. La raison de ce blocage est une détection de contenu appartenant à Sony dans la vidéo.

Pour ceux qui l’ignorent, Sintel est un film de la Blender Foundation, une association à but non-lucratif développant le logiciel de 3D Blender. Ce film est réalisé principalement à partir de logiciels libres et publié sous licence Creative Commons ainsi que toutes les ressources étant été créées. Ce film est donc loin, très loin d’être la propriété de Sony !

sintel-youtube

Sans surprise, cette censure déclencha un clash sur le web. Comme le dit TorrentFreak, Sony a réussi l’exploit de se mettre à dos les fan de logiciels libres, adeptes de Creative Commons, mouvement anti abus de copyright et groupes de protections contre la censure en un seul coup. Ça mériterait un prix.

Après un weekend de lynchage virtuel et reprise de l’info sur les grands sites d’info, la vidéo est de retour ! Suite à ce coup de pub, Sintel vient même de passer les 4 millions de vues sur Youtube. Houra, faites péter le champomi, on a gagné ?

Non.

Sintel_poster

Si le retour de la vidéo va un peu calmer les foules, le problème de fond reste inchangé. Une compagnie a la possibilité, sans aucune difficulté, justification ou contrôle a priori de censurer du contenu sur lequel elle n’a aucun droit. Un système qui devient la norme sur tous les sites de partage de contenu. Erreur ou choix de nuire à un concurrent ? Quelle que soit la cause, il est anormal que cela puisse se passer sans répercussion (même pas un “désolé”). On imagine facilement les très nombreux autres “faux-postifs” n’ayant pas la chance de bénéficier d’un tel coup médiatique.

De tels évènements montrent à quel point le système actuel ne fonctionne pas et doit changer. Peut-on espérer un changement du coté politique ? Supporter des projets comme MediaGobelin ou Gooseberry est plus que jamais important.

Télécharger Sintel (de façon propre et légale)

PS: ce titre ne veut rien dire, et alors ?

Naufrage et migration

6 April 2014

Si vous lisez cet article depuis mart-e.be, c’est que vos DNS sont à jour et que le sauvetage/migration de mon blog a réussi.

Début de semaine, j’ai eu la mauvaise surprise de constater que mon blog ne fonctionnait plus. Un coup d’œil sur le Twitter de Legtux, mon hébergeur, m’apprend qu’il y a eu un crash de disque toutes les DB sont perdues. Joie et allégresse.

On passera le manque de communication de la part de Legtux (je sais pas, un email aurait été sympa). On passera l’absence de backup de la part de Legtux (soit, ça reste un hébergeur tenu par des volontaires). On passera mon erreur de ne faire des backup que de mon serveur chez ovh et pas celui qui héberge mon blog (ça t’apprendra du con). Tout cela fait que je me retrouve avec une sauvegarde vielle de 14 mois !

Moi jouant avec mon nouveau serveur

Moi jouant avec mon nouveau serveur

Avec mon sens de la procrastination légendaire, je décide donc de remettre ça au weekend. Legtux m’a rendu de grands services mais suite à l’incident, je préfère gérer tout moi même. Je m’achète donc un nouveau Kimsufi devant remplacer l’actuel (m’en fous de ton problème de turn over, t’avais qu’a baisser les prix pour les anciens clients), installe tous mes programmes aux petits oignons et repart d’un WordPress tout frais. La partie la plus chiante fut de recréer les articles manquant dans mon backup à l’aide du merveilleux archive.net et de l’historique de mon flux RSS. J’ai perdu quelques commentaires au passage, vous m’en excuserez. Le thème a un peu morflé aussi mais il faut que je le change de toute façon !

Je passerai les prochains weekend à migrer le reste de mes services et peaufiner mon serveur. Si vous repérez d’autres soucis, n’hésitez pas à me le signaler. Avec un peu de chance, je posterai même un article de temps en temps ;-)

PS: le premier qui me lâche une morale sur le fait de faire des backup, je lui colle une gifle virtuelle.

Je me suis créé une instance GNU Social (nouveau nom de StatusNet) il y a quelques mois. A l’époque, j’avais oublié de verrouiller l’inscription. Évidement, les spammeurs trouvèrent vite mon instance et je me retrouve avec plus de 160 comptes indésirables.

Delete user

La façon simple de supprimer un compte est de se rendre dans la liste des utilisateurs (/directory/users), ouvrir un à un le profil de l’utilisateur et de le supprimer.

Si vous voulez un peu automatiser la chose, c’est possible avec ces deux commandes:

$ echo "select nickname from user where nickname != 'mart'" | mysql -u monuser -p madb > /tmp/toban.txt
$ for user in (cat toban.txt)
    php scripts/deleteuser.php -n$user -y
end

Ceci vous listera et supprimera tous les utilisateurs ne s’appelant pas ‘mart’. Dans le cas où vous possédez des comptes réels, il faudra sans doute faire une requête plus complexe pour par exemple n’obtenir que les personnes ayant poster 0 ou 1 message, etc.
Le -y étant pour ne pas demander de confirmation avant la suppression. Au passage si vous avez un utilisateur légitime s’appelant ‘nickname’, il serait également intéressant de supprimer la première ligne du fichier ;-)

Spammeurs découvrant une formulaire d'inscription sans demande d'email

Spammeurs découvrant une formulaire d’inscription sans demande d’email

Notez que la boucle for est la syntaxe Fish. L’équivalent bash devrait ressembler à:

for user in (toban.txt)
do
php scripts/deleteuser.php -n${user} -y
done

Aujourd’hui étant The Day We Fight Back, je trouvais assez adapté de parler d’un des appareil d’espionnage massif le plus répandu: le smartphone. En plus ça me donne une occasion de sortir de mon coma de 10 mois sans article.

Les applications sur Android peuvent stocker des informations soit sur la carte SD, soit en interne dans la mémoire du téléphone. Si les développeurs sont assez intelligents pour ne pas stocker des informations sensibles dans un fichier password.txt sur la carte SD (enfin j’espère), ils font beaucoup moins attention quand il s’agit de stocker cela dans dans la mémoire interne, zone mystérieuse où personne ne va jamais mettre les pieds. Et pourtant c’est bien dommage on y trouve des choses amusantes et bigrement intéressantes.

Ça ne fait aucun doute Carl, cet homme est un grand amateur de Patrick Sébastien à en voir son historique Shazaam

Ça ne fait aucun doute Carl, à en voir son historique Shazaam cet homme est un grand amateur de Patrick Sébastien

La méthode

De part le fait que mon téléphone soit rooté, j’ai justement la possibilité d’explorer l’arborescence de fichiers système (chacun sa passion, j’aime pas les timbres). Par exemple, les paramètres de wifi (y compris les clefs) sont stockées dans /data/misc/wifi/wpa_supplicant.conf, les fichiers .apk des applications sont eux dans /data/app/. Cependant le répertoire qui nous intéresse pour cet article est /data/data/.

$ adb root
restarting adbd as root
$ adb pull /data/data/ ~/android-data
pull: building file list…

$ ls ~/android-data/ | wc -l
93

Voila qui devrait nous occuper pour un moment…

Pour fonctionner chaque application a besoin d’aller rechercher les informations que vous lui avez un jour donné: la question est sous quelle forme sont elles stockées et à quel point se sont ils donnés du mal pour les cacher ? Est-ce qu’une app stocke votre mot de passe en clair ou utilisent ils un protocole type OAuth ? Les applications Android stockent leurs données sous la forme de fichier textes ou le plus souvent de base de données sqlite3. Il suffit donc d’avoir un éditeur texte et de base de données sqlite (sqlitebrowser sous linux par exemple).

N’hésitez donc pas à reproduire avec votre téléphone c’est pas si difficile et instructif.

Exemples

Voici quelques applications installées sur mon téléphone.

sshtunnel

Si vous préférez administrer votre serveur pendant les repas de famille plutôt que d’écouter les blague de tonton Roger

Pour chaque tunnel, est stocké dans le fichier org.sshtunnel/databases/sshtunnel.db, le login, mot de passe, emplacement de la clef ssh (stocké dans un fichier, pas en db), fingerprint et autre. Cette info est également répétée dans le fichier org.sshtunnel/shared_prefs/org.sshtunnel_preferences.xml.

Zombies, Run!

Très chouette jeu/app sportive qui vise le mince publique geek et sportif (mais pas trop)

Dans le fichier texte com.sixtostart.zombiesrun/files/IDENTITY se trouve un vague UUID. Il serait intéressant de creuser sa signification. Stats ?

Dans la base de donnée com.sixtostart.zombiesrun/databases/zombiesRun2Data.db, la table player contient l’email vers le compte de synchronisation et, un token ! Je le souligne parce que c’est une des rares applications ne stockant pas votre mot de passe en clair. Les autres tables contiennent votre historique de jeu (score, records, positions GPS, musiques écoutent pendant la séance,…).

Railtime

Merveilleuse application m’indiquant que j’aurais mieux fait de prendre la voiture plutôt que d’attendre le train.

Dans com.infrabel.railtime/shared_prefs/pushPreferences.xml on trouve un token surement utile pour ceux qui désireraient faire un peu de reverse engineering sur cette app.

En regardant les bases de données, on voit que Railtime utilise visiblement Google Analytics et dans com.infrabel.railtime/databases/stationsv2.db l’on retrouve les noms en 4 langues et coordonnées géographiques des 835 gares de Belgique (pratique pour compléter OpenStreetMap ;-))

Mustard

Du microblogging…

La base de donnée org.mustard.android/databases/data contient les clefs OAuth vers les différents comptes Twitter et autres. Cela veut dire que potentiellement, l’on pourrait envoyer du spam en utilisant les clefs de Mustard et la faire révoquer par Twitter.

C’est une problématique connue des clients open source utilisant OAuth. Il est difficile de cacher cette information puisque quelqu’un attaquant suffisamment persévérant finira toujours par la retrouver dans le code, soyez sympa, pas de bêtises avec.

Into the Dead

Oui j’aime les jeux de Zombie, je sais…

Dans un simple fichier XML com.sidheinteractive.sif.DR/shared_prefs/com.sidheinteractive.sif.DR.xml on trouve tous les scores du jeu. Si jamais vous êtes bloqué dans une mission, c’est de la provocation tellement il est facile de changer son score. J’avoue avoir triché et je recommencerai surement…

Firefox

Faut-il encore le présenter ?

Dans le dossier org.mozilla.firefox/files/mozilla se trouve votre profil Firefox (historique, mot de passes & Co.). Je vois pas trop ce que je pourrais ajouter à cela tellement c’était prévisible. Je ne vois même pas pourquoi j’ai créé une entrée pour cette application et ne vous ferez pas l’affront de parler des autres navigateurs.

WhatsApp

SMS over IP

Le fichier com.whatsapp/databases/msgstore.db contient tout votre historique. Vous pouvez utiliser WhatsApp Xtract pour plus de facilité. On appréciera que les images sont stockées comme des URL sans aucune authentification (comme Facebook en fait).

Shazaam

Alias le tueur de blind tests

Vous pouvez facilement retrouver l’historique de vos écoutes dans com.shazam.android/databases/library.db. Vous retrouvez ainsi artiste, titre et image facilement.
Moins drôle: on retrouve également l’historique des positions géographiques où vous avez écouté chaque titre. Conclusion: ne taggez pas de musique chez votre maitresse.

Équipe technique discutant de la protection des données dans leur application

Équipe technique discutant de la protection des données dans leur application

Ces applications ne sont que quelques exemples personnels d’analyses forensic faites avec une Chimay dans la main (donc de très grandes qualités). Si quelques applications s’en sortent plutôt bien (les « grosses » ne stockent pas les mots de passe en clair par exemple), nombres d’applications stockent encore beaucoup trop d’information sensibles. Si cela n’empêchera pas Google et consorts de connaitre vos moindre faits et gestes (ils s’en balancent du mode de stockage s’ils peuvent récupérer l’info au niveau de l’OS), gardez en tête ce que l’on peut trouver comme information avec un téléphone perdu ou un accès au debugging USB pendant 2min.

Si vous avez découvert d’autres applications stockant des informations amusantes (ou pas), n’hésitez pas à partager.

Faut-il encore présenter StatusNet ? Il est généralement considéré comme le clone libre et décentralisé de Twitter de référence. Une réussite toute relative comparé au nombre d’utilisateurs sur la version propriétaire mais un bon succès quand même par rapport aux autres projets libres du genre. Cependant, pour Evan Prodromou, son créateur, il était temps d’avoir quelque chose de nouveau et plus moderne. Il est donc passé de PHP à NodeJS, de MySQL à NoSQL, de Gitorious à Github et a créé Pump.io. Les concepts de fonctionnement sont légèrement différents : StatusNet est clairement calqué sur Twitter avec la limite de 140 caractères alors que Pump utilise un formatage riche en wysiwyg sans limite de taille, le tout à la sauce Bootstrap. Cependant le public StatusNet est visé puisqu’une migration forcée d’identi.ca (instance de StatusNet rassemblant une très grosse partie des utilisateurs) vers Pump est prévue en avril. La messe étant dite, faisons une présentation de ce nouveau venu.

pompe rouillée

Avec un nom pareil, je trouve quand même que ça part mal.

Protocole

J’avais parlé de ce problème dans mon article précédent : Pump n’utilise pas OStatus (le groupe de protocoles utilisé par StatusNet) et ne sera donc pas compatible avec ce dernier. C’est nul, je sais. Cependant les standards utilisés ne diffèrent pas trop non plus. Les activity streams sont au cœur du réseau (déjà présents dans OStatus sous forme XML mais l’on va encore plus loin cette fois). Activity Stream est un standard initié par Facebook, Google, Microsoft (et plein d’autres gens bien) pour unifier la façon de représenter des actions sur les réseaux sociaux et faciliter l’interopérabilité. Un message d’un serveur Activity Stream à un autre est par exemple :

    {
        "id": "http://coding.example/api/activity/bwkposthw",
        "actor": {
            "id": "acct:bwk@coding.example",
            "displayName": "Brian Kernighan",
            "objectType": "person",
            "url": "http://coding.example/bwk"
        },
        "verb": "post",
        "object": {
            "id": "http://coding.example/api/note/helloworld",
            "content": "Hello, World!"
            "objectType": "note"
        },
        "published": "1973-01-01T00:00:00"
    }

Dans pump, une activité est authentifiée via OAuth, ce qui permet de séparer complètement l’authentification du contenu

POST /api/user/bwk/feed HTTP/1.1
Host: coding.example
Authorization: OAuth oauth_consumer_key="[...]",
    oauth_token="[...]", [...]
Content-Type: application/json

{
    "verb": "follow",
    "object": {
        "id": "acct:ken@coding.example",
        "objectType": "person"
    }
}

C’est simple et clair. Un exemple assez sympa de proof of contest est openframgame.com. C’est un site très simple de simulation de ferme. Vous avez de l’argent avec lequel vous achetez des parcelles, des semences et de l’eau. Vous plantez des semences, vous arrosez vos plantes et les revendez une fois atteinte la maturité. Rien de très intéressant dans le fonctionnement interne mais là où ça peut être intéressant est qu’il communique avec un compte Pump via des activty streams. Le fait que votre plante ait soif ou que vous ayez revendu une parcelle de tomates est une activité envoyée au serveur. Vous pourriez ainsi prévoir des réactions automatisées comme l’envoi de l’action d’arroser lorsque une plante a soif ou poster un message de victoire dès votre premier million amassé. On peut facilement imaginer les nombreuses possibilités si certains services utilisaient le couple activity streams – PubSubHubbub. En parlant de PuSH, Evan a annoncé dans un status vouloir l’intégrer dans pump.io.

Pourquoi pas du RSS (l’enfant pauvre et délaissé du web actuel) me diriez-vous ? Je ne suis pas dans la tête d’Evan mais il a un jour fait une réflexion disant que si Google abandonnait Google Reader (et donc le RSS), c’était sans doute car le RSS est très primitif. Pas de principe de conversation, on reste dans un schéma de producteur-consommateur qui ne correspond pas web social actuel. Personnellement, je ne pense pas que le RSS soit dépassé (car le schéma producteur-consommateur convient très bien à certains types de contenu) mais le rejoins sur le fait qu’il n’est pas adapté aux réseaux sociaux. Un flux public en RSS pour suivre les messages d’une personne peut être utile (je l’avais suggéré) mais ne doit pas être le protocole central pour l’interaction (ce qui était le cas dans StatusNet).

Ce qui est génial avec cette utilisation des activity streams est qu’il n’y a plus de formats différents pour l’API publique, la communication entre serveurs ou le flux d’un utilisateur : tout est activité (ou liste d’activités) au format JSON. J’envoie une activité (après authentification avec OAuth) avec le verbe « follow » à mon serveur pour donner l’ordre de suivre quelqu’un et je reçois en réponse, en cas de succès, l’activité qui apparaîtra dans mon flux. Même l’interface web est en fait un client web utilisant des activités avec le serveur. La plupart des actions (par exemple l’enregistrement d’un nouvel utilisateur) se fait via des activités.

Je vous laisse lire la page API.md pour plus de détails mais cela explique bien le fonctionnement général. C’est simple et propre, j’aime.

Tester

À quoi ressemble ce service ? C’est très facile, allez sur la page Try it qui vous redirigera aléatoirement vers une des 10 instances déployées par Evan. Contrairement à StatusNet qui avait identi.ca comme point central du réseau (au point où les gens confondaient parfois les deux et certains clients ne supportaient qu’identi.ca), Evan a voulu que Pump fonctionne réellement comme une fédération d’instances décentralisées.

pump-e homepage

Inscrivez-vous sur une instance, suivez d’autres gens (en passant par Login -> Account on another server? dans le cas d’utilisateurs sur d’autres serveurs), envoyez des messages et des images. On n’a pas encore toutes les fonctionnalités de StatusNet mais ce n’est pas loin.

Installation

Bon fini de rire, comment on déploie son instance sur son serveur ? Bonne nouvelle : il est assez simple de faire tourner un site en NodeJS. Mauvaise nouvelle : pour ceux qui font tourner plusieurs services sur une même machine via Apache ou Nginx, déployer Pump risque de vous poser des problèmes. Votre serveur web habituel écoutant sur le port 80 ou 443, il y a conflit avec NodeJS voulant écouter sur le même port.

Plusieurs possibilités s’offrent à vous :

  • utiliser pump seul sur le port 80 ou 443 (pas pratique)
  • utiliser pump sur une IP interne ou différente de celle utilisée par Apache/Nginx (pas facile, peut être fait en utilisant une machine virtuelle par exemple, configuration ici pour apache et ici pour nginx)
  • utiliser un port différent pour NodeJS avec un proxy redirigeant vos connexions vers le port 80 (perte de performance)

Il faut savoir que NodeJS a une bonne gestion de la concurrence ce qui lui permet, entre autres, de si bons benchmark. En utilisant un proxy, vous empêchez cette concurrence et réduisez les performances de Node à celles d’Apache. C’est dommage mais pas insurmontable non plus.

Après recherche, j’ai finalement trouvé deux systèmes fonctionnant pas trop mal avec Varnish (système de cache) et Apache : soit tout fonctionnant sur le port 80 avec Varnish servant de proxy, soit avec Pump écoutant sur le port 443 et Apache sur le port 80. Voulant utiliser du SSL pour pump, j’ai choisi la deuxième solution avec un certificat CaCert. Ci-dessous les explications des deux méthodes :

Tout sur le port 80

Première méthode : on n’utilise pas de SSL et fait tout tourner sur le port 80. Pour cela, j’utilise Varnish pour faire la différence, en m’aidant de ce tutoriel.

Configurez Varnish pour écouter sur le port 80 en modifiant le fichier /etc/default/varnish

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

Créez le fichier /etc/varnish/default.vcl pour indiquer la redirection

backend apache {
    .host = "127.0.0.1";
    .port = "6001";
}
backend node {
    .host = "127.0.0.1";
    .port = "6002";
}
sub vcl_recv {
    if(req.http.host == "pump.mart-e.be") {
        set req.backend = node;
    } else {
        set req.backend = apache;
    }

    if (req.http.Upgrade ~ "(?i)websocket") {
      return (pipe);
    }
}
sub vcl_pipe {
  if (req.http.upgrade) {
    set bereq.http.upgrade = req.http.upgrade;
  }
}

En cas de domaine contenant « pump.mart-e.be », on redirige vers le port 6002, autrement vers le port 6001. Les commandes avec « pipe » étant pour permettre le fonctionnement des websockets à travers Varnish. Il vous faudra ensuite faire écouter Apache sur le port 6001 au lieu de 80 en modifiant le fichier /etc/apache2/ports.conf.

NameVirtualHost *:6001
Listen 6001

et en changent tous vos <VirtualHost *:80> par <VirtualHost *:6001> dans la configuration des sites.

En ce qui concerne pump en lui même ce n’est pas trop compliqué. Le fait qu’on utilise le port 6002 pour pump vous permet de lancer node avec un utilisateur non-root. Pump ne fonctionne pas (encore) bien avec la version 0.10 de NodeJs (il manque même certaines dépendances je pense), préférez donc la 0.8. Comme pump.io est encore en développement actif, on préférera la version git à mettre à jour régulièrement. Les explications ci-dessous utilisent mongodb mais vous pouvez utiliser un autre service tel que Redis ou même laisser le « disk » par défaut pour ne pas avoir de base de donnée (attention aux performances).

# mkdir /var/www/pump && cd /var/www/pump
# git clone https://github.com/e14n/pump.io
# cd pump.io
# npm install
# cd node_modules/databank
# npm install databank-mongodb

Utilisez le fichier pump.io.json.sample pour créer le fichier /etc/pump.io.json. Voici le mien :

{
    "driver": "mongodb",
    "params": {"host": "localhost", "port": 27017},
    "secret": "azerty12345",
    "noweb": false,
    "site": "pump-e",
    "owner": "mart-e",
    "ownerURL": "http://mart-e.be",
    "port": 80,
    "serverUser": "www-data",
    "hostname": "pump.mart-e.be",
    "address": "127.0.0.1",
    "nologger": false,
    "uploaddir": "/var/www/pump/uploads",
    "debugClient": false,
    "firehose": "ofirehose.com"
}

Installez bien le paquet mongodb et démarrez le démon (ici sur le port 27017). N’oubliez pas non plus de créer le dossier uploaddir mentionné. Lancez pump via

$ node bin/pump &> pumpd.log

ou utilisez la commande forever (npm install -g forever) pour quelque chose de plus stable. Si vous sauvegardez les logs dans un fichier, vous pouvez les consulter via bunyan (npm install -g bunyan et puis tail -f pumpd.log | bunyan), ça en facilitera grandement la lecture.

Et ceci était un des premiers services à interagir avec pump, c'est beau !

Et ceci était un des premiers services à interagir avec pump, c’est beau !

Pump en SSL

La config précédente est bien, mais c’est encore mieux si on utilise du HTTPS ! Trouvez-vous donc un certificat SSL (openssl req -nodes -new -keyout server.key -out server.crt) et envoyez-le sur votre serveur. Comme on ne veut pas produire de page d’erreur quand les gens essayent d’accéder à pump en HTTP, on va utiliser Varnish pour faire une redirection, status HTTP 302. Le fichier /etc/varnish/default.vcl devient donc :

backend apache {
    .host = "127.0.0.1";
    .port = "6001";
}
sub vcl_recv {
    if(req.http.host == "pump.mart-e.be" && req.http.X-Forwarded-Proto !~ "(?i)https") {
        set req.http.x-Redir-Url = "https://pump.mart-e.be" req.url;
        error 750 req.http.x-Redir-Url;
    } else {
        set req.backend = apache;
    }

    if (req.http.Upgrade ~ "(?i)websocket") {
      return (pipe);
    }
}
sub vcl_error {
  if (obj.status == 750) {
    set obj.http.Location = obj.response;
    set obj.status = 302;
    return(deliver);
  }
}
sub vcl_pipe {
  if (req.http.upgrade) {
    set bereq.http.upgrade = req.http.upgrade;
  }
}

Attention, si vous avez la version 3 ou plus de Varnish (dans Debian stable c’est encore la 2), la concaténation se fait avec un +, la ligne de calcul d’URL devient donc : set req.http.x-Redir-Url = "https://pump.mart-e.be" + req.url;

Varnish ne gère pas le trafic SSL donc on est obligé de rester sur le port 80 pour ce dernier.

Rien de change du coté d’apache (par contre faites bien attention dans le fichier ports.conf de ne pas écouter sur le port 443) mais le fichier de config de pump devient :

{
    "driver": "mongodb",
    "params": {"host": "localhost", "port": 27017},
    "secret": "monkey1",
    "noweb": false,
    "site": "pump-e",
    "owner": "mart-e",
    "ownerURL": "http://mart-e.be",
    "port": 443,
    "serverUser": "www-data",
    "hostname": "pump.mart-e.be",
    "address": "pump.mart-e.be",
    "nologger": false,
    "uploaddir": "/var/www/pump/uploads",
    "debugClient": false,
    "firehose": "ofirehose.com",
    "key": "/etc/ssl/server.key",
    "cert": "/etc/ssl/server.crt"
}

Notez que le champ « address » est passé de 127.0.0.1 à pump.mart-e.be. Sans cela, je n’ai pas réussi à accéder à mon serveur depuis l’extérieur. Ajoutez également l’URL de votre serveur pump (pump.mart-e.be ici) dans le fichier /etc/hosts pointant vers 127.0.0.1. Ainsi, la boucle est bouclée pour l’accès en local.

Via mes tests, j’ai noté que les serveurs semblaient retenir les précédentes informations de connexion. C’est-à-dire que les serveurs avec lesquels j’avais interagi à l’époque de mauvaises configs ou lorsque je tournais sur le port 80 semblent avoir retenu ces infos et je n’arrive plus à les contacter. J’ai ouvert un bug report à ce sujet. En attendant que cela soit réglé, faites bien attention de choisir votre mode de connexion et de vous y tenir.

Les clients

C’est bien beau d’avoir une bonne API mais qu’en est-il des clients externes ? Hélas, on n’en est qu’aux débuts. Il existe actuellement une librairie en python PyPump, utilisée par Muon, un client ncurse l’utilisant. C’est tout à ma connaissance…

Le fonctionnement de l’API semblant assez simple, ça ne devrait qu’être une question de temps avant l’apparition de plus de clients mais actuellement c’est un frein certain à l’adoption de pump. Si vous voulez recevoir la reconnaissance de toute une communauté (1170 personnes aux dernières nouvelles), c’est l’occasion rêvée pour faire un peu de développement !

Les services externes

Si vous voulez passer à Pump, une fonctionnalité intéressante est les bridges avec les autres réseaux. C’est dans ce but que pump2status a été créé. Pour l’instant, ce site vous permet de lier votre compte pump à votre compte StatusNet et vous permet de découvrir les gens ayant fait la transition (comme moi !). Dans le futur, ce site vous permettera de publier sur StatusNet vos activités Pump. Sont également prévus, par ordre de priorité et hackerliness Google+, Twitter, Facebook sans doute même des Foursquare, LinkedIn et Instagram plus tard. En raison du bug des anciennes configs mémorisées, pas certain que vous me trouverez (si vous voyez mart@pump.jpope.org, c’est mon compte de test, je ne devrais plus l’utiliser).

Là où Status.Net englobait un maximum de fonctionnalités, le but de Pump.io est d’être beaucoup plus minimaliste dans son mode de fonctionnement et de se baser sur des services externes. Les fonctionnalités de gestion du spam sont par exemple déléguées à activityspam (dont spamicity.info est une instance, wiki) ou le service OFireHose est utilisé pour faciliter la fédération du contenu public (dont ofirehose.com est une instance).

Les passerelles fonctionneraient avec ce même principe. On pourrait ainsi avoir une application externe s’occupant de récupérer du contenu venant de Twitter et de le convertir en activités poussées vers un compte pump. C’est une des possibilités parmi d’autres mais le principe reste d’utiliser des services externes.

L’idée (pas mauvaise) est de garder le coeur de Pump.io minimale pour avoir quelque chose de robuste et hack-friendly. Mon seul regret est l’absence d’extensions, je ne suis pas certain que le modèle de services externes fonctionne dans tous les cas de figure (pour une modification des templates par exemple).

Le futur

Dans une présentation datant de février dernier, Evan annoncait vouloir migrer les serveurs identi.ca de Status.Net vers pump.io en avril 2013. Les inscriptions sur identi.ca sont bloquées depuis quelques jours. On verra si ça pourra se faire mais je pense que le logiciel n’est clairement pas encore assez mature pour faire la transition aujourd’hui.

Vous l'avez rêvé, e14n n'a fait : le bouton « Je n'aime pas » !

Vous en avez rêvé, e14n n’a fait : le bouton « Je n’aime pas » !

Un des soucis potentiel est que la transition casserait tous les clients Status.Net (n’utilisant plus l’API à la Twitter). Une possibilité serait de maintenir une compatibilité avec un bridge entre les deux. J’avais vu cette suggestion faite par Evan (mais n’arrive plus à retrouver le lien). Cela faciliterait grandement les choses le temps de la transition.

Si la sauce prend bien, Evan espère voir les gens adopter massivement pump.io et développer pour celui-ci. Les possibilités d’utilisation du réseau sont assez larges et intéressantes. Openfarmgame était une démo simple. Ih8.it en est une autre. On pourrait même imaginer des analyses globales des comportements via les publications poussées sur ofirehose (de la pub ?). Les principes de fédérations semblent bien réfléchis, et l’on devrait éviter les travers rencontrés avec StatusNet et identi.ca.

Si vous ne voulez pas passer à Pump.io (parce que ça ne correspond pas à ce que vous cherchez), faites une sauvegarde de votre compte identi.ca et utilisez Status.Net sur une autre instance (c’est le moment de passer à l’auto-hébergement). N’oubliez pas, ce n’est pas parce qu’identi.ca et Evan passent à Pump.io que la communauté est obligée de suivre. C’est du libre après tout.

Pump est encore un peu jeune mais néanmoins déjà utilisable. Essayez-le, faites-vous un avis et choississez ensuite si vous voulez rester sur StatusNet ou passer à Pump (ou utiliser les deux ou aucun). Je ne compte pas encore remplacer mon compte StatusNet par Pump mais ça sera sans doute le cas un jour (et me permettra d’abandonner définitivement mon compte Friendica inutilisé). En tout cas, espérons que ce réseau ne soit pas encore « un parmi tant d’autres ».


Les souvenirs et les regrets aussi.
Mais mon serveur silencieux et fidèle sourit toujours et remercie la vie.
Je t’aimais tant, tu étais si standardisée, comment veux-tu que je t’oublie ?

– Jacques Prévert.

Les réseaux libres et décentralisés c’est beau, pas de censure ou exploitation de vos données, bel exemple de liberté d’expression. Chacun choisissant son serveur, on évite les problèmes de points de passage uniques et diminue les problèmes en cas de défaillance d’un nœud. Enfin dans la théorie parce qu’en réalité c’est complètement le bordel. Les réseaux sociaux libres fleurissent un peu partout mais il n’y a pas moyen de s’entendre.

La semaine passée, pump.io venait de sortir sa version 0.2, une première release après 4 mois de développement (c’est là qu’on se rend compte que Diaspora avec ses 2 ans de développement s’est bien foutu de nous). Pump est un projet de Evan Prodromou, le créateur de StatusNet, et présenté comme la succession de ce dernier (prévu pour la 0.3, en avril 2013, les inscriptions sur identi.ca sont d’ailleurs désormais gelées). StatusNet continuera a vivre et être maintenu mais il ne faut pas s’attendre a voir de grandes nouveautés apparaître. Pump est écrit en NodeJS et avec une base de donnée NoSQL (MongoDB & co). Je n’ai aucun problème avec le fait d’abandonner le couple vieillissant PHP/MySQL (au contraire). Le point problématique est un aspect que l’on voit apparaître très souvent avec les réseaux sociaux libres : il n’utilise pas OStatus mais une nouvelle API. OStatus est une suite de protocoles (Atom, Activity Streams, PubSubHubbub, Salmon et Webfinger) qui permet de se mettre d’accord sur la façon dont deux serveurs OStatus peuvent communiquer. C’est grâce à OStatus que je ne suis pas obligé d’utiliser StatusNet pour communiquer avec quelqu’un l’utilisant, je peux utiliser Friendica par exemple. Cependant Friendica est un peu l’exception qui confirme la règle, a part lui qui met un point d’honneur a être compatible avec plusieurs réseaux, les autres utilisent systématiquement des manières propre pour communiquer.

Prenons l’exemple de Tent, un nouveau protocole décentralisé assez sympa (dont TentStatus est la partie permettant le microblogging). La façon de voir les choses est intéressante et suis convaincu qu’on puisse voir de chouettes projets apparaître (comme la page Related Projects le montre). Cependant ils ont fait le choix de recommencer from-scratch et cassant toute compatibilité. Les serveurs Tent ne peuvent parler qu’avec des serveurs Tent. Les raisons avancées pour ne pas utiliser OStatus sont discutables : pas de messages prives, impossible de changer de serveur en gardant les relations, pas d’API standard pour l’interaction. Mais comme mentionné dans un commentaire, c’est plus drôle de partir de zéro.

installation-parabole

Avec cette parabole Turbo+ 2.0, nous devrions enfin a comprendre leurs messages codés avec ce mystérieux « XMPP »

Vous vous souvenez de Diaspora ? Belle levée de fond, beaucoup d’espoirs, deux ans de développement pour finalement abandonner le projet a la communauté. Les créateurs décident de se concentrer sur leur sorte de générateur de meme (qui utilise ironiquement Facebook-connect, un bel aveu d’échec). Il semble avoir une bonne relève et il est possible que ce projet aboutisse a quelque chose mais Diaspora part avec une mauvaise base : un protocole interne quasi inexistant (qu’on pourrait presque qualifier de propriétaire). Diaspora avait été conçut sans trop savoir où aller puisque l’API n’était pas documentée et changeait tout le temps. Le projet Friendica a essayé d’être compatible avec celui ci mais a rencontre de nombreuses difficultés. Il semblerait que la communauté a prit conscience de ce problème puisqu’ils essayent d’être compatible avec d’autres réseaux. Personnellement, j’ai abandonné mais espoirs concernant Diaspora mais je peux changer d’avis, wait and see… ou pas.

Ces deux exemples ne sont pas les seuls, dans les plus connus on a aussi Movim (a base de XMPP, pas d’interopérabilité avec d’autres API type OStatus) ou SalutAToi (utilise une API basée sur XMPP documentée mais de leur cru quand même). Notons les bons élèves que sont Friendica et BuddyCloud puisqu’ils supportent plusieurs standards.

Pour revenir a Pump, Evan avait sans doute de bonnes raisons de changer la façon d’interagir entre serveurs, il s’y connaît en réseaux décentralisés et API. En raison de quelques problèmes avec StatusNet, il a préféré repartir sur une nouvelle base. Il annonçait quand même qu’un effort serait fait pour être compatible avec StatusNet. Cependant, l’API de base reste différente, toutes les fonctionnalités devront être adaptées pour faire la transition.

Pour se rendre compte du problème, imaginons maintenant que StatusNet ou Diaspora soient complètement abandonnés par les développeurs et ne soient plus maintenus. Les logiciels ont amassés une bonne base d’utilisateur mais ces utilisateurs vont lentement migrer vers des solutions plus modernes et maintenues. Sans l’émergence d’une solution supérieure, ils vont se diviser, se tournant peut être même vers une solution propriétaire. Cette migration se fera petit a petit, avec une base d’utilisateur ne voulant pas faire de migrer en raison de la communauté déjà présente sur son vieux réseau. Si ces logiciels ne sont plus maintenus, des Pump ou Friendica seront sans doute moins tentés de continuer a maintenir un niveau de compatibilité vers eux. Les nouvelles fonctionnalités ne seraient pas portées en OStatus. La communauté se retrouverait encore plus fragmentée. C’est évidement un scénario peu probable (déjà car OStatus n’est pas utilisé que par StatusNet) mais cela montre le problème des multiplications de standards : division de la communauté encore plus accentuée en cas d’abandon de projets.

Se mettre d’accord sur un protocole standard c’est une condition essentielle pour le succès des réseaux libres décentralisés. Sans cela, je ne pense pas que l’on pourra dominer les réseaux propriétaires centralisés ayant l’avantage de ne pas avoir a se soucier de ce problème. Je ne critique pas un standard en particulier (je ne me permettrais pas d’en désigner un supérieur aux autres), que ce soit OStatus, Pump, Tent, Diaspora ou un autre à base de XMPP, il faut se mettre d’accord sur une API commune et il faut arrêter d’en développer une nouvelle pour chaque logiciel. Toutes les API ne sont sans doute pas compatibles avec tous les cas de figure (sans parler de l’école HTTP vs XMPP) mais il y a sûrement moyen de dégrossir. Créer c’est bien, améliorer l’existant, c’est mieux.

CC-BY-NC XKCD

CC-BY-NC XKCD

Google a annoncé un nouveau modèle de Chromebook : le Pixel. Une machine à 1300$ avec des specs assez misérables : i5, 4GB de RAM, SSD de 32GB, une connectique, poids et encombrement assez banal pour un 13″. Ah non il a un écran haute définition (je dirais bien pour regarder un Blu-ray dans le train mais y a pas de lecteur) et un écran tactile (woo, sé taktil !). Non là où Google mise le tout est sur son OS minimaliste et son accès au cloud. Lorsque l’on achète cette machine, l’on reçoit 1TB de stockage sur les serveurs de Google via Google Drive pendant 3 ans. Ainsi à n’importe quel moment, sur n’importe quelle machine, on peut accéder à ses fichiers en ligne. Plus de risques de crash de disques durs, Google se charge de tout ! Elle est pas belle la vie ? Excusez-moi, je pars vomir et je reviens.

*bruit de chasse d’eau*

Non ! La vie n’est pas belle. Le concept du Chromebook est une des pires idées que l’on puisse avoir et qui me fait vraiment peur si ça marche. Dans un article du journal Le Soir de samedi dernier, l’on présentait le modèle comme s’attaquant de front à Apple. Ils ne croient pas si bien dire puisque je ne vois ça comme passer d’un gaspillage d’argent (silence fan boy d’Apple, c’est dépassé de troller avec toi) à un autre sans doute pire.

chromebook-nope

Il y a un concept simple qu’on oublie de plus en plus aujourd’hui : la propriété. Si un bien m’appartient, j’en fais ce que je veux. De la voiture que l’on peut repeindre aux murs que l’on peut abattre en passant par le livre que je peux revendre, l’informatique semble s’éloigner de ces concepts. Je loue un livre sur Amazon (puisqu’il en reste proprio et peut en faire ce qu’il veut), je loue ma musique à l’écoute sur Spotify (puisque je n’y aurai plus accès si j’arrête de payer ou si une major veut retirer son catalogue), je loue même ma vie sociale (puisque une fermeture de mon compte Facebook me réduirait à l’état d’ermite). Ça ne suffit pas ? Maintenant louez tout ! Vos emails, vos documents professionnels, vos photos de famille, votre carnet d’adresse, toute votre vie numérique ! Même supprimer un fichier ne dépendant plus de vous (le fichier reste sagement sur les serveurs de Google). Il s’agit ici d’une double location : vous payez le stockage en argent (après le 1TB pendant 3 ans, c’est 50$/mois pour la même capacité), avec votre vie privée (mais ça c’est pas neuf) et si ça ne suffit pas, vous êtes dépendant du fournisseur (Google) pour accéder à vos fichiers.

De par son mode de fonctionnement, il est évident qu’un accès internet est essentiel. Pas de connexion, pas de chocolat. Ils disent viser les power-users mais considérer que les professionnels ont un accès internet tout le temps est un peu optimiste (train ? déplacements ?). Même quand je reste à mon bureau au boulot à coté du routeur, il arrive que le net saute (et oui OpenERP a installé ses bureaux à la campagne). Si on avait tous des chromebooks, chômage technique ! Il y a bien un modèle avec puce 4G mais comptez 200$ de plus.

Berger seul

Il y a deux jours, la BBox de Jean-Kevin est tombée en panne

Bien sur l’accès internet va se faire d’en plus en plus présent, les forfaits illimités 4G ne devraient pas mettre trop longtemps à arriver, le problème d’accès n’est que temporaire. Seulement vous mettez tous vos œufs dans un même panier. Qu’on soit à la ferme, à la bourse ou en informatique, c’est une très mauvaise pratique, et d’autant plus si c’est un inconnu qui porte le panier. Ploum avait fait un très bon article en imaginant un monde selon Google, c’est l’occasion de le (re)lire. Google deviendra il une nouvelle prison dorée ?

Même si ce n’est pas de bon ton de souhaiter du malheur, c’est pourtant ce que je souhaite à ce Chromebook, pour le bonheur de l’informatique en général. Je dirais bien qu’il n’y a de toute façon aucune chance pour que les gens prennent mais les précédents historiques tels que les succès de Facebook ou d’Apple laissent songeur et craintif.

C’est lors de l’ouverture du FOSDEM de 2015 que Tristan Nitot a annoncé la décision d’utiliser Webkit comme moteur de rendu pour la version 37 de Firefox. Cette déclaration fut globalement très bien accueillie par la communauté. En effet depuis le passage l’an passé d’Internet Explorer à ce moteur de rendu, Mozilla faisait figure d’extraterrestre en étant un des seul à encore utiliser Gecko et non le traditionnel Webkit.

Dans un consortium réunissant entre autre Google, Apple, Opera et Microsoft, les meilleurs développeurs ont travaillé sans relâche sur Webkit pour lui ajouter les dernières fonctionnalités possibles. L’ajout du support de la balise html expérimentale <skype/> est d’ailleurs attendu dans la prochaine version avec beaucoup d’impatience.

Certains se souviennent encore du débat virulent du W3C lors de l’introduction de l’attribut CSS @webkit-import(facebook) qui permettait facilement de calquer le look de son site sur celui du célèbre réseau social. Ce vieux groupes de barbus de la première heure ne pouvait pas réaliser l’importance de ce type de fonctionnalités. On ne regrettera pas la dissolution de leur groupe de travail depuis longtemps inutile.

Jimmy Carter se recueillant devant la tombe du moteur de rendu inconnu

Jimmy Carter se recueillant devant la tombe du moteur de rendu inconnu

Avec ces nombreuses avancées, les logiciels dotés de webkit avaient une avance sans précédent. Même les smartphones d’entrée de gamme avec un misérable quad-core permettaient une partie en réseau fluide de The Elder Scroll VI (entièrement en HTML5) alors que Firefox n’implantait que la moitié des fonctionnalités requises.

Quelques libristes convaincus ont bien tenté l’expérience FirefoxOS mais la manque de compatibilité avec la plupart des sites web (passant pourtant le HTML5 Test de Google) rendait la navigation décourageante. Ce mauvais choix de technologie avait condamné le projet avant même une sortie de sa version stable.

Ça faisait longtemps que les web-développeurs en avaient assez de passer un temps considérable à adapter leurs designs. La décision de Mozilla était obligatoire si elle voulait avoir une chance de garder ses 5% de part de marcher. Qu’est-ce qu’il y a de mal à Webkit de toute façon ? Il est open source et très puissant, tout le monde s’accorde pour le dire. Enfin un seul moteur de rendu, un grand pas pour le développement web.

Cet article est une réaction à la triste décision d’Opera de passer de Presto à Webkit annoncée cette semaine.

Depuis quelques jours le documentaire TPB AFK: The Pirate Bay Away From Keyboard est disponible en téléchargement, streaming et pré-commande. Je viens de finir de le regarder et vous conseille de le faire également si ce n’est pas encore fait.

TPB AFK download now

Le reportage suit Gottfrid Svartholm, Fredrik Neij et Peter Sunde, les fondateurs du célèbre site The Pirate Bay de 2008 à 2012, le long de leur procès fait par Hollywood et l’industrie musicale pour violation de copyright.

Le documentaire ne cherche pas à tirer au clair les faits liés au procès mais se contente de suivre les 3 geeks. Des points comme savoir si le site générait ou non d’énormes revenus (affirmé par Hollywood, démenti par le trio) n’est par exemple que légèrement abordé. On découvre plutôt le coté moins connu et pas toujours reluisant de l’organisation (ou de la non-organisation). Gottfrid se drogue, Fredrik est raciste et alcoolique et la solidarité entre les trois n’est pas des plus présentes (fuir sans donner de nouvelles quand ça tourne mal). Peter (le porte parole) est sans doute celui qui avance le plus les arguments idéologiques de libre accès à la culture et partage d’information tandis que les deux autres s’intéressent plus à l’aspect technique qu’autre chose.

On a également quelques moments assez délicieux comme Fredrik expliquant au juge avoir un filtre anti-spam redirigeant les emails contenant “DMCA” (dont les réponses sont connues) ou Gottfrid déclarant aux journalistes que la stratégie des procureurs est de mentir d’une façon tellement ennuyante qu’on s’endort et n’arrive plus à se défendre. Mon extrait préféré restant une déclaration de Peter en réponse à “quand vous êtes vous rencontré IRL pour la première fois ?”

We don’t like that expression.
We say AFK – Away From Keyboard.
We think that the internet is for real.

Le film est disponible en pré-commande sur tpbafk.tv, en streaming sur youtube ou en téléchargement BitTorrent sur TPB bien entendu.

TPB.AFK.2013.720p.h264-SimonKlose (magnet)

Internet grouille déjà de traductions dont une française est par exemple disponible ici.

En conclusion un documentaire très intéressant que tout utilisateur du site devrait regarder.

SMailArchiver v0.4

26 January 2013

Il y a quelques semaines, j’avais présenté SMailArchiver, mon script de backup d’email sécurisés en python. Aujourd’hui un petit article pour les nouveautés de la nouvelle version 0.4.

Concernant les fonctionnalités, SMailArchiver permet désormais le stockage en clair si l’argument -e ou --encrypt n’est pas utilisé. Chaque email est toujours stocké individuellement pour faciliter l’incrémental mais la commande de restauration devient -r ou --restore pour plus de cohérence (précédemment -d ou --decrypt dans la version 0.3). Celle-ci se chargera de créer un seul fichier. Le format du fichier de configuration json a également légèrement été modifié en conséquence.

L’extension pour le stockage gagne également en cohérence. Un fichier anciennement nommé 42.gz.mbox deviendra désormais 42.mbox.gz.enc, ce qui indique : un email au format mbox compressé puis chiffré. Un mail non compressé et/ou non chiffré n’aura pas l’extension .gz et/ou .enc. La restauration se base sur ces extensions pour les manipulations à réaliser.

crowed

Un peu de patience, tout le monde aura sa mise à jour

Pour ceux ayant réalisé leurs backup avec la version 0.3, un script de migration a été créé pour régler le problème de changement de format. Renseignez le dossier contenant les mails (placez éventuellement le fichier de configuration dedans) ainsi que la version depuis laquelle vous arrivez (0.3 dans ce cas). Le script se chargera de renommer les fichiers et modifier le fichier de config.

$ python migrate.py -f backup_folder/ -v 0.3
Migration from 0.3 to 0.4…
1 valid config file migrated
42.gz.mbox -> 42.mbox.gz.enc

Done.

Le programme est désormais également accessible depuis github en plus de gitorious. En espérant que cela favorisera une éventuelle contribution (non ceci n’est pas du tout un appel caché).

Étant donné que je parle essentiellement de ce script sur un blog francophone, il me semblait normal de mettre les instructions en Français. Aux cotés du précédent README, se trouve maintenant un fichier LISEZMOI. Si des polyglottes me lisent, n’hésitez pas a me soumettre des traductions en Burgonde ou Klingon.

Last but not least, l’utilisation de la licence MIT. Jusqu’à présent il n’y avait pas de licence formelle ce qui était problématique pour l’utilisation du code dans d’autres programmes. Chose réglée, j’ai opté pour une licence permissive, je n’avais pas envie d’ennuyer avec les contraintes de la GPL pour un si petit bout de code, du code réutilisé est une reconnaissance en soit.