Re: A safe text editor

[Jens Lechtenboerger]

On Mi, Sep 05 2012, notizblock wrote:

 Am 2012-09-05 09:39, schrieb antispa...@sent.at:

 Could you recommend a safe text editor, in the sense it does protect the
 edited contents in memory, but, most important, on the disk (temp files
 and such). Having functions to interact with gnupg would be even better.

 You could use vim with the gnupg.vim [1] plugin. It turns off swapfiles
 and viminfo by default and handles filenames with a .gpg, .pgp or
 .asc suffix.

 [1] http://www.vim.org/scripts/script.php?script_id=3645

If you prefer Emacs over vim, I suggest the EasyPG Assistant:
https://www.gnu.org/software/emacs/manual/html_mono/epa.html

Best wishes
Jens

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Changing the email address of a key

[Richi Lists]

That worked.
Thanks a lot!

Rgds
Richard

On Do, 2012-08-30 at 10:48 +0200, Peter Lebbing wrote:
 On 30/08/12 10:25, Richi Lists wrote:
  Using the primary key was what I tried first. But when I saw the error
  message signing failed, I thought I'd have to force the proper signing
  subkey, like I have to do for signing emails.
  
  My setup is more or less the following:
  http://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups
  with the addition of a sub key for ssh authentication:
  http://www.programmierecke.net/howto/gpg-ssh.html - section with
  smartcard (openpgp)
 
 The thing is that for a new UID, you need the, what they call, master key. 
 That
 would be the primary key. So when you followed the instructions under the
 heading Remove the master key from the keyring, you where after that unable 
 to
 use your master/primary key to create a new UID.
 
 So you go back a little in the document to the part where you had your USB 
 stick
 with the primary key and all subkeys guarded by Orcs or some other fearsome
 creature. Plead with the creature to have your USB stick back, once again 
 follow
 the section Go offline, import your primary key from the USB stick (wipe 
 away
 the Orc spittle before inserting; ignore the chew marks on the protective 
 cap).
 
 After you have created the new UID with the primary key and exported the whole
 to the USB stick, re-remove the primary key from the system.
 
 Oh, by the way, the reason you need the exclamation mark to specify which key 
 to
 use to sign is because you have two signing keys. Apparently GnuPG tries it 
 with
 the one you don't have the secret part for if you don't give the exclamation
 mark. But bear in mind the difference between a signature on a key(/UID) and 
 on
 data. The signing subkey is for signatures on data.
 
 Good luck,
 
 Peter.
 



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpgme passphrase_cb

[John Morris]

Hi again,

After spending a second day debugging this problem, I think I've 
narrowed it down.  (Sorry for the top-post, but the original post isn't 
too relevant anymore!)


I still have not found a case where passphrase_cb is actually used.  In 
the gpg2 manpage, the description of the '--{no-}use-agent' options 
indicate that the gpg agent is *always* used, which would imply that 
there is no way for gpg2 to read in a passphrase through a file descriptor.


The gpgme test cases work because they create a 'gpg-agent.conf' file in 
$GNUPGHOME pointing to the simple but workable 'pinentry' script in the 
same directory.  Although there is a 'passphrase_cb' function defined in 
t-support.h, it is presumably never used with gpg2, even though it is 
set up and ready to go.


The pygpgme test cases fail because, although there is a working 
passphrase_cb, it is never called, and there is no gpg-agent configured 
capable of supplying the passphrase.


All the above seems to be true, and yet the application I'm having 
trouble with (sigul) was working well a couple of months ago.  Can 
anyone confirm or deny the above?


Thanks-
John


On 09/06/2012 06:34 PM, John Morris wrote:

Hi,

I'm having trouble with passphrase_cb seemingly being ignored. The
GPG_AGENT_INFO environment variable is unset.

It could be similar to this bug here, and I am indeed using pygpgme:
https://bugs.launchpad.net/pygpgme/+bug/49

Can someone eyeball this trace and see if anything obvious sticks out?
I've gone through both the pygpgme and gpgme code to some degree and
can't seem to figure out why the supplied passphrase_cb isn't ever
executed.

The point in the trace where passphrase_cb is set is quite clear, and
the value stays the same until the end:
passphrase_cb=0x2e30e0/0xb7435194

However, instead of the pygpgme callback function executing, the gnome
pinentry window pops up.

I've pasted a bunch of debugging statements into the code of pygpgme.
They confirm that up until the line where gpgme_op_sign is called, the
passphrase_cb is set as expected. It is also set as expected coming out
of op_sign. However, the debug statements planted in the callback
function itself are never touched.

I tried instrumenting t-sign.c and t-support.h the same way, but the
data types are opaque there and wasn't able to get hex pointer values
for the cb function. The cb function in t-support.h does seem never to
be called, but there's no gnome pinentry dialog either, and the tests
pass, so I'm quite confused. (My crude instrumentation appends lines to
a debug file in /tmp, opening and closing after each write, so that
there's no confusion about stderr/stdout getting swallowed or lines
being written out of order.)

Thanks-

John




GPGME 2012-09-06 17:43:28 0x464e gpgme_debug: level=5
GPGME 2012-09-06 17:43:28 0x464e gpgme_check_version: call: 0=(nil),
req_version=(null), VERSION=1.3.0
GPGME 2012-09-06 17:43:28 0x464e gpgme_check_version_internal: call:
0=(nil), req_version=(null), offset_sig_validity=32
GPGME 2012-09-06 17:43:28 0x464e gpgme_new: enter: r_ctx=0xb77550a8
GPGME 2012-09-06 17:43:28 0x464e gpgme_new: leave: ctx=0x96811f8
GPGME 2012-09-06 17:43:28 0x464e gpgme_data_new_from_cbs: enter:
r_dh=0xbffd4d10, handle=0xb742a498
GPGME 2012-09-06 17:43:28 0x464e gpgme_data_new_from_cbs: leave:
dh=0x96aa890
GPGME 2012-09-06 17:43:28 0x464e gpgme_op_import: enter:
ctx=0x96811f8, keydata=0x96aa890
GPGME 2012-09-06 17:43:28 0x464e gpgme_data_get_encoding: call:
dh=0x96aa890, dh-encoding=0
GPGME 2012-09-06 17:43:28 0x464e _gpgme_add_io_cb: call:
ctx=0x96811f8, fd 5, dir=1 - tag=0x969e588
GPGME 2012-09-06 17:43:28 0x464e _gpgme_add_io_cb: call:
ctx=0x96811f8, fd 9, dir=0 - tag=0x95d2b48
GPGME 2012-09-06 17:43:28 0x464e gpgme:gpg_io_event: call:
gpg=0x9674040, event 0x4b87dcf0, type 0, type_data (nil)
GPGME 2012-09-06 17:43:28 0x464e _gpgme_run_io_cb: call:
item=0x95d2b58, need to check
GPGME 2012-09-06 17:43:28 0x464e _gpgme_run_io_cb: call:
item=0x95d2b58, handler (0x96aa890, 9)
GPGME 2012-09-06 17:43:28 0x464e _gpgme_data_outbound_handler:
enter: dh=0x96aa890, fd=0x9
GPGME 2012-09-06 17:43:28 0x464e gpgme_data_read: enter:
dh=0x96aa890, buffer=0x96aa898, size=4096
GPGME 2012-09-06 17:43:28 0x464e gpgme_data_read: leave: result=908
GPGME 2012-09-06 17:43:28 0x464e _gpgme_data_outbound_handler: leave
GPGME 2012-09-06 17:43:28 0x464e _gpgme_run_io_cb: call:
item=0x95d2b58, need to check
GPGME 2012-09-06 17:43:28 0x464e _gpgme_run_io_cb: call:
item=0x95d2b58, handler (0x96aa890, 9)
GPGME 2012-09-06 17:43:28 0x464e _gpgme_data_outbound_handler:
enter: dh=0x96aa890, fd=0x9
GPGME 2012-09-06 17:43:28 0x464e gpgme_data_read: enter:
dh=0x96aa890, buffer=0x96aa898, size=4096
GPGME 2012-09-06 17:43:28 0x464e gpgme_data_read: leave: result=0
GPGME 2012-09-06 17:43:28 0x464e _gpgme_remove_io_cb: call:
data=0x95d2b48, setting fd 0x9 (item=0x95d2b58) done
GPGME 2012-09-06 17:43:28 0x464e _gpgme_data_outbound_handler: leave
GPGME 2012-09-06 17:43:28 0x464e