Le weblog entièrement nu

Just an update about sgeps, because it seems to have made a small stir (which is more than I expected).

• Yes, I know about emacs foo.gpg. Admittedly I found out while I was “developing” sgeps, but I kept on my track anyway. The real reason was that I was having fun, but I could also mention that sgeps doesn't store data unencrypted on disk, not even temporarily. I'm not sure about vim foo.gpg. (Update: Joey Hess telle me it does the right thing.) Anyway, I don't want to fire up an editor (or switch to an already opened one) just to get a password.
• I had also found out about pwman too. My script started as pwman.pl but it was renamed later. I like the simplicity of sgeps better, especially the lack of any UI besides the CLI, but pwman is probably good in its own way, but it doesn't fit my usage pattern.
• It seems the Gentoo people don't share my qualms about making very small packages, and apparently sgeps is now packaged for Gentoo Linux.
• Mehdi Dogguy already contributed suggestions (including better error handling) and even a patch implementing sgeps --delete. Thanks to him!
• An anonymous commenter suggests that sgeps should be able to store notes as well as passwords. That wasn't a requirement I initially had, but I won't reject the patch if it comes… He also argues that it should be able to push the password into the X11 paste buffer. Again, why not, if it doesn't break anything.

I've been accumulating passwords recently. More than I could remember all in one go. I even got worried that I'd locked myself out of one of my own servers recently. So I decided to play it safe and store the passwords somewhere. However, plain text files, even on an encrypted disk, aren't the most secure plan, so I tried to go shopping for a tool that would store passwords in encrypted files and wouldn't be too inconvenient to use. I found a few (pwsafe, keysafe, keepassx, yapet and so on), but they all seem to be either graphical or using their own encryption scheme and (presumably) storage format. Being rather nervous about long-term data accessibility, I thus decided to roll my own script, that would be as simple as possible while doing just the required amount of work.

I call the result sgeps, for “simple GnuPG-encrypted password store”. Note the initial s: I didn't invent any wheel.

• Data model: a list of key/value pairs (each being a string);
• Storage: serialisation using Perl's built-in Storable module;
• Encryption: the serialised data is GnuPG-encrypted;
• Hopefully secure: no password stored in plaintext files at any time.

The code comments should give an idea of the capabilities of sgeps:

  # Usage: sgeps --create                     to create the store
  #        sgeps --add <key>                  to add a key/value to the store
  #        sgeps --list                       to list existing keys
  #        sgeps --add --overwrite <key>      to replace a key/value

I trust both GnuPG and Perl to stay around for quite some time, so hopefully I can forget even the passwords I use very rarely and still be able to recover them later. Even in the event of a hard drive dying, since the encrypted store can now be backed up and burnt on DVDs. I “just” need to be careful about my GnuPG key.

Interested people can grab sgeps from its Bazaar branch with bzr branch http://bzr.debian.org/users/lolando/sgeps/trunk/ or browse it on the web interface. I don't plan to make a Debian package for a hundred lines of Perl code, but if anyone is interested, feel free to include it in an existing package (moreutils maybe?).

News is slow this month on the FusionForge development front. We're all busy gathering all the things that we want to go into the next release, but there's no big news from the code. However, there is something of interest.

You may have heard about the Coclico project, which is an initiative aiming at collaboration and convergence between several forge engines, most notably FusionForge, Codendi and Novaforge. That project was started last October, and it holds regular meetings with its members. The next meeting is scheduled for the 2nd of February in Paris, and we thought we could host an open meeting on the 3rd for non-Coclico members, a bit like the forge meeting we had last year (which is when FusionForge was officially born), but with an emphasis on what Coclico did so far. Since most of the FusionForge hackers are in Western Europe, and several are in Paris (especially if we add those who go to Paris for the Coclico meeting), we thought it would also be a good opportunity to gather for a technical and social meeting.

It seems the Coclico open session didn't generate much interest this time (at least, it hasn't so far), so I proposed to hijack the room for this FusionForge meeting, and I didn't hear any objections. I have several themes I'd like to discuss with people, and possibly start implementing during that day:

• database maintenance and schema: unification of the upgrade scripts (including for plugins), cleanup of obsolete stuff, addition of missing constraints, and so on;
• configuration system: my initial prototype didn't raise many objections (at least in its scope), now what to do with the next steps?
• packaging and installation system: what needs to be done to keep the three ways of installation (manual, *.deb, *.rpm) in sync with as little work as possible?
• permissions system: clarification of what happens currently, ideas for evolution;
• plugins and interaction with external software: do we lack stuff that would make this easier?
• roadmap, long-term plans, this sort of things;
• other things that users may want to discuss with hackers?
• possibly drink a beer or two;

…and so on. These are in no way specific to FusionForge, and in fact I think it would be great if hackers/users of other forges were present, because we could benefit a great deal from their experience and plans. But if we find ourselves amongst FF people only, I think these would be good to discuss, possibly write some code for, and go home with a clearer picture of where our efforts should focus in the near future.

I'd therefore like to invite interested people to mark the 3rd of February on their agendas. The meeting will take place in Issy-les-Moulineaux (near Paris, within reach of the tube). If you're interested, please get in touch with us (#FusionForge on the FreeNode IRC network, or the fusionforge-general mailing-list), so we can have a rough estimate of how many people to expect. The meeting room is provided by France Télécom, and they're probably going to need numbers if not names. Further details will be announced when known.

Je rebondis sur un billet de l'excellent blog Signal, où l'auteur se plaint des procédures « de sécurité » bizarres d'un site marchand qu'il fréquente, et qui lui demande d'envoyer par courrier une photocopie de sa carte bleue pour valider un paiement par Internet. Il m'arrive une mésaventure assez similaire, sauf qu'elle ne se restreint pas à un site, et ça me chagrine fortement.

Je dispose d'une carte Visa, qui me permet notamment de régler mes achats dans les magasins que je visite, mais aussi théoriquement d'effectuer des paiements par Internet sur des sites de commerce électronique. En général, ça marche, mais depuis peu les sites qui se targuent d'être “Verified by Visa” me sont fermés. Parce que le site demande à ma banque si ma carte est bien valide, et que ma banque répond que non. Il fut un temps où la banque disait tout le temps que oui, puis la « sécurité » a été « renforcée », et son approbation est devenue conditionnée à ma capacité à répondre correctement à une question. Jusque-là, ça allait, c'était juste désolant parce que ça n'augmentait en rien la sécurité du système (la réponse à la question était facile à trouver pour tout pirate en herbe). Mais maintenant, la banque a pris une mesure énergique, et elle a décidé de n'accepter la transaction qu'après… une vérification par téléphone. Donc il faut, petit 1, que j'enregistre un numéro de téléphone chez eux, petit 2, que je reçoive sur ce téléphone un code de sécurité pour chaque transaction.

Je reprends : pour faire un paiement par Internet, j'ai maintenant besoin d'être joignable par téléphone. L'Internet… ne suffit plus.

Pour prévenir les procès d'intention : je ne râle pas uniquement parce que je n'ai pas envie de laisser traîner mon numéro de téléphone n'importe où (même si ça joue aussi). Je râle parce que je trouve débile d'imposer une restriction arbitraire et irréaliste sur une opération aussi courante en 2009 qu'un paiement sur un site marchand. Procédure de sécurité, OK, pourquoi pas, mais rien ne dit que je suis chez moi prêt à recevoir un appel. Rien ne dit non plus que j'ai un téléphone mobile, et même si j'en avais un, il y a encore en France des zones non couvertes par un réseau GSM, et où l'Internet est accessible quand même. Alors que si je suis en train de faire un paiement par Internet, où que je sois, j'ai forcément accès à Internet. Donc pourquoi ne pas me faire parvenir ce code de sécurité par ce biais ? Dans un e-mail, par exemple, ou sur le site sécurisé de gestion de mes comptes ? Ou pourquoi ne pas utiliser un système de codes préétablis, un peu comme les protections des jeux vidéo des années 80, genre quel est le troisième mot de la cinquième ligne de la page 18 d'un document qui n'a été communiqué qu'à moi ? Ou carrément un véritable dispositif sécurisé (genre un token RSA), comme ça se fait partout où les gens ont besoin de sécurité informatique et pas de farce ?

Bon, vous me connaissez, je râle facilement, donc j'ai contacté ma banque pour obtenir des précisions. J'ai pas été déçu du résultat. Ma question (après un exposé de ce que je viens de vous relater) : « et comment font les gens qui n'ont pas de téléphone sous la main ? » Première réponse : « oui, c'est pour augmenter la sécurité, donnez-moi votre numéro et je l'enregistre ». Non, merci, je veux justement m'en passer, parce que je ne suis pas forcément joignable par téléphone, répondez à la question siouplaît. Deuxième réponse, donc : « c'est une mesure imposée par Visa, et c'est tout ». Mes super-pouvoirs de geek (et des potes en qui j'ai tout lieu d'avoir confiance) me disent que c'est un gros mensonge, et que ce système est spécifique à ma banque. OK, je fais quoi maintenant ?

Maintenant, je cherche des alternatives, parce que les procédures « de sécurité » qui bloquent l'utilisation de ce qu'on cherche à sécuriser, ça ne correspond pas à l'idée communément admise de la sécurité des systèmes d'information, qui inclut, ne l'oublions pas, la confidentialité des données, leur intégrité, le contrôle d'accès, et la disponibilité du service. Si le service n'est plus disponible… la sécurité n'est pas là. Donc je suis preneur de toute information concernant des banques dont les informaticiens prennent en compte les contraintes des clients avant de développer des systèmes qui ne marchent pas. Par e-mail, ou sur carte postale, au choix.

Je note en passant que le système de carte bleue virtuelle (qui crée un numéro de carte à usage unique, et qui est censé pallier ce défaut) ne constitue pas une solution, parce que les gens qui ont mis en œuvre ce système pour ma banque n'ont pas jugé utile de m'autoriser à m'en servir, moi qui ai le mauvais goût de n'avoir ni Windows ni Mac OSX.

Quand j'étais étudiant (notamment en informatique), on ne parlait de l'informatique bancaire qu'à mi-voix, et avec l'immense respect dû aux gens qui font des systèmes quasi-invulnérables, avec des taux de disponibilité de 99,999 %, etc. Dans la vraie vie : le site de gestion de mes comptes est, parmi ceux que je fréquente, le deuxième site le plus fréquemment en carafe (celui de la SNCF est intouchable), je ne peux plus faire de paiements par Internet, je ne peux plus non plus faire de virements par Internet (il faut que je passe d'abord au guichet)… Je sais bien qu'on ne voit que les problèmes et pas le reste du temps quand tout fonctionne, mais quand même. Force est de constater que le mythe en a pris un sacré coup, et la tendance ne me semble pas en voie de renversement. Hélas.

I normally don't relay security announces for GForge or FusionForge on this blog, but I will make an exception this time: Alain Peyrat found several places in the code with insufficient input sanitizing, which can cause cross-site scripting vulnerabilities (CVE-2009-3303). It's been fixed in the 4.7 and 4.8 branches as well as the trunk of FusionForge (and in Debian Sid and Squeeze), and updated Debian packages for GForge 4.5 and 4.7rc2 have been released for users of the Etch and Lenny distributions.

The reason I make an exception for announcing this here is to remind people that I appear to be the only one maintaining code for GForge 4.5. I do that for two reasons: first, because I'm the maintainer of the package in Debian, and Debian Etch has GForge 4.5, and Etch is supported for security fixes; second, because I also admin/maintain an instance for a client of mine, so I need to backport the fixes anyway, and making them public is no bother. Both of these reasons are going to vanish sometime in the not too distant future: security support for Etch will end in February, 2010, and I hope to have migrated my client's forge to FusionForge 4.8 by then too. A direct consequence is that I will probably stop maintenance for GForge 4.5 in the coming months (at least I'll stop doing it in my free time).

So if you're still using GForge 4.5, you should really consider upgrading to something supported, either GForge AS (free download from the GForge Group) or FusionForge (free as in Free Software). Both have an upgrade path. Obviously I think FusionForge is a better choice, but my position is probably biased.

Note pour plus tard : quand à la suite de circonstances indépendantes de sa volonté on se retrouve avec une moto neuve, on a du rodage à faire. Au début, on va donc doucement, mais ensuite, on peut avoir l'impression de continuer à aller doucement, même quand on ne se limite plus aux plages de régime autorisées pendant les quelques premières centaines de kilomètres. Il convient donc, quand on retourne chez le gentil concessionnaire pour faire faire la révision de fin de rodage, de lui demander gentiment de vérifier s'il n'aurait pas malencontreusement omis d'enlever le bridage « jeunes permis » lors de la livraison de la moto.

Ce week-end, j'ai donc testé mon nouveau nouveau moteur. Et force est de constater que 85 chevaux, c'est mieux que 34. Quand en plus la route est belle et que la montagne d'automne est multicolore gris-vert-jaune-rouge…

This month hasn't seen many big changes happen in FusionForge. Notable improvements include an initial search engine for Word files, fixes to the automated builds and tests, and lots of bugfixes.

The biggest news is probably the start of the Coclico project, an initiative bringing together developers and users of several existing forges in order to reduce the gap (and ideally unify the codebase across the forks) and work together in some fields where cooperation is important. Subjects include a generalisation of the current identity/permission/authentication models and systems, data exchange and migration, interoperability, integration of agile development methods inside the forge, and better integration with the desktop applications such as IDEs. The participants include NovaForge, Codendi, and of course FusionForge. The project only officially started early this month, but we hope to be able to demonstrate results soon.

Business as usual apart from that.

Here's another round of the semi-regular bulletin about FusionForge.

First item: FusionForge 4.8.1 was released this week. It's not exactly an important update, but the 4.8 branch had been accumulating fixes over time and we felt that it would be good to push these fixes out. If you don't encounter particular problems, there's probably no need to upgrade in a hurry.

A follow-up for the rewrite of the SCM subsystem: I now consider the Bazaar and Git plugins complete. The missing part, in both cases, was a proper integration of a repository browser and the collection of commit statistics; since one of my clients wants to use Bazaar and another one wants Git, both features have been completed recently. The code still lives on a branch based off 4.8 (for people who need a 4.8-based instance), but it's also been pushed into trunk so the next release will have it natively.

Another branch I've been working on (for clients) was about making the Mediawiki plugin able to handle one wiki per project rather than one shared wiki. This is now possible with yet another 4.8-based branch, where the wiki creation is completely automated. A nice feature is that the FusionForge identification is used as a basis for Mediawiki, with different groups on the wiki depending on project membership and role in the forge. That allows specifying wiki permissions in a simple way, for instance to say that only project members can create new pages, authenticated users can only edit existing pages, and non-authenticated users are read-only. This code will be pushed to trunk in the coming weeks.

Thanks to Alain Peyrat, we now have a buildbot running Hudson for unit tests and a few other things. The coverage isn't complete yet, but we hope to increase it as time passes. It's already proven useful, by ensuring at least correctness of PHP syntax, encoding and line-endings.

I think that's about it for this time. Business as usual.

Pour ceux qui n'ont pas suivi : ma moto a servi de frein de secours à plus gros qu'elle, et elle est donc en voie de remplacement. Comme je vais reprendre la même mais en plus moderne, ça va être une moto neuve, donc soumise au nouveau système d'immatriculation des véhicules, qui n'est plus géographique mais national (et même européen, c'est dire). Chouette me disais-je, je vais pouvoir me débarrasser d'un numéro de département qui ne reflète pas grand-chose.

Eh ben non, apparemment cette indication de département reste obligatoire. On met ce qu'on veut, mais c'est obligatoire. Quelqu'un peut m'expliquer à quoi ça sert, du coup ? Et, accessoirement, quel a été le raisonnement derrière le choix de rendre obligatoire le fait de mettre un numéro quelconque qui ne représente rien ?

Mais surtout, se pose la question de ce que je vais y mettre. Y mets-je le numéro de là où j'habite actuellement ? Là où j'habitais quand j'étais petit ? Y a-t-il une convention déjà utilisée par les réfractaires ? Peut-être l'Ain (01), ou la Lozère ou la Creuse, peut-être, ou le Lot (département de Montcuq) ? Est-ce que je choisis un département au hasard ? Est-ce que je choisis le plus obscur possible ? Est-ce que je choisis un département d'Outre-Mer ? Est-ce que je choisis au hasard et que je change régulièrement ? Est-ce que j'y mets mon âge et que je le change chaque année ?

Vos suggestions sur carte postale ou par mail, merci.

Mise à jour : C'est plus la peine de me suggérer la Loire (42), ça a déjà été fait (plusieurs fois même).

Boulet le fait, Gally le fait, Mélaka le fait, Vinvin le fait, d'après mes calculs Maliki devrait pas tarder, et Thomas un peu après. C'est la saison de l'autosatisfecit, alors allons-y gaiement : youpi youpi tralala, ce blog a maintenant cinq ans (et il est toujours aussi ce-que-vous-voulez).

Au bout de cinq ans, je peux bien vous dire maintenant pourquoi je l'ai créé. Parce qu'on me pose la question, et que des fois on ne me la pose pas mais on prête des motifs fantaisistes. J'ai créé ce blog parce que (accrochez-vous) je suis une feignasse. Et qu'en août 2004, j'avais déjà dans l'idée de faire un tour du monde, et que je pressentais déjà que j'aurais la flemme d'envoyer des mails personnalisés à tout le monde. Avec un blog, y'a toujours besoin de raconter, mais une seule fois, et je pouvais ne faire des mails que ponctuellement. On me dira que le tour du monde n'est arrivé que plus d'un an après, mais j'avais prévu du temps pour me familiariser avec le machin (rigolez, rigolez, mais rappelez-vous qu'en 2004, les blogs, c'était encore un peu expérimental).

Depuis, y'a eu d'autres voyages, mais je me suis surtout servi de ce blog comme d'une chaise sur laquelle monter pour dire mes bêtises à qui voulait bien les entendre, avec des nouvelles de mon nombril et de ce à quoi j'occupe mes journées. Certains billets ont eu un peu de gloire, que je veux croire méritée (même si les données sont faussées par le nom de domaine, qui attire toutes sortes de fétichistes). D'autres sont restés dans l'obscurité qu'ils méritaient. Ni les uns ni les autres ne m'ont empêché de dormir, et je vais donc probablement continuer comme ça jusqu'à ce que j'en aie marre. Et comme le système de commentaires est habilement dissimulé derrière le « Contact » écrit en rouge, personne (ou presque) ne vient me courir sur le haricot, donc ça peut durer longtemps comme ça.

On verra bien si je tiens cinq ans de plus.