Le weblog entièrement nu

Another month, another update, but nothing spectacular to be announced in FusionForge-world. We're still working on finishing the transition to the new configuration system, we're testing the migration to a simpler and more flexible set of Apache configuration files, and work is in progress on the RPM packaging. And so on.

Possibly the most newsworthy item is the FusionForge presence at next month's Libre Software Meeting in Bordeaux (the “RMLL” in French). I'll do a FusionForge, one year and a half later talk summarising the status and progress of FusionForge, and there'll also be a *forge devroom where we'll mingle with people interested in all kinds of software forges. Come see us if you're around!

The usual semi-regular bits of news from the FusionForge project. We continue being quite active, with several hundred commits each month. The momentum doesn't seem to stop even after the 5.0 release last month. A large part of the activity stems from the Coclico project, which has several work-packages related to convergence of code across forges (mostly between FusionForge and Codendi). This convergence comes in three flavours:

• some new features are developed in common for both forges; as an example, the Mailman and ForumML plugins recently committed can now run unmodified in FusionForge and in Codendi (or at least that's the goal);
• some features existing only on the Codendi side are ported across to FusionForge; this includes the Codendi “widgets” system, which allow drag-and-drop customization of some of the web pages, and the Hudson plugin;
• finally, some of the core code is rewritten so that a common API and abstract data model can be used by higher-level pieces of code; the configuration system has been almost completely converted to a simple API, and the role-based access control system has also been rewritten into a clean model that extends both FusionForge's previous RBAC system and Codendi's, so each forge will provide new features for access control (the immediate gain for FusionForge is the ability to grant different permissions to anonymous visitors and to visitors that are logged in even if not members of the current project).

All in all, a fairly busy period for FusionForge. The current trunk is evolving rather fast, with some long-overdue rewrites being underway. Interesting times.

Résumé du week-end :

• Une cuisine qui ne me tombera plus sur la tête ;
• Pollution chimique dans ma rue (et les cheveux qui collent) ;
• Un sushi de 48 cm ;
• Guitar Hero avec Charles Ingalls ;
• La sieste à 500 m du bout du monde ;
• Une vitre de bar cassée ;
• La voix du fils caché de Fantômas et Barry White ;
• Encore une victoire de l'esprit sur la matière, et du tournevis sur l'aspirateur en plastoc (la machine à laver a pris son ticket, elle attendra son tour) ;
• Idée géniale en gestation (en collaboration avec Charles Ingalls) ;
• Et avec tout ça j'ai même eu le temps de prendre le soleil, dites-donc.

À part ça, la routine.

Fourteen months after the renaming of the Free/Open Source code of GForge 4.x to the new “FusionForge” name, we're pleased to announce version 5.0. As mentioned in the release notes, this is still an incremental step over version 4.8 rather than a revolution, but the changes are important enough, and numerous enough, that we felt it justified to bump the major version number.

Major improvements, beyond a host of bugfixes, include:

• a rewrite of the version control integration (with support for Bazaar, Darcs, Git and Mercurial in addition to the “traditional” CVS and Subversion);
• a much better integration of Mediawiki (one wiki, with its own set of permissions, per project);
• a cleaner database layer, more robust against SQL injections;
• configurable display for the trackers;
• more powerful tracker engine, with configurable workflows;
• a rework of the default theme, with better accessibility.

FusionForge 5.0 now also includes new plugins that were previously only “floating around” (or completely private):

• projectlabels gives a simple way of adding bits of HTML onto project description pages, so the forge admin can, for instance, highlight a “project of the month”;
• extratabs allows a project to define new tabs in its pages, pointing at external resources;
• globalsearch is a first step in the “federation of forges” concept, whereby a project search can be conducted on several forges at once;
• contribtracker allows a forge to prominently display major contributors to projects, to give them visibility beyond the simple commit logs.

These plugins, as well as a large part of the improvements in the trackers and the rewritten Mediawiki plugin, are a direct consequence of the “upstreaming” of work having been done in private instances of forges. We're happy to note that this goal of ours (to merge local patches into the central repository when it makes sense) seems to be working well. For the record, this 5.0 release includes work and plugins that were reintegrated from sources such as Alcatel-Lucent, Adullact and AdaCore.

This release is also the first to have had the benefit of automated testing during the whole cycle. Coverage isn't 100 % yet, but the existing unit tests and functional tests help us be confident in the quality of the release. We'll keep adding more tests as time passes, of course.

Looking back at the initial goals stated when the project started, we seem to be on the right track:

• stable release pushed out: check (this is the third one, not counting minor releases);
• new plugins merged: check;
• automated testing: check;
• external contributions merged: check;
• explicit governance model and release process: sort-of (there's still a cabal, but it's partially documented).

We still need to work on the database schema and the cross-distro part, as well as cross-forge interoperability. The good news is that work is happening on these fronts already. And with almost 2500 commits, we truly seem to have accomplished at least one of the (implicit) goals: to bring development back to a healthy state. And we're far from being out of ideas for the future, so there's a lot of good stuff still cooking!

Here's another quick update on the status of FusionForge.

We released version 4.8.3. Nothing earth-shattering, but a collection of bugfixes that had accumulated on the 4.8 branch. If you're running a patched version, you might want to merge.

We also published the second release candidate for 5.0. It's not final yet (there have been a few commits on that branch since then), but we're running out of known bugs. We're currently down to zero open bugs targeting 5.0, so the actual release is probably going to happen in a matter of days. 5.0rc2 is currently available in Debian experimental for those who want to test it, and the final 5.0 will be uploaded to unstable, and hopefully migrate to Squeeze in due time.

Stay tuned…

This is getting old news, and others have blogged about them before I did, but here's my summary of the recent activity in and around FusionForge.

The early February meeting was a success, and gathered about twenty people on the first day and a dozen or so on the second day (not planned initially). My impression is that there was a healthy mix of FusionForge hackers, FusionForge users, and people from other forge communities (Codendi, NovaForge, and even one representative from nFORGE, from South Korea). I'm not going to repeat all that was said then, especially since the proceedings are online. Beyond the technical points, I'll just advertise PlanetForge again, since everyone present agreed we had lots to share and that this site would be a good and relatively neutral place. If you're into forges, I recommend joining us in that community.

On the purely FusionForge front, news are good too. Most of the major pieces we want to see in the next release (which is probably going to be called 5.0) are in place. The last blocker we had was the merge of the rework of the default theme for better accessibility and easier maintenance and customisability (most of the theming now happens in CSS). This merge has been completed this week, and although there are still a few rough edges, it's mostly done. We'll try to fix most of these rough edges soonish, then start a stabilisation branch towards 5.0, so more experimental work can start again on trunk. For the impatient and the curious, there's a list of new features on the fusionforge.org homepage, and the site is now running code from trunk.

Of course, we're eager to get testers for that, which is why I prepared snapshot packages. They are currently stuck in NEW on their way to the official Debian experimental repository due to the renaming of the source package and the introduction of plenty of new binary packages, but they can already be obtained from my unofficial repository at people.debian.org. The packages are built for Debian unstable, but they seem to run just fine on Lenny if you grab mediawiki from backports.org (only required for the Mediawiki plugin, of course), and libnusoap-php and php-htmlpurifier from Debian testing (they don't drag any extra dependencies).

I'll end this note by reminding people of the announcement I did three months ago: as of this week, Debian Etch is no longer officially supported security-wise, and so neither is GForge 4.5. As far as I know, I was the last person doing that, and my incentives have gone away on the day Etch ceased to be supported, since it was also the day the Adullact forge finally migrated from Etch with GForge 4.5 to Lenny with FusionForge 4.8. If you're still using 4.5, well… I think you should be aware of that.

That more or less wraps it up for now. The next announcement is likely to be about a release candidate…

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.