Carnets en ligne - Technologie

Let's Encrypt + HAProxy

2016-02-11T00:00:00+01:00

Note : Cet article n'est plus à jour. Il est maintenant (2018) possible d'installer des certificats SSL Let's Encrypt d'une manière beaucoup plus simple, en utilisant certbot (et le plugin nginx certbot --nginx).

It’s time for the Web to take a big step forward in terms of security and privacy. We want to see HTTPS become the default. Let’s Encrypt was built to enable that by making it as easy as possible to get and manage certificates.

-- Let's Encrypt

Depuis début Décembre, la nouvelle autorité de certification Let's Encrypt est passée en version Beta. Les certificats SSL sont un moyen de 1. chiffrer la communication entre votre navigateur et le serveur et 2. un moyen d'être sur que le site Web auquel vous accédez est celui auquel vous pensez vous connecter (pour éviter des attaques de l'homme du milieu).

Jusqu'à maintenant, il était nécessaire de payer une entreprise pour faire en sorte d'avoir des certificats qui évitent d'avoir ce genre d'erreurs dans vos navigateurs:

Maintenant, grâce à Let's Encrypt il est possible d'avoir des certificats SSL gratuits, ce qui représente un grand pas en avant pour la sécurité de nos communications.

Je viens de mettre en place un procédé (assez simple) qui permet de configurer votre serveur pour générer des certificats SSL valides avec Let's Encrypt et le répartiteur de charge HAProxy.

Je me suis basé pour cet article sur d'autres articles, dont je vous recommande la lecture pour un complément d'information.

Validation des domaines par Let's Encrypt

Je vous passe les détails d'installation du client de Let's Encrypt, qui sont très bien expliqués sur leur documentation.

Une fois installé, vous allez taper une commande qui va ressembler à:

letsencrypt-auto certonly --renew-by-default
--webroot -w /home/www/letsencrypt-requests/ \
-d hurl.kinto-storage.org \
-d forums.kinto-storage.org

Le webroot est l'endroit ou les preuves de détention du domaine vont être déposées.

Lorsque les serveurs de Let's Encrypt vont vouloir vérifier que vous êtes bien à l'origine des demandes de certificats, ils vont envoyer une requête HTTP sur http://domaine.org/.well-known/acme-challenge, ou il voudra trouver des informations qu'il aura généré via la commande letsencrypt-auto.

J'ai choisi de faire une règle dans haproxy pour diriger toutes les requêtes avec le chemin .well-known/acme-challenge vers un backend nginx qui sert des fichiers statiques (ceux contenus dans /home/www/letsencrypt-requests/).

Voici la section de la configuration de HAProxy (et la configuration complete si ça peut être utile):

frontend http
    bind 0.0.0.0:80
    mode http
    default_backend nginx_server

    acl letsencrypt_check path_beg /.well-known/acme-challenge
    use_backend letsencrypt_backend if letsencrypt_check

    redirect scheme https code 301 if !{ ssl_fc } !letsencrypt_check

backend letsencrypt_backend
    http-request set-header Host letsencrypt.requests
    dispatch 127.0.0.1:8000

Et celle de NGINX:

server {
    listen 8000;
    server_name letsencrypt.requests;
    root /home/www/letsencrypt-requests;
}

Installation des certificats dans HAProxy

Vos certificats SSL devraient être générés dans /etc/letsencrypt/live, mais ils ne sont pas au format attendu par haproxy. Rien de grave, la commande suivant convertit l'ensemble des certificats en une version compatible avec HAProxy:

cat /etc/letsencrypt/live/domaine.org/privkey.pem /etc/letsencrypt/live/domaine.org/fullchain.pem > /etc/ssl/letsencrypt/domaine.org.pem

Et ensuite dans la configuration de haproxy, pour le (nouveau) frontend https:

bind 0.0.0.0:443 ssl no-sslv3 crt /etc/ssl/letsencrypt

Faites bien attention à avoir un frontend https pour tous vos sites en HTTPS. Pour moi cela ressemble à ça.

Une fois tout ceci fait, redémarrez votre service haproxy et zou !

Automatisation

Pour automatiser un peu tout ça, j'ai choisi de faire ça comme suit:

Un fichier domaine dans letsencrypt/domains/domain.org qui contient le script letsencrypt.
Un fichier d'installation de certificats dans letsencrypt/install-certs.sh qui s'occupe d'installer les certificats déjà générés.

Et voila ! Le tout est dans un dépot github, si jamais ça peut vous servir, tant mieux !

Ateliers d'autodéfense numérique

2016-01-14T00:00:00+01:00

Il y a huit mois, je me rendais compte de l'importance du choix des outils pour faire face à la surveillance généralisée, et notamment en rapport au chiffrement des données. Une de mes envies de l'époque était l'animation d'ateliers.

Je compte donc:

Organiser des ateliers de sensibilisation aux outils de communication, envers mes proches;

Utiliser la communication chiffrée le plus souvent possible, au moins pour rendre le déchiffrement des messages plus longue, "noyer le poisson".

-- Chiffrement

J'ai mis un peu de temps à mettre le pied à l'étrier, mais je ressors finalement du premier atelier que j'ai co-animé avec geb, auprès d'un public de journalistes.

Pour cette première édition l'idée était à la fois d'aller à la rencontre d'un public que je connais mal, de leur donner des outils pour solutionner les problèmes auxquels ils font parfois face, et de me faire une idée de ce que pouvait être un atelier sur l'autodéfense numérique.

L'objectif pour ce premier atelier était de:

Échanger autour des besoins et faire ressortir des histoires ou le manque d'outillage / connaissances à posé problème, dans des situations concrètes;
Se rendre compte des "conduites à risque", faire peur aux personnes formées pour qu'elles se rendent compte de l'état actuel des choses;
Proposer des solutions concrètes aux problèmes soulevés, ainsi que le minimum de connaissance théorique pour les appréhender.

1. Faire ressortir les problèmes

Afin de faire ressortir les problèmes, nous avons choisi de constituer des petits groupes de discussion, afin de faire des "Groupes d'Interview Mutuels", ou "GIM":

l’animateur invite les participants à se regrouper par trois, avec des personnes qu’on connaît moins puis invite chacun à livrer une expérience vécue en lien avec le thème de la réunion et les deux autres à poser des questions leur permettant de bien saisir ce qui a été vécu.

-- «Pour s'écouter», SCOP Le Pavé.

De ces GIMs nous avons pu ressortir quelques histoires, gravitant autour de:

La protection des sources (d'information): Comment faire pour aider quelqu'un à faire "fuiter" des données depuis l'intérieur d'une entreprise ?
Le chiffrement de ses données: Comment éviter de faire "fuiter" des données importantes lors d'une perquisition de matériel ?

2. Faire peur

Un des premiers objectifs est de faire peur, afin que tout le monde se rende compte à quel point il est facile d'accéder à certaines données. Grégoire m'avait conseillé quelques petites accroches qui ont ma foi bien marché:

J'ai demandé aux présent.e.s de:

donner leur mot de passe à voix haute devant les autres: a priori personne ne le fera;
venir se connecter à leur compte email depuis mon ordinateur. J'ai piégé une personne, qui est venu pour taper son mot de passe.

Cela à été un bon moyen de parler de l'importance des traces que l'on peut laisser sur un ordinateur, et de la confiance qu'il faut avoir dans le matériel que l'on utilise, à fortiori si ce ne sont pas les vôtres.

Pour continuer à leur faire peur, après une brève explication de ce qu'est SSL nous avons montré comment il était facile de scruter le réseau à la recherche de mots de passe en clair.

3. Proposer des solutions concrêtes

Une fois que tout le monde avait pleinement pris sonscience des problématiques et n'osait plus utiliser son ordinateur ou son téléphone, on à commencé à parler de quelques solutions. Plusieurs approches étaient possibles ici, nous avons choisi de présenter quelques outils qui nous semblaient répondre aux attentes:

On a expliqué ce qu'était Tails, et comment l'utiliser et le dupliquer.
On a pu faire un tour des outils existants sur Tails, notamment autour de l'anonymisation de fichiers et la suppression effective de contenus.
Certaines personnes ont pu créer une clé tails avec la persistance de configurée.
Nous nous sommes connectés au réseau Tor et testé que nos adresses IP changeaient bien à la demande.
Nous avons utilisé CryptoCat par dessus Tor, afin de voir comment avoir une conversation confidentielle dans laquelle il est possible d'échanger des fichiers.

Retours

D'une manière générale, pour une formation de trois heures et demi, je suis assez content de l'exercice, et de l'ensemble des sujets que nous avons pu couvrir. Il y a beaucoup de place pour l'amélioration, notamment en amont (j'avais par exemple oublié d'amener avec moi suffisamment de clés USB pour utiliser Tails).

La plupart des retours qu'on a pu avoir jusqu'à maintenant sont positifs, et il y a l'envie d'aller plus loin sur l'ensemble de ces sujets.

La suite

Il y a beaucoup de sujets que nous n'avons pas abordés, ou uniquement survolés, à cause du manque de temps disponible. Idéalement, il faudrait au moins une journée entière pour couvrir quelques sujets plus en détail (on peut imaginer avoir une partie théorique le matin et une partie pratique l'après-midi par exemple).

J'ai choisi volontairement de ne pas aborder le chiffrement des messages via PGP parce que je pense que la protection que ce média propose n'est pas suffisante, mais je suis en train de revenir sur ma décision: il pourrait être utile de présenter l'outil, à minima, en insistant sur certaines de ses faiblesses.

Un compte twitter à été créé recemment autour des crypto-party à Rennes, si vous êtes interessés, allez jeter un coup d'œil!

Je n'ai pas trouvé de ressources disponibles par rapport à des plans de formation sur le sujet, j'ai donc décidé de publier les nôtres, afin de co-construire avec d'autres des plans de formation.

Ils sont pour l'instant disponibles sur Read The Docs. Tous les retours sont évidemment les bienvenus !

Le mail doit-il mourir ?

2015-11-24T00:00:00+01:00

J'utilise quotidiennement le protocole email, tant bien que mal, tout en sachant que l'ensemble de mes messages passent en clair sur le réseau pour la plupart de mes conversations, puisque trop peu de monde utilise le chiffrement des messages.

Et même si j'arrive à convaincre certains de mes proches à installer PGP, je ne suis pas satisfait du résultat: les méta-données (qui contacte qui à quel moment, et pour lui dire quoi) transitent de toute manière, elles, en clair, à la vue de tous.

Ce problème est lié directement au protocole email: il est necessaire de faire fuiter ces meta-données (au moins le destinataire) pour avoir un protocole mail fonctionnel.

Le mail répond à un besoin de communication asynchrone qui permet des conversations plus réfléchies qu'un simple chat (miaou). Il est tout à fait possible d'utiliser certaines technologies existantes afin de construire le futur de l'email, pour lequel:

Les méta-données seraient chiffrées — Il n'est pas possible de savoir qui communique avec qui, et quand;
Le chiffrement serait fort (et protégé d'une phrase de passe ?);
La fuite d'une clé de chiffrement utilisée dans un échange ne permette pas de déchiffrer l'ensemble des échanges (forward secrecy);
Il ne soit pas possible de réutiliser les données comme preuve pour incriminer l'emmeteur du message (deniability);

Avec au moins ces besoins en tête, il semble qu'une revue de l'ensemble des projets existants pointe du doigt vers pond, ou vers Signal.

Malheureusement, Pond est le projet d'une seule personne, qui veut plutôt utiliser ce code comme démonstration du concept en question.

Web distribution signing

2015-10-12T00:00:00+02:00

I'm not a crypto expert, nor pretend to be one. These are thoughts I want to share with the crypto community to actually see if any solution exists to solve this particular problem.

One often pointed flaw in web-based cryptographic applications is the fact that there is no way to trust online software distributions. Put differently, you don't actually trust the software authors but are rather trusting the software distributors and certificate authorities (CAs).

I've been talking with a few folks in the past months about that and they suggested me to publish something to discuss the matter. So here I come!

The problem (Attack vectors)

Let's try to describe a few potential attacks:

Application Authors just released a new version of their open source web crypto messaging application. An Indie Hoster installs it on their servers so a wide audience can actually use it.

Someone alters the files on Indie Hoster servers, effectively replacing them with other altered files with less security properties / a backdoor. This someone could either be an Evil Attacker which found its way trough, the Indie Hoster or a CDN which delivers the files,

Trusted Certificate Authorities ("governments" or "hacking team") can also trick the User Agents (i.e. Firefox) into thinking they're talking to Indie Hoster even though they're actually talking to a different server.

Altered files are then being served to the User Agents, and Evil Attacker now has a way to actually attack the end users.

Problem Mitigation

Part of the problem is solved by the recently introduced Sub Resource Integrity (SRI). To quote them: "[it] defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation.".

SRI is a good start, but isn't enough: it ensures the assets (JavaScript files, mainly) loaded from a specific HTML page are the ones the author of the HTML page intends. However, SRI doesn't allow the User Agent to ensure the HTML page is the one he wants.

In other words, we miss a way to create trust between Application Authors and User Agents. The User-Agent currently has to trust the Certificate Authorities and the delivery (Indie Hoster).

For desktop software distribution: Crypto Experts audit the software, sign it somehow and then this signature can be checked locally during installation or runtime. It's not automated, but at least it's possible.

For web applications, we don't have such a mechanism, but it should be possible. Consider the following:

App Authors publish a new version of their software; They provide a hash of each of their distributed files (including the HTML files);
Crypto Experts audit these files and sign the hashes somehow;
User Agents can chose to trust some specific Crypto Experts;
When a User Agent downloads files, it checks if they're signed by a trusted party.

Chosing who you trust

In terms of user experience, handling certificates is hard, and that's where the community matters. Distributions such as Tails could chose who they trust to verify the files, and issue warnings / refuse to run the application in case files aren't verified.

But, as highligted earlier, CAs are hard to trust. A new instance of the same CA system wouldn't make that much differences, expect the fact that distributions could ship with a set of trusted authorities (for which revocation would still need to be taken care of).

[...] users are vulnerable to MitM attacks by the authority, which can vouch for, or be coerced to vouch for, false keys. This weakness has been highlighted by recent CA scandals. Both schemes can also be attacked if the authority does not verify keys before vouching for them.

-- SoK : Secure Messaging;

It seems that some other systems could allow for something more reliable:

Melara et al proposed CONIKS, using a series of chained commitments to Merkle prefix trees to build a key directory [...] for which individual users can efficiently verify the consistency of their own entry in the directory without relying on a third party.

This “self- auditing log” approach makes the system partially have no auditing required (as general auditing of non-equivocation is still required) and also enables the system to be privacy preserving as the entries in the directory need not be made public. This comes at a mild bandwidth cost not reflected in our table, estimated to be about 10 kilobytes per client per day for self-auditing.

-- SoK : Secure Messaging;

Now, I honestly have no idea if this thing solves the whole problem, and I'm pretty sure this design has many security problems attached to it.

However, that's a problem I would really like to see solved one day, so here the start of the discussion, don't hesitate to get in touch!

Addendum

It seems possible to increase the level a user has in a Web Application by adding indicators in the User-Agent. For instance, when using an application that's actually signed by someone considered trustful by the User-Agent (or the distributor of the User-Agent), a little green icon could be presented to the User, so they know that they can be confident about this.

A bit like User-Agents do for SSL, but for the actual signature of the files being viewed.

Service de nuages : Pourquoi avons-nous fait Cliquet ?

2015-07-14T00:00:00+02:00

Cet article est repris depuis le blog « Service de Nuages » de mon équipe à Mozilla

tldr; Cliquet est un toolkit Python pour construire des APIs, qui implémente les bonnes pratiques en terme de mise en production et de protocole HTTP.

Les origines

L'objectif pour le premier trimestre 2015 était de construire un service de stockage et de synchronisation de listes de lecture.

Au démarrage du projet, nous avons tenté de rassembler toutes les bonnes pratiques et recommandations, venant de différentes équipes et surtout des derniers projets déployés.

De même, nous voulions tirer parti du protocole de Firefox Sync, robuste et éprouvé, pour la synchronisation des données «offline».

Plutôt qu'écrire un énième article de blog, nous avons préféré les rassembler dans ce qu'on a appellé «un protocole».

Comme pour l'architecture envisagée nous avions deux projets à construire, qui devaient obéir globalement à ces mêmes règles, nous avons décidé de mettre en commun l'implémentation de ce protocole et de ces bonnes pratiques dans un «toolkit».

Cliquet est né.

Les intentions

Quelle structure JSON pour mon API ? Quelle syntaxe pour filtrer la liste via la querystring ? Comment gérer les écritures concurrentes ? Et synchroniser les données dans mon application cliente ?

Désormais, quand un projet souhaite bénéficier d'une API REST pour stocker et consommer des données, il est possible d'utiliser le protocole HTTP proposé et de se concentrer sur l'essentiel. Cela vaut aussi pour les clients, où la majorité du code d'interaction avec le serveur est réutilisable.

Comment pouvons-nous vérifier que le service est opérationnel ? Quels indicateurs StatsD ? Est-ce que Sentry est bien configuré ? Comment déployer une nouvelle version sans casser les applications clientes ?

Comme Cliquet fournit tout ce qui est nécessaire pour être conforme avec les exigences de la mise en production, le passage du prototype au service opérationnel est très rapide ! De base le service répondra aux attentes en terme supervision, configuration, déploiement et dépréciation de version. Et si celles-ci évoluent, il suffira de faire évoluer le toolkit.

Quel backend de stockage pour des documents JSON ? Comment faire si l'équipe de production impose PostgreSQL ? Et si on voulait passer à Redis ou en mémoire pour lancer les tests ?

En terme d'implémentation, nous avons choisi de fournir des abstractions. En effet, nous avions deux services dont le coeur consistait à exposer un CRUD en REST, persistant des données JSON dans un backend. Comme Pyramid et Cornice ne fournissent rien de tout prêt pour ça, nous avons voulu introduire des classes de bases pour abstraire les notions de resource REST et de backend de stockage.

Dans le but de tout rendre optionnel et «pluggable», tout est configurable depuis le fichier .ini de l'application. Ainsi tous les projets qui utilisent le toolkit se déploieront de la même manière : seuls quelques éléments de configuration les distingueront.

Le protocole

Est-ce suffisant de parler d'«API REST» ? Est-ce bien nécessaire de relire la spec HTTP à chaque fois ? Pourquoi réinventer un protocole complet à chaque fois ?

Quand nous développons un (micro)service Web, nous dépensons généralement beaucoup trop d'énergie à (re)faire des choix (arbitraires).

Nul besoin de lister ici tout ce qui concerne la dimension de la spécification HTTP pure, qui nous impose le format des headers, le support de CORS, la négocation de contenus (types mime), la différence entre authentification et autorisation, la cohérence des code status...

Les choix principaux du protocole concernent surtout :

Les resources REST : Les deux URLs d'une resource (pour la collection et les enregistrements) acceptent des verbes et des headers précis.
Les formats : le format et la structure JSON des réponses est imposé, ainsi que la pagination des listes ou la syntaxe pour filtrer/trier les resources via la querystring.
Les timestamps : un numéro de révision qui s'incrémente à chaque opération d'écriture sur une collection d'enregistrements.
La synchronisation : une série de leviers pour récupérer et renvoyer des changements sur les données, sans perte ni collision, en utilisant les timestamps.
Les permissions : les droits d'un utilisateur sur une collection ou un enregistrement (encore frais et sur le point d'être documenté) [1].
Opérations par lot: une URL qui permet d'envoyer une série de requêtes décrites en JSON et d'obtenir les réponses respectives.

Dans la dimension opérationnelle du protocole, on trouve :

La gestion de version : cohabitation de plusieurs versions en production, avec alertes dans les entêtes pour la fin de vie des anciennes versions.
Le report des requêtes : entêtes interprétées par les clients, activées en cas de maintenance ou de surchage, pour ménager le serveur.
Le canal d'erreurs : toutes les erreurs renvoyées par le serveur ont le même format JSON et ont un numéro précis.
Les utilitaires : URLs diverses pour répondre aux besoins exprimés par l'équipe d'administrateurs (monitoring, metadonnées, paramètres publiques).

Ce protocole est une compilation des bonnes pratiques pour les APIs HTTP (c'est notre métier !), des conseils des administrateurs système dont c'est le métier de mettre à disposition des services pour des millions d'utilisateurs et des retours d'expérience de l'équipe de Firefox Sync pour la gestion de la concurrence et de l'«offline-first».

Il est documenté en détail.

Dans un monde idéal, ce protocole serait versionné, et formalisé dans une RFC. En rêve, il existerait même plusieurs implémentations avec des technologies différentes (Python, Go, Node, etc.). [2]

[1]	Voir notre article dédié sur les permissions

[2]	Rappel: nous sommes une toute petite équipe !

Le toolkit

Choix techniques

Cliquet implémente le protocole en Python (2.7, 3.4+, pypy), avec Pyramid [3].

Pyramid est un framework Web qui va prendre en charge tout la partie HTTP, et qui s'avère pertinent aussi bien pour des petits projets que des plus ambitieux.

Cornice est une extension de Pyramid, écrite en partie par Alexis et Tarek, qui permet d'éviter d'écrire tout le code boilerplate quand on construit une API REST avec Pyramid.

Avec Cornice, on évite de réécrire à chaque fois le code qui va cabler les verbes HTTP aux méthodes, valider les entêtes, choisir le sérialiseur en fonction des entêtes de négociation de contenus, renvoyer les codes HTTP rigoureux, gérer les entêtes CORS, fournir la validation JSON à partir de schémas...

Cliquet utilise les deux précédents pour implémenter le protocole et fournir des abstractions, mais on a toujours Pyramid et Cornice sous la main pour aller au delà de ce qui est proposé !

[3]	Au tout début nous avons commencé une implémentation avec Python-Eve (Flask), mais n'étions pas satisfaits de l'approche pour la configuration de l'API. En particulier du côté magique.

Concepts

Bien évidemment, les concepts du toolkit reflètent ceux du protocole mais il y a des éléments supplémentaires:

Les backends : abstractions pour le stockage, le cache et les permissions (ex. PostgreSQL, Redis, en-mémoire, ...)
La supervision : logging JSON et indicateurs temps-réel (StatsD) pour suivre les performances et la santé du service.
La configuration : chargement de la configuration depuis les variables d'environnement et le fichier .ini
La flexibilité : dés/activation ou substitution de la majorité des composants depuis la configuration.
Le profiling : utilitaires de développement pour trouver les goulets d'étranglement.

Proportionnellement, l'implémentation du protocole pour les resources REST est la plus volumineuse dans le code source de Cliquet. Cependant, comme nous l'avons décrit plus haut, Cliquet fournit tout un ensemble d'outillage et de bonnes pratiques, et reste donc tout à fait pertinent pour n'importe quel type d'API, même sans manipulation de données !

L'objectif de la boîte à outils est de faire en sorte qu'un développeur puisse constuire une application simplement, en étant sûr qu'elle réponde aux exigeances de la mise en production, tout en ayant la possibilité de remplacer certaines parties au fur et à mesure que ses besoins se précisent.

Par exemple, la persistence fournie par défault est schemaless (e.g JSONB), mais rien n'empêcherait d'implémenter le stockage dans un modèle relationnel.

Comme les composants peuvent être remplacés depuis la configuration, il est tout à fait possible d'étendre Cliquet avec des notions métiers ou des technologies exotiques ! Nous avons posé quelques idées dans la documentation de l'éco-système.

Dans les prochaines semaines, nous allons introduire la notion d'«évènements» (ou signaux), qui permettraient aux extensions de s'interfacer beaucoup plus proprement.

Nous attachons beaucoup d'importance à la clareté du code, la pertinence des patterns, des tests et de la documentation. Si vous avez des commentaires, des critiques ou des interrogations, n'hésitez pas à nous en faire part !

Cliquet, à l'action.

Nous avons écrit un guide de démarrage, qui n'exige pas de connaître Pyramid.

Pour illustrer la simplicité et les concepts, voici quelques extraits !

Étape 1

Activer Cliquet:

import cliquet
from pyramid.config import Configurator

def main(global_config, **settings):
    config = Configurator(settings=settings)

    cliquet.initialize(config, '1.0')
    return config.make_wsgi_app()

À partir de là, la plupart des outils de Cliquet sont activés et accessibles.

Par exemple, les URLs hello (/v1/) ou supervision (/v1/__heartbeat__). Mais aussi les backends de stockage, de cache, etc. qu'il est possible d'utiliser dans des vues classiques Pyramid ou Cornice.

Étape 2

Ajouter des vues:

def main(global_config, **settings):
    config = Configurator(settings=settings)

    cliquet.initialize(config, '1.0')
    config.scan("myproject.views")
    return config.make_wsgi_app()

Pour définir des resources CRUD, il faut commencer par définir un schéma, avec Colander, et ensuite déclarer une resource:

from cliquet import resource, schema

class BookmarkSchema(schema.ResourceSchema):
    url = schema.URL()

@resource.register()
class Bookmark(resource.BaseResource):
    mapping = BookmarkSchema()

Désormais, la resource CRUD est disponible sur /v1/bookmarks, avec toutes les fonctionnalités de synchronisation, filtrage, tri, pagination, timestamp, etc. De base les enregistrements sont privés, par utilisateur.

$ http GET "http://localhost:8000/v1/bookmarks"
HTTP/1.1 200 OK
...
{
    "data": [
        {
            "url": "http://cliquet.readthedocs.org",
            "id": "cc103eb5-0c80-40ec-b6f5-dad12e7d975e",
            "last_modified": 1437034418940,
        }
    ]
}

Étape 3

Évidemment, il est possible choisir les URLS, les verbes HTTP supportés, de modifier des champs avant l'enregistrement, etc.

@resource.register(collection_path='/user/bookmarks',
                   record_path='/user/bookmarks/{{id}}',
                   collection_methods=('GET',))
class Bookmark(resource.BaseResource):
    mapping = BookmarkSchema()

    def process_record(self, new, old=None):
        if old is not None and new['device'] != old['device']:
            device = self.request.headers.get('User-Agent')
            new['device'] = device
        return new

Plus d'infos dans la documentation dédiée !

Note

Il est possible de définir des resources sans validation de schema. Voir le code source de Kinto.

Étape 4 (optionelle)

Utiliser les abstractions de Cliquet dans une vue Cornice.

Par exemple, une vue qui utilise le backend de stockage:

from cliquet import Service

score = Service(name="score",
                path='/score/{game}',
                description="Store game score")

@score.post(schema=ScoreSchema)
def post_score(request):
    collection_id = 'scores-' + request.match_dict['game']
    user_id = request.authenticated_userid
    value = request.validated  # c.f. Cornice.

    storage = request.registry.storage
    record = storage.create(collection_id, user_id, value)
    return record

Vos retours

N'hésitez pas à nous faire part de vos retours ! Cela vous a donné envie d'essayer ? Vous connaissez un outil similaire ? Y-a-t-il des points qui ne sont pas clairs ? Manque de cas d'utilisation concrets ? Certains aspects mal pensés ? Trop contraignants ? Trop de magie ? Overkill ?

Nous prenons tout.

Points faibles

Nous sommes très fiers de ce que nous avons construit, en relativement peu de temps. Et comme nous l'exposions dans l'article précédent, il y a du potentiel !

Cependant, nous sommes conscients d'un certain nombre de points qui peuvent être vus comme des faiblesses.

La documentation d'API : actuellement, nous n'avons pas de solution pour qu'un projet qui utilise Cliquet puisse intégrer facilement toute la documentation de l'API obtenue.
La documentation : il est très difficile d'organiser la documentation, surtout quand le public visé est aussi bien débutant qu'expérimenté. Nous sommes probablement victimes du «curse of knowledge».
Le protocole : on sent bien qu'on va devoir versionner le protocole. Au moins pour le désolidariser des versions de Cliquet, si on veut aller au bout de la philosophie et de l'éco-système.
Le conservatisme : Nous aimons la stabilité et la robustesse. Mais surtout nous ne sommes pas tout seuls et devons nous plier aux contraintes de la mise en production ! Cependant, nous avons très envie de faire de l'async avec Python 3 !
Publication de versions : le revers de la médaille de la factorisation. Il arrive qu'on préfère faire évoluer le toolkit (e.g. ajouter une option) pour un point précis d'un projet. En conséquence, on doit souvent releaser les projets en cascade.

Quelques questions courantes

Pourquoi Python ?

On prend beaucoup de plaisir à écrire du Python, et le calendrier annoncé initialement était très serré: pas question de tituber avec une technologie mal maitrisée !

Et puis, après avoir passé près d'un an sur un projet Node.js, l'équipe avait bien envie de refaire du Python.

Pourquoi pas Django ?

On y a pensé, surtout parce qu'il y a plusieurs fans de Django REST Framework dans l'équipe.

On l'a écarté principalement au profit de la légèreté et la modularité de Pyramid.

Pourquoi pas avec un framework asynchrone en Python 3+ ?

Pour l'instant nos administrateurs système nous imposent des déploiements en Python 2.7, à notre grand désarroi /o\

Pour Reading List, nous avions activé gevent.

Puisque l'approche consiste à implémenter un protocole bien déterminé, nous n'excluons pas un jour d'écrire un Cliquet en aiohttp ou Go si cela s'avèrerait pertinent.

Pourquoi pas JSON-API ?

Comme nous l'expliquions au retour des APIdays, JSON-API est une spécification qui rejoint plusieurs de nos intentions.

Quand nous avons commencé le protocole, nous ne connaissions pas JSON-API. Pour l'instant, comme notre proposition est beaucoup plus minimaliste, le rapprochement n'a pas dépassé le stade de la discussion.

Est-ce que Cliquet est un framework REST pour Pyramid ?

Non.

Au delà des classes de resources CRUD de Cliquet, qui implémentent un protocole bien précis, il faut utiliser Cornice ou Pyramid directement.

Est-ce que Cliquet est suffisamment générique pour des projets hors Mozilla ?

Premièrement, nous faisons en sorte que tout soit contrôlable depuis la configuration .ini pour permettre la dés/activation ou substitution des composants.

Si le protocole HTTP/JSON des resources CRUD vous satisfait, alors Cliquet est probablement le plus court chemin pour construire une application qui tient la route.

Mais l'utilisation des resources CRUD est facultative, donc Cliquet reste pertinent si les bonnes pratiques en terme de mise en production ou les abstractions fournies vous paraissent valables !

Cliquet reste un moyen simple d'aller très vite pour mettre sur pied une application Pyramid/Cornice.

Est-ce que les resources JSON supporte les modèles relationnels complexes ?

La couche de persistence fournie est très simple, et devrait répondre à la majorité des cas d'utilisation où les données n'ont pas de relations.

En revanche, il est tout à fait possible de bénéficier de tous les aspects du protocole en utilisant une classe Collection maison, qui se chargerait elle de manipuler les relations.

Le besoin de relations pourrait être un bon prétexte pour implémenter le protocole avec Django REST Framework :)

Est-il possible de faire ci ou ça avec Cliquet ?

Nous aimerions collecter des besoins pour écrire un ensemble de «recettes/tutoriels». Mais pour ne pas travailler dans le vide, nous aimerions connaitre vos idées ! (ex. brancher l'authentification Github, changer le format du logging JSON, stocker des données cartographiques, ...)

Est-ce que Cliquet peut manipuler des fichiers ?

Nous l'envisageons, mais pour l'instant nous attendons que le besoin survienne en interne pour se lancer.

Si c'est le cas, le protocole utilisé sera Remote Storage, afin notamment de s'intégrer dans l'éco-système grandissant.

Est-ce que la fonctionnalité X va être implémentée ?

Cliquet est déjà bien garni. Plutôt qu'implémenter la fonctionnalité X, il y a de grandes chances que nous agissions pour s'assurer que les abstractions et les mécanismes d'extension fournis permettent de l'implémenter sous forme d'extension.

Service de nuages : Perspectives pour l'été

2015-07-07T00:00:00+02:00

Cet article est repris depuis le blog « Service de Nuages » de mon équipe à Mozilla

Mozilla a pour coutume d'organiser régulièrement des semaines de travail où tous les employés sont réunis physiquement. Pour cette dernière édition, nous avons pu retrouver nos collègues du monde entier à Whistler, en Colombie Britannique au Canada !

Ce fût l'occasion pour notre équipe de se retrouver, et surtout de partager notre vision et nos idées dans le domaine du stockage, afin de collecter des cas d'utilisation pour notre solution Kinto.

Dans cet article, nous passons en revue les pistes que nous avons pour les prochains mois.

Ateliers et promotion

Nicolas a présenté Kinto.js dans un atelier dédié, avec comme support de présentation le tutorial d'introduction.

L'application résultante, pourtant toute simple, permet d'appréhender les concepts de synchronisation de Kinto. Le tout sans installation prélable, puisque Rémy a mis en place un serveur de dev effacé tous les jours.

Nous avions mis un point d'honneur à faire du Vanilla.JS, déjà pour éviter les combats de clochers autour des frameworks, mais aussi pour mettre en évidence qu'avec HTML5 et ES6, on n'était plus aussi démunis qu'il y a quelques années.

Ce petit atelier nous a permis de nous rendre compte qu'on avait encore de grosses lacunes en terme de documentation, surtout en ce qui concerne l'éco-système et la vision globale des projets (Kinto, Kinto.js, Cliquet, ...). Nous allons donc faire de notre mieux pour combler ce manque.

Mozilla Payments

Comme décrit précédemment, nous avons mis en place un système de permissions pour répondre aux besoins de suivi des paiements et abonnements.

Pour ce projet, Kinto sera utilisé depuis une application Django, via un client Python.

Maintenant que les développements ont été livrés, il faut transformer l'essai, réussir l'intégration, l'hébergement et la montée en puissance. La solution doit être livrée à la fin de l'année.

À venir

Nous aimerions en profiter pour implémenter une fonctionnalité qui nous tient à coeur : la construction de la liste des enregistrements accessibles en lecture sur une collection partagée.

Firefox OS et stockage

Nous avons eu beaucoup d'échanges avec l'équipe de Firefox OS, avec qui nous avions déjà eu l'occasion de collaborer, pour le serveur d'identification BrowserID par SMS et pour Firefox Hello.

In-App sync

Kinto, la solution simple promue pour la synchronisation de données dans les applications Firefox OS ? La classe ! C'est ce qu'on avait en tête depuis longtemps, déjà à l'époque avec Daybed. Voici donc une belle opportunité à saisir !

Il va falloir expliciter les limitations et hypothèses simplificatrices de notre solution, surtout en termes de gestion de la concurrence. Nous sommes persuadés que ça colle avec la plupart des besoins, mais il ne faudrait pas décevoir :)

Le fait que Dale, un des auteurs de PouchDB et Michiel de Jong, un des auteurs de Remote Storage, nous aient encouragés sur nos premiers pas nous a bien motivé !

Cut the Rope

Kinto devrait être mis à profit pour synchroniser les paramètres et les scores du jeu. Un premier exercice et une première vitrine sympas !

« SyncTo »

Firefox Sync est la solution qui permet de synchroniser les données de Firefox (favoris, extensions, historique, complétion des formulaires, mots de passe, ...) entre plusieurs périphériques, de manière chiffrée.

L'implémentation du client en JavaScript est relativement complexe et date un peu maintenant. Le code existant n'est pas vraiment portable dans Firefox OS et les tentatives de réécriture n'ont pas abouti.

Nous souhaitons implémenter un pont entre Kinto et Firefox Sync, de manière à pouvoir utiliser le client Kinto.js, plus simple et plus moderne, pour récupérer les contenus et les stocker dans IndexedDB. Le delta à implémenter côté serveur est faible car nous nous étions inspirés du protocole déjà éprouvé de Sync. Côté client, il s'agira surtout de câbler l'authentification BrowserId et la Crypto.

Alexis a sauté sur l'occasion pour commencer l'écriture d'un client python pour Firefox Sync, qui servira de brique de base pour l'écriture du service.

Cloud Storage

Eden Chuang et Sean Lee ont présenté les avancées sur l'intégration de services de stockages distants (DropBox, Baidu Yun) dans Firefox OS. Actuellement, leur preuve de concept repose sur FUSE.

Nous avons évidemment en tête d'introduire la notion de fichiers attachés dans Kinto, en implémentant la specification *Remote Storage*, mais pour l'instant les cas d'utilisations ne se sont pas encore présentés officiellement.

À venir

Nous serons probablement amenés à introduire la gestion de la concurrence dans le client JS, en complément de ce qui a été fait sur le serveur, pour permettre les écritures simultanées et synchronisation en tâche de fond.

Nous sommes par ailleurs perpétuellement preneurs de vos retours — et bien entendu de vos contributions — tant sur le code serveur que client !

Contenus applicatifs de Firefox

Aujourd'hui Firefox a un cycle de release de six semaines. Un des objectifs consiste à désolidariser certains contenus applicatifs de ces cycles relativement longs (ex. règles de securité, dictionnaires, traductions, ...) [1].

Il s'agit de données JSON et binaire qui doivent être versionnées et synchronisées par les navigateurs (lecture seule).

Il y a plusieurs outils officiels qui existent pour gérer ça (Balrog, Shavar, ...), et pour l'instant, aucun choix n'a été fait. Mais lors des conversations avec l'équipe en charge du projet, ce fût vraiment motivant de voir que même pour ce genre de besoins internes, Kinto est tout aussi pertinent !

[1]	La bonne nouvelle c'est que toutes les fonctionnalités third-party qui ont été intégrées récemment vont redevenir des add-ons \o/.

Awesome bar

L'équipe Firefox Labs, le laboratoire qui élève des pandas roux en éprouvette, serait vraiment intéressé par notre solution, notamment pour abreuver en données un prototype pour améliorer Awesome bar, qui fusionnerait URL, historique et recherche.

Nous ne pouvons pas en dire beaucoup plus pour l'instant, mais les fonctionnalités de collections d'enregistrements partagées entre utilisateurs de Kinto correspondent parfaitement à ce qui est envisagé pour le futur du navigateur :)

À venir

Nous serons donc probablement amenés, avant de la fin de l'année, à introduire des fonctionnalités d'indexation et de recherche full-text (comprendre ElasticSearch). Cela rejoint nos plans précédents, puisque c'est quelque chose que nous avions dans Daybed, et qui figurait sur notre feuille de route !

Browser.html

L'équipe Recherche explore les notions de plateforme, et travaille notamment sur l'implémentation d'un navigateur en JS/HTML avec React: browser.html

Kinto correspond parfaitement aux attentes de l'équipe pour synchroniser les données associées à un utilisateur.

Il pourrait s'agir de données de navigation (comme Sync), mais aussi de collections d'enregistrements diverses, comme par exemple les préférences du navigateur ou un équivalent à Alexa.com Top 500 pour fournir la complétion d'URL sans interroger le moteur de recherche.

L'exercice pourrait être poussé jusqu'à la synchronisation d'états React entre périphériques (par exemple pour les onglets).

À venir

Si browser.html doit stocker des données de navigation, il faudra ajouter des fonctionnalités de chiffrement sur le client JS. Ça tombe bien, c'est un sujet passionant, et il y a plusieurs standards !

Pour éviter d'interroger le serveur à intervalle régulier afin de synchroniser les changements, l'introduction des *push notifications* semble assez naturelle. Il s'agirait alors de la dernière pierre qui manque à l'édifice pour obtenir un «Mobile/Web backend as a service» complet.

Conclusion

Nous sommes dans une situation idéale, puisque ce que nous avions imaginé sur notre feuille de route correspond à ce qui nous est demandé par les différentes équipes.

L'enjeu consiste maintenant à se coordonner avec tout le monde, ne pas décevoir, tenir la charge, continuer à améliorer et à faire la promotion du produit, se concentrer sur les prochaines étapes et embarquer quelques contributeurs à nos cotés pour construire une solution libre, générique, simple et auto-hébergeable pour le stockage de données sur le Web :)

Service de nuages : Stocker et interroger les permissions avec Kinto

2015-05-26T00:00:00+02:00

Cet article est repris depuis le blog « Service de Nuages » de mon équipe à Mozilla

tl;dr: On a maintenant un super système de permission mais comment faire pour stocker et interroger ces permissions de manière efficace ?

La problématique

Maintenant que nous avons défini un modèle de gestion des permissions sur les objets qui nous satisfait, le problème est de stocker ces permissions de manière efficace afin de pouvoir autoriser ou interdire l'accès à un objet pour la personne qui fait la requête.

Chaque requête sur notre API va générer une ou plusieurs demandes d'accès, il faut donc que la réponse soit très rapide sous peine d'impacter la vélocité du service.

Obtenir la liste des "principals" d'un utilisateur

Les principals de l'utilisateur correspondent à son user_id ainsi qu'à la liste des identifiants des groupes dans lesquels il a été ajouté.

Pour éviter de recalculer les principals de l'utilisateur à chaque requête, le mieux reste de maintenir une liste des principals par utilisateur.

Ainsi lorsqu'on ajoute un utilisateur à un groupe, il faut bien penser à ajouter le groupe à la liste des principals de l'utilisateur.

Ça se complexifie lorsqu'on ajoute un groupe à un groupe.

Dans un premier temps interdire l'ajout d'un groupe à un groupe est une limitation qu'on est prêts à accepter pour simplifier le modèle.

L'avantage de maintenir la liste des principals d'un utilisateur lors de la modification de cette liste c'est qu'elle est déjà construite lors des lectures, qui sont dans notre cas plus fréquentes que les écritures.

Cela nécessite de donner un identifiant unique aux groupes pour tous les buckets.

Nous proposons de de les nommer avec leur URI: /buckets/blog/groups/moderators

Obtenir la liste des "principals" d'un ACE

Rappel, un "ACE" est un Access Control Entry, un des éléments d'une ACL (e.g. modifier un enregistrement).

Avec le système de permissions choisi, les permissions d'un objet héritent de celle de l'objet parent.

Par exemple, avoir le droit d'écriture sur un bucket permet la création des permissions et la modification de tous ses records.

Ce qui veut dire que pour obtenir la liste complète des principals ayant une permission sur un objet, il faut regarder à plusieurs endroits.

Rémy a décrit dans un gist la liste d'héritage de chaque permission.

Prenons l'exemple de l'ajout d'un record dans une collection.

Le droit records:create est obtenu si l'on a l'un des droits suivants:

bucket:write
collection:write
records:create

Notre première idée était de stocker les permissions sur chaque objet et de maintenir la liste exhaustive des permissions lors d'une modification d'ACL. Cependant cela nécessitait de construire cette liste lors de l'ajout d'un objet et de mettre à jour tout l'arbre lors de sa suppression. (Je vous laisse imaginer le nombre d'opérations nécessaires pour ajouter un administrateur sur un *bucket contenant 1000 collections avec 100000 records chacune.*)

La solution que nous avons désormais adoptée consiste à stocker les principals de chaque ACE (qui a le droit de faire telle action sur l'objet), et de faire l'union des ACE hérités, afin de les croiser avec les principals de l'utilisateur :

(ACE(object, permission) ∪ inherited_ACE) ∩ PRINCIPALS(user)

Par exemple l'ACE: /buckets/blog/collections/article:records:create hérite de l'ACE /buckets/blog/collections/article:write et de /buckets/blog:write :

(ACE(/buckets/blog/collections/article:records:create) ∪ ACE(/buckets/blog/collections/article:write) ∪ ACE(/buckets/blog:write)) ∩ PRINCIPALS('fxa:alexis')

Récupérer les données de l'utilisateur

La situation se corse lorsqu'on souhaite limiter la liste des records d'une collection à ceux accessibles pour l'utilisateur, car on doit faire cette intersection pour tous les records.

Une première solution est de regarder si l'utilisateur est mentionné dans les ACL*s du *bucket ou de la collection:

Ensuite, si ce n'est pas le cas, alors on filtre les records pour lesquels les principals correspondent à ceux de l'utilisateur.

principals = get_user_principals(user_id)
can_read_all = has_read_perms(bucket_id, collection_id,
                              principals)
if can_read_all:
    records = get_all_records(bucket_id, collection_id,
                              filters=[...])
else:
    records = filter_read_records(bucket_id, collection_id,
                                  principals=principals,
                                  filters=[...])

Il faudra faire quelque chose de similaire pour la suppression multiple, lorsqu'un utilisateur souhaitera supprimer des enregistrements sur lesquels il a les droits de lecture mais pas d'écriture.

Le modèle de données

Pour avoir une idée des requêtes dans un backend SQL, voyons un peu ce que donnerait le modèle de données.

Le format des ID

Utiliser des URI comme identifiant des objets présente de nombreux avantages (lisibilité, unicité, cohérence avec les URLs)

bucket: /buckets/blog
groupe: /buckets/blog/group/moderators
collection: /buckets/blog/collections/articles
record: /buckets/blog/collections/articles/records/02f3f76f-7059-4ae4-888f-2ac9824e9200

Les tables

Pour le stockage des principals et des permissions:

CREATE TABLE user(id TEXT, principals TEXT[]);
CREATE TABLE perms(ace TEXT, principals TEXT[]);

La table perms va associer des principals à chaque ACE (e.g.``/buckets/blog:write``).

Pour le stockage des données:

CREATE TABLE object(id TEXT, type TEXT, parent_id TEXT, data JSONB,
                    write_principals TEXT[], read_principals TEXT[]);

La colonne parent_id permet de savoir à qui appartient l'objet (e.g. groupe d'un bucket, collection d'un bucket, record d'une collection, ...).

Exemple d'utilisateur

INSERT INTO user (id, principals)
     VALUES ('fxa:alexis', '{}');

INSERT INTO user (id, principals)
     VALUES ('fxa:natim',
             '{"/buckets/blog/groups/moderators"}');

Exemple d'objets

Bucket

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog',
    'bucket',
    NULL,
    '{"name": "blog"}'::JSONB,
    '{}', '{"fxa:alexis"}');

Group

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog/groups/moderators',
    'group',
    '/buckets/blog',
    '{"name": "moderators", "members": ['fxa:natim']}'::JSONB,
    '{}', '{}');

Ce groupe peut être gére par fxa:alexis puisqu'il a la permission write dans le bucket parent.

Collection

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog/collections/articles',
    'collection',
    '/buckets/blog',
    '{"name": "article"}'::JSONB,
    '{"system.Everyone"}',
    '{"/buckets/blog/groups/moderators"}');

Cette collection d'articles peut être lue par tout le monde, et gérée par les membres du groupe moderators, ainsi que fxa:alexis, via le bucket.

Records

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog/collections/articles/records/02f3f76f-7059-4ae4-888f-2ac9824e9200',
    'record',
    '/buckets/blog/collections/articles',
    '{"name": "02f3f76f-7059-4ae4-888f-2ac9824e9200",
      "title": "Stocker les permissions", ...}'::JSONB,
    '{}', '{}');

Interroger les permissions

Obtenir la liste des "principals" d'un ACE

Comme vu plus haut, pour vérifier une permission, on fait l'union des principals requis par les objets hérités, et on teste leur intersection avec ceux de l'utilisateur:

WITH required_principals AS (
     SELECT unnest(principals) AS p
       FROM perms
      WHERE ace IN (
         '/buckets/blog:write',
         '/buckets/blog:read',
         '/buckets/blog/collections/article:write',
         '/buckets/blog/collections/article:read')
 ),
 user_principals AS (
     SELECT unnest(principals)
       FROM user
      WHERE id = 'fxa:natim'
 )
 SELECT COUNT(*)
   FROM user_principals a
  INNER JOIN required_principals b
     ON a.p = b.p;

Filtrer les objets en fonction des permissions

Pour filtrer les objets, on fait une simple intersection de liste (merci PostgreSQL):

SELECT data
  FROM object o, user u
 WHERE o.type = 'record'
   AND o.parent_id = '/buckets/blog/collections/article'
   AND (o.read_principals && u.principals OR
        o.write_principals && u.principals)
   AND u.id = 'fxa:natim';

Les listes s'indexent bien, notamment grâce aux index GIN.

Avec Redis

Redis présente plusieurs avantages pour ce genre de problématiques. Notamment, il gère les set nativement (listes de valeurs uniques), ainsi que les opérations d'intersection et d'union.

Avec Redis on peut écrire l'obtention des principals pour un ACE comme cela :

SUNIONSTORE temp_perm:/buckets/blog/collections/articles:write  permission:/buckets/blog:write  permission:/buckets/blog/collections/articles:write
SINTER temp_perm:/buckets/blog/collections/articles:write principals:fxa:alexis

SUNIONSTORE permet de créer un set contenant les éléments de l'union de tous les set suivants. Dans notre cas on le nomme temp_perm:/buckets/blog/collections/articles:write et il contient l'union des sets d'ACLs suivants: - permission:/buckets/blog:write - permission:/buckets/blog/collections/articles:write
SINTER retourne l'intersection de tous les sets passés en paramètres dans notre cas : - temp_perm:/buckets/blog/collections/articles:write - principals:fxa:alexis

Plus d'informations sur : - http://redis.io/commands/sinter - http://redis.io/commands/sunionstore

Si le set résultant de la commande SINTER n'est pas vide, alors l'utilisateur possède la permission.

On peut ensuite supprimer la clé temporaire temp_perm.

En utilisant MULTI on peut même faire tout cela au sein d'une transaction et garantir ainsi l'intégrité de la requête.

Conclusion

La solution a l'air simple mais nous a demandé beaucoup de réflexion en passant par plusieurs propositions.

L'idée finale est d'avoir :

Un backend spécifique permettant de stocker les principals des utilisateurs et des ACE (e.g. avec les sets Redis) ;
La liste des principals read et write sur la table des objets.

C'est dommage d'avoir le concept de permissions à deux endroits, mais cela permet de connaître rapidement la permission d'un utilisateur sur un objet et également de pouvoir récupérer tous les objets d'une collection pour un utilisateur si celui-ci n'a pas accès à tous les records de la collection, ou toutes les collections du bucket.

Les problèmes de PGP

2015-05-25T00:00:00+02:00

Flip a bit in the communication between sender and recipient and they will experience decryption or verification errors. How high are the chances they will start to exchange the data in the clear rather than trying to hunt down the man in the middle?

-- http://secushare.org/PGP

Une fois passé l'euphorie du "il faut utiliser PGP pour l'ensemble de nos communications", j'ai réalisé lors de discussions que PGP avait plusieurs problèmes, parmi ceux-ci:

Les meta données (y compris le champ "sujet" de la conversation) sont quand même échangées en clair (il est possible de savoir qu'un message à été échangé entre telle et telle personne, a telle date);
PGP se base sur un protocole de communication qui est lui non chiffré, et il est donc facile de soit se tromper, soit dégrader le mode de conversation vers une méthode non chiffrée;
Il est facile de connaître votre réseau social avec PGP, puisque tout le principe est de signer les clés des personnes dont vous validez l'identité;
En cas de fuite de votre clé privée, tous les messages que vous avez chiffrés avec elle sont compromis. On dit que PGP ne fournit pas de forward secrecy;
La découverte de la clé de pairs se passe souvent en clair, sans utiliser une connexion "sécurisée" (HTTPS). Tout le monde peut donc voir ces échanges et savoir de qui vous cherchez la clé;
Les discussions de groupes sont très difficiles: il faut chiffrer pour chacun des destinataires (ou que ceux-ci partagent une paire de clés).

Je suis en train de creuser à propos les alternatives à PGP, par exemple Pond, qui lui ne construit pas par dessus un standard déjà établi, et donc n'hérite pas de ses défauts (mais pas non plus de son réseau déjà établi).

En attendant, quelques bonnes pratiques sur PGP ;)

Bonnes pratiques

Il est en fait assez facile d'utiliser PGP de travers. Riseup à fait un excellent guide qui explique comment configurer son installation correctement.

J'en ai déjà parlé, mais il faut absolument choisir des phrases de passes suffisamment longues. Pas facile de les retenir, mais indispensable. Vous pouvez aussi avoir un document chiffré avec une clé que vous ne mettez jamais en ligne, qui contiens ces phrases de passe, au cas ou vous les oubliez.
Générez des clés RSA de 4096 bits, en utilisant sha512;
Il faut utiliser une date d'expiration de nos clés suffisamment proche (2 ans). Il est possible de repousser cette date si nécessaire, par la suite.

Parmi les choses les plus frappantes que j'ai rencontrées:

Utiliser le flag –hidden-recipient avec PGP pour ne pas dévoiler qui est le destinataire du message;
Ne pas envoyer les messages de brouillons sur votre serveur, ils le seraient en clair !;
Utilisez HPKS pour communiquer avec les serveurs de clés, sinon tout le trafic est en clair.

Le projet Bitmask vise lui à rendre les outils de chiffrement d'échanges de messages et de VPN simples à utiliser, encore quelque chose à regarder.

Enfin bref, y'a du taf.