je voulais juste mettre un bémol sur ces statistiques de Linuxfr. J'ai une adresse de messagerie instantanée mais je ne la rentre pas et ne la rentrerai jamais dans ma configuration Linuxfr tant qu'elle est affichée publiquement, sans choix de la rendre privée.
Je ne veux pas que mon email soit publique, et je vois pas la différence pour mon adresse IM. Je ne souhaite pas que des bots s'empare de mon adresse et me spamme un jour par IM.
En dehors de cela, si Linuxfr se mettait à utiliser Jabber pour me communiquer des informations ou me permettre de faire certaines actions ET que cette adresse n'est pas ainsi publiquement accessible pour être collectée par des bots, je la rentrerais.
Je ne sais pas si il y a beaucoup de gens dans mon cas, mais c'était juste pour signaler que cela pouvait avoir un impact sur les statistiques si vous comptez les utiliser pour savoir le pourcentage de libristes du site qui utilise Jabber.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
c'est pas une histoire de meilleur concept. Ce sont juste des conceptions différentes.
À partir de là, je ne crois qu'il y ait besoin de te vendre quoi que ce soit. Et oui bien sûr, on peut se débrouiller sans et oui tout ce qu'on fait dans un concept, on peut le faire dans un autre. Il suffit de voir tout ce qu'ont fait des millions de développeurs dans le monde, qu'ils utilisent une logique impérative, fonctionnelle, objet, déclaratif, etc. en-veux-tu-en-voilà (et avant ça y a des dizaines d'années, des programmes étaient entièrement écrit en assembleur, c'est dire si on peut tout faire quel que soit la "famille" du langage).
Par contre c'est simplement que certains concepts s'adaptent plus aisément à certains problèmes que d'autres.
Par exemple, si je développe un programme où les données rentre, sont traitées, sortent constamment, je vois tout de suite du fonctionnel: t'as une entrée, une sortie et une boîte noire au milieu.
L'objet est vraiment très agréable et permet des designs très "évident" (donc agréable à utiliser) pour tous les problèmes avec des "entités", que l'on peut conceptualiser, qui ont des caractéristiques et qui peuvent effectuer certaines actions.
Etc.
En fait il faut juste voir des classes de problématiques et ce qui permettra de faire la plus jolie et évidente API (soit parce que c'est le but final, ou soit parce qu'on va l'utiliser soi-même). Ça n'empêche pas qu'il y a en fait 1000 autres designs possibles pour la même fonctionnalité et qu'un autre design dans une tout autre logique peut également être très agréable.
C'est juste une question de choix.
Enfin y a la question du langage à utiliser. Personnellement je m'adapte. Quand j'écris en OCaml par exemple, je pense essentiellement soit classe soit fonctionnel. Mes programmes n'auront (presque) jamais la moindre boucle, je préfère les retours de fonctions aux références, et je m'arrange pour que mes fonctions récursives soient toujours terminales (sauf si la complication apportées ne vaut pas le gain. Ça arrive parfois, par exemple pour les fonctions qui auront des appels récursifs peu profond par design).
Si par contre j'écris en C, je fais des boucles, des paramètres par références et du massivement impératif comme tout le monde.
Il faut savoir profiter des forces d'un outil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
non c'est pas facile. Pour les utilisateurs, tu peux le faire de manière plus ou moins transparente mais c'est pas forcément facile. Si le serveur ne prévoit pas ce genre de cas, c'est à toi de faire le nécessaire, ce qui implique quelques requêtes ds la BDD. Par contre, ça ne peut pas être transparent pour les contacts des utilisateurs par définition. En effet tu n'as pas accès à la base de données des contacts (sauf si tous les contacts de tes utilisateurs sont aussi dans tes utilisateurs bien sûr) et tu ne peux donc pas agir sur leur roster (imagine s'il existait une possibilité pour cela, ça signifierait que quelqu'un pourrait monter un faux serveur et créer des utilisateurs dessus pour "s'emparer" des utilisateurs d'autres serveurs, et ce de manière totalement invisible, donc il serait capable de faire des attaques ciblées en se faisant passer pour d'autres).
En conclusion, ce n'est pas la bonne solution.
Une solution pourrait être que tu pourrais envoyer des notifications de "déménagement" pour tous les contacts de tous les comptes utilisateurs (XEP-0283, l'extension expérimentale qui existe actuellement et implique que les contacts devront approuver manuellement le changement, par rapport à ce que je disais précédemment sur les problèmes de sécurité). Mais je ne sais pas exactement quels clients implémentent réellement cette XEP. Je ne la connais pas trop non plus, mais je pense qu'elle pourrait être vraiment améliorée pour être rendue plus transparente, tout en étant sécurisée. J'y jetterai peut-être un œil un jour.
Ma conclusion cependant serait que je ne te conseille pas de le faire de manière trop transparente. Déjà simplement parce que tes utilisateurs devront bien savoir que leur adresse a changée pour la donner aux gens. Ensuite parce que s'il y a des problèmes parce que des contacts n'ont pas pris en compte le changement (leur client ne supportait pas la XEP "moved" par exemple), ben tes utilisateurs pourraient ne pas s'en rendre compte immédiatement et simplement croire que tel ou tel contact ne se connecte plus pendant longtemps. Alors que s'ils sont bien informés, ils sont conscients que des problèmes peuvent survenir et donc être proactifs (rentrer en contact avec certains utilisateurs pour s'assurer qu'ils se mettent à jour).
Mon conseil:
1/ utilise la nouvelle adresse pour les nouveaux inscrits, mais garde l'ancienne en parallèle par défaut sans transférer personne. Un nouvel inscrit ne peut se faire par contre que sur la nouvelle.
Par contre informe tes anciens utilisateurs qu'une nouvelle adresse est disponible.
2/ réserve tous les nicks sur la nouvelle adresse qui existent déjà sur l'ancienne. Et fais savoir à chaque utilisateur que s'ils décident de "déménager", leur nick leur est réservé aussi longtemps qu'ils ont leur ancien compte.
3/ si un utilisateur désire déménager vers la nouvelle adresse, prépare tout pour lui faciliter la tâche le plus possible. Par exemple, il a juste un clic à faire sur une page (ou un bot XMPP à qui il envoie un message), ce qui génère automatiquement des stanzas de déménagement pour tous ses contacts, ainsi qu'envoie des autorisations à tous ses anciens contacts pour son nouveau compte).
4/ L'utilisateur qui déménage devrait garder un accès à son ancienne adresse un certain temps (6 mois?), ce qui lui permettrait de gérer les contacts qui ne supportaient pas la XEP-0283 et donc n'ont pas inscrit le nouveau JID (l'utilisateur a donc besoin de son ancienne adresse pour voir quand ils sont connectés, discuter avec eux et leur dire qu'il a changé si besoin par exemple) ou gérer les gens à qui il aurait récemment donné son ancien JID et qui inscriraient ce dernier. Et autre...
Et il faut savoir que tout type de migration a toujours son lot de problème. Mon expérience là-dedans, c'est qu'une bonne communication pour prévenir de cela vaut mieux qu'essayer d'être le plus discret possible (transparent) car lorsque les utilisateurs s'en rendent compte (car ils s'en rendront compte, et certains auront des problèmes), ils seront furieux. Alors que si tu leur laisses le choix en les prévenant des risques sur le court terme mais des avantages sur le long terme, ce sera un choix conscient de leur part, donc ils prennent leur part de responsabilité!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
bien sûr que c'est possible! J'en parle même dans mon article!
Je cite un organisme qui propose ce service (payant): Google avec les Google Apps.
Beaucoup plus proche des libristes, l'Apinc (Association pour la Promotion de l'Internet Non Commercial) aussi propose le même service gratuitement:
http://jabber.apinc.org/.
Je suis un peu bête d'avoir oublié de parler de leur service (n'hésitez pas à ajouter ce lien à la dépêche!). Ce genre de service se démocratise de plus en plus et leur sécurisation est un de nos gros sujets du moment (cf. l'article et je détaille plus bas dans ce post).
L'un comme l'autre te permettrait d'avoir ton jid comme toi@tondomaine.fr, et ce sans que tondomaine.fr redirige vers quoi que ce soit d'autre que ton site web dans un navigateur.
J'explique même comment ça marche dans l'article (même si c'est vrai que je n'ai pas détaillé, car si je détaille tout, l'article est trop long, un reproche qu'on me fait souvent): on utilise les DNS SRV records.
Les ancêtres
La vieille méthode que http utilise encore, c'est effectivement juste de rediriger un domaine vers l'adresse principale qui lui est dédiée (ce qu'on appelle un enregistrement A pour IPv4 et AAAA pour IPv6. Il existe chez Mozilla un rapport de bug depuis 11 ans et demi pour utiliser les SRV et ne passer aux A/AAAA qu'en fallback, auquel je suis abonné moi-même depuis quelques années et qui a beaucoup de votes, d'abonnés, et a même eu des patchs envoyés par certains, mais Mozilla ne semble pas intéressé alors que le service http a déjà été enregistré par l'IANA).
Mais ça c'est la méthode antique, aucune flexibilité.
La relêve (actuelle)
Les enregistrements de service, c'est bcp plus subtil. On fait un enregistrement DNS qui dit quelles IPs regarder pour tel "service". Nous, on a deux enregistrement de service principaux: xmpp-client ou xmpp-server (selon qu'on parle au client ou serveur).
Une entité fait donc une requête DNS pour le domaine concerné du service désiré, et ça retourne une liste de couples (IP, port) à utiliser. Ça permet de préciser quelles IPs hébergent ton service Jabber et sur quel port (je connais au moins 2 serveurs qui n'utilisent pas le port par défaut sans aucun problème de fonctionnement alors que les services web doivent utiliser un truc moche à la example.com:8888 pour faire pareil), qui peut tout à fait être différent de ton serveur web.
Note que pour les petits organismes avec plusieurs serveurs mais sans beaucoup d'argent, ou sans tout une équipe d'administrateurs dédiés à l'infrastructure, SRV permet aussi un répartition de charges statique (donc basique mais suffisante pour beaucoup de petites et moyennes structures). Les enregistrements possèdent en effet un système de priorité et poids à utiliser conjointement pour se connecter aléatoirement (avec préférence) sur des machines différentes d'une utilisation à l'autre.
Un enregistrement normal (A/AAAA) n'a pas d'équivalent de ce système de répartition de charges car au mieux, on mélange les enregistrements A/AAAA aléatoirement (ils ont donc tous le même poids, on ne peut préciser les probabilités de connexion souhaités selon la machine, ce que fait SRV).
Donc oui, c'est possible, c'est même facile à faire. Ça demande des compétences très basique pour quiconque a les compétences de base pour avoir son propre domaine (c'est presque pas de l'administration info tellement c'est facile).
1/ tu t'inscris sur le service qui va héberger ton serveur.
2/ tu ajoutes un enregistrement DNS (pour ceux qui n'hébergent pas leurs propre serveur DNS, c'est en général simplement dans l'interface web de ton registrar) et tu ajoutes un (ou plusieurs si le service qui t'héberge a plusieurs machines) enregistrement de service xmpp-client et xmpp-server.
Et... c'est fini! XMPP fait ça depuis des années. En fait c'était déjà standard dans la RFC3920, comme je le dis dans l'article, donc on fait tous ça depuis au moins... 7 ans!
Google ne se gêne pas pour utiliser tout cela pour ses 5 machines XMPP client (et il a 5 machines xmpp-server différentes pour le même domaine):
$ ring -t SRV _xmpp-client._tcp.gmail.com
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk4.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 5
weight= 0
port= 5222
target= talk.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk1.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk2.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
priority= 20
weight= 0
port= 5222
target= talk3.l.google.com.
Bien sûr certains font encore la vieille méthode avec un enregistrement A et/ou AAAA sur un sous domaine de leur domaine principal. Genre im.example.com. Perso j'ai jamais compris pourquoi! Je ne connais pas un client ni un serveur de nos jours qui ne gère pas les SRV records. Et au final c'est plus compliqué car on doit créer et gérer un nouveau sous-domaine.
Le futur
Enfin la seule problématique avec cette solution est la sécurisation par certificats X509 (TLS). Les possesseurs d'un domaine n'aime pas toujours donner un certificats pour leur domaine principal à un service tier, et ça peut se comprendre (le service tier, si malveillant, aurait alors le pouvoir — presque officiel — pour se faire passer pour le domaine principal pour d'autres types de service, comme le web).
Il est en réalité possible d'associer un certificat à un enregistrement de service (il y a au moins un CA qui propose ce genre de certificat), mais malheureusement à ce que j'ai compris les navigateurs web (encore eux!) ne regardent pas vraiment ce champs et donc cette sécurité passe à la trappe à l'heure actuelle. C'est pourquoi (encore comme je le dis dans l'article! J'explique trop mal?) pas mal de gens réfléchissent à une solution pour rendre ce passage de pouvoir à la fois aussi sécurisé que si on le faisait nous-même mais sans donner les pleins pouvoirs sur tout le domaine. Y a au moins un brouillon de RFC proposé sur le sujet (mais je l'ai pas encore lu, je ne connais pas sa pertinence).
Et après j'en lis plus haut que XMPP est une vieux truc alors qu'on est parmi le top de la technologie Internet (on est parmi les premiers à utiliser les technologies les plus récentes. SCRAM par exemple, XMPP est LA technologie qui fait vraiment démarrer ça et comparé aux vieux mécanismes SASL, c'est vraiment génial. SRV aussi, nous sommes parmi ceux qui ont créé une adoption massive; bien que sur le coup, je crois que SIP était avant nous) et qu'on est constamment à innover sur tous les fronts et à prendre des risques en adoptant des technologies avant les autres. Alors bien sûr on cherche aussi la rétrocompatibilité en même temps. Mais après si on cassait l'intéropérabilité entre les serveurs récents et anciens, vous iriez encore vous plaindre (et un peu plus à raison pour une fois)!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
1/ pourrait-on mettre à jour les liens RFCs? Je pensais qu'ils resteraient un peu, mais les liens donnés étaient en fait les liens dans la dernière phase du processus de standardisation (qui s'est stabilisé aujourd'hui, bien que les versions données étaient déjà les versions finales qui n'avaient quasiment aucune chance d'être modifié dans cette étape avant le statut final).
Ou encore, je préfère personnellement utiliser: http://tools.ietf.org/html/rfc6120 (etc. 6121, 6122)
parce que c'est du html avec hyperliens dans les menus (et qu'on peut aussi avoir la version txt ou pdf à partir de là).
2/ Aussi pourriez-vous modifier aussi le "TLS EXTERNAL" qui est une bête erreur alors que je sais pertinemment que c'est TLS + SASL EXTERNAL. Ça m'évitera d'avoir honte. ;-)
Je donne aussi l'astuce aux gens intéressés dans les RFCs et dans l'utilisation avancés d'un navigateur web aussi: dans Firefox (et je pense dans le plupart des concurrents, y a un équivalent), vous pouvez enregistrer un bookmark de la sorte: http://tools.ietf.org/html/rfc%s
Et vous mettez un "keyword", par exemple "rfc". Puis dans votre barre d'adresse, vous tapez juste "rfc 6120" et paf! Vous êtes direct dans la bonne rfc! C'est ce que je fais personnellement pour naviguer rapidement d'une RFC à l'autre.
Vous pouvez adapter cette astuce à tout type de site qui utilise des URL "parlantes" et simples (comme quoi, c'est important de penser l'architecture des URL!).
Merci.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
1/ le nom: je suis d'accord, le choix du nom n'est pas terrible pour le grand public, c'est sûr. Mais c'est uniquement un choix "technique" de nom pour un protocole. Cela n'implique pas qu'on souhaite que les utilisateurs se mettent à l'utiliser (pas moi en tous cas).
Les utilisateurs disent-ils "je vais regarder sur le web" ou bien "je vais consulter des pages html par http"? Disent-ils "tiens je t'ai envoyé un email!" ou bien "Je t'ai envoyé un message par smtp, l'as-tu reçu par pop/imap?". Etc.
De manière général, il faut différencier le nom d'un protocole et son utilisation. C'est juste un nom technique (de même que je suis sûr que les voitures ont un nom technique et ridicule avant d'avoir un nom sexy pour passer en publicité, de même pour la plupart des projets!), faut arrêter de se focaliser dessus.
Jabber est toujours un très bon nom, utilisable et le nom du serveur publique géré par la XSF s'appelle toujours jabber.org et personne ne parle de changer ce nom.
Pour ma part, je préfèrerais qu'on utilise le nom générique de "messagerie instantanée" et qu'on oublie un instant le nom des protocoles. Avec le travail d'intéropérabilité avec SIP, ça sera d'ailleurs d'autant plus vrai. Qu'importe le protocole derrière, on a une adresse qui permet de discuter, on s'en fiche du reste.
2/ Je suis triste aussi que Facebook ait décidé de ne pas ouvrir ses serveurs, mais ça ne m'étonne pas plus que cela de cette entreprise. Ils ont aussi fermé leur réseau web, tu sais. On ne peut pas regarder les pages Facebook sans compte (moi j'ai jamais pu en tous cas). Ben ils font pareil avec Jabber qu'ils ont fait pour le web. Est-ce que tu vas te plaindre aussi que le web c'est nul parce qu'y a des serveurs fermés comme Facebook?
3/ Les extensions, ce sont comme des RFC, sauf que c'est au niveau de la XSF au lieu de la IETF. Donc on a aussi un protocole de standardisation. Ainsi les extensions commencent avec des statuts expérimentals, elles sont testées, implémentées, modifiées. Et parfois elles passent au stade de standards XSF. Parfois elles sont abandonnées. Parfois certains font leurs extensions dans leur coin pour une utilisation privée (réseau d'entreprise, ou autre) sans intention de standardiser donc de proposer une XEP. Y a de tout.
Encore une fois, va voir combien de brouillons de RFC sont proposés à la IETF, le nombre de brouillons que cela a impliqué (on a 23 brouillons entre la RFC 3920 et 6120, et 21 pour 6121!), et combien passent en standard quand la plupart passent aux oubliettes. Vas-tu dire que la IETF pue parce qu'ils permettent tant de versions expérimentales?
4/ Il n'y a qu'un standard Jingle. Le fameux "Jingle by Google" n'existe pas. Ils ne se sont simplement pas mis à jour encore avec la version standardisée, c'est tout. Mais ils y viendront, comme tout le monde qui veut implémenter la VOIP par XMPP. Ils n'ont aucun intérêt à ne pas le faire.
Je rappelle que c'est Google qui a fait la proposition de Jingle, ils ont donc la plus vieille implémentation expérimentale du protocole. C'est sûr, c'est plus facile quand le protocole existe déjà. Eux, il n'existait pas. Ils ont expérimenté, ont proposé un standard, ça a été étudié, discuté, et on l'a standardisé.
C'est ce que je disais dans l'article: pour l'instant tout le monde a une version de base, plus ou moins complète, basée sur une version plus ou moins expérimentale du protocole selon quand ils ont commencé à implémenter (avant que le protocole soit fixé ou après). On attend donc juste que tout ça se tasse et que les diverses versions se mettent à jour. Ça prend le temps qu'il faut mais ça viendra.
Mais sinon, non: il n'y a qu'un Jingle.
Pour SIP, c'est différent. Y a eu tentative de standardisation de deux protocoles qui à l'origine était finalement assez différents: l'un était vraiment orienté texte (XMPP), l'autre voix (SIP). Au final, avec le temps et les évolutions, les fonctions ont commencé à se recouper puis de plus en plus. Mais c'était trop tard, les deux protocoles étaient déjà standardisés et avaient chacun une grosse masse utilisateur. C'est pas comme si quelqu'un va se mettre à vouloir dire "ok ben finalement on révoque un des deux protocoles". Donc on fait avec et maintenant seul le temps peut nous dire si l'un des deux protocoles va prévaloir ou si les deux vont coexister ainsi pendant encore longtemps.
Et donc faire avec, c'est ce qu'on fait avec les discussions sur l'intéropérabilité entre les deux réseaux (voir la liste de discussion SIXPAC (SIP Interworking with XMPP in Presence Aware Clients) de l'IETF).
Note au final qu'il y a encore un autre cas où plein de technologies très différentes intéropère. Et c'est aussi dans les télécoms, on appelle ça le téléphone! Entre le RTC, d'autres variantes numériques fixes, et une foultitude de protocoles différents pour le mobile (GSM, GPRS, 3D, etc. En veux-tu en voilà)… Ben personne se plaint des téléphones et des protocoles derrière!
Bon bah nous c'est pareil. On arrive pas à rendre les protocoles intéropérables aussi vite que les consortium (ou je ne sais quel type d'organisme) de téléphonie, mais on n'a pas le même argent non plus. Aussi surtout on ne vous demande pas des sommes mirobolantes pour améliorer le système. Mais je trouve qu'on se débrouille quand même bien avec les moyens du bord.
Tu aurais préféré qu'Internet soit un système tout fermé avec des protocoles qu'on paye à prix d'or et géré uniquement par des grosses sociétés?
Voilà pour les divers points.
XMPP n'est pas le protocole parfait. Il a beaucoup de problèmes et il n'y a aucun doute que si les divers acteurs du protocole devait repartir de zéro maintenant, on ferait pas mal de choses différemment. Mais c'est ça le travail de standardisation. On se bat pour faire un système qui convient à tous pour être une norme ouverte, non couverte par des centaines de brevets, et libre d'utilisation pour tous.
Ensuite libre à toi si tu trouves que c'est de la merde et si tu préfères utiliser un réseau fermé qui a sûrement un nom très sexy, des serveurs très ouverts entre eux-même, aucune extension et une technologie son et vidéo intéropérable avec elle-même.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bien que n'ayant jamais testé ton projet, j'avais vu tes divers journaux que tu avais fait dessus, et en fait tu m'avais presque énervé, parce que t'as plein d'idées très similaires aux miennes. ;-)
Quoiqu'il en soit, si ton projet est suffisamment avancé pour être utilisable (parce qu'y a quand même une sélection, on ne peut laisser n'importe quel projet inexistant prendre la place de projet solides) et que tu souhaites aller encore plus loin, tu peux probablement proposer une idée (ou plusieurs même) de projet impliquant SaT, pour lesquels tu pourrais être mentor. Donc SaT pourrait participer au Google Summer of Code sous la tutelle de la XSF. Jette donc un œil au lien donné plus haut.
Bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
comme je disais dans le ticket, même programmé avec les pieds, je suis persuadé que ce sera déjà mieux que Google (qui est vraiment super mauvais pour Linuxfr dans mon expérience, pas vous?), parce que nous avons accès à la structure et logique interne du site.
À partir de là, ça signifie qu'on peut commencer par avoir un moteur de recherche basique fait en 30 minutes (genre on cherche juste la liste des mots en se limitant aux tags, au titre, puis au texte, et enfin on rajoute un bonus aux tickets récents, avec cet ordre de poids: ce sera déjà une grosse amélioration et ça fait quelques lignes de code pour la logique), puis progressivement l'améliorer avec le temps (affiner les poids, rajouter des éléments, créer un systèmes d'options à sélectionner, voire un jour tenter l'expérience d'un moteur de recherche avec apprentissage).
Notez que je suis prêt à aider, mais il me faudrait un environnement de développement déjà prêt. Mon expérience désastreuse lors du concours pour le nouveau site m'a décidé à ne plus essayer d'installer cela moi-même.
Enfin pour les pubs, je comprends. Oui l'idée de tous les ans proposer une campagne de don est intéressante en switchant sur Google search en même temps, et tant que la campagne n'est pas bouclée, semble bien. Aussi n'y a-t-il pas des entreprises qui pourraient sponsoriser Linuxfr (sous et/ou matériel, je crois que les deux se sont déjà faits pour l'assoce, non?)? Je suis sûr que c'est facile, surtout si c'est pas grand chose, parce que vous représentez la source numéro 1 d'informations relatives à Linux et au Libre en France.
Peut-on avoir un ordre de grandeur sur la somme représentée par ces pubs? Quand vous dites que c'est pas grand chose, c'est quoi? 50 euros? 100? 1000?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
cette solution permet-elle de restreindre les droits utilisateurs simples (1)? Par exemple si je veux lancer un programme en m'assurant que ce problème ne puisse pas du tout lire dans le système de fichier (même les fichiers appartenant à l'utilisateur qui fait tourner le programme), est-ce possible?
Ou bien cela permet simplement de donner quelques droits supplémentaires à un utilisateur (qui sont normalement réservés à root), mais pas tous (2)?
Je m'intéresse justement en ce moment à faire la première chose (1) en particulier. Quelles sont les solutions existantes (Capsicum ou autre) capables de faire ce genre de restrictions sous Linux?
Je suis intéressé par tout lien sur la chose ou points de départ pour une recherche. En particulier je souhaite ne pas avoir à modifier un kernel (donc en fait Capsicum, qui m'intéresse dans le concept et peut-être dans l'avenir, n'est cependant pas intéressant pour moi à court terme tant que ce n'est pas un élément de base de Linux).
Merci pour ce sujet intéressant en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel.
Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead).
Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités.
Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent.
Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
I actually think that Direct3D is a rather better API today.
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction cube(l) alors qu'une moins bonne aurait la fonction make_a_regular_hexahedron(d) où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.
C'est cela que l'on appelle une mauvaise API (Interface!) en général.
Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction make_a_regular_hexahedron est vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.
C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Direct3D handles multi-threading better, and newer versions manage state better.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai ball(r). On peut maintenant faire des boules en une ligne de code.
De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant.
C'est en gros, ce qu'ils disent dans l'article là:
While newer versions of OpenGL have kept up-to-date with some of the features found in DirectX, including DirectX 10's geometry shader, they usually have to be implemented via extensions, rather than the main API.
Enfin tout cela est confirmé par:
we wouldn’t get any huge benefits by making the switch, so I can’t work up much enthusiasm for cleaning it out of our codebase.
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
en fait les designers ont de la chance. Pour eux, c'était "facile" de participer (j'entends par là qu'ils n'ont rien à installer: ils codent, et testent direct sur le site alpha). Pour les développeurs "cœur", on devait se taper toute l'installation du site web (ruby, rails, la dizaine de module, le serveur web, etc.), avec des problèmes de version, etc.
J'ai perdu des heures dessus. Puis un autre développeur sympa a monté une image virtuelle et on nous l'a gentiment fournie. Alors moi, je cherche un logiciel de virtualisation pour cette image. Mais... erreur: la version du logiciel fournie dans ma vieille distri n'était pas compatible avec l'image. Je vais sur le site du logiciel, je prends les sources du logiciel, je compile, je l'installe. Je lance... cette fois la version est bonne, ça ne refuse pas l'image, mais... le serveur virtuel ne veut pas démarrer. J'ai des erreurs. Puis au final j'en ai eu marre et j'ai arrêté.
J'ai passé je-ne-sais-combien d'heures rien que pour essayer de monter mon environnement de développement avant d'abandonner (peut-être même plus que ça m'aurait pris pour coder cette killer-feature que je prévoyais). Je ne sais si c'est la raison pour les autres (je crois qu'y en a eu d'autres, il me semble avoir vu mention de cela), mais c'est la mienne.
Il faut dire aussi: je suis développeur, pas admin. Normalement quand je bosse sur un environnement complexe déjà en place (et linuxfr en est un), on a des admins qui se chargent de tout nous mettre en place. Non pas que je ne peux pas le faire moi-même, mais:
1/ ça me fait grave chier. Je déteste administrer. J'aime coder.
2/ ça me prendrait beaucoup plus de temps que l'admin qui connait bien son système.
3/ étant donné tous les problèmes que j'ai rencontrés, je me dis maintenant qu'il aurait fallu une doc bien plus précise que celle qu'on a eu malheureusement pour remonter tout cet environnement (dans un temps raisonnable, j'entends).
4/ ça tombe mal, ce mois en particulier, j'avais encore moins de temps que le mois d'avant et d'après.
Admins de Linuxfr, ne prenez pas cette critique mal surtout. Je n'ai aucun ressentiment contre vous. Donc ce n'est que de la critique que j'espère constructive, et sans aucune amertume. Je voulais juste participer au concours parce que je trouvais cela marrant et qu'y avait justement une nouvelle fonctionnalité html5 avec laquelle j'aurais voulu m'amuser un peu. Le prix à gagner ne valait pas ce développement donc ce n'était pas vraiment dans le but de le gagner de toutes façons.
Mais je suis sûr que ça prendrait juste 20 mins à un admin pro qui connait l'environnement Linuxfr de monter un environnement virtuel (par participant) et de fournir un accès ssh au participant dessus. Donc la prochaine fois que vous organisez un tel concours, je conseillerais de préparer qqch comme ça.
:-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
dois-je comprendre de ta réponse que tu penses que je trouve que XMPP est bon pour plein de choses parce que je souhaite ensuite me vendre dans la foulée comme consultant ou quelque chose du genre? Donc en gros que même si je ne croyais pas en XMPP, je le "vendrais" tout de même, pour ensuite pouvoir me vendre moi-même?
Alors outre le fait que quelqu'un pourrait trouver cela insultant (mais t'as de la chance, je ne suis pas susceptible), je tiens juste à préciser que je ne suis pas "consultant XMPP" (ni consultant tout court), et que je ne travaille (j'entends ici "travailler" dans le sens où je gagne ma vie) pas dans le milieu XMPP (bien que ça peut m'intéresser bien évidemment, mais je ne cherche pas plus que ça).
Ma "seule" relation avec XMPP est que j'y "travaille" (cette fois dans le sens "j'y passe du temps") sur mon temps libre, à la fois en développement perso de logiciel Libre, et aussi sur l'amélioration des RFCs IETF associées et des XEPs.
Donc si je promeus XMPP, c'est vraiment parce que j'y crois, et non pas pour des raisons vénales.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
j'avais fait un plugin pour Firefox (doit y avoir 2 ans, waw le temps passe!) qui stocke justement les marques pages sur un nœud pubsub de son compte Jabber (cf. XEP-0048 bien que celle-ci mérite une bonne réécriture, que je prévoyais également en même temps de compléter le plugin). Mais ce plugin est resté à un stade très expérimental (il est très mal intégré à Firefox, pour l'instant c'est tout juste un "proof of concept" basique, fonctionnel mais pas du tout utilisable avec plaisir) parce que je n'ai jamais pris le temps d'aller plus loin, bien que j'ai encore envie d'y revenir dès que je le veux.
En gros, les marques pages sont stockées sur son serveur XMPP (qui est donc décentralisé, on peut même avoir son propre serveur si on veut contrôle total), et est privé. Mais PubSub étant ce qu'il est avec son système de droit, on doit aussi pouvoir avoir des nœuds publiques ou semi-publiques (comme je dis plus haut: on choisit à qui on partage au cas par cas, ou bien par groupe de contact, ou à tout le monde, etc.) pour partager ses marques pages, de sorte que si quelqu'un change ses marques pages publiques et que j'y suis inscrit, la liste serait automatiquement mise à jour dans mon navigateur. Etc.
Aussi vous l'aurez compris, je ne suis pas d'accord avec les gens plus haut qui pensent que XMPP n'est pas du tout adapté pour ce genre de choses.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
P.S.: les avatars PEP ont un autre gros avantage (en plus de garantir la vie privée de certains s'ils ne souhaitent pas rendre leur avatar publique, ce qui est leur droit, non?), c'est que ton bot peut (il "peut", mais n'est pas obligé et peut se contenter de demander l'avatar une seule fois) aussi s'inscrire au nœud PEP publique de l'avatar (ce n'est pas une inscription à la présence de l'utilisateur, il ne devient pas contact), de sorte qu'à chaque fois que le nœud est mis à jour (nouvel avatar), il envoie l'information à tous les inscrits. Donc lors de sa prochaine connexion, ton bot peut mettre à jour l'avatar de l'utilisateur sur ton site web.
C'est même beaucoup mieux qu'une inscription à la présence puisque c'est la seule information dont ton bot a besoin. Avec une inscription présence, cela génère plein d'information inutile sur le réseau (la présence elle-même déjà, que ton bot envoie et qu'il reçoit de tous les contacts, puis toute information relative, comme des "découvertes" de fonctionnalités faites par les contacts du bot à celui-ci, ou bien la liste de leur propre fonctionnalité qu'ils envoient potentiellement pro-activement, etc.).
Là, aucun échange superflu, uniquement la nouvelle information nécessaire, SI et QUAND l'avatar change, et seulement à ce moment là.
C'est de là que vient le nom PubSub: "Publish-Subscribe" (Publier-S'inscrire).
Perso j'irais avec une implémentation là dessus si j'étais toi (mais je suis pas sûr que ce soit l'implémentation choisie par la plupart des clients à l'heure actuelle).
Enfin bon vcard marche aussi parfaitement pour ton use case, seulement il n'y aura pas de mise à jour pro-active (si jamais tu veux savoir si un avatar est mis à jour et que tu n'as pas d'inscription présence, tu dois redemander).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
tout dépend de comment sont implémentés les avatars actuellement.
Il existe pour l'instant 3 (je pense pas plus, mais qui sait?.. on a tellement de doublons) spécifications pour les avatars XMPP:
- ceux basés sur une requête spécifique (IQ-based, XEP-0008), historiquement. Mais cette méthode n'est plus considérée comme valide et obsolète (ce qui ne signifie pas qu'il n'y a pas quelques implémentations qui l'utilisent encore peut-être).
Ta demande est-être possible avec cette XEP mais je ne creuse pas, cette spéc est très limitée et inintéressante.
- ceux basés sur les vcards (XEP-0153), méthode très répandue et la spéc est considéré comme active (la seule spéc avatar active), bien qu'historique également (donc potentiellement supplantable).
Cette spéc te permet déjà de faire ce que tu souhaites puisque la spéc vcard (XEP-0054) précise bien dans les considérations de sécurité que la vcard est visible par le monde entier. Il n'y a pas de notion de droits sur une vcard donc ton bot XMPP peut demander la vcard de n'importe qui et *n'a pas besoin de demander à être inscrit dans ses contacts!*
- ceux basés sur PEP, donc PubSub (XEP-0084). Son statut est en "brouillon", mais c'est le seul considéré comme en état de standardisation. En gros ça se bagarre avec la XEP vcard pour savoir qui l'emporte.
Là aussi c'est possible puisque PubSub a un système de droits élaborés, contrairement à vcard qui est "visible par le monde entier". Donc un utilisateur peut théoriquement décider à qui il montre ses infos publiés au cas par cas (ça peut être seulement à ses contacts, voire seulement à un groupe de contacts, par une liste de JID, à tout le monde, ou même sur demande que l'utilisateur reçoit puis valide ou refuse ensuite). Évidemment les clients gèrent très mal, voire pas du tout pour tous ceux que j'ai vu, ce genre de droits sur les nœuds Pubsub ou PEP, et il ne demandent jamais ce genre d'infos. Donc cela dépend probablement de l'implémentation du client et du serveur, cad quels droits par défaut ils mettent en créant un nœud. Étant donné ce que j'avais vu à l'époque de tests sur PubSub (mais mes derniers tests remontent bien à un an ou plus maintenant), y a de fortes chances que les droits par défaut soient souvent publiques, malheureusement (je dis "malheureusement" de manière générale, par contre le nœud avatar, je pense que "publique" peut être une bonne valeur par défaut, mais il faudrait quand même que l'utilisateur puisse changer cette valeur s'il le souhaite).
Mais heureusement par contre pour toi qui peut sûrement récupérer les avatar PEP de cette façon.
Pour conclure, je pense que tu n'auras pas de problème pour faire ce que tu veux. Par contre tu peux voir que les avatars Jabber sont un peu un bordel pour l'instant et que théoriquement, un même utilisateur pourrait avoir 3 avatars différents selon la technologie choisie pour la récupérer.
Bye.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Cool. Merci à vous deux. J'ai pas eu de linuxfriens dans mon public (enfin je crois, ou bien trop timide pour dire bonjour) mais ,ca s'est bien pass'e en tous cas. À une prochaine peut-etre donc. Je vais voyager encore mais je reviendrai peut-etre vivre au Japon dans quelques mois, donc si je refais un concert... j'en ferai à nouveau part ici.
Bonne journ'ee!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
donc si je comprends bien ce que tu me dis, en gros il ne *faut pas* refuser un email si le FROM ne correspond pas à la vraie adresse d'envoi ou en vérifiant l'enregistrement SPF du FROM?
Donc je suis condamné à recevoir des faux emails d'arnaque de mon propre domaine en gros (ou encore des faux emails de mes comptes Facebook/Twitter/le truc hype du moment, alors que je n'ai aucun compte chez les moindre de ces services), lesquels passent le filtre SPF car celui-ci ne se base pas sur l'adresse du FROM mais sur la vraie adresse d'envoi.
Alors bien sûr, ces emails ne passent en général pas le filtre spam ensuite, mais j'aimerais tout de même pouvoir les refuser avant tellement ce sont des faux évidents selon moi (mon domaine, donc mon adresse email, datant de nombreuses années, je reçois plus d'une centaine de spams par jour, aux alentours de 150 même. Et je parle juste de mon compte, pas du serveur).
C'est quand même vraiment un protocole ridicule le protocol email.
Si quelqu'un a des suggestions, je suis tous yeux.
Merci pour la réponse et pour d'éventuelles autres réponses.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
le lendemain de l'annonce de libération du VP8, quelqu'un a posté un patch sur la mailing list de développement de mplayer/mencoder, pour le support de VP8/WebM.
Donc oui, c'est actuellement supporté dans la version de développement (dans le dépôt de source donc), bien que je n'ai pas testé personnellement.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
non si tu lis le post de la fondation, ou mon explication plus haut, tu verrais que le tinyurl pointe sur le site Jira lui-même. Il n'y a pas d'autre machine impliquée ici. Le tinyurl très probablement ne devait servir qu'à cacher la taille de l'url (ainsi que le fait qu'elle contienne un script pour ceux qui l'auraient lu). Mais le domaine de l'url n'aurait rien eu de suspicieux par contre.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Donc en ce cas, la solution 3/ est à bânir. Le navigateur peut juste filtrer par les méthodes 1/ et 2/ (même si le script est intégré dans la page "graphiquement", il n'est pas exécuté, juste affiché, donc le navigateur peut faire la différence et la méthode 2/ ne bloque donc pas ce type d'utilisation).
Mais je vois d'autres problèmes.
Par exemple, imaginons qu'on veuille justement désactiver, mais partiellement seulement, certaines parties d'un script inclus dans une page et que cela permette d'en changer le sens (et obtenir même un usage néfaste), on pourrait alors:
- inclure dans une url une variable contenant la copie de la partie du script à virer (que l'on sait sera incluse dans la page retournée).
- Le serveur lui en réalité ne connaît pas cette variable bidon, n'en prendra pas compte et retournera la page normalement.
- Le navigateur ne sait pas ce que fait ou non le serveur en interne, bien évidemment, par contre il reconnaît que le bout de script qu'il a vu dans l'url se retrouve dans la page comme code à exécuter. Il en conclut "intelligemment" qu'il s'agit sûrement d'une faille de cross scripting et que ce code a été injecté (alors qu'il n'en est rien, il n'y a aucune corrélation réelle entre l'url et ce script).
- Le navigateur retire ce bout de script, mais s'il exécute le reste, ça peut devenir dangereux (si ça a été pensé pour l'être).
Donc ici on a généré une attaque en faisant croire au système de protection qu'il y avait une autre attaque! Ainsi il faut faire très gaffe aussi avec ce genre de sécurité intelligente qui peuvent elle-même créer des failles là où il n'y en avait pas auparavant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Psychofox, justement le script ne vient pas d'une autre machine. Je sais que l'explication est assez technique donc difficile à comprendre mais c'est ce que j'explique dans mon message plus haut.
Le script est injecté dans la page (par une url dans ce cas, mais d'autres méthodes sont envisageables), de sorte qu'il est tout à fait envisageable que le serveur lui-même sert la page avec le script inclus dedans. Là encore, les deux sont possibles. On pourrait aussi imaginer que le script est inséré côté client, par exemple si les variables url sont parsées par du javascript, qui à son tour exécute des scripts qui y sont passés. Mais le cas où l'url est parsée côté serveur et donc que ce dernier sert une page avec le script dedans est tout à fait probable. Dans l'attaque en question, rien n'est précisé sur la méthode exacte du cross scripting (encore une fois, ils attendent probablement que la faille soit comblée).
Par conséquent, d'un point de vue purement basique techniquement, le script ne vient pas d'une autre machine: il vient du serveur.
Cependant il est clair que toute méthode impliquant un script (donc une exécution sur machine) passable par url est mauvaise par design (franchement! Non?). Et comme je soulignais, le navigateur peut sûrement détecter ce genre d'anomalie, mais ce n'est pas du tout un truc évident, car de manière générale, il n'y a pas de bug technique, mais un "bug humain". On demande au navigateur là de repérer et protéger une grosse erreur du développeur (= accepter du code exécutable dans l'url sans protection particulière, l'équivalent d'utiliser la fonction "system" dans un programme sans aucune vérification, et pour une exécution de code très sensible). Néanmoins comme dans ce cas, il y a peu de chances que ça soit bien utilisé, on peut essayer...
Perso, je vois ca ainsi:
1/ si le script est intégré côté client, on peut repérer ça facilement et donc bloquer un tel script.
2/ sinon (intégré côté serveur), on peut essayer de repérer des familiarités entre les scripts intégrés dans la page et ce qui est passé en url. C'est apparemment ce que fait IE8beta2 par exemple (lien très intéressant donné par PasBill PasGate ci-dessous).
3/ de manière générale et plus simple, je me demande s'il ne faut pas virer de l'url tout ce qui ressemble à un script avant même de faire la requête au serveur. Comme je disais, je ne vois pas de bon usage, et même si le script n'est pas intégré dans la page en réponse, rien ne dit qu'il n'est pas exécuté sur le serveur lui-même et peut donc s'avérer très dangereux là-bas.
Néanmoins cela pose la question: jusqu'où «l'intelligence» (au sens IA) du navigateur doit aller pour protéger les erreurs de développement? Et qui sait si — en faisant cela — on ne bloque pas aussi des requêtes légitimes (contre toute attente, il existe peut-être de bons usages, même si je ne les vois pas dans l'immédiat, avec des serveurs qui vérifient et traitent le script au préalable par exemple pour en faire quelque chose d'adéquat, ou le supprimer si dangereux).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Commentaire auto-centré
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Open Discussion Day ce jeudi 19 mai. Évalué à 4.
Salut,
je voulais juste mettre un bémol sur ces statistiques de Linuxfr. J'ai une adresse de messagerie instantanée mais je ne la rentre pas et ne la rentrerai jamais dans ma configuration Linuxfr tant qu'elle est affichée publiquement, sans choix de la rendre privée.
Je ne veux pas que mon email soit publique, et je vois pas la différence pour mon adresse IM. Je ne souhaite pas que des bots s'empare de mon adresse et me spamme un jour par IM.
En dehors de cela, si Linuxfr se mettait à utiliser Jabber pour me communiquer des informations ou me permettre de faire certaines actions ET que cette adresse n'est pas ainsi publiquement accessible pour être collectée par des bots, je la rentrerais.
Je ne sais pas si il y a beaucoup de gens dans mon cas, mais c'était juste pour signaler que cela pouvait avoir un impact sur les statistiques si vous comptez les utiliser pour savoir le pourcentage de libristes du site qui utilise Jabber.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 4.
Salut,
c'est pas une histoire de meilleur concept. Ce sont juste des conceptions différentes.
À partir de là, je ne crois qu'il y ait besoin de te vendre quoi que ce soit. Et oui bien sûr, on peut se débrouiller sans et oui tout ce qu'on fait dans un concept, on peut le faire dans un autre. Il suffit de voir tout ce qu'ont fait des millions de développeurs dans le monde, qu'ils utilisent une logique impérative, fonctionnelle, objet, déclaratif, etc. en-veux-tu-en-voilà (et avant ça y a des dizaines d'années, des programmes étaient entièrement écrit en assembleur, c'est dire si on peut tout faire quel que soit la "famille" du langage).
Par contre c'est simplement que certains concepts s'adaptent plus aisément à certains problèmes que d'autres.
Par exemple, si je développe un programme où les données rentre, sont traitées, sortent constamment, je vois tout de suite du fonctionnel: t'as une entrée, une sortie et une boîte noire au milieu.
L'objet est vraiment très agréable et permet des designs très "évident" (donc agréable à utiliser) pour tous les problèmes avec des "entités", que l'on peut conceptualiser, qui ont des caractéristiques et qui peuvent effectuer certaines actions.
Etc.
En fait il faut juste voir des classes de problématiques et ce qui permettra de faire la plus jolie et évidente API (soit parce que c'est le but final, ou soit parce qu'on va l'utiliser soi-même). Ça n'empêche pas qu'il y a en fait 1000 autres designs possibles pour la même fonctionnalité et qu'un autre design dans une tout autre logique peut également être très agréable.
C'est juste une question de choix.
Enfin y a la question du langage à utiliser. Personnellement je m'adapte. Quand j'écris en OCaml par exemple, je pense essentiellement soit classe soit fonctionnel. Mes programmes n'auront (presque) jamais la moindre boucle, je préfère les retours de fonctions aux références, et je m'arrange pour que mes fonctions récursives soient toujours terminales (sauf si la complication apportées ne vaut pas le gain. Ça arrive parfois, par exemple pour les fonctions qui auront des appels récursifs peu profond par design).
Si par contre j'écris en C, je fais des boucles, des paramètres par références et du massivement impératif comme tout le monde.
Il faut savoir profiter des forces d'un outil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 3.
Salut,
non c'est pas facile. Pour les utilisateurs, tu peux le faire de manière plus ou moins transparente mais c'est pas forcément facile. Si le serveur ne prévoit pas ce genre de cas, c'est à toi de faire le nécessaire, ce qui implique quelques requêtes ds la BDD. Par contre, ça ne peut pas être transparent pour les contacts des utilisateurs par définition. En effet tu n'as pas accès à la base de données des contacts (sauf si tous les contacts de tes utilisateurs sont aussi dans tes utilisateurs bien sûr) et tu ne peux donc pas agir sur leur roster (imagine s'il existait une possibilité pour cela, ça signifierait que quelqu'un pourrait monter un faux serveur et créer des utilisateurs dessus pour "s'emparer" des utilisateurs d'autres serveurs, et ce de manière totalement invisible, donc il serait capable de faire des attaques ciblées en se faisant passer pour d'autres).
En conclusion, ce n'est pas la bonne solution.
Une solution pourrait être que tu pourrais envoyer des notifications de "déménagement" pour tous les contacts de tous les comptes utilisateurs (XEP-0283, l'extension expérimentale qui existe actuellement et implique que les contacts devront approuver manuellement le changement, par rapport à ce que je disais précédemment sur les problèmes de sécurité). Mais je ne sais pas exactement quels clients implémentent réellement cette XEP. Je ne la connais pas trop non plus, mais je pense qu'elle pourrait être vraiment améliorée pour être rendue plus transparente, tout en étant sécurisée. J'y jetterai peut-être un œil un jour.
Ma conclusion cependant serait que je ne te conseille pas de le faire de manière trop transparente. Déjà simplement parce que tes utilisateurs devront bien savoir que leur adresse a changée pour la donner aux gens. Ensuite parce que s'il y a des problèmes parce que des contacts n'ont pas pris en compte le changement (leur client ne supportait pas la XEP "moved" par exemple), ben tes utilisateurs pourraient ne pas s'en rendre compte immédiatement et simplement croire que tel ou tel contact ne se connecte plus pendant longtemps. Alors que s'ils sont bien informés, ils sont conscients que des problèmes peuvent survenir et donc être proactifs (rentrer en contact avec certains utilisateurs pour s'assurer qu'ils se mettent à jour).
Mon conseil:
1/ utilise la nouvelle adresse pour les nouveaux inscrits, mais garde l'ancienne en parallèle par défaut sans transférer personne. Un nouvel inscrit ne peut se faire par contre que sur la nouvelle.
Par contre informe tes anciens utilisateurs qu'une nouvelle adresse est disponible. 2/ réserve tous les nicks sur la nouvelle adresse qui existent déjà sur l'ancienne. Et fais savoir à chaque utilisateur que s'ils décident de "déménager", leur nick leur est réservé aussi longtemps qu'ils ont leur ancien compte. 3/ si un utilisateur désire déménager vers la nouvelle adresse, prépare tout pour lui faciliter la tâche le plus possible. Par exemple, il a juste un clic à faire sur une page (ou un bot XMPP à qui il envoie un message), ce qui génère automatiquement des stanzas de déménagement pour tous ses contacts, ainsi qu'envoie des autorisations à tous ses anciens contacts pour son nouveau compte). 4/ L'utilisateur qui déménage devrait garder un accès à son ancienne adresse un certain temps (6 mois?), ce qui lui permettrait de gérer les contacts qui ne supportaient pas la XEP-0283 et donc n'ont pas inscrit le nouveau JID (l'utilisateur a donc besoin de son ancienne adresse pour voir quand ils sont connectés, discuter avec eux et leur dire qu'il a changé si besoin par exemple) ou gérer les gens à qui il aurait récemment donné son ancien JID et qui inscriraient ce dernier. Et autre...
Et il faut savoir que tout type de migration a toujours son lot de problème. Mon expérience là-dedans, c'est qu'une bonne communication pour prévenir de cela vaut mieux qu'essayer d'être le plus discret possible (transparent) car lorsque les utilisateurs s'en rendent compte (car ils s'en rendront compte, et certains auront des problèmes), ils seront furieux. Alors que si tu leur laisses le choix en les prévenant des risques sur le court terme mais des avantages sur le long terme, ce sera un choix conscient de leur part, donc ils prennent leur part de responsabilité!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 10.
Salut,
bien sûr que c'est possible! J'en parle même dans mon article!
Je cite un organisme qui propose ce service (payant): Google avec les Google Apps.
Beaucoup plus proche des libristes, l'Apinc (Association pour la Promotion de l'Internet Non Commercial) aussi propose le même service gratuitement: http://jabber.apinc.org/. Je suis un peu bête d'avoir oublié de parler de leur service (n'hésitez pas à ajouter ce lien à la dépêche!). Ce genre de service se démocratise de plus en plus et leur sécurisation est un de nos gros sujets du moment (cf. l'article et je détaille plus bas dans ce post).
L'un comme l'autre te permettrait d'avoir ton jid comme toi@tondomaine.fr, et ce sans que tondomaine.fr redirige vers quoi que ce soit d'autre que ton site web dans un navigateur.
J'explique même comment ça marche dans l'article (même si c'est vrai que je n'ai pas détaillé, car si je détaille tout, l'article est trop long, un reproche qu'on me fait souvent): on utilise les DNS SRV records.
Les ancêtres
La vieille méthode que http utilise encore, c'est effectivement juste de rediriger un domaine vers l'adresse principale qui lui est dédiée (ce qu'on appelle un enregistrement A pour IPv4 et AAAA pour IPv6. Il existe chez Mozilla un rapport de bug depuis 11 ans et demi pour utiliser les SRV et ne passer aux A/AAAA qu'en fallback, auquel je suis abonné moi-même depuis quelques années et qui a beaucoup de votes, d'abonnés, et a même eu des patchs envoyés par certains, mais Mozilla ne semble pas intéressé alors que le service http a déjà été enregistré par l'IANA).
Mais ça c'est la méthode antique, aucune flexibilité.
La relêve (actuelle)
Les enregistrements de service, c'est bcp plus subtil. On fait un enregistrement DNS qui dit quelles IPs regarder pour tel "service". Nous, on a deux enregistrement de service principaux: xmpp-client ou xmpp-server (selon qu'on parle au client ou serveur).
Une entité fait donc une requête DNS pour le domaine concerné du service désiré, et ça retourne une liste de couples (IP, port) à utiliser. Ça permet de préciser quelles IPs hébergent ton service Jabber et sur quel port (je connais au moins 2 serveurs qui n'utilisent pas le port par défaut sans aucun problème de fonctionnement alors que les services web doivent utiliser un truc moche à la example.com:8888 pour faire pareil), qui peut tout à fait être différent de ton serveur web.
Note que pour les petits organismes avec plusieurs serveurs mais sans beaucoup d'argent, ou sans tout une équipe d'administrateurs dédiés à l'infrastructure, SRV permet aussi un répartition de charges statique (donc basique mais suffisante pour beaucoup de petites et moyennes structures). Les enregistrements possèdent en effet un système de priorité et poids à utiliser conjointement pour se connecter aléatoirement (avec préférence) sur des machines différentes d'une utilisation à l'autre.
Un enregistrement normal (A/AAAA) n'a pas d'équivalent de ce système de répartition de charges car au mieux, on mélange les enregistrements A/AAAA aléatoirement (ils ont donc tous le même poids, on ne peut préciser les probabilités de connexion souhaités selon la machine, ce que fait SRV).
Donc oui, c'est possible, c'est même facile à faire. Ça demande des compétences très basique pour quiconque a les compétences de base pour avoir son propre domaine (c'est presque pas de l'administration info tellement c'est facile).
1/ tu t'inscris sur le service qui va héberger ton serveur.
2/ tu ajoutes un enregistrement DNS (pour ceux qui n'hébergent pas leurs propre serveur DNS, c'est en général simplement dans l'interface web de ton registrar) et tu ajoutes un (ou plusieurs si le service qui t'héberge a plusieurs machines) enregistrement de service xmpp-client et xmpp-server.
Et... c'est fini! XMPP fait ça depuis des années. En fait c'était déjà standard dans la RFC3920, comme je le dis dans l'article, donc on fait tous ça depuis au moins... 7 ans!
Google ne se gêne pas pour utiliser tout cela pour ses 5 machines XMPP client (et il a 5 machines xmpp-server différentes pour le même domaine):
Bien sûr certains font encore la vieille méthode avec un enregistrement A et/ou AAAA sur un sous domaine de leur domaine principal. Genre im.example.com. Perso j'ai jamais compris pourquoi! Je ne connais pas un client ni un serveur de nos jours qui ne gère pas les SRV records. Et au final c'est plus compliqué car on doit créer et gérer un nouveau sous-domaine.
Le futur
Enfin la seule problématique avec cette solution est la sécurisation par certificats X509 (TLS). Les possesseurs d'un domaine n'aime pas toujours donner un certificats pour leur domaine principal à un service tier, et ça peut se comprendre (le service tier, si malveillant, aurait alors le pouvoir — presque officiel — pour se faire passer pour le domaine principal pour d'autres types de service, comme le web).
Il est en réalité possible d'associer un certificat à un enregistrement de service (il y a au moins un CA qui propose ce genre de certificat), mais malheureusement à ce que j'ai compris les navigateurs web (encore eux!) ne regardent pas vraiment ce champs et donc cette sécurité passe à la trappe à l'heure actuelle. C'est pourquoi (encore comme je le dis dans l'article! J'explique trop mal?) pas mal de gens réfléchissent à une solution pour rendre ce passage de pouvoir à la fois aussi sécurisé que si on le faisait nous-même mais sans donner les pleins pouvoirs sur tout le domaine. Y a au moins un brouillon de RFC proposé sur le sujet (mais je l'ai pas encore lu, je ne connais pas sa pertinence).
Et après j'en lis plus haut que XMPP est une vieux truc alors qu'on est parmi le top de la technologie Internet (on est parmi les premiers à utiliser les technologies les plus récentes. SCRAM par exemple, XMPP est LA technologie qui fait vraiment démarrer ça et comparé aux vieux mécanismes SASL, c'est vraiment génial. SRV aussi, nous sommes parmi ceux qui ont créé une adoption massive; bien que sur le coup, je crois que SIP était avant nous) et qu'on est constamment à innover sur tous les fronts et à prendre des risques en adoptant des technologies avant les autres. Alors bien sûr on cherche aussi la rétrocompatibilité en même temps. Mais après si on cassait l'intéropérabilité entre les serveurs récents et anciens, vous iriez encore vous plaindre (et un peu plus à raison pour une fois)!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Requête de mise à jour aux admins
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 5.
Bonjour,
1/ pourrait-on mettre à jour les liens RFCs? Je pensais qu'ils resteraient un peu, mais les liens donnés étaient en fait les liens dans la dernière phase du processus de standardisation (qui s'est stabilisé aujourd'hui, bien que les versions données étaient déjà les versions finales qui n'avaient quasiment aucune chance d'être modifié dans cette étape avant le statut final).
Les bons liens sont donc:
http://www.rfc-editor.org/rfc/rfc6120.txt http://www.rfc-editor.org/rfc/rfc6121.txt http://www.rfc-editor.org/rfc/rfc6122.txt
Ou encore, je préfère personnellement utiliser:
http://tools.ietf.org/html/rfc6120 (etc. 6121, 6122)
parce que c'est du html avec hyperliens dans les menus (et qu'on peut aussi avoir la version txt ou pdf à partir de là).
2/ Aussi pourriez-vous modifier aussi le "TLS EXTERNAL" qui est une bête erreur alors que je sais pertinemment que c'est TLS + SASL EXTERNAL. Ça m'évitera d'avoir honte. ;-)
Je donne aussi l'astuce aux gens intéressés dans les RFCs et dans l'utilisation avancés d'un navigateur web aussi: dans Firefox (et je pense dans le plupart des concurrents, y a un équivalent), vous pouvez enregistrer un bookmark de la sorte: http://tools.ietf.org/html/rfc%s Et vous mettez un "keyword", par exemple "rfc". Puis dans votre barre d'adresse, vous tapez juste "rfc 6120" et paf! Vous êtes direct dans la bonne rfc! C'est ce que je fais personnellement pour naviguer rapidement d'une RFC à l'autre.
Vous pouvez adapter cette astuce à tout type de site qui utilise des URL "parlantes" et simples (comme quoi, c'est important de penser l'architecture des URL!).
Merci.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 10.
Salut,
je vais répondre aux divers points:
1/ le nom: je suis d'accord, le choix du nom n'est pas terrible pour le grand public, c'est sûr. Mais c'est uniquement un choix "technique" de nom pour un protocole. Cela n'implique pas qu'on souhaite que les utilisateurs se mettent à l'utiliser (pas moi en tous cas).
Les utilisateurs disent-ils "je vais regarder sur le web" ou bien "je vais consulter des pages html par http"? Disent-ils "tiens je t'ai envoyé un email!" ou bien "Je t'ai envoyé un message par smtp, l'as-tu reçu par pop/imap?". Etc.
De manière général, il faut différencier le nom d'un protocole et son utilisation. C'est juste un nom technique (de même que je suis sûr que les voitures ont un nom technique et ridicule avant d'avoir un nom sexy pour passer en publicité, de même pour la plupart des projets!), faut arrêter de se focaliser dessus. Jabber est toujours un très bon nom, utilisable et le nom du serveur publique géré par la XSF s'appelle toujours jabber.org et personne ne parle de changer ce nom.
Pour ma part, je préfèrerais qu'on utilise le nom générique de "messagerie instantanée" et qu'on oublie un instant le nom des protocoles. Avec le travail d'intéropérabilité avec SIP, ça sera d'ailleurs d'autant plus vrai. Qu'importe le protocole derrière, on a une adresse qui permet de discuter, on s'en fiche du reste.
2/ Je suis triste aussi que Facebook ait décidé de ne pas ouvrir ses serveurs, mais ça ne m'étonne pas plus que cela de cette entreprise. Ils ont aussi fermé leur réseau web, tu sais. On ne peut pas regarder les pages Facebook sans compte (moi j'ai jamais pu en tous cas). Ben ils font pareil avec Jabber qu'ils ont fait pour le web. Est-ce que tu vas te plaindre aussi que le web c'est nul parce qu'y a des serveurs fermés comme Facebook?
3/ Les extensions, ce sont comme des RFC, sauf que c'est au niveau de la XSF au lieu de la IETF. Donc on a aussi un protocole de standardisation. Ainsi les extensions commencent avec des statuts expérimentals, elles sont testées, implémentées, modifiées. Et parfois elles passent au stade de standards XSF. Parfois elles sont abandonnées. Parfois certains font leurs extensions dans leur coin pour une utilisation privée (réseau d'entreprise, ou autre) sans intention de standardiser donc de proposer une XEP. Y a de tout.
Encore une fois, va voir combien de brouillons de RFC sont proposés à la IETF, le nombre de brouillons que cela a impliqué (on a 23 brouillons entre la RFC 3920 et 6120, et 21 pour 6121!), et combien passent en standard quand la plupart passent aux oubliettes. Vas-tu dire que la IETF pue parce qu'ils permettent tant de versions expérimentales?
4/ Il n'y a qu'un standard Jingle. Le fameux "Jingle by Google" n'existe pas. Ils ne se sont simplement pas mis à jour encore avec la version standardisée, c'est tout. Mais ils y viendront, comme tout le monde qui veut implémenter la VOIP par XMPP. Ils n'ont aucun intérêt à ne pas le faire.
Je rappelle que c'est Google qui a fait la proposition de Jingle, ils ont donc la plus vieille implémentation expérimentale du protocole. C'est sûr, c'est plus facile quand le protocole existe déjà. Eux, il n'existait pas. Ils ont expérimenté, ont proposé un standard, ça a été étudié, discuté, et on l'a standardisé.
C'est ce que je disais dans l'article: pour l'instant tout le monde a une version de base, plus ou moins complète, basée sur une version plus ou moins expérimentale du protocole selon quand ils ont commencé à implémenter (avant que le protocole soit fixé ou après). On attend donc juste que tout ça se tasse et que les diverses versions se mettent à jour. Ça prend le temps qu'il faut mais ça viendra.
Mais sinon, non: il n'y a qu'un Jingle.
Pour SIP, c'est différent. Y a eu tentative de standardisation de deux protocoles qui à l'origine était finalement assez différents: l'un était vraiment orienté texte (XMPP), l'autre voix (SIP). Au final, avec le temps et les évolutions, les fonctions ont commencé à se recouper puis de plus en plus. Mais c'était trop tard, les deux protocoles étaient déjà standardisés et avaient chacun une grosse masse utilisateur. C'est pas comme si quelqu'un va se mettre à vouloir dire "ok ben finalement on révoque un des deux protocoles". Donc on fait avec et maintenant seul le temps peut nous dire si l'un des deux protocoles va prévaloir ou si les deux vont coexister ainsi pendant encore longtemps.
Et donc faire avec, c'est ce qu'on fait avec les discussions sur l'intéropérabilité entre les deux réseaux (voir la liste de discussion SIXPAC (SIP Interworking with XMPP in Presence Aware Clients) de l'IETF).
Note au final qu'il y a encore un autre cas où plein de technologies très différentes intéropère. Et c'est aussi dans les télécoms, on appelle ça le téléphone! Entre le RTC, d'autres variantes numériques fixes, et une foultitude de protocoles différents pour le mobile (GSM, GPRS, 3D, etc. En veux-tu en voilà)… Ben personne se plaint des téléphones et des protocoles derrière!
Bon bah nous c'est pareil. On arrive pas à rendre les protocoles intéropérables aussi vite que les consortium (ou je ne sais quel type d'organisme) de téléphonie, mais on n'a pas le même argent non plus. Aussi surtout on ne vous demande pas des sommes mirobolantes pour améliorer le système. Mais je trouve qu'on se débrouille quand même bien avec les moyens du bord.
Tu aurais préféré qu'Internet soit un système tout fermé avec des protocoles qu'on paye à prix d'or et géré uniquement par des grosses sociétés?
Voilà pour les divers points.
XMPP n'est pas le protocole parfait. Il a beaucoup de problèmes et il n'y a aucun doute que si les divers acteurs du protocole devait repartir de zéro maintenant, on ferait pas mal de choses différemment. Mais c'est ça le travail de standardisation. On se bat pour faire un système qui convient à tous pour être une norme ouverte, non couverte par des centaines de brevets, et libre d'utilisation pour tous.
Ensuite libre à toi si tu trouves que c'est de la merde et si tu préfères utiliser un réseau fermé qui a sûrement un nom très sexy, des serveurs très ouverts entre eux-même, aucune extension et une technologie son et vidéo intéropérable avec elle-même.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 1.
Salut,
désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external => SASL external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 2.
Salut,
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Salut à Toi
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 1.
Salut à toi aussi! ;-)
Bien que n'ayant jamais testé ton projet, j'avais vu tes divers journaux que tu avais fait dessus, et en fait tu m'avais presque énervé, parce que t'as plein d'idées très similaires aux miennes. ;-)
Quoiqu'il en soit, si ton projet est suffisamment avancé pour être utilisable (parce qu'y a quand même une sélection, on ne peut laisser n'importe quel projet inexistant prendre la place de projet solides) et que tu souhaites aller encore plus loin, tu peux probablement proposer une idée (ou plusieurs même) de projet impliquant SaT, pour lesquels tu pourrais être mentor. Donc SaT pourrait participer au Google Summer of Code sous la tutelle de la XSF. Jette donc un œil au lien donné plus haut.
Bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Google nous donne des sous
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Avoir enfin un vrai moteur de recherche. Évalué à 3 (+0/-0).
Salut,
comme je disais dans le ticket, même programmé avec les pieds, je suis persuadé que ce sera déjà mieux que Google (qui est vraiment super mauvais pour Linuxfr dans mon expérience, pas vous?), parce que nous avons accès à la structure et logique interne du site.
À partir de là, ça signifie qu'on peut commencer par avoir un moteur de recherche basique fait en 30 minutes (genre on cherche juste la liste des mots en se limitant aux tags, au titre, puis au texte, et enfin on rajoute un bonus aux tickets récents, avec cet ordre de poids: ce sera déjà une grosse amélioration et ça fait quelques lignes de code pour la logique), puis progressivement l'améliorer avec le temps (affiner les poids, rajouter des éléments, créer un systèmes d'options à sélectionner, voire un jour tenter l'expérience d'un moteur de recherche avec apprentissage). Notez que je suis prêt à aider, mais il me faudrait un environnement de développement déjà prêt. Mon expérience désastreuse lors du concours pour le nouveau site m'a décidé à ne plus essayer d'installer cela moi-même.
Enfin pour les pubs, je comprends. Oui l'idée de tous les ans proposer une campagne de don est intéressante en switchant sur Google search en même temps, et tant que la campagne n'est pas bouclée, semble bien. Aussi n'y a-t-il pas des entreprises qui pourraient sponsoriser Linuxfr (sous et/ou matériel, je crois que les deux se sont déjà faits pour l'assoce, non?)? Je suis sûr que c'est facile, surtout si c'est pas grand chose, parce que vous représentez la source numéro 1 d'informations relatives à Linux et au Libre en France.
Peut-on avoir un ordre de grandeur sur la somme représentée par ces pubs? Quand vous dites que c'est pas grand chose, c'est quoi? 50 euros? 100? 1000?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Restreindre les droits utilisateurs ou avoir un utilisateur avec certains droits admins?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 2.
Salut,
cette solution permet-elle de restreindre les droits utilisateurs simples (1)? Par exemple si je veux lancer un programme en m'assurant que ce problème ne puisse pas du tout lire dans le système de fichier (même les fichiers appartenant à l'utilisateur qui fait tourner le programme), est-ce possible?
Ou bien cela permet simplement de donner quelques droits supplémentaires à un utilisateur (qui sont normalement réservés à root), mais pas tous (2)?
Je m'intéresse justement en ce moment à faire la première chose (1) en particulier. Quelles sont les solutions existantes (Capsicum ou autre) capables de faire ce genre de restrictions sous Linux?
Je me suis bien sûr intéressé aux "capabilities" du noyau Linux mais tout ce que je lis (par exemple http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt ) semble indiquer que cela ne permet que la seconde fonctionnalité (2) que j'ai citée plus haut.
Je suis intéressé par tout lien sur la chose ou points de départ pour une recherche. En particulier je souhaite ne pas avoir à modifier un kernel (donc en fait Capsicum, qui m'intéresse dans le concept et peut-être dans l'avenir, n'est cependant pas intéressant pour moi à court terme tant que ce n'est pas un élément de base de Linux).
Merci pour ce sujet intéressant en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Direct3D vs OpenGL. Évalué à 4.
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel. Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead). Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités. Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent. Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Direct3D vs OpenGL. Évalué à 9.
Bonjour,
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction
cube(l)alors qu'une moins bonne aurait la fonctionmake_a_regular_hexahedron(d)où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.C'est cela que l'on appelle une mauvaise API (Interface!) en général.
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction
make_a_regular_hexahedronest vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai
ball(r). On peut maintenant faire des boules en une ligne de code. De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant. C'est en gros, ce qu'ils disent dans l'article là:Enfin tout cela est confirmé par:
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi, ca marche
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Raccourci clavier pour venir au commentaire non lu précédent cassé. Évalué à 1 (+0/-0).
Ici Firefox 3.6.11 sous Linux. Ailleurs je sais pas, j'ai pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et la partie "killer feature" du concours ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Les résultats du concours LinuxFr.org. Évalué à 10.
en fait les designers ont de la chance. Pour eux, c'était "facile" de participer (j'entends par là qu'ils n'ont rien à installer: ils codent, et testent direct sur le site alpha). Pour les développeurs "cœur", on devait se taper toute l'installation du site web (ruby, rails, la dizaine de module, le serveur web, etc.), avec des problèmes de version, etc.
J'ai perdu des heures dessus. Puis un autre développeur sympa a monté une image virtuelle et on nous l'a gentiment fournie. Alors moi, je cherche un logiciel de virtualisation pour cette image. Mais... erreur: la version du logiciel fournie dans ma vieille distri n'était pas compatible avec l'image. Je vais sur le site du logiciel, je prends les sources du logiciel, je compile, je l'installe. Je lance... cette fois la version est bonne, ça ne refuse pas l'image, mais... le serveur virtuel ne veut pas démarrer. J'ai des erreurs. Puis au final j'en ai eu marre et j'ai arrêté.
J'ai passé je-ne-sais-combien d'heures rien que pour essayer de monter mon environnement de développement avant d'abandonner (peut-être même plus que ça m'aurait pris pour coder cette killer-feature que je prévoyais). Je ne sais si c'est la raison pour les autres (je crois qu'y en a eu d'autres, il me semble avoir vu mention de cela), mais c'est la mienne.
Il faut dire aussi: je suis développeur, pas admin. Normalement quand je bosse sur un environnement complexe déjà en place (et linuxfr en est un), on a des admins qui se chargent de tout nous mettre en place. Non pas que je ne peux pas le faire moi-même, mais:
1/ ça me fait grave chier. Je déteste administrer. J'aime coder.
2/ ça me prendrait beaucoup plus de temps que l'admin qui connait bien son système.
3/ étant donné tous les problèmes que j'ai rencontrés, je me dis maintenant qu'il aurait fallu une doc bien plus précise que celle qu'on a eu malheureusement pour remonter tout cet environnement (dans un temps raisonnable, j'entends).
4/ ça tombe mal, ce mois en particulier, j'avais encore moins de temps que le mois d'avant et d'après.
Admins de Linuxfr, ne prenez pas cette critique mal surtout. Je n'ai aucun ressentiment contre vous. Donc ce n'est que de la critique que j'espère constructive, et sans aucune amertume. Je voulais juste participer au concours parce que je trouvais cela marrant et qu'y avait justement une nouvelle fonctionnalité html5 avec laquelle j'aurais voulu m'amuser un peu. Le prix à gagner ne valait pas ce développement donc ce n'était pas vraiment dans le but de le gagner de toutes façons.
Mais je suis sûr que ça prendrait juste 20 mins à un admin pro qui connait l'environnement Linuxfr de monter un environnement virtuel (par participant) et de fournir un accès ssh au participant dessus. Donc la prochaine fois que vous organisez un tel concours, je conseillerais de préparer qqch comme ça.
:-)
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: autre décentralisation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 5.
dois-je comprendre de ta réponse que tu penses que je trouve que XMPP est bon pour plein de choses parce que je souhaite ensuite me vendre dans la foulée comme consultant ou quelque chose du genre? Donc en gros que même si je ne croyais pas en XMPP, je le "vendrais" tout de même, pour ensuite pouvoir me vendre moi-même?
Alors outre le fait que quelqu'un pourrait trouver cela insultant (mais t'as de la chance, je ne suis pas susceptible), je tiens juste à préciser que je ne suis pas "consultant XMPP" (ni consultant tout court), et que je ne travaille (j'entends ici "travailler" dans le sens où je gagne ma vie) pas dans le milieu XMPP (bien que ça peut m'intéresser bien évidemment, mais je ne cherche pas plus que ça).
Ma "seule" relation avec XMPP est que j'y "travaille" (cette fois dans le sens "j'y passe du temps") sur mon temps libre, à la fois en développement perso de logiciel Libre, et aussi sur l'amélioration des RFCs IETF associées et des XEPs.
Donc si je promeus XMPP, c'est vraiment parce que j'y crois, et non pas pour des raisons vénales.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: autre décentralisation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 5.
j'avais fait un plugin pour Firefox (doit y avoir 2 ans, waw le temps passe!) qui stocke justement les marques pages sur un nœud pubsub de son compte Jabber (cf. XEP-0048 bien que celle-ci mérite une bonne réécriture, que je prévoyais également en même temps de compléter le plugin). Mais ce plugin est resté à un stade très expérimental (il est très mal intégré à Firefox, pour l'instant c'est tout juste un "proof of concept" basique, fonctionnel mais pas du tout utilisable avec plaisir) parce que je n'ai jamais pris le temps d'aller plus loin, bien que j'ai encore envie d'y revenir dès que je le veux.
En gros, les marques pages sont stockées sur son serveur XMPP (qui est donc décentralisé, on peut même avoir son propre serveur si on veut contrôle total), et est privé. Mais PubSub étant ce qu'il est avec son système de droit, on doit aussi pouvoir avoir des nœuds publiques ou semi-publiques (comme je dis plus haut: on choisit à qui on partage au cas par cas, ou bien par groupe de contact, ou à tout le monde, etc.) pour partager ses marques pages, de sorte que si quelqu'un change ses marques pages publiques et que j'y suis inscrit, la liste serait automatiquement mise à jour dans mon navigateur. Etc.
Aussi vous l'aurez compris, je ne suis pas d'accord avec les gens plus haut qui pensent que XMPP n'est pas du tout adapté pour ce genre de choses.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Théoriquement, ça devrait déjà être possible
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 4.
C'est même beaucoup mieux qu'une inscription à la présence puisque c'est la seule information dont ton bot a besoin. Avec une inscription présence, cela génère plein d'information inutile sur le réseau (la présence elle-même déjà, que ton bot envoie et qu'il reçoit de tous les contacts, puis toute information relative, comme des "découvertes" de fonctionnalités faites par les contacts du bot à celui-ci, ou bien la liste de leur propre fonctionnalité qu'ils envoient potentiellement pro-activement, etc.).
Là, aucun échange superflu, uniquement la nouvelle information nécessaire, SI et QUAND l'avatar change, et seulement à ce moment là.
C'est de là que vient le nom PubSub: "Publish-Subscribe" (Publier-S'inscrire).
Perso j'irais avec une implémentation là dessus si j'étais toi (mais je suis pas sûr que ce soit l'implémentation choisie par la plupart des clients à l'heure actuelle).
Enfin bon vcard marche aussi parfaitement pour ton use case, seulement il n'y aura pas de mise à jour pro-active (si jamais tu veux savoir si un avatar est mis à jour et que tu n'as pas d'inscription présence, tu dois redemander).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Théoriquement, ça devrait déjà être possible
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 6.
tout dépend de comment sont implémentés les avatars actuellement.
Il existe pour l'instant 3 (je pense pas plus, mais qui sait?.. on a tellement de doublons) spécifications pour les avatars XMPP:
- ceux basés sur une requête spécifique (IQ-based, XEP-0008), historiquement. Mais cette méthode n'est plus considérée comme valide et obsolète (ce qui ne signifie pas qu'il n'y a pas quelques implémentations qui l'utilisent encore peut-être).
Ta demande est-être possible avec cette XEP mais je ne creuse pas, cette spéc est très limitée et inintéressante.
- ceux basés sur les vcards (XEP-0153), méthode très répandue et la spéc est considéré comme active (la seule spéc avatar active), bien qu'historique également (donc potentiellement supplantable).
Cette spéc te permet déjà de faire ce que tu souhaites puisque la spéc vcard (XEP-0054) précise bien dans les considérations de sécurité que la vcard est visible par le monde entier. Il n'y a pas de notion de droits sur une vcard donc ton bot XMPP peut demander la vcard de n'importe qui et *n'a pas besoin de demander à être inscrit dans ses contacts!*
- ceux basés sur PEP, donc PubSub (XEP-0084). Son statut est en "brouillon", mais c'est le seul considéré comme en état de standardisation. En gros ça se bagarre avec la XEP vcard pour savoir qui l'emporte.
Là aussi c'est possible puisque PubSub a un système de droits élaborés, contrairement à vcard qui est "visible par le monde entier". Donc un utilisateur peut théoriquement décider à qui il montre ses infos publiés au cas par cas (ça peut être seulement à ses contacts, voire seulement à un groupe de contacts, par une liste de JID, à tout le monde, ou même sur demande que l'utilisateur reçoit puis valide ou refuse ensuite). Évidemment les clients gèrent très mal, voire pas du tout pour tous ceux que j'ai vu, ce genre de droits sur les nœuds Pubsub ou PEP, et il ne demandent jamais ce genre d'infos. Donc cela dépend probablement de l'implémentation du client et du serveur, cad quels droits par défaut ils mettent en créant un nœud. Étant donné ce que j'avais vu à l'époque de tests sur PubSub (mais mes derniers tests remontent bien à un an ou plus maintenant), y a de fortes chances que les droits par défaut soient souvent publiques, malheureusement (je dis "malheureusement" de manière générale, par contre le nœud avatar, je pense que "publique" peut être une bonne valeur par défaut, mais il faudrait quand même que l'utilisateur puisse changer cette valeur s'il le souhaite).
Mais heureusement par contre pour toi qui peut sûrement récupérer les avatar PEP de cette façon.
Pour conclure, je pense que tu n'auras pas de problème pour faire ce que tu veux. Par contre tu peux voir que les avatars Jabber sont un peu un bordel pour l'instant et que théoriquement, un même utilisateur pourrait avoir 3 avatars différents selon la technologie choisie pour la récupérer.
Bye.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour une prochaine fois ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Concert blues-rock à Nakano, Tokyo le 31 juillet. Évalué à 1.
Bonne journ'ee!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pratique courante
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Améliorer la configuration SPF. Évalué à 2.
donc si je comprends bien ce que tu me dis, en gros il ne *faut pas* refuser un email si le FROM ne correspond pas à la vraie adresse d'envoi ou en vérifiant l'enregistrement SPF du FROM?
Donc je suis condamné à recevoir des faux emails d'arnaque de mon propre domaine en gros (ou encore des faux emails de mes comptes Facebook/Twitter/le truc hype du moment, alors que je n'ai aucun compte chez les moindre de ces services), lesquels passent le filtre SPF car celui-ci ne se base pas sur l'adresse du FROM mais sur la vraie adresse d'envoi.
Alors bien sûr, ces emails ne passent en général pas le filtre spam ensuite, mais j'aimerais tout de même pouvoir les refuser avant tellement ce sont des faux évidents selon moi (mon domaine, donc mon adresse email, datant de nombreuses années, je reçois plus d'une centaine de spams par jour, aux alentours de 150 même. Et je parle juste de mon compte, pas du serveur).
C'est quand même vraiment un protocole ridicule le protocol email.
Si quelqu'un a des suggestions, je suis tous yeux.
Merci pour la réponse et pour d'éventuelles autres réponses.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mencoder
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Quelques outils pour générer des fichiers WebM. Évalué à 2.
le lendemain de l'annonce de libération du VP8, quelqu'un a posté un patch sur la mailing list de développement de mplayer/mencoder, pour le support de VP8/WebM.
Donc oui, c'est actuellement supporté dans la version de développement (dans le dépôt de source donc), bien que je n'ai pas testé personnellement.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 1.
non si tu lis le post de la fondation, ou mon explication plus haut, tu verrais que le tinyurl pointe sur le site Jira lui-même. Il n'y a pas d'autre machine impliquée ici. Le tinyurl très probablement ne devait servir qu'à cacher la taille de l'url (ainsi que le fait qu'elle contienne un script pour ceux qui l'auraient lu). Mais le domaine de l'url n'aurait rien eu de suspicieux par contre.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 3.
Donc en ce cas, la solution 3/ est à bânir. Le navigateur peut juste filtrer par les méthodes 1/ et 2/ (même si le script est intégré dans la page "graphiquement", il n'est pas exécuté, juste affiché, donc le navigateur peut faire la différence et la méthode 2/ ne bloque donc pas ce type d'utilisation).
Mais je vois d'autres problèmes.
Par exemple, imaginons qu'on veuille justement désactiver, mais partiellement seulement, certaines parties d'un script inclus dans une page et que cela permette d'en changer le sens (et obtenir même un usage néfaste), on pourrait alors:
- inclure dans une url une variable contenant la copie de la partie du script à virer (que l'on sait sera incluse dans la page retournée).
- Le serveur lui en réalité ne connaît pas cette variable bidon, n'en prendra pas compte et retournera la page normalement.
- Le navigateur ne sait pas ce que fait ou non le serveur en interne, bien évidemment, par contre il reconnaît que le bout de script qu'il a vu dans l'url se retrouve dans la page comme code à exécuter. Il en conclut "intelligemment" qu'il s'agit sûrement d'une faille de cross scripting et que ce code a été injecté (alors qu'il n'en est rien, il n'y a aucune corrélation réelle entre l'url et ce script).
- Le navigateur retire ce bout de script, mais s'il exécute le reste, ça peut devenir dangereux (si ça a été pensé pour l'être).
Donc ici on a généré une attaque en faisant croire au système de protection qu'il y avait une autre attaque! Ainsi il faut faire très gaffe aussi avec ce genre de sécurité intelligente qui peuvent elle-même créer des failles là où il n'y en avait pas auparavant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 4.
Le script est injecté dans la page (par une url dans ce cas, mais d'autres méthodes sont envisageables), de sorte qu'il est tout à fait envisageable que le serveur lui-même sert la page avec le script inclus dedans. Là encore, les deux sont possibles. On pourrait aussi imaginer que le script est inséré côté client, par exemple si les variables url sont parsées par du javascript, qui à son tour exécute des scripts qui y sont passés. Mais le cas où l'url est parsée côté serveur et donc que ce dernier sert une page avec le script dedans est tout à fait probable. Dans l'attaque en question, rien n'est précisé sur la méthode exacte du cross scripting (encore une fois, ils attendent probablement que la faille soit comblée).
Par conséquent, d'un point de vue purement basique techniquement, le script ne vient pas d'une autre machine: il vient du serveur.
Cependant il est clair que toute méthode impliquant un script (donc une exécution sur machine) passable par url est mauvaise par design (franchement! Non?). Et comme je soulignais, le navigateur peut sûrement détecter ce genre d'anomalie, mais ce n'est pas du tout un truc évident, car de manière générale, il n'y a pas de bug technique, mais un "bug humain". On demande au navigateur là de repérer et protéger une grosse erreur du développeur (= accepter du code exécutable dans l'url sans protection particulière, l'équivalent d'utiliser la fonction "system" dans un programme sans aucune vérification, et pour une exécution de code très sensible). Néanmoins comme dans ce cas, il y a peu de chances que ça soit bien utilisé, on peut essayer...
Perso, je vois ca ainsi:
1/ si le script est intégré côté client, on peut repérer ça facilement et donc bloquer un tel script.
2/ sinon (intégré côté serveur), on peut essayer de repérer des familiarités entre les scripts intégrés dans la page et ce qui est passé en url. C'est apparemment ce que fait IE8beta2 par exemple (lien très intéressant donné par PasBill PasGate ci-dessous).
3/ de manière générale et plus simple, je me demande s'il ne faut pas virer de l'url tout ce qui ressemble à un script avant même de faire la requête au serveur. Comme je disais, je ne vois pas de bon usage, et même si le script n'est pas intégré dans la page en réponse, rien ne dit qu'il n'est pas exécuté sur le serveur lui-même et peut donc s'avérer très dangereux là-bas.
Néanmoins cela pose la question: jusqu'où «l'intelligence» (au sens IA) du navigateur doit aller pour protéger les erreurs de développement? Et qui sait si — en faisant cela — on ne bloque pas aussi des requêtes légitimes (contre toute attente, il existe peut-être de bons usages, même si je ne les vois pas dans l'immédiat, avec des serveurs qui vérifient et traitent le script au préalable par exemple pour en faire quelque chose d'adéquat, ou le supprimer si dangereux).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]