It's been six months since Xfce 4.10 has been released. And it's been four months since Wheezy is frozen. Due to this timing (and the fact Squeeze has 4.6 and doing a 4.6 → 4.10 upgrade needed some tuning in various packages), it was decided to not try to push 4.10 into Wheezy that late in the release cycle.

So Xfce 4.10 was uploaded to experimental instead, and as it needs a full rebuild of all panel plugins against 4.10 panel (another reason for not trying to push it to Wheezy), those have not been uploaded. You can try Xfce 4.10 using experimental, but you'll need to remove the xfce4-goodies metapackage and the various depending plugin (since they'll just crash if you try to load them on 4.10 panel).

Multiple people asked me (either on IRC, by private or public mail) when 4.10 will be uploaded to unstable and transition to testing. Like last time, the answer is : not before Wheezy is released. Right now, we're more interested in stabilizing Wheezy and squashing the bugs there than adding new ones in unstable.

So, if you want to have Xfce 4.10 in Debian sid/testing sooner, then the easiest and fastest way is to fix some release critical bugs so we can release sooner, and then start breaking sid by uploading a whole lot of new stuff there.

Note that this is true also for other software like GNOME, KDE stack (I have no idea how to call it these days), the Linux kernel, strongswan or whatever.

About development releases of Xfce 4.11 (like the recently released exo 0.9 and Thunar 1.5), well, since we already use experimental for 4.10, there's not much chance they get uploaded anytime soon. We could try to package them and let people build it themselves, or I could host it somewhere on my server for people to try. But as I already said, we're more interested in fixing bug in Wheezy right now, and people interested in finding bugs in Xfce development releases (so they are fixed for the final one) should build it themselves and report everything they find on the Xfce bugzilla.

TL;DR: if you care about new, shiny stuff, please help fixing RC bugs in Wheezy.

Ce soir, en prenant le métro pour rentrer à la maison, je suis tombé là dessus, qui trainait par terre :

Pour les moins parisiens ou les plus jeunes d'entre nous, c'est un ticket de métro parisien d'il y a pfiou, des années. C'est le premier que j'ai connu, et j'ai fait un paquet d'accordéons en ticket de métros avec ceux là (je sais pas si maman a osé jeter ceux que je lui avais offerts). Apparemment il a été en production de 1976 à 1992.

Le plus étonnant dans l'histoire, c'est qu'il a visiblement été composté hier, ce qui veut dire qu'il a été conservé dans de bonnes conditions et qu'il était encore correctement magnétisé.

Ça m'a filé un sacré coup de nostalgie, n'empêche.

A friend of mine recently reminded me of the OpenPGP smartcard v2, and told me that it was perfectly able to handle 4096 bit RSA keys (provided you have GnuPG v2.0.18+). I had the opportunity to play with one a little, and notice it was super easy to use it for ssh authentication, especially since I already use gpg-agent as my ssh-agent (it should be easy to use a purely software authentication key as ssh key with GnuPG 2.1). So I decided to buy two of them and try to switch my main key (0x71ef0ba8) to it.

The cards arrived this weekend, and I was able to play with it a little. I didn't log every command I typed, but it was pretty easy, in the end. What I decided to do was to use one smartcard for every day usage, and one only for key signing. So basically, I would generate three (signing, encryption, authentication) subkeys, put them on smartcard 1, then put the primary key on smartcard 2. Then erase the private parts, and only keep them on smartcards.

In case it interests people, here the somehow detailed steps. Note that everywhere 'gpg' means 'gpg2' on Debian, we really need GnuPG v2 for correct smartcard handling. You'd better use gpg-agent too, although it doesn't seem mandatory.

1. make a backup! As we're gonna play with private parts (!), it's always a good idea to have backups. And it'll be useful to have one later, in case there's a problem with the smartcards. You can do a copy of your complete ~/.gnupg folder, but I simply did:

   corsac@scapa: umask 066
   corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
   

2. Add three subkeys. Skip this is you already have subkeys (you usually already have an encryption subkey, but I wanted to switch to a new one too) --expert is needed in order to chose capabilities.

   corsac@scapa: gpg --expert --edit-key 71ef0ba8
   gpg> addkey
   Please select what kind of key you want:
      (3) DSA (sign only)
      (4) RSA (sign only)
      (5) Elgamal (encrypt only)
      (6) RSA (encrypt only)
      (7) DSA (set your own capabilities)
      (8) RSA (set your own capabilities)
   Your selection? 8
   
   Possible actions for a RSA key: Sign Encrypt Authenticate 
   Current allowed actions: Sign Encrypt 
   
      (S) Toggle the sign capability
      (E) Toggle the encrypt capability
      (A) Toggle the authenticate capability
      (Q) Finished
   
   Your selection? e
   
   Possible actions for a RSA key: Sign Encrypt Authenticate 
   Current allowed actions: Sign 
   
      (S) Toggle the sign capability
      (E) Toggle the encrypt capability
      (A) Toggle the authenticate capability
      (Q) Finished
   
   Your selection? Q
   RSA keys may be between 1024 and 4096 bits long.
   What keysize do you want? (2048) 
   Requested keysize is 2048 bits
   Please specify how long the key should be valid.
            0 = key does not expire
           = key expires in n days
         w = key expires in n weeks
         m = key expires in n months
         y = key expires in n years
   Key is valid for? (0) 1y
   Key expires at dim. 27 oct. 2013 20:38:44 CET
   Is this correct? (y/N) y
   Really create? (y/N) y
   We need to generate a lot of random bytes. It is a good idea to perform
   some other action (type on the keyboard, move the mouse, utilize the
   disks) during the prime generation; this gives the random number
   generator a better chance to gain enough entropy.
   

   Repeat this for encryption and authentication subkeys. Then save and send the key to keyservers

   gpg> save
   corsac@scapa: gpg --send-keys 71ef0ba8
   

3. Next, we'll switch to the smartcard part. I use a Gemalto PC ExpressCard reader which is perfectly recognized under Debian. You just need few tools:

   root@scapa: ~# apt-get install pcscd scdaemon
   

   Plug the reader, insert the card, make sure it's detected:

   corsac@scapa: gpg --card-status
   Application ID ...: D2760001240102000005000016A10000
   Version ..........: 2.0
   Manufacturer .....: ZeitControl
   ...
   

   You can edit various parameter (name etc.) and change the PINs using gpg:

   corsac@scapa: gpg --change-pin
   corsac@scapa: gpg --card-edit
   

4. Then we'll put the subkeys in the first smartcard. It might be a good idea to export again the private keys for backups.

   corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
   

5. We'll now use the keytocard gpg command to move the private parts on the smartcard:

   corsac@scapa: gpg --edit-key 71ef0ba8
   gpg> key 1 # select encryption subkey
   gpg> keytocard
   gpg> key 2 # select signature subkey
   gpg> keytocard
   gpg> key 3 # select authentication subkey
   gpg> keytocard
   gpg> save
   

   A quick check on the card now reveals that it's populated:

   corsac@scapa: gpg --card-status
   Application ID ...: D2760001240102000005000016A10000
   Version ..........: 2.0
   Manufacturer .....: ZeitControl
   Serial number ....: 000016A1
   Name of cardholder: Yves-Alexis Perez
   Language prefs ...: fr
   Sex ..............: unspecified
   URL of public key : http://www.corsac.net/71ef0ba8.asc
   Login data .......: corsac
   Signature PIN ....: forced
   Key attributes ...: 2048R 2048R 2048R
   Max. PIN lengths .: 32 32 32
   PIN retry counter : 3 3 3
   Signature counter : 7
   Signature key ....: 9745 B022 7323 81FE 9E7E  AFF5 6DDB 53F2 A675 C0A5
         created ....: 2012-10-27 11:24:07
   Encryption key....: F7E0 078F EA1A 5F23 92E0  20B3 A83A D136 D98D 0D9F
         created ....: 2012-10-27 11:27:01
   Authentication key: 8CFD D478 AB4A 16F8 F0EC  CD33 24E2 3B5C CC0E 273D
         created ....: 2012-10-17 14:29:18
   General key info..: pub  2048R/A675C0A5 2012-10-27 Yves-Alexis Perez 
   sec>  4096R/71EF0BA8  created: 2009-05-06  expires: never     
                         card-no: 0005 000016A2
   ssb   4096g/36E31BD8  created: 2009-05-06  expires: never     
   ssb>  2048R/CC0E273D  created: 2012-10-17  expires: 2013-10-27
                         card-no: 0005 000016A1
   ssb>  2048R/A675C0A5  created: 2012-10-27  expires: 2013-10-27
                         card-no: 0005 000016A1
   ssb>  2048R/D98D0D9F  created: 2012-10-27  expires: 2013-10-27
                         card-no: 0005 000016A1
   

6. At that point, the private part is replaced by a stub in the secret keyring, so when you export them, you only export stubs which you can then use anywhere without actually giving your private key. So now is a good idea to export the subkeys so you can import them on other boxes:

   corsac@scapa: gpg -o 71ef0ba8-subkeys.gpg --export-secret-subkeys 71ef0ba8
   

   Note that only the subkeys private parts have been moved to the card, not the primary one, so you're still able to sign keys. Here, you have multiple choices. You can simply erase the private key (and later re-import the stubs) and use the offline copy made above when you need to sign another key.

7. What I did is something else. I've put the primary key on my second OpenPGP smartcard. That way, I won't lose it, it'll be kept safely in my house, but still be on a hardware token where it won't come out.

   The procedure for doing is so is exactly the same as above. First take a backup (in case you didn't do it first, do it now since after the keytocard command you won't have a backup of your primary key and there'll be no way to extract it from the smartcard. Then put the new smartcard in the reader, edit the key (don't select a subkey) and run the keytocard command.

   After that, running gpg --export-secret-keys will export the stub and not the private part of your primary key.

In the end, it seems that everything is running fine. Only issue is that scdaemon is sometime not behaving nicely (especially after a card change or or suspend/resume cycle). I didn't yet report a bug but you might want to kill it in case it's stuck.

You can also use the authentication subkey for ssh logins. When the card is inserted, the authentication subkey appears automatically (through the magic of gpg-agent):

corsac@scapa: ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EA... cardno:0005000016A1

And now you can add it to your various authorized_keys and use the smartcard for SSH.

After some feedback from other people, I have an important update to make on my last post. As I said, what decided me to eventually buy an OpenPGP smartcard was that it supported 4096 bit keys, so it would fit my 4096R/71EF0BA8 key.

In the end, it seems it's a little more complicated than that. 4096R keys are indeed supported, as far as signing and authentication are concerned. But encryption keys seem limited to 3072 bits (or maybe more, I didn't test toroughly). When trying to decrypt some stuff encrypted for a 4096R key on the smartcard, gpg fails with some “general error”. It has already been reported here, but no news since.

In my case, it's not that bad, I decided to go for 2048R for all subkeys. But if you desperately need 4096 bit encryption key, OpenPGPv2 smartcards might not be the right solution for you. I have no idea if the problem lies in GnuPG or in the smartcard, and I can't really find much information on this.