Echoes Corsac.net - Echoes camshot
lundi 07 avril 2014 (1 post)
  • CVE-2014-0160 / heartbleed

Short version:

  • yes we're affected;
  • we're currently working on it;
  • we didn't have an early warning so we're doing as fast as we can.

DSA should be in your INBOX in a few moments, and the updates on the mirror a moment later.

[UPDATE Tue, 08 Apr 2014 01:06:42 +0200]

After the upgrade, you really need to restart all TLS application using libssl1.0.0 to get the fix. Usual suspects are webservers, mailservers etc. Don't forget to restart clients too. Easiest way is to completely reboot the sever, but in case that's not a solution, you can check the process still using the old library with the following snippet:

grep -l 'libssl.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u

Some people seem to indicate that the 64kB leak can enable an attacker to get pretty much anything from the process memory space, including the certificate private key. While we weren't able to confirm that yet, that's not really impossible, so you might also want to regenerate those private keys, although that's not something you should do in a rush either.

Yves-Alexis@23:35:30 (Debian)

samedi 08 mars 2014 (1 post)
  • Météo

Avec les semaines pourries qu'on s'est tapé ces derniers temps, ça fait quand même plaisir :

Corsac@11:10:57 (Roadbook)

dimanche 05 janvier 2014 (1 post)
  • Films 2013

La cuvée 2013, donc, comme d'habitude en début d'année suivante. Une année pas très prolifique (17 films) mais bon. À noter une forte concentration au début de l'année (il fallait écluser les congés 2012 avant la fin mars) ainsi que fin octobre (suite à mon marathon).

  • Django Unchained : 22 janvier 2013, MK2 Beaubourg
  • Zero Dark Thirty : 7 février 2013, UGC Ciné Cité les Halles
  • Gangster squad : 13 février 2013, UGC Ciné Cité les Halles
  • Die Hard 5 : 1er mars 2013, UGC Montparnasse
  • No : 22 mars 2013, MK2 Quai de Seine
  • Cloud Atlas : 25 mars 2013, MK2 Quai de Loire
  • Mariage à l'anglaise : 12 avril 2013, MK2 Quai de Loire
  • Iron Man 3 : 19 mai 2013, UGC Ciné Cité Bercy
  • Prisoners : 26 octobre 2013, UGC Montparnasse
  • Sheriff Jackson : 26 octobre 2013, UGC Ciné Cité Les Halles
  • Malavita : 27 octobre 2013, UGC Ciné Cité Les Halles
  • Omar : 27 octobre 2013, UGC Ciné Cité Les Halles
  • La vie d'Adèle : 27 octobre 2013, UGC Ciné Cité Les Halles
  • Jeune & jolie : 28 octobre 2013, MK2 Parnasse
  • Blue Jasmine : 29 octobre 2013, UGC Ciné Cité Les Halles
  • Gravity : 30 octobre 2013, UGC Maillot
  • The lunchbox : 30 décembre 2013, UGC Ciné Cité Les Halles

Dans l'ensemble, là encore, un plutôt bon cru. Faut dire que quand on va moins souvent au cinéma, on sélectionne aussi plus, évidemment. Quelques petites déceptions (plus ou moins attendues, disons), mais aussi quelques pétites. J'ai déjà parlé de de la série PrisonersMalavitaOmarLa vie d'Adèle et Gravity, mais j'ai aussi vraiment beaucoup apprécié The lunchbox, et évidemment Django Unchained.

Corsac@19:01:30 (Echoes)

vendredi 27 décembre 2013 (1 post)
  • On the road

Aujourd'hui, sur l'autoroute, trois voitures sur la file de gauche, derrière moi, m'ont gentiment cédé le passage alors que j'étais sur la file de droite, afin de me permettre de faire un dépassement.

J'en reviens toujours pas. C'est Noël ?!

Corsac@21:36:20 (Roadbook)

samedi 21 décembre 2013 (1 post)
  • Hiver

Aujourd'hui les jours rallongent \o/

Corsac@11:17:00 (Roadbook)

vendredi 20 décembre 2013 (1 post)
  • Tour Eiffel

Je suis pas raide dingue de la Tour Eiffel, mais à force de la voir tous les jours, voire à passer devant, on finit quand même par l'apprécier.

Et comme j'aime bien le principe des photos du jour, j'ai profité l'été dernier d'aller/retour sur le champ de mars pour en prendre, et monter ça en petite vidéo pour rigoler.

Évidemment il aurait fallu que ça dure un peu plus longtemps, mais ça rend pas si mal que ça…

Corsac@22:47:51 (Echoes)

mardi 26 novembre 2013 (1 post)
  • Parce que sinon elle râle !

Ne soustrayons pas à la tradition.

Bonne fête Delphine !

Corsac@09:58:47 (Roadbook)

samedi 02 novembre 2013 (1 post)
  • Cinéma

C'est le moins qu'on puisse dire que notre fréquentation des salles obscures a nettement baissé depuis trois ans. Quasiment nulle la première année, on a réussi à augmenter quand même un peu la fréquentation les années suivantes (merci les RTTs d'ailleurs).

Ce coup ci, merci les vacances de la Toussaint. Profitant de quelques jours d'absence des miss, puis du centre de loisir, je me suis dit que j'allais me faire « quelques » toiles. N'ayant pas fait les choses à moitié, voilà le résultat :

Dans l'ensemble, je suis vraiment content du lot, hormis Sheriff Jackson, un peu moins bien et Blue Jasmine (vraie déception pour le coup). Dans la grande majorité des cas (en fait tout sauf La vie d'Adèle et Gravity) je n'avais pas la moindre information sur le film, et j'ai donc choisi à l'horaire (c'est en fait pas si évident que ça de caler trois films dont un de trois heure dans la même journée).

Une mention spéciale à Prisoners et Malavita, ainsi que La vie d'Adèle.

Corsac@21:59:09 (Echoes)

dimanche 25 août 2013 (1 post)
  • Expiration extension on PGP subkeys

So, last year I've switched to an OpenPGP smartcard setup for my whole personal/Debian PGP usage. When doing so, I've also switched to subkeys, since it's pretty natural when using a smartcard. I initially set up an expiration of one year for the subkeys, and everything seems to be running just fine for now.

The expiration date was set to october 27th, and I though it'd be a good idea to renew them quite in advance, considering there's my signing key in there, which is (for example) used to sign packages. If the Debian archive considers my signature subkey expired, that means I can't upload packages anymore, which is a bit of a problem (although I think I could still upload packages signed by the main key). dak (Debian Archive Kit, the software managing the Debian archive) uses keys from the keyring provided by Debian admins, which is usually updated every month or so from the keyring.debian.org public key server, so pushing the expiration date two months before the due date seemed like a good idea.

I've just did that, and it was pretty easy, actually. For those who followed my setup last year, here's how I did it:

First, I needed my main smartcard (the one storing the main key), since it's the only one able to do operations on the subkeys. So I plug it, and then:

corsac@scapa: gpg --edit-key 71ef0ba8
gpg (GnuPG) 1.4.14; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/71EF0BA8  created: 2009-05-06  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096g/36E31BD8  created: 2009-05-06  expires: never       usage: E   
sub  2048R/CC0E273D  created: 2012-10-17  expires: 2013-10-27  usage: A   
sub  2048R/A675C0A5  created: 2012-10-27  expires: 2013-10-27  usage: S   
sub  2048R/D98D0D9F  created: 2012-10-27  expires: 2013-10-27  usage: E   
[ultimate] (1). Yves-Alexis Perez <corsac@corsac.net>
[ultimate] (2)  Yves-Alexis Perez (Debian) <corsac@debian.org>

gpg&> key 2

pub  4096R/71EF0BA8  created: 2009-05-06  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096g/36E31BD8  created: 2009-05-06  expires: never       usage: E   
sub* 2048R/CC0E273D  created: 2012-10-17  expires: 2013-10-27  usage: A   
sub  2048R/A675C0A5  created: 2012-10-27  expires: 2013-10-27  usage: S   
sub  2048R/D98D0D9F  created: 2012-10-27  expires: 2013-10-27  usage: E   
[ultimate] (1). Yves-Alexis Perez <corsac@corsac.net>
[ultimate] (2)  Yves-Alexis Perez (Debian) <corsac@debian.org>

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 429d
Key expires at mar. 28 oct. 2014 12:43:35 CET
Is this correct? (y/N) y

At that point, a pinentry dialog should ask you the PIN, and the smartcard will sign the subkey. Repear for all the subkeys (in my case, 3 and 4). If you ask for PIN confirmation at every signature, the pinentry dialog should reappear each time.

When you're done, check that everything is ok, and save:

gpg> save
corsac@scapa: gpg --list-keys 71ef0ba8
gpg: checking the trustdb
gpg: public key of ultimately trusted key AF2195C9 not found
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   4  signed:   5  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1  valid:   5  signed:  53  trust: 5-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2013-12-28
pub   4096R/71EF0BA8 2009-05-06
uid                  Yves-Alexis Perez <corsac@corsac.net>
uid                  Yves-Alexis Perez (Debian) <corsac@debian.org>
sub   4096g/36E31BD8 2009-05-06 [expires: 2014-10-28]
sub   2048R/CC0E273D 2012-10-17 [expires: 2014-10-28]
sub   2048R/A675C0A5 2012-10-27 [expires: 2014-10-28]
sub   2048R/D98D0D9F 2012-10-27 [expires: 2014-10-28]

Now that we have the new subkeys definition locally, we need to push it to the keyservers so other people get it too. In my case, I also need to push it to Debian keyring keyserver so it gets picked at the next update:

corsac@scapa: gpg --send-keys 71ef0ba8
gpg: sending key 71EF0BA8 to hkp server subkeys.pgp.net
corsac@scapa: gpg --keyserver keyring.debian.org --send-keys 71ef0ba8
gpg: sending key 71EF0BA8 to hkp server keyring.debian.org

Main smartcard now back in safe place. As far as I can tell, there's no operation needed on the daily smartcard (which only holds the subkeys), but you will need to refresh your public key on any machine you use it on before it gets the updated expiration date.

Yves-Alexis@14:18:12 (Debian)

samedi 06 juillet 2013 (1 post)
  • Xfce 4.10, final part

Someone recently asked me about the Debian Xfce 4.10 status, as apparently I forgot to update this post series.

So, as you might have noticed, the full Xfce 4.10 desktop environment is currently in Debian Jessie (current name for testing). All in all, the transition went well and smooth.

One of the most regular question I get about Xfce 4.10 is the panel behavior when it comes to the “task bar” expansion. In xfce4-panel 4.8, when people wanted to have a full side panel with a task bar plugin inside, they added a “Windows buttons” plugin and configured the panel to 100% length. Then the “Windows buttons” would expand to occupy all the free space on the panel. It was a special case plugins, as usually other plugins only used a fixed space. Now, in 4.10, this is not the case anymore. “Windows button” uses a fixed size. And the plugins are left-aligned, which means usually people end up with some space at the far right of the panel. To restore the previous behavior back (which is actually the pre-4.8 behavior, 4.8 was an exception by itself), one needs to add a “Separator” plugin, then configure it to expand (and optionnally select a transparent handle). Then move it next right to the “Windows buttons” plugin.

Another thing which might be a bit surprising for upgrading users is the change in the “Action buttons” plugin, which people usually use to logout. In 4.8, by default, it's set to run the logout dialog. In 4.10, by default, it's set to logout directly (but with a confirmation dialog). If you prefer the previous behavior, you can just configure the “Action buttons” plugin and select the “Log out…” item instead of the “Log out” one (I know, it's a bit confusing).

If you have any question, don't hesitate to reach us by mail or on irc (#debian-xfce on Freenode). Other than that remember that Xfce really needs you help, both in Debian and upstream (and at that point, I'd say *especially* upstream). There's a lot of unmaintained project under the Xfce umbrella, some of them part of the core (like xfce4-power-manager), so if you have some spare time and some C/GTK+ knowledge, feel free to contact the Xfce team on the mailing list.

Yves-Alexis@10:53:57 (Debian)

dimanche 02 juin 2013 (1 post)
  • Hiding encrypted disks in Thunar with udisks2

udisks2 was uploaded recently to Debian sid. With this, people might have seen hidden encrypted disks reappear in Thunar. Hiding disks in udisks was previously done by setting an udev propery. For example, I did this using /etc/udev/rules.d/99-hide-disks.rules:

KERNEL=="sda2", ENV{UDISKS_PRESENTATION_HIDE}="1"

This is not valid anymore in udisks2, but only the property name has changed. You can simply replace by:

KERNEL=="sda2", ENV{UDISKS_IGNORE}="1"

I'm not too sure yet if it has side-effects (PRESENTATION_HIDE seems pretty harmless, but IGNORE might be a bit more invasive) but for now it seems to work just fine.

Yves-Alexis@10:38:34 (Debian)

vendredi 24 mai 2013 (1 post)
  • Xfce 4.10, part 2

This is an update on the Xfce 4.10 transition to unstable. Most desktop components have been uploaded, built and installed to the archive.

We're now currently building and uploading the various goodies, and especially panel plugins. There's a lot of them so it takes some time.

Once we'll have finished to build and upload all the goodies, we'll ask for binNMUs on the packages which don't need a sourceful upload but need to be rebuilt against libxfce4util or xfce4-panel 4.10.

You can follow the transition status using the release team page.

In any case, please be patient while we upload all the packages. Again, no need to report installability issues in unstable for now, we are aware of it and don't need more warnings. We'll fix the fallouts in due time.

Yves-Alexis@07:59:04 (Debian)

mercredi 22 mai 2013 (1 post)
  • Xfce 4.10, part 1

Thanks to the release team ACK, I've started uploading Xfce 4.10 to unstable yesterday. For now, I've only pushed Xfce 4.10.1 desktop components, which means people using xfce4 + xfce4-goodies in unstable won't be able to upload at once.

That's because panel plugins have a quite hard dependency on the running xfce4-panel, and the communication protocol has changed between Xfce 4.8 and 4.10. So all panel plugins need to be rebuild against the new xfce4-panel. I'll start uploading new releases or packages revisions this evening, and binNMUs will be scheduled for the rest, but it'll take some days.

In the meantime, you can safely wait before upgrading xfce4. If you don't use external panel plugins, then you can accept to remove xfce4-goodies and the various xfce4-*-plugins and upgrade to xfce4 4.10.

There's no need to report a bug about that situation, we're already aware of it and it's somehow intended, things will settle in a few days.

Yves-Alexis@07:26:05 (Debian)

mardi 01 janvier 2013 (1 post)
  • Les films 2012

Je crois que l'année dernière j'avais même pas fait de post, tellement on était allés voir peu de choses. Cette année, on s'en est plutôt pas trop mal tirés. Surtout vers la fin, grâce aux contributions très appréciées de nos baby-sitters. Alors c'est sur que ça n'a rien à voir avec la grande époque, mais tout de même.

Sans attendre, donc, le cru 2012 :

  • The Artist : 2 mars 2012, MK2 Gambetta
  • My week with Marylin: 21 avril 2012, MK2 Quai de Loire
  • The Avengers : 7 mai 2012, UGC Ciné Cité les Halles
  • Moonrise Kingdom : 18 mai 2012, UGC Ciné Cité les Halles
  • La part des anges : 3 juillet 2012, UGC Ciné cité les Halles
  • À perdre la raison : 7 septembre 2012, MK2 Quai de Seine
  • Starbuck : 9 septembre 2012,  Gaumont Rennes
  • The We and the I, 2 octobre  2012, UGC Ciné Cité Les Halles
  • Skyfall: 1er novembre 2012, UGC Ciné Cité Les Halles
  • Une nouvelle chance : 27 novembre 2012, UGC Ciné Cité Les Halles
  • Argo : 6 décembre 2012, UGC Ciné Cité Les Halles
Onze films, ça reste un peu léger pour rentabiliser une carte UGC/MK2 illimité, mais bon. On notera une quasi complète disparition du MK2, remplacé en grande partie par l'UGC des Halles. Il faut dire que c'est direct en métro. Dans l'ensemble, à part À perdre la raison, j'ai pas eu de mauvaise surprise, je crois que j'ai vraiment tout aimé. Une mention particulière pour The We and the I, je crois.

 

Corsac@14:58:11 (Echoes)

vendredi 21 décembre 2012 (1 post)
  • Hiver

Aujourd'hui les jours rallongent \o/

Corsac@20:03:34 (Roadbook)

lundi 26 novembre 2012 (1 post)
  • Parce que sinon elle râle !

Bonne fête Delphine !

Corsac@21:13:45 (Roadbook)

mercredi 31 octobre 2012 (1 post)
  • Update on OpenPGPv2 smartcards

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.

Yves-Alexis@20:45:55 (Debian)

lundi 29 octobre 2012 (1 post)
  • Switching to OpenPGP smartcard

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.

Yves-Alexis@23:19:10 (Debian)

lundi 22 octobre 2012 (2 posts)
  • Souvenirs en accordéons

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.

Corsac@21:32:00 (Roadbook)

  • Debian, Xfce 4.10 and Xfce 4.11

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.

Yves-Alexis@07:42:14 (Debian)

Images
Stats
  • 1482 posts
  • 4333 jours
  • 0.34 posts/jour
  • IRC
  • Last.fm
Stuff
Gallery
Tech
Webcomics
Weblogs
Desktop