generating revocation certs non-interactively

Michelle Gmail mkfranny at
Wed May 6 23:08:57 CEST 2015

Some how in the one ur doing this to I have done nothing to deserve to have put through  2 months of non stop names called then I love then I hate u ... Do u tell me who needs help. I did no approve to have anyone jailbreak my phone and make my 2 computer 1 iPad and my iPhone to have all these public files I did not allow these it is illegal he is going to far w this anyone with the intent to purposely do this to someone is demented. This is wrong what he is doing I'm very upset I did nothing to deserve this pls stop.

Sent from my iPhone

On May 5, 2015, at 2:46 PM, luis <luis at> wrote:

> On 05/05/15 09:41, Werner Koch wrote:
> Note that GnuPG 2.1 generates revocation certificates by default.

Great! Good to know!

> The idea is that you should be able to tell the reason for the
> revocation.
Yes of course, this makes perfect sense. There is however the fact that
good practice guides now a days often advice to generate a preemptive
revocation certificate at the time of creation of the key. So at that
moment the reason is well... not really relevant. So it's great that 2.1
does this on keypair generation.

> You need to use this command
>  gpg --command-fd 0 --status-fd 2 --gen-revoke 0x12345678
> and act upon the GET_* status lines.
Great, thanks!

This hack seems to have worked though (in python), but your suggestion
seems more robust:

   import pexpect

   cmd = "gpg --homedir {0} --gen-revoke {1}".format(KEYRING_DIR, 
   px = pexpect.spawn(cmd, timeout=5)

   px.expect("Your decision?")
   px.expect("> ")
   px.expect("Is this okay?")


   bidx = px.before.index('-----BEGIN PGP PUBLIC KEY BLOCK-----')
   eidx = px.before.index('-----END PGP PUBLIC KEY BLOCK-----')
   eidx += len('-----END PGP PUBLIC KEY BLOCK-----')
   print px.before[bidx:eidx]


Gnupg-users mailing list
Gnupg-users at

More information about the Gnupg-users mailing list