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.

Update: sgeps now has its dedicated page at SGEPS.

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?).

Update: sgeps now has its dedicated page at SGEPS.

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.