Re: failed to convert unprotected openpgp key: Checksum error

[Phil Pennock]

On 2018-01-19 at 19:57 +1100, Simon Kissane wrote:
> However, when I try to decrypt data encrypted with the private key, I
> get a "failed to convert unprotected openpgp key: Checksum error"

Simpler check:

% gpg --export-secret-key
gpg: key 4252EB6983CE74C44F549B6F8666715904EE61F2: error receiving key from 
agent: Checksum error - skipped
gpg: WARNING: nothing exported

If I use `gpg --expert --full-generate-key` to make an SCEA RSA/4096
key, then it looks almost identical in structure to yours.

If I just `gpg --import` a dearmored version of the key, then I get a
checksum error at that time:
gpg: key 68F870F8C0FAA42B: public key 
"root:testGpg:key_54503F79_3794_456C_8725_8977A68B71C1" imported
gpg: key 68F870F8C0FAA42B/68F870F8C0FAA42B: error sending to agent: Checksum 
error

so something in the scripted setup you created suppressed that error
message, which is Unfortunate by GnuPG.  The key still ends up added to
the keyring in the above, even with the error, but it's unusable.
This might be a bug in GnuPG: IMO if it's broken and will never be
usable, then it should not be added and gpg should exit false.

So at this point, it looks to me like it really is an incorrect
checksum, exposing unfortunate edge-case handling in GnuPG.

-Phil

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

Re: [OT] Re: failed to convert unprotected openpgp key: Checksum error

[Daniele Nicolodi]

On 1/22/18 12:30 PM, Kristian Fiskerstrand wrote:
> On 01/22/2018 06:31 PM, Daniele Nicolodi wrote:
>> On 1/22/18 5:31 AM, Kristian Fiskerstrand wrote:
>>> On 01/22/2018 08:33 AM, Werner Koch wrote:
 That is an acceptable user-id.  I would have used a dot as delimiter but
 that is a personal taste.
>>>
>>> Dot is a permitted part of username in POSIX though, while : is not :)
>>
>> Uh? As far as I know, the only characters not allowed are / and null.
> 
> http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap03.html#tag_03_426
> 
>  3.426 User Name

Sorry, I should not be writing email before my morning coffee: I read
filenames instead than usernames.

Cheers,
Daniele

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

Re: [OT] Re: failed to convert unprotected openpgp key: Checksum error

[Daniele Nicolodi]

On 1/22/18 5:31 AM, Kristian Fiskerstrand wrote:
> On 01/22/2018 08:33 AM, Werner Koch wrote:
>> That is an acceptable user-id.  I would have used a dot as delimiter but
>> that is a personal taste.
> 
> Dot is a permitted part of username in POSIX though, while : is not :)

Uh? As far as I know, the only characters not allowed are / and null.

Cheers,
Daniele

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

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[André Colomb]

Hello Daniel,

I'm on Ubuntu 17.10 with GnuPG 2.1.15, by the way.

Daniel Kahn Gillmor  wrote on 2018-01-22 12:53
(UTC+0100)
> It may also depend on how the session itself is started.  Maybe one of
> you is starting the user session in non-graphical mode (either a vt
> login, or maybe ssh?), while the other one is starting it directly from
> a graphical display manager?

The session is started by GDM3, using the vanilla gnome-session scripts
(not the adapted ubuntu-session, also based on GNOME 3).  The systemd
user unit file is copied from /usr/lib/systemd/user/gpg-agent.service
and the Upstart-specific "initctl" command line commented out.

The main difference I see here is that I have enabled the user unit by
symlinking from ~/.config/systemd/user/default.target.wants/, whereas
the Ubuntu package includes the symlink in
/usr/lib/systemd/user/graphical-session-pre.target.wants/.

acolomb@barnov:~$ systemctl --user status gpg-agent.service
   Loaded: loaded (/home/acolomb/.config/systemd/user/gpg-agent.service;
enabled; vendor preset: enabled)

> do you have dbus-user-session installed?  (it is recommended)

Yes.

(from your other message:)
> the systemd user service takes care of automatically launching the
> gpg-agent when the user connects to it via the ssh-agent protocol, so
> this isn't required when using systemd.

I can't see how it does that in my packaged Ubuntu version (2.1.15),
there is no gpg-agent.socket unit file anywhere?

Any other ideas on how to debug this?  What logging should I enable for
gpg-agent and how?

Btw. it affects both my Yubikey as well as file-based authentication
subkeys, so not specific to scdaemon apparently.

Regards
André
-- 
Greetings...
From: André Colomb 

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

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Daniel Kahn Gillmor]

On Mon 2018-01-22 11:52:21 +0100, Peter Lebbing wrote:
> It works for me out-of-the-box on Debian stretch/stable, supervised by
> systemd... if I SSH before I do any GnuPG stuff, it correctly prompts me
> in the (graphical) session that started the agent. So something must be
> different in your installation.

It may also depend on how the session itself is started.  Maybe one of
you is starting the user session in non-graphical mode (either a vt
login, or maybe ssh?), while the other one is starting it directly from
a graphical display manager?

do you have dbus-user-session installed?  (it is recommended)

   --dkg

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

[OT] Re: failed to convert unprotected openpgp key: Checksum error

[Kristian Fiskerstrand]

On 01/22/2018 08:33 AM, Werner Koch wrote:
> That is an acceptable user-id.  I would have used a dot as delimiter but
> that is a personal taste.

Dot is a permitted part of username in POSIX though, while : is not :)

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Don't be afraid to go out on a limb. That's where the fruit is."
(H. Jackson Browne)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Daniel Kahn Gillmor]

On Mon 2018-01-22 08:43:41 +0100, Werner Koch wrote:
> Another problem with ssh is that ssh can't start gpg-agent on the the
> fly.  Thus you need to make sure that gpg-agent has already been started
> when you use ssh.  A way to ensure this is to run 
>
>   gpg -K

the systemd user service takes care of automatically launching the
gpg-agent when the user connects to it via the ssh-agent protocol, so
this isn't required when using systemd.

 --dkg


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

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[Peter Lebbing]

On 22/01/18 09:36, André Colomb wrote:
> Strange thing is, I could use the GPG part of gpg-agent already before
> issuing that command.  Why does that behave differently?

Because GnuPG *does* pass TTY and display to the agent.

> Can something be done to the systemd user unit file so the process gets
> told the correct $DISPLAY at least?

It works for me out-of-the-box on Debian stretch/stable, supervised by
systemd... if I SSH before I do any GnuPG stuff, it correctly prompts me
in the (graphical) session that started the agent. So something must be
different in your installation.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[André Colomb]

On 2018-01-22 08:43, Werner Koch wrote:
>> As far as I understand, because I use `systemd`'s user service, whenever
>> I want to unlock an authentication key I need to run the command
>> `gpg-connect-agent updatestartuptty /bye`.
> 
> Although I have no experience with the peculiarities of the --supervised
> mode, there is no need to run the updatestartuptty command.  That command
> is only used to switch gpg-agent's default $DISPLAY and tty to the one
> active in the shell you run this command.  This is required because the
> ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the
> DISPLAY/tty which shall be used to pop-up the Pinentry.

I can confirm that it actually IS necessary to send "updatestartuptty"
for ssh-agent functionality to work in this scenario.  The gpg-agent
process started by systemd's user session has no $DISPLAY and no
$GPG_TTY set (looking at /proc/###/environ).  Its cmdline does not
contain --supervised either.

I always wondered why I got the message "agent refused operation" when
using an SSH key from gpg-agent.  Restarting gpg-agent manually after
logging in was my workaround thus far, but today I found out that
updatestartuptty suffices.

Strange thing is, I could use the GPG part of gpg-agent already before
issuing that command.  Why does that behave differently?

Can something be done to the systemd user unit file so the process gets
told the correct $DISPLAY at least?

Kind regards
André

-- 
Greetings...
From: André Colomb 

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