Non, la signature numérique ne modifie pas du tout l'API car cela n'apparaîtra que comme des attributs de plus parmi d'autres.
Le 22 février 2012 18:29, Emilie Laffray <[email protected]> a écrit : > Salut, > > c'est fort intéressant mais plutôt que nous abreuver de ce genre de détails > peut être faudrait il en parler sur la liste de Développement en anglais, la > ou toutes les réelles discussions techniques ont lieu. > De plus, il y a des raisons historiques et de performances pour le > comportement de l'API. Déjà, c'est un choix volontaire de réduire la taille > car c'est une API pour les contributeurs. Quand le point est soulevé, on > pointe vers le fichier planète avec synchronisation. > Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la > réalité. De plus, la réplication est déjà possible. Passer vers une solution > décentralisée avec une signature ne résoudra pas grand chose et le coup de > calcul des signatures sera important, sans parler le coup de la > synchronisation (il suffit de demander aux gens qui ont des miroirs ici) > rend une vrai solution décentralisée extrêmement compliquée. > Ta solution de la signature si elle n'est pas valide obligerait de rappeler > l'API et donc de rajouter une charge supplémentaire. > > Emilie Laffray > > 2012/2/22 Philippe Verdy <[email protected]> >> >> Le 22 février 2012 15:49, sly (sylvain letuffe) <[email protected]> a >> écrit : >> > On mercredi 22 février 2012, sukran.geo sukran.geo wrote: >> >> Bonjour, J'ai une zone dans OSM que je veux télécharger, mais... >> >> apparemment, elle est trop grande, et voici le message qui s'affiche. >> >> (voir >> >> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem, >> >> pb >> >> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas >> >> faire >> >> plein de petits morceaux. >> > >> > Elle est grosse comment ta zone ? >> > Parce que si tu veux ouvrir un département complet dans JOSM, il vaut >> > mieux >> > oublier tout de suite et faire autrement ;-) >> > Si c'est raisonnablement petit, mais que l'api officielle te bloque, >> > dans JOSM >> > tu peux tenter de remplacer api.openstreetmap.org par >> > api.openstreetmap.fr >> > les limites en téléchargement son plus élevées >> >> Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de >> réplication sur des miroirs synchronisés, capables de répondre de >> concert à une même requête. >> >> Quelques idées suivent... >> >> Une sorte de RSYNC mais adapté aux bases de données (et non à un >> système de fichiers hiérarchique), par lequel toute modification >> enregistrée dans la base principale permet d'alimenter un flux de >> redistribution des transactions "committées" vers un ensemble de bases >> miroirs. De tels systèmes de réplication sont dans tous les RDMBS >> commerciaux, mais pas toujours dans les RDBMS libres où ce sont >> souvent des greffons mal intégrés ne garantissant pas la >> synchrinisation de l'ensemble et la cohérence relationelle des >> transactions annulées par un "rollback". >> >> Cela nécessite des systèmes réellement transactionnels pour valider >> l'état réel des modifications confirmées sur une base centrale, mais >> aussi un système de "rattrapage" permettant même de resynchroniser une >> base esclave qui aurait perdu à un moment donné le fil et devrait se >> remettre à jour (par exemple en cas d'arrêt momentané pour une >> maintenance, ou à cause d'un problème réseau temporaire, ou simplement >> pour démarrer une nouvelle base esclave au départ vierge, avec une >> synchronisation qui va progressivement charger les donnés manquantes). >> >> Enfin si une telle réplication était réellement opérationnelle et >> assez rapide pour qu'un ensemble de bases miroirs puissent toutes >> répondre à une demande de chargement de données (je ne parle pas des >> requêtes de modification de ces données), une déclaration de ces bases >> miroirs opérationnelle pourrait avoir lieu dans le système DNS afin >> que ces requêtes soient distribuées au hasard sur n'importe laquelle >> de ces bases et pas forcément la base centrale qui est bien plus utile >> et seulement nécessaire pour valider les transactions de modification. >> >> Cela imposerait d'avoir deux adresses (URL) de bases de données dans >> les éditeurs : une pour les chargements et mises à jour, l'autre pour >> les modifications, sachant que ce n'est qu'au moment où on va valider >> les données (dans un système de « validation en deux phases ») que la >> première chose qui sera faite sera de comparer les versions provenant >> des miroirs et celles actuellement dans la base, afin qu'à ce seul >> moment-là le serveur central puisse fournir une URL vers les données à >> jour dans un des miroirs disponibles sur lequel le serveur central >> pourrait poser un verrou temporaire sur les objets correspondants, >> pour la validation en deux phases, jusqu'à ce que soit la transaction >> soit validée par un "commit" soit annulée par un "rollback", soit que >> cette annulation ait lieu automatiquement après un délai raisonnable, >> le client devant alors refaire ses transactions et étant prévenu que >> sa dernière transaction a été annulée). >> >> Bote: les transations sont autre chose que les groupes de >> modifications qui sont des regroupements logiques effectués >> utilisateur par utilisateur (selon leur propre logique et leur >> déploiement car un même utilisateur peut utiliser simultanément >> plusieurs outils et donc avoir plusieurs groupes de modification >> ouverts. Ces groupes sont ouverts pour une durée relativement longue >> (la fermeture automatique n'a lieu qu'au bout de deux heures >> d'inactivité sur ce groupe, en théorie du moins car j'ai déjà vu le >> serveur fermer prématurément un groupe en moins de 5 minutes, et même >> parfois au beau milieu d'un enregistrement, les autres modifications >> non envoyées étant alors rejetées mais devant être enregistrées dans >> un autre groupe). >> >> Pour moi la fermeture automatique des groupes n'est pas nécessaire, >> sauf pour leur attacher quelques attributs en commun. Notamment le >> suivi des attributs indiquant quel est logiciel utilisé, qui l'a créé, >> quand il a commencé et quand *l'utilisateur* a indiqué qu'il avait >> terminé, et finalisé son commentaire. >> >> Le commentaire ne devrait être finalisé que si *toutes* les modifs ont >> pu être envoyées. En cas de conflit d'édition, un groupe de modifs >> peut rester ouvert relativement longtemps, le temps pour l'utilisateur >> de régler ces conflits avant de soumettre les autres données, dont bon >> nombre d'ailleurs ne sont pas en conflit. >> >> Mais le serveur alors va fermer prématurément un groupe de modifs, >> alors que les données envoyées sont incomplètes, ce qui laisse par >> exemple des noeuds ajoutés, mais pas les chemins qui les connecte, ou >> des voies ajoutées sensées remplacer une autre dont la demande de >> suppression n'est pas encore passée. >> >> A cause de cela, cela laisse des doublons et données incohérentes dans >> la base, et aucun moyen pour les outils de suivi de savoir quoi faire. >> D'autant plus que le serveur OSM ne renseigne même pas quand il a >> *lui-même* fermé un groupe de modification laissé ouvert (normalement >> le temp pour l'utilisateur de régler les conflits ou ses problèmes de >> connexion). >> >> Bref, la fermeture automatique des groupes de modification est une >> très mauvaise idée, et même une totale et complète ***aberration*** du >> schéma actuel. Cela ne correspond d'ailleurs à rien en terme >> transactionnel, puisque les validations (commits) et réplications se >> feront à une échelle bien plus petite, celles des objets (avec leurs >> attributs et leurs membres pour les relations). >> >> Les groupes de modifications eux-mêmes sont un objet distinct de la >> base de données. Leur existence est nécessaire avant toute autre >> opérations de création/modification/suppression sur les autres objets, >> mais personne d'autre que l'utilisateur qui l'a créé via son logiciel, >> ***pas même le serveur***, ne doit avoir à en contrôler l'indication >> de sa fermeture, ni certains autres attributs tels que le commentaire, >> voire des métadonnées nécessaires à la l'octroi de licence, car >> personne d'autre que lui ne pourra les changer (en revanche le serveur >> continuera à contrôler des attributs comme l'identité de >> l'utilisateur, si cette identité a été certifiée par un protocole >> sécurisé, et les dates d'ouverture ou de dernière modification dans ce >> groupe ; il ne fera éventuellement qu’exiger que certains autres >> attributs soient renseignés dans le groupe de modifications, comme >> l'identification suffisante du logiciel utilisé, ou le "user-agent" >> d'un navigateur, et quelques autres données comme la langue utilisée >> dans le logiciel de l'utilisateur). >> >> Ces objets "groupes de modifications" entrent dans les données >> nécessaires pour analyser les historiques, retrouver les auteurs, >> comprendre les raisons de certaines données, ou à quoi elles étaient >> peut-être destinées; elles sont aussi indispensable pour suivre les >> conditions de licence et donc doivent être conservées si les autres >> objets qui sont listés dans ce groupe à une version donnée sont encore >> présents dans la base. Ces groupes de modification sont aussi à >> transporter dans les systèmes de synchronisation, au même titre que >> les objets géométriques (neuds et chemins) et les relations (ces >> objets les référencent version par version). >> >> Un groupe de modifications peut être mis à jour autant de fois que >> nécessaire par un même utilisateur et sans limite de durée — du moins >> tant que le même utilisateur n'a pas rouvert un autre groupe >> référençant des modifications sur un ou plusieurs des mêmes objets >> géométriques ou relations, seul cas où éventuellement on peut admettre >> une fermeture automatique. Mais je penche plutôt sur une condition de >> fermeture basée sur un volume maximum en nombre d'objets modifiés dans >> le groupe (basée davantage sur une politique mise en œuvre par le >> logiciel client qu'un contrôle absolu par le serveur), afin que le >> client s'assure d'envoyer des données cohérentes et suffisantes dans >> un même groupe de modifications, notamment quant il doit créer ou >> modifier un chemin, dont les nœuds modifiés/créés/ajoutés devraient >> toujours être dans le même groupe de modifications. Le logiciel client >> pourra créer automatiquement autant de groupes de modifications que >> nécessaire pour respecter correctement les contraintes de volume par >> groupe, mais seul l'utilisateur doit en contrôler la fermeture, même >> s'il y en a plusieurs, afin qu'il puisse finaliser le commentaire et >> les données nécessaires à une licence ou le contrôle ultérieur de >> validité de cette licence, telles que la citation d'une source >> autorisée, ou encore des commentaires destinés à une maintenance >> ultérieure sur des données seulement estimées ou incomplètes, ou >> encore pouvoir résoudre un conflit partiel nécessitant de modifier >> encore un objet déjà envoyé dans ce groupe de modifications. >> >> En revanche les transactions sur le serveur c'est autre chose ! Cela >> ne concerne que les objets individuels (ou presque) et se limite à >> assurer qu'il n'y a pas de conflit de versions, ni perte de la >> cohérence référentielle de base: >> * un chemin doit toujours associer au moins deux nœuds (quitte à ce >> qu'ils soient superposés géométriquement). >> * les nœuds d'un chemin doivent toujours exister, et doivent avoir un >> numéro de rang unique dans ce chemin (afin de pouvoir définir un >> ordre). >> * les membres d'une relation doivent toujours exister, et doivent >> avoir un numéro de rang unique dans la relation (afin de pouvoir >> définir un ordre). >> * chaque version d'un noeud/chemin/relation doit toujours référencer >> un groupe de modifs existant, >> * une même version d'un noeud/chemin/relation ne peut pas être >> référencée par plusieurs groupes de modifs, >> * un groupe de modifs doit toujours référencer un utilisateur >> existant et cette référence à un utilisateur ne peut pas être changée >> (on ne peut que supprimer un groupe de modifiations et les versions de >> nœuds/chemins/relations qui référencent ce groupe). >> * et certains attributs sur ces objets sont obligatoires et respecter >> certaines contraintes pour leur valeur ou leur format. >> >> Ces règles de base (purement relationnelles) sont celles servant à >> définir les briques minimales de ce qui sera synchronisé entre >> serveurs ou miroirs et lors des transactions (même pour les >> transactions à validation multiphase). Avec cela on peut sérieusement >> envisager un déploiement solide et plus large de serveurs coopérant >> entre eux, y compris pour la contribution de leur bande passante, et >> avec les utilisateurs, avec un coût partageable qui pourra être réduit >> pour le bénéfice de tout le monde pour peu que chacun puisse faire une >> contribution, même petite au regard du volume total des transactions >> échangées, mais pourtant utile à tous car elle aussi partagée et >> offerte aussi aux autres en tant que service supplémentaire. >> >> Toutefois pour que les miroirs fonctionnent réellement, il doit >> exister un moyen de vérifier que ceux-ci ne véhiculent pas >> d'informations altérées par rapport au serveur central où sont >> validées les modifs. La solution simple consiste à ce que le serveur >> central calcule une signature numérique des données qu'il a validées, >> avec un certificat de sécurité dont il détient seul la clé privée, >> tandis qu'il fournit à tous une copie du certificat de sécurité >> contenant la clé publique permettant de comparer les signatures >> numériques recalculées. Cette signature numérique serait alors un >> attribut de tous les objets qui peuvent accessibles et sont distribués >> par la base. >> >> La signature numérique d'une version d'un objet étant dépendante de la >> date de cette version, ainsi que du certificat utilisé pour la >> calculer à cette date, il faut aussi que l'objet contiennent la >> référence à ce certificat (devenu un objet relationnel à part entière >> dans la base). Ce qui permet aussi plus tard de mettre à jour ou >> changer ces certificats et de recalculer les signatures numériques des >> autres objets relationnels (et leurs attributs textuels, numériques ou >> géométriques) en cas d'expiration du certificat. Bref deux attributs >> par objet: la signature numérique (par exemple une chaine hexadécimale >> de longueur fixe dans un attribut "Signature:SHA1"), et un URI (URL ou >> URN) vers la copie publique du certificat de sécurité (dans un >> attribut comme "Signature:Certificate"). >> >> Ces attributs seront calculés par le serveur de validation uniquement >> et présentés dans toutes les requêtes. Il faut une signature séparée >> par objet (nœud, chemin, relation, groupe de modifications, >> utilisateur), cette signature exposée publiquement ne devant être >> calculée QUE sur les données publiques accessibles (pas les données >> privées ou secrètes, par exemple dans un objet de type utilisateur). >> >> De la même façon le serveur central de validation peut aussi calculer >> une signature numérique pour un objet représentant un serveur >> lui-même, si le système autorise ce serveur à effectuer des >> validations locales qui seront ensuite transmises par ce serveur local >> au serveur central, "au nom de" ses propres utilisateurs sur le >> serveur local. Cela permet un système où la confiance et la >> responsabilité peut être déléguée et partagée, de façon limitée, avec >> une responsabilité assumée par celui qui gère un serveur local. Cela >> peut aussi servir à accorder à un serveur local davantage de droits en >> terme de bande passante, car il assure un service pour de nombreux >> utilisateurs en soulageant le serveur central de la visite de ces >> mêmes nombreux utilisateurs. >> >> Avec un objet dans la base de données représentant un serveur >> (probablement représenté par une URL, mais ce peut être aussi un >> simple ID numérique vers un objet contenant en attribut cette URL à >> priori unique dans la base), une requête à un serveur pourra donner >> une réponse contenant la référence à un autre serveur disponible (par >> exemple lors d'opérations de maintenance sur l'un d'eux, ou d'un >> problème de disponibilité d'une liaison, ou de délai de mise à jour >> dans les données en cache d'un serveur DNS utilisé par le client). >> >> _______________________________________________ >> Talk-fr mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-fr > > _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
