Les keyrings/keychains/autres sont supportés par tous les OS majeurs (KWallet pour kde, Gnome Keyring pour gnome, Keychain pour mac os, Windows's Vault pour doz). Le problème c'est que nos logiciels libres cross-plateforme ne les supporte pas (Firefox dans ton cas).
Ces keyring résolvent très bien le problème d'accéder à ses mots de passe rapidement sur la machine (voir le niveau d'intégration du keychain dans mac os ou du kwallet dans kde) mais ils deviennent nuls dès qu'on a besoin d'y accéder depuis un autre PC. Du coup, on doit passer par d'autres choses comme keypassx qui permet de stocker sur une clé usb ses mots de passe.
Le problème de keypassx, c'est que si tu perds ta clé, tu perds tes mots de passe. Si tu gardes des copies, locales, tu sais pas si elles sont à jour. Il faut donc du versionnement. Le top serait une sorte de git pour mots de passe, totalement décentralisable et mergeable à souhait !
C'est pour combler ces problèmes que j'ai commencé le projet PPassKeeper en 2008. C'est une lib cross-plateforme pour abstraire le stockage/récupération de mot de passe ou tout autre secret.
Quand un programme cross-plateforme linke avec PPassKeeper, il laisse à l'utilisateur le choix du lieu de stockage de ses mots de passe. En effet, PPassKeeper (ppk pour les intimes) est basé sur une architecture modulaire qui permet aux utilisateur de choisir quel module va se charger du stockage du mot de passe. Tout est documenté.
Pour l'instant, seuls le kwallet et le gnome keyring sont supportés, le support du keychain et du vault arriveront dans la beta 3.
Avec ppk, on solve le problème des programmes open sources qui stockent les mots de passes n'importe comment (stockage dans un fichier en clair pour pidgin par exemple) et on centralise les mots de passe de tous les programmes en un seul lieu (celui que l'user veut).
Reste le problème de l'accès à distance aux mots de passe. Pour ça, je suis en train de développer mon propre keyring (je suis élève-ingénieur en sécurité informatique, j'ai quelques notions en crypto) qui supportera très bientôt un système de centralisation (sur un ftp) et plus tard, sera un système décentralisé(miam miam pour coder ça). Ce keyring ainsi que la version centralisée sera dispo dans la beta 3).
Toujours dans la catégorie 'en prévision', il faut réaliser l'intégration de ppk dans les programmes.
Pidgin n'expose actuellement pas aux plugins d'API permettant de stocker les mots de passe. Une personne a proposé l'utilisation de ppk directement, perso, je m'en fou tant que je peux développer un plugin qui hookera le stockage de mot de passe. Ces changements sont prévus pour pidgin 3.
Reste Firefox/chromium. On a vu que c'était possible car beaucoup le font, j'espère qu'il y en a des open sources pour pouvoir forker ça et modifier simplement le back-end pour ppk.
D'ailleurs, je profite de ce journal pour lancer un appel aux contributions. Je suis actuellement l'unique programmeur de ce projet. Un ami donne des coups de mains, surtout sur le binding python. D'autres personnes me donnent leurs avis et souhaits mais si vous voulez voir ppk dans vos distribs, il va encore falloir un max de boulot.
On a actuellement besoin de graphistes, d'évangélisateurs pour faire connaître le projet et recueillir les remarques des programmeurs pour avoir l'API la plus consistante possible avant le freeze de la version 1.0 et de programmeurs en tout genre (pour créer des plugins pour les applis, faire/hacker de nouveau modules de stockage, hacker le coeur).
Les repos ont été mis à jour il y a quelques heures.
Je tourne dessus depuis la rc3, c'est dingue le niveau d'intégration que propose KDE. Je suis toujours pas fan de l'interface mais on ne peut pas dire que c'est l'interface utilisateur la plus développée de Linux, et même que Windows ou Mac OS X (c'est que mon avis).
Je suis au courant de ça, mais le travail n'avance pas et je trouve l'approche mauvaise. Faire une API D-Bus, c'est fondamentalement pas vraiment multi-plateformes.
Ici, on a un système de greffons et une bibliothèque qui se charge d'abstraire le stockage des secrets.
Ici, le beta n'est pas très bien approprié, en fait, ça aurait dû être une alpha. Cependant, j'ai fais l'erreur d'appeler la précédente version beta1, je suis donc obligé de l'appeler beta 2 :s
C'est de l'alpha car l'API n'est pas vraiment stable et n'est pas complet au niveau des fonctionnalités.
J'ai besoin d'aide pour vérifier que tout va bien pour pouvoir freezer l'API. Ce gel arrivera avec les versions release candidate.
J'avouerai avoir eu du mal à comprendre ce que tu disais :D
En effet, c'est dommage de bloquer IE. Sur mon site, je sais qu'IE ne passe pas (même le 8) alors qu'il est conforme XHTML strict 1.0 et CSS 3 et donne le même résultat sur Firefox et Webkit, cependant, je laisse quand même IE venir.
Il y a plus important dans la vie que le style CSS d'un site, son contenu par exemple :D
Cet épisode est à propos d'un drone qui peut lire dans les pensées des gens et neutraliser les gens avant qu'ils ne tuent. Bien sur, à la fin, ça fini mal mais plus par excès de confiance des politiques dans le système que part un problème technique.
Je vais voir pour avoir la version 1.7 en parallèle.
Cela dit, y'a pas marqué que c'est simplement la version 1.7 qui marche. Il faut 1.7 ou supérieur.
Possible que ce soit simplement le test qui chie car si ils testent ça simplement comme une chaîne de caractère, normal que ça chie. Je regarderai ce soir.
Je voulais pas lancer de troll, mais je pensais justement à ça. Même pour un petit projet, c'est pas maintenable
GNU a fait beaucoup de choses pour le libre, énormément, mais rarement du code de qualité ou des choses réellement utilisables.
Franchement, je ne cracherai pas dessus car c'est vraiment des choses vraiment géniales qu'ils font, mais c'est souvent trop limité à une élite. Autotools, c'est une tonne de constantes magiques, de macro affreuses (les macros, c'est le mal !), des fichiers partout et 3 à 4 commandes à lancer avant de pouvoir profiter du configure.
Comment être sur de comprendre ce qu'on fait ?
Pour en revenir au sujet, je vois mal Gtk utiliser autre chose qu'autotools. M'enfin, c'est quand même chiant qu'on ne puisse pas compiler sur un OS à jour (ArchLinux).
Bon, je ne dirai rien sur le niveau de cradocité du système de build de gtk.
Arriver à me dire que la dépendance automake 1.7 n'est pas respectée quand j'ai automake 1.11, c'est toujours marrant :d.
Encore merci pour la news, je vais faire marcher le truc et voir ce que ça donne.
En fait, vu que le 2.6.31rc3 vient de sortir, je me suis re-décidé à tester le KMS avec radeon.
Ça marchait avant, mais niveau stabilité, j'ai eu vu mieux.
Tant qu'à y être, ça m'intéresse de tester ce que donnerai la dernière version de GTK+ vu qu'on peut les faire cohabiter.
Je dois modifier quelle variable d'environnement pour lui dire d'utiliser la version dans /usr/local ?
Petite précision, je suis bien développeur, mais pas du projet ni de quoi que ce soit dans la stack graphique. Je me tiens juste très informé dessus car ça m'intéresse vraiment :)
Ça pourrait bien faire l'objet d'une dépêche, tout comme Gallium3D.
Wayland est petit serveur graphique qui n'implémente pas le protocole X11, il est développé par Kristian Hogsberg travaillant pour red hat.
Ce petit projet est prometteur car il est très léger (destiné aussi bien aux embedded Linux qu'aux ordinateurs de bureau), se base sur les dernières avancés graphiques KMS/DRI2/EAGLE/GEM et aussi car le projet complet se limite à moins de 5000 lignes pour l'instant.
Pour le champ d'application du système, le but premier serait d'abolir de changement de TTY pour effectuer un changement de TTY. On pourrait imaginer un cube qui passerait d'un utilisateur à un autre à la demande :). C'est possible car Wayland supporte de lancer plusieurs serveur X11 en mode root-less.
Pour l'instant, seul clutter a un backend Wayland, mais maintenant, rien n'empêche Gtk d'être porté. Qt software est aussi intéréssé par le projet et le port est normalement déjà en cours. Quand ces ports seront réalisés, on peut imaginer laisser tomber le serveur X et utiliser n'importe quel bureau classique sur nos systèmes Linux.
Petite précision, je ne suis pas développeur de la chose, très peu de monde arrive à tester ça et je n'ai malhreusement pas le matos requis pour l'instant :s Je ne fais que traduire les informations que j'ai eu et ce que j'en ai compris. À mon gout, la révolution est en marche :)
C'est possible, y'en a même des tonnes :
- gaupol
- subtitleeditor
- gnome-subtitles
- ksubtile
- ...
J'ai juste prit quelques éléments de la liste fournie par la commande `yaourt subtitle`sous ArchLinux.
J'ai déjà due subber une vidéo, j'avais pas eu de problème mais je me souviens plus du nom du programme ...
# Bientôt dans PPassKeeper
Posté par Martin Peres (site web personnel) . En réponse au journal Stockage des mots de passe. Évalué à 6.
Ces keyring résolvent très bien le problème d'accéder à ses mots de passe rapidement sur la machine (voir le niveau d'intégration du keychain dans mac os ou du kwallet dans kde) mais ils deviennent nuls dès qu'on a besoin d'y accéder depuis un autre PC. Du coup, on doit passer par d'autres choses comme keypassx qui permet de stocker sur une clé usb ses mots de passe.
Le problème de keypassx, c'est que si tu perds ta clé, tu perds tes mots de passe. Si tu gardes des copies, locales, tu sais pas si elles sont à jour. Il faut donc du versionnement. Le top serait une sorte de git pour mots de passe, totalement décentralisable et mergeable à souhait !
C'est pour combler ces problèmes que j'ai commencé le projet PPassKeeper en 2008. C'est une lib cross-plateforme pour abstraire le stockage/récupération de mot de passe ou tout autre secret.
Quand un programme cross-plateforme linke avec PPassKeeper, il laisse à l'utilisateur le choix du lieu de stockage de ses mots de passe. En effet, PPassKeeper (ppk pour les intimes) est basé sur une architecture modulaire qui permet aux utilisateur de choisir quel module va se charger du stockage du mot de passe. Tout est documenté.
Pour l'instant, seuls le kwallet et le gnome keyring sont supportés, le support du keychain et du vault arriveront dans la beta 3.
Avec ppk, on solve le problème des programmes open sources qui stockent les mots de passes n'importe comment (stockage dans un fichier en clair pour pidgin par exemple) et on centralise les mots de passe de tous les programmes en un seul lieu (celui que l'user veut).
Reste le problème de l'accès à distance aux mots de passe. Pour ça, je suis en train de développer mon propre keyring (je suis élève-ingénieur en sécurité informatique, j'ai quelques notions en crypto) qui supportera très bientôt un système de centralisation (sur un ftp) et plus tard, sera un système décentralisé(miam miam pour coder ça). Ce keyring ainsi que la version centralisée sera dispo dans la beta 3).
Toujours dans la catégorie 'en prévision', il faut réaliser l'intégration de ppk dans les programmes.
Pidgin n'expose actuellement pas aux plugins d'API permettant de stocker les mots de passe. Une personne a proposé l'utilisation de ppk directement, perso, je m'en fou tant que je peux développer un plugin qui hookera le stockage de mot de passe. Ces changements sont prévus pour pidgin 3.
Reste Firefox/chromium. On a vu que c'était possible car beaucoup le font, j'espère qu'il y en a des open sources pour pouvoir forker ça et modifier simplement le back-end pour ppk.
D'ailleurs, je profite de ce journal pour lancer un appel aux contributions. Je suis actuellement l'unique programmeur de ce projet. Un ami donne des coups de mains, surtout sur le binding python. D'autres personnes me donnent leurs avis et souhaits mais si vous voulez voir ppk dans vos distribs, il va encore falloir un max de boulot.
On a actuellement besoin de graphistes, d'évangélisateurs pour faire connaître le projet et recueillir les remarques des programmeurs pour avoir l'API la plus consistante possible avant le freeze de la version 1.0 et de programmeurs en tout genre (pour créer des plugins pour les applis, faire/hacker de nouveau modules de stockage, hacker le coeur).
Le site du projet: http://ppasskeeper.mupuf.org , hébergé par http://mupuf.org/ .
[^] # Re: KDE 4.4 déjà sur ArchLinux
Posté par Martin Peres (site web personnel) . En réponse à la dépêche KDE SC 4.4 est sorti. Évalué à 3.
# Petit problème dans le lien vers le communiqué
Posté par Martin Peres (site web personnel) . En réponse à la dépêche KDE SC 4.4 est sorti. Évalué à 4.
# KDE 4.4 déjà sur ArchLinux
Posté par Martin Peres (site web personnel) . En réponse à la dépêche KDE SC 4.4 est sorti. Évalué à 5.
Je tourne dessus depuis la rc3, c'est dingue le niveau d'intégration que propose KDE. Je suis toujours pas fan de l'interface mais on ne peut pas dire que c'est l'interface utilisateur la plus développée de Linux, et même que Windows ou Mac OS X (c'est que mon avis).
Vous en pensez quoi ?
[^] # Re: Très interressant !
Posté par Martin Peres (site web personnel) . En réponse à la dépêche PPassKeeper, bibliothèque d'abstraction de stockage de données sensibles, passe en bêta 2. Évalué à 3.
Ici, on a un système de greffons et une bibliothèque qui se charge d'abstraire le stockage des secrets.
C'est bien mieux, non ?
[^] # Re: Très interressant !
Posté par Martin Peres (site web personnel) . En réponse à la dépêche PPassKeeper, bibliothèque d'abstraction de stockage de données sensibles, passe en bêta 2. Évalué à 2.
C'est de l'alpha car l'API n'est pas vraiment stable et n'est pas complet au niveau des fonctionnalités.
J'ai besoin d'aide pour vérifier que tout va bien pour pouvoir freezer l'API. Ce gel arrivera avec les versions release candidate.
# Magie des snapshots !
Posté par Martin Peres (site web personnel) . En réponse au journal Btrfs : idées d'application des snapshots inscriptibles. Évalué à 3.
[^] # Re: Quelle bande d'arriérés...
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Interview de S.P.Zeidler, administratrice système de la Fondation NetBSD. Évalué à 4.
En effet, c'est dommage de bloquer IE. Sur mon site, je sais qu'IE ne passe pas (même le 8) alors qu'il est conforme XHTML strict 1.0 et CSS 3 et donne le même résultat sur Firefox et Webkit, cependant, je laisse quand même IE venir.
Il y a plus important dans la vie que le style CSS d'un site, son contenu par exemple :D
[^] # Re: C'est juste pour le fun…
Posté par Martin Peres (site web personnel) . En réponse à la dépêche [Droneries] EMAV 2009. Évalué à 3.
Un petit lien: http://fr.wikipedia.org/wiki/Masters_of_Science_Fiction
Cet épisode est à propos d'un drone qui peut lire dans les pensées des gens et neutraliser les gens avant qu'ils ne tuent. Bien sur, à la fin, ça fini mal mais plus par excès de confiance des politiques dans le système que part un problème technique.
# ArchLinux
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Exploit local dans le noyau Linux 2.6.30. Évalué à 4.
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 2.
Cela dit, y'a pas marqué que c'est simplement la version 1.7 qui marche. Il faut 1.7 ou supérieur.
Possible que ce soit simplement le test qui chie car si ils testent ça simplement comme une chaîne de caractère, normal que ça chie. Je regarderai ce soir.
Bonne journée aux moules
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 3.
GNU a fait beaucoup de choses pour le libre, énormément, mais rarement du code de qualité ou des choses réellement utilisables.
Franchement, je ne cracherai pas dessus car c'est vraiment des choses vraiment géniales qu'ils font, mais c'est souvent trop limité à une élite. Autotools, c'est une tonne de constantes magiques, de macro affreuses (les macros, c'est le mal !), des fichiers partout et 3 à 4 commandes à lancer avant de pouvoir profiter du configure.
Comment être sur de comprendre ce qu'on fait ?
Pour en revenir au sujet, je vois mal Gtk utiliser autre chose qu'autotools. M'enfin, c'est quand même chiant qu'on ne puisse pas compiler sur un OS à jour (ArchLinux).
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 2.
Arriver à me dire que la dépendance automake 1.7 n'est pas respectée quand j'ai automake 1.11, c'est toujours marrant :d.
Encore merci pour la news, je vais faire marcher le truc et voir ce que ça donne.
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 1.
Je m'occupe de ça dès que mesa daignera bien recompiler :)
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 1.
Ça marchait avant, mais niveau stabilité, j'ai eu vu mieux.
Tant qu'à y être, ça m'intéresse de tester ce que donnerai la dernière version de GTK+ vu qu'on peut les faire cohabiter.
Je dois modifier quelle variable d'environnement pour lui dire d'utiliser la version dans /usr/local ?
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 3.
Je vais voir pour en faire un par semaine, ça a de quoi motiver :)
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 6.
http://groups.google.com/group/wayland-display-server/web/fr(...)
Petite précision, je suis bien développeur, mais pas du projet ni de quoi que ce soit dans la stack graphique. Je me tiens juste très informé dessus car ça m'intéresse vraiment :)
Ça pourrait bien faire l'objet d'une dépêche, tout comme Gallium3D.
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 9.
Ce petit projet est prometteur car il est très léger (destiné aussi bien aux embedded Linux qu'aux ordinateurs de bureau), se base sur les dernières avancés graphiques KMS/DRI2/EAGLE/GEM et aussi car le projet complet se limite à moins de 5000 lignes pour l'instant.
Pour le champ d'application du système, le but premier serait d'abolir de changement de TTY pour effectuer un changement de TTY. On pourrait imaginer un cube qui passerait d'un utilisateur à un autre à la demande :). C'est possible car Wayland supporte de lancer plusieurs serveur X11 en mode root-less.
Pour l'instant, seul clutter a un backend Wayland, mais maintenant, rien n'empêche Gtk d'être porté. Qt software est aussi intéréssé par le projet et le port est normalement déjà en cours. Quand ces ports seront réalisés, on peut imaginer laisser tomber le serveur X et utiliser n'importe quel bureau classique sur nos systèmes Linux.
Petite précision, je ne suis pas développeur de la chose, très peu de monde arrive à tester ça et je n'ai malhreusement pas le matos requis pour l'instant :s Je ne fais que traduire les informations que j'ai eu et ce que j'en ai compris. À mon gout, la révolution est en marche :)
# À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par Martin Peres (site web personnel) . En réponse au journal Gtk+ client side windows merge. Évalué à 3.
[^] # Re: Obi-Wan Kenobi
Posté par Martin Peres (site web personnel) . En réponse au sondage Ma disposition de clavier pour visiter Linuxfr.org est :. Évalué à 5.
Comment tu fais ces écritures ? ça marche aussi avec ceux qui n'ont pas de vrai OS totalement en UTF8 ?
# Super !
Posté par Martin Peres (site web personnel) . En réponse à la dépêche ext3 est mort ? Vive ext4 !. Évalué à 7.
Petit problème cependant à la ligne :
ReiserFS 3 8 Tbyte 6 Tbyte
Vous vouliez dire 16 à la place de 6 ?
Voilà, encore merci
# Tarif unique des livres ?
Posté par Martin Peres (site web personnel) . En réponse au journal Que les francais, qu'ils aiment les artistes ... francais. Évalué à 3.
J'ai jamais vu ça personnellement cela dit :s
[^] # Re: Gains de performance
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 2.
J'attend que Arch Linux sorte le paquet pour GCC 4.4 pour me recompiler toute mon architecture graphique !
# J'en connais un qui va plus pouvoir poster pendant quelques temps
Posté par Martin Peres (site web personnel) . En réponse au journal J'aime Debian. Évalué à 6.
Sachant que tu as un tout petit proco, pourquoi utiliser https ?
[^] # Re: traduction de vidéos
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Nouvelle version d'EKD pour Linux. Évalué à 3.
- gaupol
- subtitleeditor
- gnome-subtitles
- ksubtile
- ...
J'ai juste prit quelques éléments de la liste fournie par la commande `yaourt subtitle`sous ArchLinux.
J'ai déjà due subber une vidéo, j'avais pas eu de problème mais je me souviens plus du nom du programme ...
Bonne recherche