From gniibe at fsij.org  Thu Mar  1 01:14:15 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 01 Mar 2018 09:14:15 +0900
Subject: Fwd: gnupg SmartCard V3.3
In-Reply-To: <87woyxrwls.fsf@wheatstone.g10code.de>
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>
 <87woyxrwls.fsf@wheatstone.g10code.de>
Message-ID: <87bmg8bqjs.fsf@iwagami.gniibe.org>

Hello,

Werner Koch <wk at gnupg.org> wrote:
> @gniibe: Do you have any more up to date information on macOS and
> smartcard readers?

If possible, I recommend to use GnuPG's in-stock driver to access
smartcard.  It is direct access by libusb, not using PC/SC service.

For GNU/Linux, if you don't have any other use of PC/SC service, please
uninstall it, or disable the service, and try again with GnuPG's
in-stock driver.

For the driver, I maintain this list:

    https://wiki.debian.org/GnuPG/CCID_Driver

For macOS, I think that it still uses old PC/SC and libccid library.
I'm afraid that new readers (with new features like pinpad support)
don't work well, or don't work at all.

I need macOS developers who build GnuPG with libusb.  Currently, GnuPG
scdaemon uses PC/SC service on macOS and Windows.  On GNU/Linux, people
can use both ways (in-stock driver or PC/SC).


> - Cherry GmbH SmartBoard XX44

  02.... Short APDU level exchange

Because of this limitation, this reader cannot handle larger APDU (~=
packet), which is needed for recent RSA key size.  You can still use it
with RSA-1024.

> -  KOBIL EMV CAP - SecOVID Reader III

  bPINSupport: 0x03
     PIN Verification supported
     PIN Modification supported

I'm afraid it doesn't work on macOS.

> - Alcor Micro AU9540 00 00

I had a bug report with this reader: 

    https://dev.gnupg.org/T1947

I think it now works fine by GnuPG's in-stock driver on GNU/Linux.
Please test.

It seems that this reader has a problem in PC/SC service, and it's not
supported by PC/SC-lite + libccid.

   https://pcsclite.alioth.debian.org/ccid/unsupported.html#0x058F0x9540

			*	*	*

Supporting users' freedom on computing (for their privacy in digital
world), I need have/collect/maintain knowledge of those hardware.

But... when there is a problem, it tends to be because of bad firmware
implementation, which is proprietary.  In the proprietary world, the
practice is... to be "fixed" in the proprietary driver (than the
firmware).  But that "fix" has tendency not to be published to users or
developers of free software.

For me, it's a pity that I somehow need to have knowledge around those
proprietary firmware.

Perhaps, someday, in free software, I will write CCID reader
implementation which accesses smartcard, by free software (I mean,
development environment), for free software (= GnuPG maintenance); Then,
we can proceed to free firmware of smartcard itself.

# About ten years ago, I didn't take that approach but a short cut, that
# was Gnuk.  The reason was that it was difficult to find hardware
# vendors which allowed developing free firmware implementation of
# smartcard.

Having free CCID reader implementation still makes sense, to encourage
free firmware implementation of smartcard.  I'd like to work for some
part this year.
-- 


From guru at unixarea.de  Thu Mar  1 09:05:32 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 1 Mar 2018 09:05:32 +0100
Subject: Fwd: gnupg SmartCard V3.3
In-Reply-To: <87bmg8bqjs.fsf@iwagami.gniibe.org>
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>
 <87woyxrwls.fsf@wheatstone.g10code.de>
 <87bmg8bqjs.fsf@iwagami.gniibe.org>
Message-ID: <20180301080532.GA7509@sh4-5.1blu.de>

El d?a Thursday, March 01, 2018 a las 09:14:15AM +0900, NIIBE Yutaka escribi?:

> Hello,
> 
> Werner Koch <wk at gnupg.org> wrote:
> > @gniibe: Do you have any more up to date information on macOS and
> > smartcard readers?
> 
> If possible, I recommend to use GnuPG's in-stock driver to access
> smartcard.  It is direct access by libusb, not using PC/SC service.
> 
> For GNU/Linux, if you don't have any other use of PC/SC service, please
> uninstall it, or disable the service, and try again with GnuPG's
> in-stock driver.
> 
> For the driver, I maintain this list:
> 
>     https://wiki.debian.org/GnuPG/CCID_Driver
> 
> For macOS, I think that it still uses old PC/SC and libccid library.
> I'm afraid that new readers (with new features like pinpad support)
> don't work well, or don't work at all.
> 

Hello,

I do yous the following USB token ond FreeBSD-12 CURRENT and the 'pcscd'
is configured to be started by devd on device attach:

Mar  1 08:00:56 r314251-amd64 kernel: ugen0.2: <Identiv uTrust 3512 SAM slot Token> at usbus0
Mar  1 08:00:56 r314251-amd64 root: CCID uTrust, type: ATTACH, system: USB, subsystem: INTERFACE
Mar  1 08:00:56 r314251-amd64 root: /usr/local/sbin/pcscd
Mar  1 08:00:56 r314251-amd64 root: Unknown USB device: vendor 0x04e6 product 0x5816 bus uhub0

The OpenPGP card works fine as:

$ gpg2 --card-status

Reader ...........: Identiv uTrust 3512 SAM slot Token (55511514602745)
00 00
Application ID ...: D27600012401020100050000532B0000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 0000532B
Name of cardholder: Matthias Apitz
...

Do I have any chance to use the USB token and the card directly without
'pcscd'?

Thanks

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub


From kr at glsys.de  Thu Mar  1 10:08:14 2018
From: kr at glsys.de (=?utf-8?Q?Klaus_R=C3=B6mer?=)
Date: Thu, 1 Mar 2018 10:08:14 +0100
Subject: gnupg SmartCard V3.3
In-Reply-To: <87woyxrwls.fsf@wheatstone.g10code.de>
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>
 <87woyxrwls.fsf@wheatstone.g10code.de>
Message-ID: <E0FFB870-122B-482F-B50C-DBBC6F95E5A9@glsys.de>


> Am 28.02.2018 um 15:56 schrieb Werner Koch <wk at gnupg.org>:
> 
> On Tue, 27 Feb 2018 01:04, kr at glsys.de said:
> 
>> gpg2 --version is 2.1.11
> 
> That is a pretty old an somewhat buggy version which will likely have
> problems with newer smartcards.
> 
>> Tried gpg (GnuPG/MacGPG2) 2.2.3
>> on a completely different machine (mac)
> 
> That version is recent enough and as long as macOS is properly
> configured for the card it will work.  You maywant to ask over at
> gpgtools.org, though.
> 
>> Tried three different card-reader:
>> - Cherry GmbH SmartBoard XX44
> 
> IIRC that is the old Omnikey reader based keyboard.  I have one myself.
> It does not work with 2048 bit keys unless you use their Windows driver.
> 
>> -  KOBIL EMV CAP - SecOVID Reader III
> 
> I am not sure which reader this is, I had to dump my Kobil reader a logn
> time ago wehn I moved to 2048 bit keys.  The problem is slightly
> different than with Omnicard keys but I can't remember the details.
> 
>> - Alcor Micro AU9540 00 00
> 
> I am not sure about them.  Quite some time ago they simply did not worked.
This is my target device because it is build-in in our Laptops,
i found this ct 2017-10 (german computer magazine) Article,
where they claim the reader to be working with the openpgp smartcard Version 2.1 
by transfering precreated 4096-Bit keys. This is exactly what i am tring to do - and it seems to work, only the stub keys are not being generated?

So either i am doing something stupid or the V3.3 card incorporated changes which broke this.
I ordered another reader and asked if it would be possible do buy some 2.1 cards for cross-tersting, but it seems they would have to be manufactured as they are out of stock.

Can anybody suggest how i could further debug the --card-edit and --card-status to find out why the stubs are not being generated?

Kind Regards,
 Klaus


> 
> @gniibe: Do you have any more up to date information on macOS and
> smartcard readers?
> 
> 
> Shalom-Salam,
> 
>   Werner
> 
> -- 
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From thomas.jarosch at intra2net.com  Thu Mar  1 12:32:42 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Thu, 01 Mar 2018 12:32:42 +0100
Subject: gnupg SmartCard V3.3
In-Reply-To: <E0FFB870-122B-482F-B50C-DBBC6F95E5A9@glsys.de>
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <87woyxrwls.fsf@wheatstone.g10code.de>
 <E0FFB870-122B-482F-B50C-DBBC6F95E5A9@glsys.de>
Message-ID: <2789559.azVr8nC1vH@storm.m.i2n>

Hello Klaus,

On Thursday, 01 March 2018 10:08:14 CET Klaus R?mer wrote:
> This is my target device because it is build-in in our Laptops,
> i found this ct 2017-10 (german computer magazine) Article,
> where they claim the reader to be working with the openpgp smartcard Version
> 2.1 by transfering precreated 4096-Bit keys. This is exactly what i am
> tring to do - and it seems to work, only the stub keys are not being
> generated?
> 
> So either i am doing something stupid or the V3.3 card incorporated changes
> which broke this. I ordered another reader and asked if it would be
> possible do buy some 2.1 cards for cross-tersting, but it seems they would
> have to be manufactured as they are out of stock.

Today I'm also setting up a bunch of V3.3 cards.

There is indeed a problem: OpenSC added support for the new cards just
in the current git HEAD version. See:
https://github.com/OpenSC/OpenSC/issues/1215

-> we compiled opensc from git on Fedora now are able to talk to the card.

You might be affected by this if gnupg talks to the card
via opensc instead of the builtin libusb based CCID driver.
(that's what NIIBE Yutaka suspected in his reply)

HTH,
Thomas





From peter at digitalbrains.com  Thu Mar  1 13:06:03 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 1 Mar 2018 13:06:03 +0100
Subject: [FEATURE REQ] Keygrips in --card-status (was: gpgsm --gen-key with
 key on smartcard)
In-Reply-To: <87o9k8q400.fsf@wheatstone.g10code.de>
References: <1784563.ycYbank3zz@storm.m.i2n>
 <87tvu1te8g.fsf@wheatstone.g10code.de> <3184488.u4he08tPDS@storm.m.i2n>
 <87o9k8q400.fsf@wheatstone.g10code.de>
Message-ID: <82d1ddaa-ec5c-e69a-048a-652d8438abd4@digitalbrains.com>

On 28/02/18 20:59, Werner Koch wrote:
> But that is about gpg and not about gpgsm.

Currently, it's not that easy to get the keygrip for an OpenPGP
smartcard key.

For keys for which the public part is available, it's:
$ gpg --card-status
Note desired KEYID
$ gpg --with-keygrip -k $KEYID
Find the KEYID in the certificate listed and see the keygrip below it.

I have smartcards with Auth keys that are not part of an OpenPGP
certificate. For these and other cases where the public part is not in
the keyring, it's more difficult to get the keygrip. Probably something
like:
$ gpg-connect-agent 'keyinfo --list' /bye|grep 87061340
for my GnuK with serial FFFE 87061340.

So if --card-status would actually use the --with-keygrip option, it
would be much easier to look up the keygrip for an OpenPGP smartcard,
*especially* when the smartcard is not currently in use by gpg. Even
though the query is done by "gpg --card-status", it is more a feature
for OpenPGP smartcards regardless of whether they are used for OpenPGP keys.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180301/e0cb05ea/attachment.sig>

From kr at glsys.de  Thu Mar  1 15:26:34 2018
From: kr at glsys.de (=?utf-8?Q?Klaus_R=C3=B6mer?=)
Date: Thu, 1 Mar 2018 15:26:34 +0100
Subject: gnupg SmartCard V3.3
In-Reply-To: <2789559.azVr8nC1vH@storm.m.i2n>
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <87woyxrwls.fsf@wheatstone.g10code.de>
 <E0FFB870-122B-482F-B50C-DBBC6F95E5A9@glsys.de>
 <2789559.azVr8nC1vH@storm.m.i2n>
Message-ID: <DE6FDD94-A281-4916-B13A-DCE0179E380D@glsys.de>

Thank you all for the support!
The mail about needing support for the V3.3 cards in opensc pointed me in the right direction.
I relied on the information that the V3.3 is backwards compatible to the V2.1
but this does not seem to be the case.
Compiling a fresh gpg 2.2.5  with --enable-ccid-driver from source did the trick for the linux machines.

Kind Regards,
 Klaus R?mer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180301/896f2f39/attachment.sig>

From wk at gnupg.org  Thu Mar  1 17:16:50 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 01 Mar 2018 17:16:50 +0100
Subject: gnupg SmartCard V3.3
In-Reply-To: <E0FFB870-122B-482F-B50C-DBBC6F95E5A9@glsys.de> ("Klaus
 =?utf-8?Q?R=C3=B6mer=22's?=
 message of "Thu, 1 Mar 2018 10:08:14 +0100")
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>
 <87woyxrwls.fsf@wheatstone.g10code.de>
 <E0FFB870-122B-482F-B50C-DBBC6F95E5A9@glsys.de>
Message-ID: <874llzn53h.fsf@wheatstone.g10code.de>

On Thu,  1 Mar 2018 10:08, kr at glsys.de said:

> i found this ct 2017-10 (german computer magazine) Article,
> where they claim the reader to be working with the openpgp smartcard Version 2.1 
> by transfering precreated 4096-Bit keys. This is exactly what i am

Well most drivers work on Windows because they fix them using their
Windows drivers.  This does not work on Linux because tehre is no
generic (and proprietary) driver for them.

> So either i am doing something stupid or the V3.3 card incorporated changes which broke this.
> I ordered another reader and asked if it would be possible do buy some
> 2.1 cards for cross-tersting, but it seems they would have to be

The interface part of the 3.3 cards is not different from the 2.1 cards;
the chnages are just in the OpenPGP card application which counterpart
is in GnuPG.

> Can anybody suggest how i could further debug the --card-edit and --card-status to find out why the stubs are not being generated?

Now, are you on 2.1.11 or 2.2.3?


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180301/b0046521/attachment.sig>

From thomas.jarosch at intra2net.com  Thu Mar  1 18:18:10 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Thu, 01 Mar 2018 18:18:10 +0100
Subject: openpgp smartcard: ssh auth speed vs. RSA key size
Message-ID: <1820120.8HcFG6KVnb@storm.m.i2n>

Hello together,

here's an interesting observation on ssh auth speed
when using different key sizes on the openpgp smartcard:

RSA 2048 bit key: 0.7s
RSA 4096 bit key: 3.1s

Card used is an openpgp smartcard V3.3
with gnupg 2.2.4. The ssh key is accessed via gpg-agent.

We found this while creating our keys with 4096 bit and now reverted to 2048 
bit. It's secure enough and the speed hit is almost not noticeable.

The time was measured with:

	$ time ssh SERVERNAME /bin/true

Cheers,
Thomas





From ben at adversary.org  Thu Mar  1 18:27:26 2018
From: ben at adversary.org (Ben McGinnes)
Date: Fri, 2 Mar 2018 04:27:26 +1100
Subject: Use the same passphrase for PGP and SSH keys and get prompted
 only once by gpg-agent
In-Reply-To: <87po4ptdnx.fsf@wheatstone.g10code.de>
References: <874lmqs3bn.fsf@gmail.com> <87a7wdxcd7.fsf@wheatstone.g10code.de>
 <87o9ktm1gg.fsf@gmail.com> <87r2pox4t4.fsf@wheatstone.g10code.de>
 <20180221062734.4riam3btaqgpkrl5@adversary.org>
 <87po4ptdnx.fsf@wheatstone.g10code.de>
Message-ID: <20180301172726.7i2zryqzxsjzk5er@adversary.org>

On Wed, Feb 28, 2018 at 03:02:58PM +0100, Werner Koch wrote:
> On Wed, 21 Feb 2018 07:27, ben at adversary.org said:
> 
> >> No, there is no way to configure an extra hack to also test a passphrase
> >> for an ssh key.
> >
> > Wanna bet?
> 
> Oh no, I don't want to promote create solutions of our complex API ;-)

Heheh.

I have a friend who frequently used to say that if a question began
with "Would it be wrong to ..." then the answer was always "No."

I think it was about the point where I asked, "Would it be wrong to
release freshwater crocodiles just a little upstream of [local picnic
area where children feed ducks and geese] just in time for the summer
holidays?" that he gave up.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180302/d516a70d/attachment-0001.sig>

From wk at gnupg.org  Thu Mar  1 19:14:39 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 01 Mar 2018 19:14:39 +0100
Subject: [FEATURE REQ] Keygrips in --card-status
In-Reply-To: <82d1ddaa-ec5c-e69a-048a-652d8438abd4@digitalbrains.com> (Peter
 Lebbing's message of "Thu, 1 Mar 2018 13:06:03 +0100")
References: <1784563.ycYbank3zz@storm.m.i2n>
 <87tvu1te8g.fsf@wheatstone.g10code.de>
 <3184488.u4he08tPDS@storm.m.i2n>
 <87o9k8q400.fsf@wheatstone.g10code.de>
 <82d1ddaa-ec5c-e69a-048a-652d8438abd4@digitalbrains.com>
Message-ID: <87y3jbll2o.fsf@wheatstone.g10code.de>

On Thu,  1 Mar 2018 13:06, peter at digitalbrains.com said:

> So if --card-status would actually use the --with-keygrip option, it
> would be much easier to look up the keygrip for an OpenPGP smartcard,

Good suggestion.  Here is the output you will see in 2.2.6 when
--with-keygrip is used with --card-status:

Signature counter : 4604
Signature key ....: C1D3 4B69 219E 4AEE C0BA  1C21 E3FD FF21 8E45 B72B
      created ....: 2015-02-18 18:12:18
      keygrip ....: 1D538E0FA8DFC2ED7F0382ED25ADE1EF23D12C5C
Encryption key....: DC9D AC60 8A8F 118F D8D0  F332 F4EC 45F1 1B45 7A45
      created ....: 2016-02-14 13:12:34
      keygrip ....: EE5A80CF605C7B8A2402E9CB41B553F2E5069B33
Authentication key: 59CE FA65 05DF 817B 3FE9  8F57 A588 F0D2 ABD0 CAF6
      created ....: 2016-02-14 13:14:07
      keygrip ....: EE5A80CF605C7B8A2402E9CB41B553F2E5069B33

and the --with-colons output has an addtional "grp: record (even without
--with-keygrip).


Shalom-Salam,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180301/8283b6bd/attachment.sig>

From wk at gnupg.org  Thu Mar  1 19:20:02 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 01 Mar 2018 19:20:02 +0100
Subject: openpgp smartcard: ssh auth speed vs. RSA key size
In-Reply-To: <1820120.8HcFG6KVnb@storm.m.i2n> (Thomas Jarosch's message of
 "Thu, 01 Mar 2018 18:18:10 +0100")
References: <1820120.8HcFG6KVnb@storm.m.i2n>
Message-ID: <87sh9jlktp.fsf@wheatstone.g10code.de>

On Thu,  1 Mar 2018 18:18, thomas.jarosch at intra2net.com said:

> We found this while creating our keys with 4096 bit and now reverted to 2048 
> bit. It's secure enough and the speed hit is almost not noticeable.

With a gnuk token and an ed25519 key it will even be much faster than
with a RSA 2048 bit key and a real smartcard.  Unfortunately the
Zeitcontrol card does not support ed25519.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180301/7e3a926f/attachment.sig>

From wk at gnupg.org  Thu Mar  1 19:21:31 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 01 Mar 2018 19:21:31 +0100
Subject: Use the same passphrase for PGP and SSH keys and get prompted
 only once by gpg-agent
In-Reply-To: <87po4ptdnx.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Wed, 28 Feb 2018 15:02:58 +0100")
References: <874lmqs3bn.fsf@gmail.com> <87a7wdxcd7.fsf@wheatstone.g10code.de>
 <87o9ktm1gg.fsf@gmail.com> <87r2pox4t4.fsf@wheatstone.g10code.de>
 <20180221062734.4riam3btaqgpkrl5@adversary.org>
 <87po4ptdnx.fsf@wheatstone.g10code.de>
Message-ID: <87fu5jlkr8.fsf@wheatstone.g10code.de>

On Wed, 28 Feb 2018 15:02, wk at gnupg.org said:

> Oh no, I don't want to promote create solutions of our complex API ;-)

s/create/creative/



-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180301/c12ddbe5/attachment.sig>

From dkg at fifthhorseman.net  Fri Mar  2 05:20:43 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 01 Mar 2018 23:20:43 -0500
Subject: entropy gathering daemon
In-Reply-To: <87sh9lrvrx.fsf@wheatstone.g10code.de>
References: <E1er38O-0008UR-MR@wheatstone.g10code.de>
 <87sh9lrvrx.fsf@wheatstone.g10code.de>
Message-ID: <87sh9jqfac.fsf@fifthhorseman.net>

On Wed 2018-02-28 16:14:42 +0100, Werner Koch wrote:
> On Wed, 28 Feb 2018 15:53, edgar at pettijohn-web.com said:
>
>> for chroot'd programs that need it on a filesystem mounted nodev. I
>> sent some patches awhile back to add arc4random_buf as the entropy
>> gathering 'device'. Which I've been using with no problems since. And
>
> In case you have a problem with scarce entropy you may want to add
>
> only-urandom
>
> to /etc/gcrypt/random.conf - in almost all cases this okay for all
> libgcrypt users.

On the GNU/Linux platform, /dev/random is basically a legacy interface
at this point.  See the modern documentation in random(4).

/dev/urandom is considered appropriate for all use cases except the
early boot.  However, GnuPG and gcrypt don't know whether the're being
used in the early boot process or not.  Therefore, according to
random(4) they should be using the getrandom(2) system call with no
flags set.

Is there any chance that gcrypt will adopt this approach on GNU/Linux
systems, or at least make it available so that GnuPG can use it?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180301/81411122/attachment.sig>

From wk at gnupg.org  Fri Mar  2 16:30:04 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Mar 2018 16:30:04 +0100
Subject: entropy gathering daemon
In-Reply-To: <87sh9jqfac.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Thu, 01 Mar 2018 23:20:43 -0500")
References: <E1er38O-0008UR-MR@wheatstone.g10code.de>
 <87sh9lrvrx.fsf@wheatstone.g10code.de>
 <87sh9jqfac.fsf@fifthhorseman.net>
Message-ID: <87tvtysdfn.fsf@wheatstone.g10code.de>

On Fri,  2 Mar 2018 05:20, dkg at fifthhorseman.net said:

> Is there any chance that gcrypt will adopt this approach on GNU/Linux
> systems, or at least make it available so that GnuPG can use it?

This is already the case since libgcrypt 1.7.1; /etc/gcrypt/random.conf
was only added with 1.8.0.

Note that you can't verify that by watching for an open of
/dev/[u]random - the device will be opened in any case.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180302/1503879c/attachment.sig>

From rjh at sixdemonbag.org  Sat Mar  3 05:43:26 2018
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 2 Mar 2018 23:43:26 -0500
Subject: New employment
Message-ID: <1bbb1369-830c-fff2-6636-079fe731090c@sixdemonbag.org>

I'm taking a new job with IronNet Cybersecurity, which is run by former
Director of the National Security Agency Keith Alexander.  My work will
not overlap with GnuPG in any way.

I'm presenting this in a spirit of full disclosure, so that if and when
it comes out later that "the guy who maintains the FAQ was spotted in a
bar with Keith Alexander last December!", people here can say "yeah, it
was a corporate Christmas party, big deal".



From wk at gnupg.org  Sat Mar  3 17:21:06 2018
From: wk at gnupg.org (Werner Koch)
Date: Sat, 03 Mar 2018 17:21:06 +0100
Subject: New employment
In-Reply-To: <1bbb1369-830c-fff2-6636-079fe731090c@sixdemonbag.org> (Robert
 J. Hansen's message of "Fri, 2 Mar 2018 23:43:26 -0500")
References: <1bbb1369-830c-fff2-6636-079fe731090c@sixdemonbag.org>
Message-ID: <87bmg5ruz1.fsf@wheatstone.g10code.de>

On Sat,  3 Mar 2018 05:43, rjh at sixdemonbag.org said:
> I'm taking a new job with IronNet Cybersecurity, which is run by former
> Director of the National Security Agency Keith Alexander.  My work will
> not overlap with GnuPG in any way.

Thanks for letting us know and thanks for maintaining the FAQ and for
all the other help you provide here.


Salam-Shalom,

   Werner


ps. 
For those who don't know IcronNet they may want to search for Bruce
Schneiers comments.

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180303/1d3baffa/attachment.sig>

From bereska at hotmail.com  Sat Mar  3 19:40:35 2018
From: bereska at hotmail.com (Dmitry Gudkov)
Date: Sat, 3 Mar 2018 18:40:35 +0000
Subject: New employment
In-Reply-To: <87bmg5ruz1.fsf@wheatstone.g10code.de>
References: <1bbb1369-830c-fff2-6636-079fe731090c@sixdemonbag.org>
 <87bmg5ruz1.fsf@wheatstone.g10code.de>
Message-ID: <DM5PR01MB22365447A588DC1FEDA04F51A6C40@DM5PR01MB2236.prod.exchangelabs.com>

thanks, Robert
good luck
we'll miss you

On 03/03/2018 19:21, Werner Koch wrote:

On Sat,  3 Mar 2018 05:43, rjh at sixdemonbag.org<mailto:rjh at sixdemonbag.org> said:


I'm taking a new job with IronNet Cybersecurity, which is run by former
Director of the National Security Agency Keith Alexander.  My work will
not overlap with GnuPG in any way.



Thanks for letting us know and thanks for maintaining the FAQ and for
all the other help you provide here.


Salam-Shalom,

   Werner


ps.
For those who don't know IcronNet they may want to search for Bruce
Schneiers comments.





_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org<mailto:Gnupg-users at gnupg.org>
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users&data=02%7C01%7C%7Cd9436b5b8e8945850a4608d5812c3eb8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636556949381454703&sdata=%2Bzn7gd9e%2F3uhqHoQZ0bvwkofwbw5r%2BeDcLp0HIZktcY%3D&reserved=0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180303/6e74cd7d/attachment-0001.html>

From mattator at gmail.com  Sat Mar  3 18:50:52 2018
From: mattator at gmail.com (Matt)
Date: Sun, 4 Mar 2018 02:50:52 +0900
Subject: [gpgme] generate a wheel of the python bindings
Message-ID: <CADHp1NwWG2Evek7k+UUvVCf1xQzxyeMdj0RKdCKz+0yQCZ7iiw@mail.gmail.com>

Hi,

I've been trying to package gpgme python bindings for nixos
(www.nixos.org) since it's a dependency of the mail reader I use
(alot) but I haven't succeeded yet.

I manage to compile the python 2.7 bindings and to build a "wheel" (as
required by nixos, a wheel is a zip file replacing the older "egg'
binaries) but for some reason my wheel is empty ;/ (it has egg-info
but not the gpg package).

The -meager- result of my efforts is visible here
https://github.com/NixOS/nixpkgs/pull/30429#issuecomment-370126211 and

Also I believe that if one wants to be able to run "setup.py install",
he will need a patch similar to:
https://github.com/teto/gpgme/compare/7da01c7352d41eb33e445968b248544d301588f9...nix

I've tried asking on #python but couldn't find a solution. I really
some skilled user can help solve that as I miss my mailreader :)

Cheers


From basix at basix.tech  Sat Mar  3 20:41:54 2018
From: basix at basix.tech (Basix)
Date: Sun, 04 Mar 2018 04:41:54 +0900
Subject: GPG is not working because of log-file configuration
Message-ID: <1520106114.1892425.1290370304.63CE4647@webmail.messagingengine.com>

Hello, I'm a user of GPG and I got some problem.

Recently my machine showing this message when do something in GPG:

[sample at localhost ~]$ gpg
gpg: /home/sample/.gnupg/gpg.conf:5: invalid option
[sample at localhost ~]$ cat -n ~/.gnupg/gpg.conf
     1	
     2	###+++--- GPGConf ---+++###
     3	utf8-strings
     4	debug-level basic
     5	log-file socket:///home/sample/.gnupg/log-socket
     6	###+++--- GPGConf ---+++### 2018? 02? 22? (?) 
     7	# GPGConf edited this configuration file.
     8	# It will disable options before this marked block, but it will
     9	# never change anything below these lines.

I think Kleopatra or another GPG frontend misconfigured my gpg.conf. How do I fix it myself?

-- 
Public PGP Key:  DB68 98D2 0F92 613C


From basix at basix.tech  Sat Mar  3 21:06:34 2018
From: basix at basix.tech (Basix)
Date: Sun, 04 Mar 2018 05:06:34 +0900
Subject: GPG is not working because of gpg.conf
Message-ID: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>

Hello, I'm a user of GPG and I got some problem.

Recently my machine showing this message when do something in GPG:

[sample at localhost ~]$ gpg
gpg: /home/sample/.gnupg/gpg.conf:5: invalid option
[sample at localhost ~]$ cat -n ~/.gnupg/gpg.conf
     1	
     2	###+++--- GPGConf ---+++###
     3	utf8-strings
     4	debug-level basic
     5	log-file socket:///home/sample/.gnupg/log-socket
     6	###+++--- GPGConf ---+++### 2018? 02? 22? (?) 
     7	# GPGConf edited this configuration file.
     8	# It will disable options before this marked block, but it will
     9	# never change anything below these lines.

I think Kleopatra or another GPG frontend misconfigured my gpg.conf. How do I fix it myself? My GnuPG version is 1.4.22.

-- 
Public PGP Key:  DB68 98D2 0F92 613C


From basix at basix.tech  Sat Mar  3 21:05:31 2018
From: basix at basix.tech (Basix)
Date: Sun, 04 Mar 2018 05:05:31 +0900
Subject: GPG is not working because of gpg.conf
Message-ID: <1520107531.1899665.1290388624.1857B976@webmail.messagingengine.com>

Hello, I'm a user of GPG and I got some problem.

Recently my machine showing this message when do something in GPG:

[sample at localhost ~]$ gpg
gpg: /home/sample/.gnupg/gpg.conf:5: invalid option
[sample at localhost ~]$ cat -n ~/.gnupg/gpg.conf
     1	
     2	###+++--- GPGConf ---+++###
     3	utf8-strings
     4	debug-level basic
     5	log-file socket:///home/sample/.gnupg/log-socket
     6	###+++--- GPGConf ---+++### 2018? 02? 22? (?) 
     7	# GPGConf edited this configuration file.
     8	# It will disable options before this marked block, but it will
     9	# never change anything below these lines.

I think Kleopatra or another GPG frontend misconfigured my gpg.conf. How do I fix it myself? My GnuPG version is 1.4.22.

-- 
Public PGP Key:  DB68 98D2 0F92 613C


From basix at basix.tech  Sat Mar  3 22:19:47 2018
From: basix at basix.tech (Basix)
Date: Sun, 04 Mar 2018 06:19:47 +0900
Subject: GPG is not working because of log-file configuration
In-Reply-To: <1520106114.1892425.1290370304.63CE4647@webmail.messagingengine.com>
References: <1520106114.1892425.1290370304.63CE4647@webmail.messagingengine.com>
Message-ID: <1520111987.1922534.1290428944.553FFC9B@webmail.messagingengine.com>

On ?, 04 3? 2018 04:41 +0900, Basix <basix at basix.tech> wrote:
> Hello, I'm a user of GPG and I got some problem.

Sorry for another thread with same contents. My email client had some problem.


-- 
Public PGP Key:  0F92613C


From ben at adversary.org  Sat Mar  3 23:46:15 2018
From: ben at adversary.org (Ben McGinnes)
Date: Sun, 4 Mar 2018 09:46:15 +1100
Subject: New employment
In-Reply-To: <1bbb1369-830c-fff2-6636-079fe731090c@sixdemonbag.org>
References: <1bbb1369-830c-fff2-6636-079fe731090c@sixdemonbag.org>
Message-ID: <20180303224615.mjwdyf3mfhxjb56h@adversary.org>

On Fri, Mar 02, 2018 at 11:43:26PM -0500, Robert J. Hansen wrote:
> I'm taking a new job with IronNet Cybersecurity,

Congratulations.  :-)

> which is run by former Director of the National Security Agency
> Keith Alexander.  My work will not overlap with GnuPG in any way.

Well, that trumps my need to leave GPG signed copies of completing the
ITAR questionaire on the git server, so thanks for that.

> I'm presenting this in a spirit of full disclosure, so that if and
> when it comes out later that "the guy who maintains the FAQ was
> spotted in a bar with Keith Alexander last December!", people here
> can say "yeah, it was a corporate Christmas party, big deal".

Heh.

If you happen to run into anyone who was working in their SNAC
division around 2008, thank them for me.  Though their copy has since
been taken off their website, this little document proved invaluable
in a little data forensics job I did in 2015:

http://okbounty.adversary.org/pdf_risks.pdf

I'll never meet the author and probably never even know who it was,
but there work was greatly appreciated (to the tune of a five figure
pay day for five days of work).


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180304/c8525991/attachment.sig>

From ben at adversary.org  Sun Mar  4 00:39:27 2018
From: ben at adversary.org (Ben McGinnes)
Date: Sun, 4 Mar 2018 10:39:27 +1100
Subject: [gpgme] generate a wheel of the python bindings
In-Reply-To: <CADHp1NwWG2Evek7k+UUvVCf1xQzxyeMdj0RKdCKz+0yQCZ7iiw@mail.gmail.com>
References: <CADHp1NwWG2Evek7k+UUvVCf1xQzxyeMdj0RKdCKz+0yQCZ7iiw@mail.gmail.com>
Message-ID: <20180303233927.nwvqjbx3pcchcq2o@adversary.org>

On Sun, Mar 04, 2018 at 02:50:52AM +0900, Matt wrote:
> Hi,
> 
> I've been trying to package gpgme python bindings for nixos
> (www.nixos.org) since it's a dependency of the mail reader I use
> (alot) but I haven't succeeded yet.

Okay.

With GPGME as a dependency ... Claws or Mutt/Neomutt?

> I manage to compile the python 2.7 bindings and to build a "wheel"
> (as required by nixos, a wheel is a zip file replacing the older
> "egg' binaries) but for some reason my wheel is empty ;/ (it has
> egg-info but not the gpg package).

This is pretty much always going to run into trouble with these
bindings due to the nature of what they are.  Unlike other wrappers
(e.g. python-gnupg) they're a bit more than simply wrapping the
command line executables with subprocess invocations.

The GPGME Python bindings are built against the version of GPGME it's
released with; functions are linked to their C counterparts with SWIG
via the gpgme.h header file for that version.  In order to have
functional bindings in the python module, you must also have a
functional copy of GPGME built at the same time, for the same platform
(architecture and OS).

Which means providing a separate, precompiled python binary like a
wheel will almost always introduce unexpected errors and failures.

> The -meager- result of my efforts is visible here
> https://github.com/NixOS/nixpkgs/pull/30429#issuecomment-370126211 and

Interesting.  I can definitely answer one part of it, though:

The reason you ended up with an "empty" module was because you were
just trying to build the module as a stand alone Python module.
Without the rest of the GPGME C API to which it's bound, it is
effectively useless.  With the two together, however, it provides a
pythonic interface to the entire GnuPG suite of software and
libraries.

When GPGME is compiled it produces the gpgme.h file most relevant to
that host (from src/gpgme.h.in) and once that's done the building and
installation of the various bindings in lang/ are performed against
that gpgme.h file.

> Also I believe that if one wants to be able to run "setup.py install",
> he will need a patch similar to:
> https://github.com/teto/gpgme/compare/7da01c7352d41eb33e445968b248544d301588f9...nix

No chance.  It'd introduce too many points of failure and an
expectation that these bindings will behave the same way as PyNaCl or
cryptography.py.

Also, your repo there looks like an old release, somewhere in the beta
period before 1.10.0 was released.  There have definitely been
significant updates to both GPGME and the python bindings since then.

> I've tried asking on #python but couldn't find a solution.

Yeah, I saw that, but it seems I missed you by a couple of hours or
so.

> I really some skilled user can help solve that as I miss my
> mailreader :)

I'm not really familiar with NixOS, but from what I've read it's
another Linux distribution with its own take on package management.
If that system can handle both binary packages and compiling packages
from source, like many other package managers, then it should be
achievable.

If it only has the facility to provide binary packages then you will
need to build those binaries for every single architecture and OS type
Nix supports in order to do so.  Either that or go bloat happy and try
to support as many as possible.  This is very much *not* recommended,
however, because it is quite possible that incorporating something for
one set of architecture and system version could very easily cause
problems with others.

There are certainly other package managers which are already quite
capable of correctly building GPGME and the Python bindings.  I build
it regularly on OS X with a slightly mixed approach.  I use MacPorts
to grab all the library dependencies and build from source (actually
most of my ports are built from source, but not quite all); the gnupg2
(i.e. GPG 2.2.x) has a slightly modified configuration (compared to
the standard portfile) and then built from source.

Then I build GPGME manually while referencing the dependencies in
/opt/local, but installing to /usr/local (so it finds my preferred
installation of Python 3 instead of the MacPorts one).  After running
autogen.sh I use this configure command:

    ./configure --prefix=/usr/local --exec-prefix=/usr/local \
    --with-libgpg-error-prefix=/opt/local \
    --with-libassuan-prefix=/opt/local --enable-maintainer-mode

Followed by the usual make, make check, sudo make install (though you
can use gmake instead if there's a difference on your system).

I also adjust the portfile for Neomutt to use my manually built GPGME
in /usr/local instead of the one kicking around in /opt/local (which
is just there to tick the dependency boxes for other packages).


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180304/e75c2980/attachment.sig>

From 1301716945 at qq.com  Sun Mar  4 06:11:27 2018
From: 1301716945 at qq.com (1301716945 at qq.com)
Date: Sun, 04 Mar 2018 13:11:27 +0800
Subject: Is there an easy way to create an Android application?
Message-ID: <i5rh7gqls9rotbkri7hv8i4f.1520139987510@email.android.com>+7084ABCE39A9B5B9

If I want to create a Android front end for gpg. Is there an easy way? Maybe use command-line to interaction with gpg?
My English is poor.
Thank you.

From basix at basix.tech  Sun Mar  4 11:04:47 2018
From: basix at basix.tech (Basix)
Date: Sun, 04 Mar 2018 19:04:47 +0900
Subject: Is there an easy way to create an Android application?
In-Reply-To: <i5rh7gqls9rotbkri7hv8i4f.1520139987510@email.android.com>
References: <i5rh7gqls9rotbkri7hv8i4f.1520139987510@email.android.com>
Message-ID: <1520157887.3163023.1290775616.4856DFA8@webmail.messagingengine.com>

On ?, 04 3? 2018 13:11 +0800, "1301716945 at qq.com" <1301716945 at qq.com> wrote:
> If I want to create a Android front end for gpg. Is there an easy way? 
> Maybe use command-line to interaction with gpg?
> My English is poor.
> Thank you.
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

If you just need Android front-end for GPG, please consider using OpenKeychain. But if you want to create an application, you should learn how to make application and take a look at some PGP library.

-- 
Public PGP Key:  0F92613C


From wangtianjiao.wang959 at gmail.com  Sun Mar  4 11:34:09 2018
From: wangtianjiao.wang959 at gmail.com (Genghuang Wang)
Date: Sun, 4 Mar 2018 18:34:09 +0800
Subject: Is there an easy way to create an Android application?
In-Reply-To: <5a9bc0be.828adf0a.da4c6.1a01SMTPIN_ADDED_BROKEN@mx.google.com>
References: <5a9bc0be.828adf0a.da4c6.1a01SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CAL57ndHdj0TEavpooUjtCNMRvdFAo+tstyV6k18icNhgeBJNSQ@mail.gmail.com>

Hello

There is an old project for porting GnuPG to Android, by the Guardian
Project, but is no longer maintained. The old website is in
https://guardianproject.info/code/gnupg/ , But this project recommends
an Android APP called OpenKeychain. It is an OpenPGP implementation
for Android. It is hosted at
https://github.com/open-keychain/open-keychain .  It is open source in
the license of GPLv3.

If you would like to develop an application based on OpenKeychain, you
have to open source in GPLv3, too.

On 4 March 2018 at 13:11, 1301716945 at qq.com <1301716945 at qq.com> wrote:
> If I want to create a Android front end for gpg. Is there an easy way? Maybe use command-line to interaction with gpg?
> My English is poor.
> Thank you.
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From kloecker at kde.org  Sun Mar  4 17:33:26 2018
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sun, 04 Mar 2018 17:33:26 +0100
Subject: GPG is not working because of log-file configuration
In-Reply-To: <1520106114.1892425.1290370304.63CE4647@webmail.messagingengine.com>
References: <1520106114.1892425.1290370304.63CE4647@webmail.messagingengine.com>
Message-ID: <2601555.RID5udXWQF@thufir>

On Samstag, 3. M?rz 2018 20:41:54 CET Basix wrote:
> Hello, I'm a user of GPG and I got some problem.
> 
> Recently my machine showing this message when do something in GPG:
> 
> [sample at localhost ~]$ gpg
> gpg: /home/sample/.gnupg/gpg.conf:5: invalid option
> [sample at localhost ~]$ cat -n ~/.gnupg/gpg.conf
>      1
>      2	###+++--- GPGConf ---+++###
>      3	utf8-strings
>      4	debug-level basic
>      5	log-file socket:///home/sample/.gnupg/log-socket
>      6	###+++--- GPGConf ---+++### 2018? 02? 22? (?)
>      7	# GPGConf edited this configuration file.
>      8	# It will disable options before this marked block, but it will
>      9	# never change anything below these lines.
> 
> I think Kleopatra or another GPG frontend misconfigured my gpg.conf. How do
> I fix it myself?

Remove the timestamp at the end of line 6. Apparently, the (UTF-8-encoded?) 
Unicode characters confuse gpg.

GPGConf probably should write the timestamp in ISO date/time format instead of 
in localized date/time format.


Regards,
Ingo





From mail at davidlasek.eu  Sun Mar  4 19:28:52 2018
From: mail at davidlasek.eu (D)
Date: Sun, 4 Mar 2018 19:28:52 +0100
Subject: initramfs - gpg decryption failed invalid IPC response
In-Reply-To: <87lgfdtdhr.fsf@wheatstone.g10code.de>
References: <8c08b400-b2c6-9459-2dc2-a7e0c2dc9691@davidlasek.eu>
 <87lgfdtdhr.fsf@wheatstone.g10code.de>
Message-ID: <3b443407-bf99-8f94-2238-a43b05201cc3@davidlasek.eu>

Thank you for getting back to me. I have added the options to the 
decryption command.

It reports that it fails on invoking `pinentry` utility.

I attached an image with the full log if interested.


pinentry-tty binary and gpg-agent.conf files are added to the the 
initram image here:

https://github.com/fogine/initramfs-scencrypt/blob/master/scencrypt-install#L22-L28


Have anything changed so that I'd need to set GPG_TTY to a specific value?

Currently I do not set the variable as I don't think I have access to 
the tty at that point.

I also tried to run `pinentry-tty -d` in the hook immediately before the 
gpg decryption command is executed - pinentry successfully started 
listening for STDIN, and I could use `GETPIN` command which would ask 
for a? PIN and dump it out. No error or debug messages were printed.

Any ideas?


On 02/28/2018 03:06 PM, Werner Koch wrote:
> On Wed, 31 Jan 2018 22:25,mail at davidlasek.eu  said:
>
>>  ??? gpg (GnuPG) 2.2.4
>>  ??? libgcrypt 1.8.2
>> And prints:
>>
>>     gpg: encrypted with <bit-length> RSA key, ID <key id>. created
>>     <date> <owner name + email>
>>
>>     gpg: public key decryption failed: Invalid IPC response
>>
>>     gpg: decryption failed: No secret key
> Can you please add
>
>    --verbose --debug=ipc
>
> to the gpg invocation?  This will show the IPC and thus the invalid IPC
> response.
>
>
> Salam-Shalom,
>
>     Werner
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180304/61326b56/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootlog_gpg.jpg
Type: image/jpeg
Size: 367919 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180304/61326b56/attachment-0001.jpg>

From wk at gnupg.org  Sun Mar  4 19:59:47 2018
From: wk at gnupg.org (Werner Koch)
Date: Sun, 04 Mar 2018 19:59:47 +0100
Subject: GPG is not working because of gpg.conf
In-Reply-To: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 (basix@basix.tech's message of "Sun, 04 Mar 2018 05:06:34 +0900")
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
Message-ID: <877eqrsm3g.fsf@wheatstone.g10code.de>

On Sat,  3 Mar 2018 21:06, basix at basix.tech said:

> I think Kleopatra or another GPG frontend misconfigured my gpg.conf. How do I fix it myself? My GnuPG version is 1.4.22.

Create a possible empty file

   ~/.gnupg/gpg.conf-1

this will then be used for the 1.4 version.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180304/d61b6c41/attachment.sig>

From wk at gnupg.org  Sun Mar  4 20:17:28 2018
From: wk at gnupg.org (Werner Koch)
Date: Sun, 04 Mar 2018 20:17:28 +0100
Subject: GPG is not working because of log-file configuration
In-Reply-To: <2601555.RID5udXWQF@thufir> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22'?=
 =?utf-8?Q?s?= message of "Sun, 04 Mar 2018 17:33:26 +0100")
References: <1520106114.1892425.1290370304.63CE4647@webmail.messagingengine.com>
 <2601555.RID5udXWQF@thufir>
Message-ID: <87vaebr6pj.fsf@wheatstone.g10code.de>

On Sun,  4 Mar 2018 17:33, kloecker at kde.org said:

> Remove the timestamp at the end of line 6. Apparently, the (UTF-8-encoded?) 
> Unicode characters confuse gpg.

That looks like a c+p error.  The timestamp is an asctime and has no
Unicode characters.  But even then it won't harm because it is comment
line.

The problem the OP is due to the use of a gnupg-2 conf file with
gnupg-1.  If gnupg-1 is still required, the simpelest solution is to
create an empty  ~/.gnupg/gpg.conf-1 file.


Shalom-Salam,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180304/9e3ed4d5/attachment.sig>

From basix at basix.tech  Mon Mar  5 10:41:16 2018
From: basix at basix.tech (Basix)
Date: Mon, 05 Mar 2018 18:41:16 +0900
Subject: GPG is not working because of gpg.conf
In-Reply-To: <877eqrsm3g.fsf@wheatstone.g10code.de>
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
Message-ID: <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>

On Sun, 04 Mar 2018 19:59 +0100, Werner Koch <wk at gnupg.org> wrote:
> Create a possible empty file
> 
>    ~/.gnupg/gpg.conf-1
> 
> this will then be used for the 1.4 version.

I don't think this error is because of that because error message says gpg.conf.

-- 
Public PGP Key:  0F92613C


From guru at unixarea.de  Mon Mar  5 11:19:12 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 5 Mar 2018 11:19:12 +0100
Subject: using the SSH secret key fails sometimes
Message-ID: <20180305101912.GA18176@sh4-5.1blu.de>


Hello,

This is on FreeBSD with:

$ gpg2 --version
gpg (GnuPG) 2.1.19
libgcrypt 1.7.6

$ ps ax | egrep 'gnu|pcs'
1034  -  Ss     0:00,59 gpg-agent --homedir /home/guru/.gnupg-ccid --use-standard-socket 
1036  -  S      0:02,24 scdaemon --multi-server --homedir /home/guru/.gnupg-ccid
3844  -  S      0:01,04 /usr/local/sbin/pcscd

>From time to time (let's say 1-2 times a day) the access to the SSH secret on
the OpenPGP card fails. The card is already unlocked in this moment
because the unlocking the KDE desktop has asked for the PIN.
Initializing a SSH session produces the attached error in the scdaemon's
log file.

It helps to withdraw the card and insert it again (which starts a new
proc /usr/local/sbin/pcscd).

Any idea where to look? Thanks

	matthias


2018-03-05 10:53:40 scdaemon[1036.802017e00] manejador del descriptor 13 iniciado
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK GNU Privacy Guard's Smartcard server ready
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- SERIALNO
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S SERIALNO D27600012401020100050000532B0000
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- GETINFO card_list
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S SERIALNO D27600012401020100050000532B0000
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- SERIALNO --demand=D27600012401020100050000532B0000
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S SERIALNO D27600012401020100050000532B0000
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- GETATTR $AUTHKEYID
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S $AUTHKEYID OPENPGP.3
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- GETATTR SERIALNO
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S SERIALNO D27600012401020100050000532B0000
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- READKEY OPENPGP.3
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(548 byte(s) skipped) ]
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- GETATTR $DISPSERIALNO
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S $DISPSERIALNO 00050000532B
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- SERIALNO --demand=D27600012401020100050000532B0000
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S SERIALNO D27600012401020100050000532B0000
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- SETDATA 3021300906052B0E03021A05000414579704ECB5FC67E700FAD99C8080277E86DCAD94
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> OK
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 <- PKAUTH OPENPGP.3
2018-03-05 10:53:40 scdaemon[1036.802017e00] pcsc_transmit failed: not transacted (0x80100016)
2018-03-05 10:53:40 scdaemon[1036.802017e00] apdu_send_simple(0) failed: general error
2018-03-05 10:53:40 scdaemon[1036.802017e00] operation auth result: General error
2018-03-05 10:53:40 scdaemon[1036.802017e00] app_auth failed: General error
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> ERR 100663297 General error <SCD>
2018-03-05 10:54:04 scdaemon[1036.802017e00] DBG: chan_13 <- BYE
2018-03-05 10:54:04 scdaemon[1036.802017e00] DBG: chan_13 -> OK closing connection
2018-03-05 10:54:04 scdaemon[1036.802017e00] manejador del descriptor 13 terminado

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub


From peter at digitalbrains.com  Mon Mar  5 12:53:04 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 5 Mar 2018 12:53:04 +0100
Subject: enigmail with pgp 2.2.4
In-Reply-To: <DM5PR01MB22363A85A50995E5988FCA62A6C20@DM5PR01MB2236.prod.exchangelabs.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
 <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
 <DM5PR01MB223671FDE24F7590B9184E83A6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <db30bf83-b148-8f9d-9b63-7b98f38329e1@digitalbrains.com>
 <DM5PR01MB22363A85A50995E5988FCA62A6C20@DM5PR01MB2236.prod.exchangelabs.com>
Message-ID: <b9d5ae64-7e0e-6b35-67ee-860c33ef755c@digitalbrains.com>

On 25/02/18 15:45, Dmitry Gudkov wrote:> i thought you forgot about me)

It's all a matter of free time and willingness. If I have 5 minutes and
see a question I can quickly answer, I might do that. But if an answer
takes a lot of time, it will have to wait.

> I have a confession to make, too. Not only I'm not a developer, but I'm
> a fresh convert from os to linux).

Ah, welcome :-). Using software that was not provided by or specifically
for your distribution is an advanced topic, so it's not surprising you
might feel uncertain what to do at times.

> Correct me if I'm wrong but the best conclusion I could make for your
> letter is that unless I locally build a Debian package myself (the
> epitome of thoroughness!), I can't be 100% sure everything works as it
> should.

Well, building Debian packages is the best way to integrate into the
Ubuntu ecosystem. But that doesn't mean it's the only good solution.
Installing stuff into /usr/local is a time-honored Unix tradition. Many
distributions will respect those traditions. I'm merely indicating that
I'm not sure I'm giving 100% correct advice. But if I'm right, it should
just work fine.

> I guess it must
> be boring for you to dedicate more of your time on this, but I can't
> help but asking to provide one for me in hope that there are some more
> inexperienced GNU/Linux users on this mailing list who might be very
> much interested in building the epitome of thoroughness themselves but
> just too shy to ask for guidance)

It's not boring, it's time-consuming, that's the problem. I will not
build packages for Ubuntu 16.04. As a matter of fact, I think interest
in 16.04 will drop a bit in one and a half month :-). But if I can find
the time for it, I might have a look at building those equivs-packages
so you can use your local installation in /usr/local instead of the
packaged version.

But I haven't found that time yet.

I did notice an old post on gnupg-devel that was replied to just now,
where Phil Pennock says he's packaging GnuPG 2.2 for Ubuntu 16.04:
<https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033211.html>

But he's explicitly staying out of the way of the 2.1.11 offered by
Ubuntu. That makes it more difficult to use for the end user. It seems
wise when the system has 2.0 installed. But I think there's something to
be said for going a bit further in the case of 16.04 and install a
recent 2.2 for usage by the whole system. The system already has a 2.1+
version, so anything that depends on gpg2 being 2.0 will already be
broken; you can't break it any further anyway. And 2.1.11 has known bugs
and deficiencies, and the fixes have not been backported by Ubuntu. It
seems nothing but a win to replace it with 2.2.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180305/0a3fe68d/attachment.sig>

From peter at digitalbrains.com  Mon Mar  5 12:53:53 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 5 Mar 2018 12:53:53 +0100
Subject: [FEATURE REQ] Keygrips in --card-status
In-Reply-To: <87y3jbll2o.fsf@wheatstone.g10code.de>
References: <1784563.ycYbank3zz@storm.m.i2n>
 <87tvu1te8g.fsf@wheatstone.g10code.de> <3184488.u4he08tPDS@storm.m.i2n>
 <87o9k8q400.fsf@wheatstone.g10code.de>
 <82d1ddaa-ec5c-e69a-048a-652d8438abd4@digitalbrains.com>
 <87y3jbll2o.fsf@wheatstone.g10code.de>
Message-ID: <3799d412-e0bc-388e-9ef6-e10dc32b536e@digitalbrains.com>

On 01/03/18 19:14, Werner Koch wrote:
> Good suggestion.  Here is the output you will see in 2.2.6 when
> --with-keygrip is used with --card-status:

Ah, great, thanks!

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180305/5ca73dbc/attachment.sig>

From peter at digitalbrains.com  Mon Mar  5 12:56:49 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 5 Mar 2018 12:56:49 +0100
Subject: GPG is not working because of gpg.conf
In-Reply-To: <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
Message-ID: <f33f75f3-6550-3c8a-b756-5a8e926bf435@digitalbrains.com>

On 05/03/18 10:41, Basix wrote:
> I don't think this error is because of that because error message says gpg.conf.

The problem is that the log-file option is not supported by GnuPG 1.4;
it was introduced in some 2.x version.

GnuPG 1.4.22 will look for the following files in order:
~/.gnupg/gpg.conf-1.4.22
~/.gnupg/gpg.conf-1.4
~/.gnupg/gpg.conf-1
~/.gnupg/gpg.conf

and it will take the first one it sees and stop there. By creating
gpg.conf-1, it will never get to gpg.conf and take the unsupported
option from there. Any configuration for GnuPG 1.4.22 will have to be
done in gpg.conf-1, and a 2.x version will still pick up the log-file
option from gpg.conf.

HTH,

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180305/0ce73998/attachment-0001.sig>

From wk at gnupg.org  Mon Mar  5 13:24:28 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 05 Mar 2018 13:24:28 +0100
Subject: GPG is not working because of gpg.conf
In-Reply-To: <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
 (basix@basix.tech's message of "Mon, 05 Mar 2018 18:41:16 +0900")
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
Message-ID: <87inaapv5v.fsf@wheatstone.g10code.de>

On Mon,  5 Mar 2018 10:41, basix at basix.tech said:

> I don't think this error is because of that because error message says gpg.conf.

gpg searches for its configurarion file in this order (I use 1.4.23 as
example):

  gpg.conf-1.4.23
  gpg.conf-1.4
  gpg.conf-1
  gpg.conf

The first existing one is used.  This allows to have separate
configuration files for different gpg versions.  But take care, the GUI
configuration dialogs parse and modify only gpg.conf.


Shalom-Salam,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180305/1532d2aa/attachment.sig>

From bereska at hotmail.com  Mon Mar  5 14:40:25 2018
From: bereska at hotmail.com (Dmitry Gudkov)
Date: Mon, 5 Mar 2018 13:40:25 +0000
Subject: enigmail with pgp 2.2.4
In-Reply-To: <b9d5ae64-7e0e-6b35-67ee-860c33ef755c@digitalbrains.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
 <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
 <DM5PR01MB223671FDE24F7590B9184E83A6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <db30bf83-b148-8f9d-9b63-7b98f38329e1@digitalbrains.com>
 <DM5PR01MB22363A85A50995E5988FCA62A6C20@DM5PR01MB2236.prod.exchangelabs.com>
 <b9d5ae64-7e0e-6b35-67ee-860c33ef755c@digitalbrains.com>
Message-ID: <DM5PR01MB22363F6BC16929BF19AF4788A6DA0@DM5PR01MB2236.prod.exchangelabs.com>

thank you for being patient with super noobs like me
hope you will find some time to build those packages
in the meantime I'll keep on learning GnuPG
by the way distro-packaged 2.1.11 in /usr/bin/gpg2 and freshly compiled
2.2.4 in /usr/local/bin/gpg live peacefully together on my ubuntu 16.04
machine to date
however I don't get to do much with it so far except for encrypt/decrypt
correspondence and files, edit/export/import keys to other machines,
backup, etc.

regards,
Dmitry

On 05/03/2018 14:53, Peter Lebbing wrote:
> On 25/02/18 15:45, Dmitry Gudkov wrote:> i thought you forgot about me)
> 
> It's all a matter of free time and willingness. If I have 5 minutes and
> see a question I can quickly answer, I might do that. But if an answer
> takes a lot of time, it will have to wait.
> 
>> I have a confession to make, too. Not only I'm not a developer, but I'm
>> a fresh convert from os to linux).
> 
> Ah, welcome :-). Using software that was not provided by or specifically
> for your distribution is an advanced topic, so it's not surprising you
> might feel uncertain what to do at times.
> 
>> Correct me if I'm wrong but the best conclusion I could make for your
>> letter is that unless I locally build a Debian package myself (the
>> epitome of thoroughness!), I can't be 100% sure everything works as it
>> should.
> 
> Well, building Debian packages is the best way to integrate into the
> Ubuntu ecosystem. But that doesn't mean it's the only good solution.
> Installing stuff into /usr/local is a time-honored Unix tradition. Many
> distributions will respect those traditions. I'm merely indicating that
> I'm not sure I'm giving 100% correct advice. But if I'm right, it should
> just work fine.
> 
>> I guess it must
>> be boring for you to dedicate more of your time on this, but I can't
>> help but asking to provide one for me in hope that there are some more
>> inexperienced GNU/Linux users on this mailing list who might be very
>> much interested in building the epitome of thoroughness themselves but
>> just too shy to ask for guidance)
> 
> It's not boring, it's time-consuming, that's the problem. I will not
> build packages for Ubuntu 16.04. As a matter of fact, I think interest
> in 16.04 will drop a bit in one and a half month :-). But if I can find
> the time for it, I might have a look at building those equivs-packages
> so you can use your local installation in /usr/local instead of the
> packaged version.
> 
> But I haven't found that time yet.
> 
> I did notice an old post on gnupg-devel that was replied to just now,
> where Phil Pennock says he's packaging GnuPG 2.2 for Ubuntu 16.04:
> <https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033211.html>
> 
> But he's explicitly staying out of the way of the 2.1.11 offered by
> Ubuntu. That makes it more difficult to use for the end user. It seems
> wise when the system has 2.0 installed. But I think there's something to
> be said for going a bit further in the case of 16.04 and install a
> recent 2.2 for usage by the whole system. The system already has a 2.1+
> version, so anything that depends on gpg2 being 2.0 will already be
> broken; you can't break it any further anyway. And 2.1.11 has known bugs
> and deficiencies, and the fixes have not been backported by Ubuntu. It
> seems nothing but a win to replace it with 2.2.
> 
> Peter.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180305/6c207bcb/attachment.sig>

From philipp.gesang at intra2net.com  Mon Mar  5 14:06:18 2018
From: philipp.gesang at intra2net.com (Philipp Gesang)
Date: Mon, 5 Mar 2018 14:06:18 +0100
Subject: agent losing connection to socket
Message-ID: <20180305130618.GD3840@drift.m.i2n>

Dear list,

for me the agent (v2.2.5) stops responding after one usage or
two. It doesn?t seem to recover from this state. Here is what I
know:

When resuming after a connection, the agent appears to stop
listening on its socket:

    12922 stat("/home/REDACTED/.config/gnupg", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
    12922 pselect6(8, [3 4 6 7], NULL, NULL, {tv_sec=4, tv_nsec=150980}, {[], 8}) = 0 (Timeout)
    ?
    12922 clone(child_stack=0x7fb24f6d7ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fb24f6d89d0, tls=0x7fb24f6d8700, child_tidptr=0x7fb24f6d89d0) = 13195
    ?
    13195 exit(0)                           = ?
    13195 +++ exited with 0 +++
    12922 <... pselect6 resumed> )          = 0 (Timeout)
    12922 wait4(13055, NULL, WNOHANG, NULL) = 0
    12922 pselect6(8, [6 7], NULL, NULL, {tv_sec=4, tv_nsec=236006}, {[], 8}) = 0 (Timeout)
    12922 wait4(13055, NULL, WNOHANG, NULL) = 0

Where fds 3 and 4 are the gpg and ssh sockets, respectively. 6
and 7 are inotify handles. Agent log:

    2018-03-05 11:26:01 gpg-agent[12922] DBG: chan_10 -> BYE
    ?
    2018-03-05 11:26:01 gpg-agent[12922] ssh request handler for sign_request (13) ready
    2018-03-05 11:26:02 gpg-agent[12922] ssh handler 0x7fb24f6d8700 for fd 10 started
    2018-03-05 11:26:02 gpg-agent[12922] ssh handler 0x7fb24f6d8700 for fd 10 terminated
    2018-03-05 11:26:37 gpg-agent[12922] can't connect my own socket: IPC connect call failed
    2018-03-05 11:26:37 gpg-agent[12922] this process is useless - shutting down

At which point the agent continues indefinitely in the above
loop. It doesn?t recover even when HUP?ed.

gpg-agent runs socket-activated in ?supervised? mode. Passing
--disable-check-own-socket makes the problem disappear.

What is going on here?

Best,
Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180305/3707fd00/attachment.sig>

From mattator at gmail.com  Mon Mar  5 19:15:38 2018
From: mattator at gmail.com (Matt)
Date: Tue, 6 Mar 2018 03:15:38 +0900
Subject: [gpgme] generate a wheel of the python bindings
In-Reply-To: <20180303233927.nwvqjbx3pcchcq2o@adversary.org>
References: <CADHp1NwWG2Evek7k+UUvVCf1xQzxyeMdj0RKdCKz+0yQCZ7iiw@mail.gmail.com>
 <20180303233927.nwvqjbx3pcchcq2o@adversary.org>
Message-ID: <CADHp1Nx6cv4X=-mD0HbrhLNZuhzJYDUHpyorCqO1EC_5DELTHQ@mail.gmail.com>

Thanks for the detail answer.

> With GPGME as a dependency ... Claws or Mutt/Neomutt?
Nope, just "alot" :) https://github.com/pazz/alot

Your mail cleared some of my doubts: Nixos is a source based
distribution with binary cache. I was trying to package the python
bindings separately than gpgme because it seemed cleaner. At the end
of the day though I just overcomplicated things. Looking into more
details building a wheel is not necessary either so I will just use
the upstream `make install`.

python seems to run some tests during the build but I couldn't find
the flag to prevent these ? I found
"--disable-gpgconf-test" "--disable-gpg-test" "--disable-gpgsm-test"
"--disable-g13-test" but  none disable the python tests.

Ideally I would make the tests run too (nixos rules don't make it
mandatory but it's encouraged) but iI wonder if the paths
"/build/gpgme-1.10.0/lang/python/tests/" are ok ? (it's unusual to see
a path starting with "/build" ).

=====
gcc -pthread -shared -lgcc_s -g -O2 -Wall -Wcast-align -Wshadow
-Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W
-Wextra -Wbad-function-cast -Wwrite-strings
-Wdeclaration-after-statement -Wno-missing-field-initializers
-Wno-sign-compare -Wpointer-arith
python2-gpg/temp.linux-x86_64-2.7/python2-gpg/gpgme_wrap.o
python2-gpg/temp.linux-x86_64-2.7/python2-gpg/helpers.o
-L../../src/.libs
-L/nix/store/7b2z0vfbs9539ga4pxx5gmli47rz5y3n-python-2.7.14/lib
-lpython2.7 -o python2-gpg/lib.linux-x86_64-2.7/gpg/_gpgme.so
-L/nix/store/3m9br2anary4yssv6ag2kjh35i0qnhim-gpgme-1.10.0/lib -lgpgme
-L/nix/store/drlbifsp8ivs4fb3pk8sf2i58s82456y-libassuan-2.5.1/lib
-lassuan -L/nix/store/y92c6dahh8i7wjhlh71mj5c1225a5073-libgpg-error-1.27/lib
-lgpg-error
running build_py
copying gpg/core.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
copying gpg/results.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
copying gpg/util.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
copying gpg/__init__.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
copying gpg/callbacks.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
copying gpg/errors.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/validity.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/create.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/status.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/sigsum.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/event.py -> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/pk.py -> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/md.py -> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/protocol.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/import.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/keysign.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
copying gpg/constants/__init__.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants
creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/data
copying gpg/constants/data/encoding.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/data
copying gpg/constants/data/__init__.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/data
creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/keylist
copying gpg/constants/keylist/mode.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/keylist
copying gpg/constants/keylist/__init__.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/keylist
creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
copying gpg/constants/sig/notation.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
copying gpg/constants/sig/mode.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
copying gpg/constants/sig/__init__.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/tofu
copying gpg/constants/tofu/__init__.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/tofu
copying gpg/constants/tofu/policy.py ->
python2-gpg/lib.linux-x86_64-2.7/gpg/constants/tofu
make[4]: Leaving directory '/build/gpgme-1.10.0/lang/python'
Making all in tests
make[4]: Entering directory '/build/gpgme-1.10.0/lang/python/tests'
echo no-force-v3-sigs > ./gpg.conf
echo ignore-invalid-option agent-program >> ./gpg.conf
echo "agent-program `which gpg-agent`|--debug-quick-random" >> ./gpg.conf
/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash:
which: command not found
echo pinentry-program /build/gpgme-1.10.0/tests/gpg/pinentry >gpg-agent.conf
gpgconf --kill all
/nix/store/cb3slv3szhp46xkrczqw7mscy5mnk64l-coreutils-8.29/bin/mkdir
-p ./private-keys-v1.d
for k in ../../../tests/gpg/13CD0F3BDF24BE53FE192D62F18737256FF6E4FD
../../../tests/gpg/76F7E2B35832976B50A27A282D9B87E44577EB66
../../../tests/gpg/A0747D5F9425E6664F4FFBEED20FBCA79FDED2BD
../../../tests/gpg/13CBE3758AFE42B5E5E2AE4CED27AFA455E3F87F
../../../tests/gpg/7A030357C0F253A5BBCD282FFC4E521B37558F5C; do \
          cp $k private-keys-v1.d/${k#../../../tests/gpg/}.key; \
        done
echo x > ./private-keys-v1.d/gpg-sample.stamp
gpg --batch --no-permission-warning \
               --import ../../../tests/gpg/pubdemo.asc
gpg: keybox '/build/gpgme-1.10.0/lang/python/tests/pubring.kbx' created
gpg: /build/gpgme-1.10.0/lang/python/tests/trustdb.gpg: trustdb created
gpg: key 2D727CC768697734: public key "Alfa Test (demo key)
<alfa at example.net>" imported
gpg: failed to start agent '|--debug-quick-random': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: key FE180B1DA9E3B0B2: public key "Bob (demo key)" imported
gpg: failed to start agent '|--debug-quick-random': No such file or directory
gpg: can't connect to the agent: No such file or directory
....
gpg: Total number processed: 26
gpg:               imported: 26
make[4]: *** [Makefile:630: pubring-stamp] Error 2
make[4]: Leaving directory '/build/gpgme-1.10.0/lang/python/tests'
make[3]: *** [Makefile:471: all-recursive] Error 1
....
make: *** [Makefile:449: all] Error 2

2018-03-04 8:39 GMT+09:00 Ben McGinnes <ben at adversary.org>:
> On Sun, Mar 04, 2018 at 02:50:52AM +0900, Matt wrote:
>> Hi,
>>
>> I've been trying to package gpgme python bindings for nixos
>> (www.nixos.org) since it's a dependency of the mail reader I use
>> (alot) but I haven't succeeded yet.
>
> Okay.
>
> With GPGME as a dependency ... Claws or Mutt/Neomutt?
>
>> I manage to compile the python 2.7 bindings and to build a "wheel"
>> (as required by nixos, a wheel is a zip file replacing the older
>> "egg' binaries) but for some reason my wheel is empty ;/ (it has
>> egg-info but not the gpg package).
>
> This is pretty much always going to run into trouble with these
> bindings due to the nature of what they are.  Unlike other wrappers
> (e.g. python-gnupg) they're a bit more than simply wrapping the
> command line executables with subprocess invocations.
>
> The GPGME Python bindings are built against the version of GPGME it's
> released with; functions are linked to their C counterparts with SWIG
> via the gpgme.h header file for that version.  In order to have
> functional bindings in the python module, you must also have a
> functional copy of GPGME built at the same time, for the same platform
> (architecture and OS).
>
> Which means providing a separate, precompiled python binary like a
> wheel will almost always introduce unexpected errors and failures.
>
>> The -meager- result of my efforts is visible here
>> https://github.com/NixOS/nixpkgs/pull/30429#issuecomment-370126211 and
>
> Interesting.  I can definitely answer one part of it, though:
>
> The reason you ended up with an "empty" module was because you were
> just trying to build the module as a stand alone Python module.
> Without the rest of the GPGME C API to which it's bound, it is
> effectively useless.  With the two together, however, it provides a
> pythonic interface to the entire GnuPG suite of software and
> libraries.
>
> When GPGME is compiled it produces the gpgme.h file most relevant to
> that host (from src/gpgme.h.in) and once that's done the building and
> installation of the various bindings in lang/ are performed against
> that gpgme.h file.
>
>> Also I believe that if one wants to be able to run "setup.py install",
>> he will need a patch similar to:
>> https://github.com/teto/gpgme/compare/7da01c7352d41eb33e445968b248544d301588f9...nix
>
> No chance.  It'd introduce too many points of failure and an
> expectation that these bindings will behave the same way as PyNaCl or
> cryptography.py.
>
> Also, your repo there looks like an old release, somewhere in the beta
> period before 1.10.0 was released.  There have definitely been
> significant updates to both GPGME and the python bindings since then.
>
>> I've tried asking on #python but couldn't find a solution.
>
> Yeah, I saw that, but it seems I missed you by a couple of hours or
> so.
>
>> I really some skilled user can help solve that as I miss my
>> mailreader :)
>
> I'm not really familiar with NixOS, but from what I've read it's
> another Linux distribution with its own take on package management.
> If that system can handle both binary packages and compiling packages
> from source, like many other package managers, then it should be
> achievable.
>
> If it only has the facility to provide binary packages then you will
> need to build those binaries for every single architecture and OS type
> Nix supports in order to do so.  Either that or go bloat happy and try
> to support as many as possible.  This is very much *not* recommended,
> however, because it is quite possible that incorporating something for
> one set of architecture and system version could very easily cause
> problems with others.
>
> There are certainly other package managers which are already quite
> capable of correctly building GPGME and the Python bindings.  I build
> it regularly on OS X with a slightly mixed approach.  I use MacPorts
> to grab all the library dependencies and build from source (actually
> most of my ports are built from source, but not quite all); the gnupg2
> (i.e. GPG 2.2.x) has a slightly modified configuration (compared to
> the standard portfile) and then built from source.
>
> Then I build GPGME manually while referencing the dependencies in
> /opt/local, but installing to /usr/local (so it finds my preferred
> installation of Python 3 instead of the MacPorts one).  After running
> autogen.sh I use this configure command:
>
>     ./configure --prefix=/usr/local --exec-prefix=/usr/local \
>     --with-libgpg-error-prefix=/opt/local \
>     --with-libassuan-prefix=/opt/local --enable-maintainer-mode
>
> Followed by the usual make, make check, sudo make install (though you
> can use gmake instead if there's a difference on your system).
>
> I also adjust the portfile for Neomutt to use my manually built GPGME
> in /usr/local instead of the one kicking around in /opt/local (which
> is just there to tick the dependency boxes for other packages).
>
>
> Regards,
> Ben


From ben at adversary.org  Mon Mar  5 19:30:16 2018
From: ben at adversary.org (Ben McGinnes)
Date: Tue, 6 Mar 2018 05:30:16 +1100
Subject: GPG is not working because of gpg.conf
In-Reply-To: <87inaapv5v.fsf@wheatstone.g10code.de>
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
 <87inaapv5v.fsf@wheatstone.g10code.de>
Message-ID: <20180305183016.4j4ihrbjwewyenbg@adversary.org>

On Mon, Mar 05, 2018 at 01:24:28PM +0100, Werner Koch wrote:
> 
> gpg searches for its configurarion file in this order (I use 1.4.23 as
> example):
> 
>   gpg.conf-1.4.23
>   gpg.conf-1.4
>   gpg.conf-1
>   gpg.conf
> 
> The first existing one is used.  This allows to have separate
> configuration files for different gpg versions.  But take care, the GUI
> configuration dialogs parse and modify only gpg.conf.

Good to know, but will a version of GPG always select the highest in a
listor the closest number to its own version number if there's not an
exact match?

So if we slightly modify that example and say we have these conf
files:

 1. gpg.conf-1.4.23
 2. gpg.conf-1.4.20
 3. gpg.conf-1.4
 4. gpg.conf-1
 5. gpg.conf

Now if I'm using 1.4.21, will it select the closest version number
(1.4.20) or the highest (1.4.23)?


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180306/877c472c/attachment.sig>

From 2017-r3sgs86x8e-lists-groups at riseup.net  Mon Mar  5 22:23:01 2018
From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA)
Date: Mon, 5 Mar 2018 21:23:01 +0000
Subject: GPG is not working because of gpg.conf
In-Reply-To: <20180305183016.4j4ihrbjwewyenbg@adversary.org>
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com> 
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
 <87inaapv5v.fsf@wheatstone.g10code.de>
 <20180305183016.4j4ihrbjwewyenbg@adversary.org>
Message-ID: <124852262.20180305212301@my_localhost_LG>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Monday 5 March 2018 at 6:30:16 PM, in
<mid:20180305183016.4j4ihrbjwewyenbg at adversary.org>, Ben McGinnes
wrote:-


> So if we slightly modify that example and say we have
> these conf
> files:

>  1. gpg.conf-1.4.23
>  2. gpg.conf-1.4.20
>  3. gpg.conf-1.4
>  4. gpg.conf-1
>  5. gpg.conf

> Now if I'm using 1.4.21, will it select the closest
> version number
> (1.4.20) or the highest (1.4.23)?

I would have expected it to select 1.4.

- --
Best regards

MFPA                  <mailto:2017-r3sgs86x8e-lists-groups at riseup.net>

The truth is rarely pure and never simple
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWp21NV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+jUMAQDR/irt5ixECYg64F+f4qwgZ11hqsIqforEmBcmSIUkhgD/QarLecFOL2Yg
0O1X2zuOHqKStjOTalJXGPisivbsoAGJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWp21NV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/8XeD/4xmQ23enmgyZIHT6euylTNHXW1
DMsgGCQPg9laaIv0N5bc5L/XwD0putCOjyapicMetv7T8IY8Dn+ZkPgepkfdY8jd
9hXJBPg5MLyiasayWziBtu0/4ZT35GHLOMMaEBYG6W+OnH3eRcaAsYxD7c1PzI7b
fTR20gJX2tJemSuLLWKNgpt4ZZhJBxeLHmR+BDJ8Tm3hKB0o/xuzXRm0cjEy/ZHh
lo0kpRV6VJgDmArC5bApEXqjADpgYEQFKgL+sdbGI3BV6M7HDGEa10VfxWw+u7fR
H6w0o8bgUtj0IpyFSyUct0BDPqLwO+3gLr0WalgQEMpOBjuF0bNnEJ9PIiO6nsGJ
a7k+n1tO9HxA+94IRWiZyM0HdcXyDXObvIFzFIx1x3LbF7BGFW4nVzoxi9nzJws9
Toquh5noxFyHfJr+P+0uUI2y3LQ4a1Kjga4303BJjxPd+TsycddmTQr80Hakyo+R
vX2jXkCc4ED9Pz2L3vIYsymiyvyBKnvwIlN6+kv1WBoV5nySFUCKQepU/9VEsnLT
GAsiJYjrwPvEERWejOynQU0vkHW6IARwjltLsIEKsK+r6MB+9IQcE3Rgxex63w82
4FE7SpWhU75NwVag/h+Qfes6u6d3gjphAFV50q/bMW4oP7XgW9IPuJacw/Z4tXBo
3NOV/TvoIy5kAOzX/g==
=LrGl
-----END PGP SIGNATURE-----



From wk at gnupg.org  Tue Mar  6 09:53:01 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Mar 2018 09:53:01 +0100
Subject: GPG is not working because of gpg.conf
In-Reply-To: <20180305183016.4j4ihrbjwewyenbg@adversary.org> (Ben McGinnes's
 message of "Tue, 6 Mar 2018 05:30:16 +1100")
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
 <87inaapv5v.fsf@wheatstone.g10code.de>
 <20180305183016.4j4ihrbjwewyenbg@adversary.org>
Message-ID: <87efkxoaaa.fsf@wheatstone.g10code.de>

On Mon,  5 Mar 2018 19:30, ben at adversary.org said:

> Good to know, but will a version of GPG always select the highest in a
> listor the closest number to its own version number if there's not an
> exact match?

No, the algorithm views the version as a string simply trims the
dot/dash delimted parts one after the other until it finds an _exact_
match.

> Now if I'm using 1.4.21, will it select the closest version number
> (1.4.20) or the highest (1.4.23)?

It will use 1.4

Note that there is another compatibility feature which can be used to
ignore errors due to new options.  For example:

--8<---------------cut here---------------start------------->8---
ignore-invalid-option  foo bar
verbose
foo
--8<---------------cut here---------------end--------------->8---

Here foo is an option only available in 2.3.0 but you want to use this
gpg.conf also with gpg 2.2.5.  The ignore-invalid-option meta option
will silently ignore unknown options named "foo" or "bar".  Multiple
ignore-invalid-option lines are cumulative.

This feature is available since 1.4.13 and 2.0.20 .


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180306/5c531031/attachment.sig>

From tlikonen at iki.fi  Tue Mar  6 10:30:02 2018
From: tlikonen at iki.fi (Teemu Likonen)
Date: Tue, 06 Mar 2018 11:30:02 +0200
Subject: GPG is not working because of gpg.conf
In-Reply-To: <87efkxoaaa.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Tue, 06 Mar 2018 09:53:01 +0100")
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
 <87inaapv5v.fsf@wheatstone.g10code.de>
 <20180305183016.4j4ihrbjwewyenbg@adversary.org>
 <87efkxoaaa.fsf@wheatstone.g10code.de>
Message-ID: <87lgf5o8kl.fsf@iki.fi>

Werner Koch [2018-03-06 09:53:01+01] wrote:

> Note that there is another compatibility feature which can be used to
> ignore errors due to new options.  For example:
>
> ignore-invalid-option  foo bar
> verbose
> foo

> This feature is available since 1.4.13 and 2.0.20 .

The feature is not documented in 2.1.18. Is it documented in newer
versions?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180306/2b06a86b/attachment.sig>

From tlikonen at iki.fi  Tue Mar  6 10:35:40 2018
From: tlikonen at iki.fi (Teemu Likonen)
Date: Tue, 06 Mar 2018 11:35:40 +0200
Subject: GPG is not working because of gpg.conf
In-Reply-To: <87inaapv5v.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Mon, 05 Mar 2018 13:24:28 +0100")
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
 <87inaapv5v.fsf@wheatstone.g10code.de>
Message-ID: <87h8pto8b7.fsf@iki.fi>

Werner Koch [2018-03-05 13:24:28+01] wrote:

> gpg searches for its configurarion file in this order (I use 1.4.23 as
> example):
>
>   gpg.conf-1.4.23
>   gpg.conf-1.4
>   gpg.conf-1
>   gpg.conf

That feature is not documented in 2.1.18 but it seems to work. (I tried
"gpg.conf-2.1".)


-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180306/7b4fd041/attachment.sig>

From divan at santanas.co.za  Tue Mar  6 13:11:59 2018
From: divan at santanas.co.za (Divan Santana)
Date: Tue, 06 Mar 2018 14:11:59 +0200
Subject: gpg agent Could not add identity agent refused operation
Message-ID: <878tb51jzk.fsf@santanas.co.za>

Hello,

I'm trying to use gpg-agent to manage my ssh key though am getting this
error:

  ~ ? ssh-add ~/.ssh/id_rsa
  Enter passphrase for /home/admin/.ssh/id_rsa:
  Could not add identity "/home/admin/.ssh/id_rsa": agent refused operation

Is this because I have a 16k RSA ssh key?
How can I debug this further? I've tried many diff suggestions I found
online but none of them work for me.

  ~ ? ssh-keygen -l -f ~/.ssh/id_rsa.pub
  16384 SHA256:oMs4Eq8/34jDDV/TXjJ5POZVhIDKTD0WWCPLZtHSVqs swish (RSA)

More info:

  ~ ? echo $SSH_AUTH_SOCK
  /home/admin/.gnupg/S.gpg-agent.ssh
  ~ ? ll /home/admin/.gnupg/S.gpg-agent.ssh
  srwx------ 1 admin admin 0 Mar  6 09:46 /home/admin/.gnupg/S.gpg-agent.ssh
  ~ ? ps -ef |egrep 'gpg'
  admin     3290     1  0 09:46 ?        00:00:00 gpg-agent --homedir
  /home/admin/.gnupg --use-standard-socket --daemon

  ~ ? cat .gnupg/gpg-agent.conf
  pinentry-program /usr/bin/pinentry-gtk-2
  default-cache-ttl 3600
  max-cache-ttl 36000
  enable-ssh-support
  default-cache-ttl-ssh 36000

  ~ ? cat .gnupg/gpg.conf |egrep -v '^#|^$'
  require-cross-certification
  keyserver  hkp://keys.gnupg.net
  default-key  B6DC7019551B9B96
  use-agent

  ~ ? pacman -Q |grep -i gnupg
  gnupg 2.2.5-1

Thanks very much!
--
Divan


From mattator at gmail.com  Tue Mar  6 16:36:24 2018
From: mattator at gmail.com (Matt)
Date: Wed, 7 Mar 2018 00:36:24 +0900
Subject: [gpgme] generate a wheel of the python bindings
In-Reply-To: <CADHp1Nx6cv4X=-mD0HbrhLNZuhzJYDUHpyorCqO1EC_5DELTHQ@mail.gmail.com>
References: <CADHp1NwWG2Evek7k+UUvVCf1xQzxyeMdj0RKdCKz+0yQCZ7iiw@mail.gmail.com>
 <20180303233927.nwvqjbx3pcchcq2o@adversary.org>
 <CADHp1Nx6cv4X=-mD0HbrhLNZuhzJYDUHpyorCqO1EC_5DELTHQ@mail.gmail.com>
Message-ID: <CADHp1Nz5om_XWa4exeZBcRbVRMeF89LnWbdFaOuMpvuu1gZpUA@mail.gmail.com>

All problems disappeared with latest source. So everything is ok :)
Thank you once again

2018-03-06 3:15 GMT+09:00 Matt <mattator at gmail.com>:
> Thanks for the detail answer.
>
>> With GPGME as a dependency ... Claws or Mutt/Neomutt?
> Nope, just "alot" :) https://github.com/pazz/alot
>
> Your mail cleared some of my doubts: Nixos is a source based
> distribution with binary cache. I was trying to package the python
> bindings separately than gpgme because it seemed cleaner. At the end
> of the day though I just overcomplicated things. Looking into more
> details building a wheel is not necessary either so I will just use
> the upstream `make install`.
>
> python seems to run some tests during the build but I couldn't find
> the flag to prevent these ? I found
> "--disable-gpgconf-test" "--disable-gpg-test" "--disable-gpgsm-test"
> "--disable-g13-test" but  none disable the python tests.
>
> Ideally I would make the tests run too (nixos rules don't make it
> mandatory but it's encouraged) but iI wonder if the paths
> "/build/gpgme-1.10.0/lang/python/tests/" are ok ? (it's unusual to see
> a path starting with "/build" ).
>
> =====
> gcc -pthread -shared -lgcc_s -g -O2 -Wall -Wcast-align -Wshadow
> -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W
> -Wextra -Wbad-function-cast -Wwrite-strings
> -Wdeclaration-after-statement -Wno-missing-field-initializers
> -Wno-sign-compare -Wpointer-arith
> python2-gpg/temp.linux-x86_64-2.7/python2-gpg/gpgme_wrap.o
> python2-gpg/temp.linux-x86_64-2.7/python2-gpg/helpers.o
> -L../../src/.libs
> -L/nix/store/7b2z0vfbs9539ga4pxx5gmli47rz5y3n-python-2.7.14/lib
> -lpython2.7 -o python2-gpg/lib.linux-x86_64-2.7/gpg/_gpgme.so
> -L/nix/store/3m9br2anary4yssv6ag2kjh35i0qnhim-gpgme-1.10.0/lib -lgpgme
> -L/nix/store/drlbifsp8ivs4fb3pk8sf2i58s82456y-libassuan-2.5.1/lib
> -lassuan -L/nix/store/y92c6dahh8i7wjhlh71mj5c1225a5073-libgpg-error-1.27/lib
> -lgpg-error
> running build_py
> copying gpg/core.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
> copying gpg/results.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
> copying gpg/util.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
> copying gpg/__init__.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
> copying gpg/callbacks.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
> copying gpg/errors.py -> python2-gpg/lib.linux-x86_64-2.7/gpg
> creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/validity.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/create.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/status.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/sigsum.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/event.py -> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/pk.py -> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/md.py -> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/protocol.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/import.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/keysign.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> copying gpg/constants/__init__.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants
> creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/data
> copying gpg/constants/data/encoding.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/data
> copying gpg/constants/data/__init__.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/data
> creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/keylist
> copying gpg/constants/keylist/mode.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/keylist
> copying gpg/constants/keylist/__init__.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/keylist
> creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
> copying gpg/constants/sig/notation.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
> copying gpg/constants/sig/mode.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
> copying gpg/constants/sig/__init__.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/sig
> creating python2-gpg/lib.linux-x86_64-2.7/gpg/constants/tofu
> copying gpg/constants/tofu/__init__.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/tofu
> copying gpg/constants/tofu/policy.py ->
> python2-gpg/lib.linux-x86_64-2.7/gpg/constants/tofu
> make[4]: Leaving directory '/build/gpgme-1.10.0/lang/python'
> Making all in tests
> make[4]: Entering directory '/build/gpgme-1.10.0/lang/python/tests'
> echo no-force-v3-sigs > ./gpg.conf
> echo ignore-invalid-option agent-program >> ./gpg.conf
> echo "agent-program `which gpg-agent`|--debug-quick-random" >> ./gpg.conf
> /nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash:
> which: command not found
> echo pinentry-program /build/gpgme-1.10.0/tests/gpg/pinentry >gpg-agent.conf
> gpgconf --kill all
> /nix/store/cb3slv3szhp46xkrczqw7mscy5mnk64l-coreutils-8.29/bin/mkdir
> -p ./private-keys-v1.d
> for k in ../../../tests/gpg/13CD0F3BDF24BE53FE192D62F18737256FF6E4FD
> ../../../tests/gpg/76F7E2B35832976B50A27A282D9B87E44577EB66
> ../../../tests/gpg/A0747D5F9425E6664F4FFBEED20FBCA79FDED2BD
> ../../../tests/gpg/13CBE3758AFE42B5E5E2AE4CED27AFA455E3F87F
> ../../../tests/gpg/7A030357C0F253A5BBCD282FFC4E521B37558F5C; do \
>           cp $k private-keys-v1.d/${k#../../../tests/gpg/}.key; \
>         done
> echo x > ./private-keys-v1.d/gpg-sample.stamp
> gpg --batch --no-permission-warning \
>                --import ../../../tests/gpg/pubdemo.asc
> gpg: keybox '/build/gpgme-1.10.0/lang/python/tests/pubring.kbx' created
> gpg: /build/gpgme-1.10.0/lang/python/tests/trustdb.gpg: trustdb created
> gpg: key 2D727CC768697734: public key "Alfa Test (demo key)
> <alfa at example.net>" imported
> gpg: failed to start agent '|--debug-quick-random': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: key FE180B1DA9E3B0B2: public key "Bob (demo key)" imported
> gpg: failed to start agent '|--debug-quick-random': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> ....
> gpg: Total number processed: 26
> gpg:               imported: 26
> make[4]: *** [Makefile:630: pubring-stamp] Error 2
> make[4]: Leaving directory '/build/gpgme-1.10.0/lang/python/tests'
> make[3]: *** [Makefile:471: all-recursive] Error 1
> ....
> make: *** [Makefile:449: all] Error 2
>
> 2018-03-04 8:39 GMT+09:00 Ben McGinnes <ben at adversary.org>:
>> On Sun, Mar 04, 2018 at 02:50:52AM +0900, Matt wrote:
>>> Hi,
>>>
>>> I've been trying to package gpgme python bindings for nixos
>>> (www.nixos.org) since it's a dependency of the mail reader I use
>>> (alot) but I haven't succeeded yet.
>>
>> Okay.
>>
>> With GPGME as a dependency ... Claws or Mutt/Neomutt?
>>
>>> I manage to compile the python 2.7 bindings and to build a "wheel"
>>> (as required by nixos, a wheel is a zip file replacing the older
>>> "egg' binaries) but for some reason my wheel is empty ;/ (it has
>>> egg-info but not the gpg package).
>>
>> This is pretty much always going to run into trouble with these
>> bindings due to the nature of what they are.  Unlike other wrappers
>> (e.g. python-gnupg) they're a bit more than simply wrapping the
>> command line executables with subprocess invocations.
>>
>> The GPGME Python bindings are built against the version of GPGME it's
>> released with; functions are linked to their C counterparts with SWIG
>> via the gpgme.h header file for that version.  In order to have
>> functional bindings in the python module, you must also have a
>> functional copy of GPGME built at the same time, for the same platform
>> (architecture and OS).
>>
>> Which means providing a separate, precompiled python binary like a
>> wheel will almost always introduce unexpected errors and failures.
>>
>>> The -meager- result of my efforts is visible here
>>> https://github.com/NixOS/nixpkgs/pull/30429#issuecomment-370126211 and
>>
>> Interesting.  I can definitely answer one part of it, though:
>>
>> The reason you ended up with an "empty" module was because you were
>> just trying to build the module as a stand alone Python module.
>> Without the rest of the GPGME C API to which it's bound, it is
>> effectively useless.  With the two together, however, it provides a
>> pythonic interface to the entire GnuPG suite of software and
>> libraries.
>>
>> When GPGME is compiled it produces the gpgme.h file most relevant to
>> that host (from src/gpgme.h.in) and once that's done the building and
>> installation of the various bindings in lang/ are performed against
>> that gpgme.h file.
>>
>>> Also I believe that if one wants to be able to run "setup.py install",
>>> he will need a patch similar to:
>>> https://github.com/teto/gpgme/compare/7da01c7352d41eb33e445968b248544d301588f9...nix
>>
>> No chance.  It'd introduce too many points of failure and an
>> expectation that these bindings will behave the same way as PyNaCl or
>> cryptography.py.
>>
>> Also, your repo there looks like an old release, somewhere in the beta
>> period before 1.10.0 was released.  There have definitely been
>> significant updates to both GPGME and the python bindings since then.
>>
>>> I've tried asking on #python but couldn't find a solution.
>>
>> Yeah, I saw that, but it seems I missed you by a couple of hours or
>> so.
>>
>>> I really some skilled user can help solve that as I miss my
>>> mailreader :)
>>
>> I'm not really familiar with NixOS, but from what I've read it's
>> another Linux distribution with its own take on package management.
>> If that system can handle both binary packages and compiling packages
>> from source, like many other package managers, then it should be
>> achievable.
>>
>> If it only has the facility to provide binary packages then you will
>> need to build those binaries for every single architecture and OS type
>> Nix supports in order to do so.  Either that or go bloat happy and try
>> to support as many as possible.  This is very much *not* recommended,
>> however, because it is quite possible that incorporating something for
>> one set of architecture and system version could very easily cause
>> problems with others.
>>
>> There are certainly other package managers which are already quite
>> capable of correctly building GPGME and the Python bindings.  I build
>> it regularly on OS X with a slightly mixed approach.  I use MacPorts
>> to grab all the library dependencies and build from source (actually
>> most of my ports are built from source, but not quite all); the gnupg2
>> (i.e. GPG 2.2.x) has a slightly modified configuration (compared to
>> the standard portfile) and then built from source.
>>
>> Then I build GPGME manually while referencing the dependencies in
>> /opt/local, but installing to /usr/local (so it finds my preferred
>> installation of Python 3 instead of the MacPorts one).  After running
>> autogen.sh I use this configure command:
>>
>>     ./configure --prefix=/usr/local --exec-prefix=/usr/local \
>>     --with-libgpg-error-prefix=/opt/local \
>>     --with-libassuan-prefix=/opt/local --enable-maintainer-mode
>>
>> Followed by the usual make, make check, sudo make install (though you
>> can use gmake instead if there's a difference on your system).
>>
>> I also adjust the portfile for Neomutt to use my manually built GPGME
>> in /usr/local instead of the one kicking around in /opt/local (which
>> is just there to tick the dependency boxes for other packages).
>>
>>
>> Regards,
>> Ben


From wk at gnupg.org  Tue Mar  6 18:30:57 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Mar 2018 18:30:57 +0100
Subject: GPG is not working because of gpg.conf
In-Reply-To: <87lgf5o8kl.fsf@iki.fi> (Teemu Likonen's message of "Tue, 06 Mar
 2018 11:30:02 +0200")
References: <1520107594.1900861.1290389288.49381EAF@webmail.messagingengine.com>
 <877eqrsm3g.fsf@wheatstone.g10code.de>
 <1520242876.3638873.1291668304.65C8369D@webmail.messagingengine.com>
 <87inaapv5v.fsf@wheatstone.g10code.de>
 <20180305183016.4j4ihrbjwewyenbg@adversary.org>
 <87efkxoaaa.fsf@wheatstone.g10code.de> <87lgf5o8kl.fsf@iki.fi>
Message-ID: <87zi3lkt66.fsf@wheatstone.g10code.de>

On Tue,  6 Mar 2018 10:30, tlikonen at iki.fi said:

> The feature is not documented in 2.1.18. Is it documented in newer
> versions?

It is kind of an emergency option in case we accidently remove an option
;-)


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180306/b853f822/attachment.sig>

From stefan.claas at posteo.de  Tue Mar  6 20:06:23 2018
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 6 Mar 2018 20:06:23 +0100
Subject: OS X - can't open GnuPG-2.2.5.dmg
Message-ID: <1b0123f8-59f7-c8fa-a689-7991367cc133@posteo.de>

Hi,

just tried to update my GnuPG install on my iMac,
from the SourceForge repository, but the image
won't open. The shasum matches and with DiskUtility
it shows also that the .dmg is o.k.

Downloaded several times, with the same result. :-(

Regards
Stefan

?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xD68B6EAC6ECF3AB6.asc
Type: application/pgp-keys
Size: 4268 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180306/edede773/attachment.key>

From guru at unixarea.de  Sat Mar 10 11:10:20 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Sat, 10 Mar 2018 11:10:20 +0100
Subject: OpenPGP card bricked
Message-ID: <20180310101020.GA2577@c720-r314251>


Hello,

After a power-off reset of my laptop the OpenPGP Card seems to be
damaged. The pcscd can't read the card anymore. It gives up with:

...
00006225 commands.c:244:CmdPowerOn Card absent or mute
00000052 ifdhandler.c:1213:IFDHPowerICC() PowerUp failed
00000017 eventhandler.c:301:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

(the full log is attached).

I already tried a different reader USB token (an HID Global OMNIKEY 6121)
and a different laptop. So, it seems to be the SIM card itself.

What can I do?

Thanks

	matthias

00000000 debuglog.c:289:DebugLogSetLevel() debug level=debug
00000731 configfile.l:358:DBGetReaderList() Parsing conf file: /usr/local/etc/reader.conf.d
00000059 pcscdaemon.c:655:main() pcsc-lite 1.8.20 daemon ready.
00013066 hotplug_libusb.c:536:HPAddHotPluggable() Adding USB device: 0:2:0
00002551 readerfactory.c:1079:RFInitializeReader() Attempting startup of Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00 using /usr/local/lib/pcsc/drivers//ifd-ccid.bundle/Contents/FreeBSD/libccid.so
00000308 readerfactory.c:954:RFBindFunctions() Loading IFD Handler 3.0
00000063 ifdhandler.c:1953:init_driver() Driver version: 1.4.25
00003982 ifdhandler.c:1970:init_driver() LogLevel: 0x0003
00000024 ifdhandler.c:1981:init_driver() DriverOptions: 0x0000
00002569 ifdhandler.c:110:CreateChannelByNameOrChannel() Lun: 0, device: usb:04e6/5816:libusb-1.0:0:2:0
00000067 ccid_usb.c:287:OpenUSBByName() Using: /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist
00003506 ccid_usb.c:305:OpenUSBByName() ifdManufacturerString: Ludovic Rousseau (ludovic.rousseau at free.fr)
00000019 ccid_usb.c:306:OpenUSBByName() ifdProductString: Generic CCID driver
00000015 ccid_usb.c:307:OpenUSBByName() Copyright: This driver is protected by terms of the GNU Lesser General Public License version 2.1, or (at your option) any later version.
00000803 ccid_usb.c:621:OpenUSBByName() Found Vendor/Product: 04E6/5816 (Identiv uTrust 3512 SAM slot Token)
00000021 ccid_usb.c:623:OpenUSBByName() Using USB bus/device: 0/2
00000012 ccid_usb.c:680:OpenUSBByName() bNumDataRatesSupported is 0
03074616 ccid_usb.c:836:ReadUSB() read failed (0/2): -7 LIBUSB_ERROR_TIMEOUT
01934240 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFB3, usb:04e6/5816:libusb-1.0:0:2:0 (lun: 0)
00000054 readerfactory.c:395:RFAddReader() Using the reader polling thread
00000591 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFAE, usb:04e6/5816:libusb-1.0:0:2:0 (lun: 0)
00000031 ifdhandler.c:470:IFDHGetCapabilities() Reader supports 1 slot(s)
00000072 hotplug_libusb.c:440:HPEstablishUSBNotifications() Driver ifd-ccid.bundle does not support IFD_GENERATE_HOTPLUG. Using active polling instead.
00000015 hotplug_libusb.c:449:HPEstablishUSBNotifications() Polling forced every 1 second(s)
00000071 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00001093 ifdhandler.c:1146:IFDHPowerICC() action: PowerUp, usb:04e6/5816:libusb-1.0:0:2:0 (lun: 0)
00008985 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00010735 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00010756 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00010201 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00010779 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00010778 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00010779 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00010848 readerfactory.c:1420:RFWaitForReaderInit() Waiting init for reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00006225 commands.c:244:CmdPowerOn Card absent or mute
00000052 ifdhandler.c:1213:IFDHPowerICC() PowerUp failed
00000017 eventhandler.c:301:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED
00000013 eventhandler.c:302:EHStatusHandlerThread() Error powering up card: 2148532246 0x80100016
59123860 pcscdaemon.c:192:signal_thread() Received signal: 2
00000047 pcscdaemon.c:225:signal_thread() Preparing for suicide
00361939 hotplug_libusb.c:403:HPRescanUsbBus() Hotplug stopped
00640696 readerfactory.c:1363:RFCleanupReaders() entering cleaning function
00000117 readerfactory.c:1372:RFCleanupReaders() Stopping reader: Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00
00000018 readerfactory.c:608:RFRemoveReader() UnrefReader() count was: 1
00000012 eventhandler.c:176:EHDestroyEventHandler() Stomping thread.
00000015 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFB1, usb:04e6/5816:libusb-1.0:0:2:0 (lun: 0)
00000012 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFB2, usb:04e6/5816:libusb-1.0:0:2:0 (lun: 0)
00000011 eventhandler.c:201:EHDestroyEventHandler() Request stopping of polling thread
00000011 ifdhandler.c:344:IFDHStopPolling() usb:04e6/5816:libusb-1.0:0:2:0 (lun: 0)
00401709 eventhandler.c:502:EHStatusHandlerThread() Die
00000177 eventhandler.c:216:EHDestroyEventHandler() Thread stomped.
00000019 readerfactory.c:1130:RFUnInitializeReader() Attempting shutdown of Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00.
00000025 ifdhandler.c:282:IFDHCloseChannel() usb:04e6/5816:libusb-1.0:0:2:0 (lun: 0)
00009467 ccid_usb.c:189:close_libusb_if_needed() libusb_exit
00000089 readerfactory.c:991:RFUnloadReader() Unloading reader driver.
00000133 winscard_svc.c:152:ContextsDeinitialize() remaining threads: 0
00000059 pcscdaemon.c:781:at_exit() cleaning /var/run/pcscd
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Thanks to the Soviet Army for the Victory in Stalingrad! -- ?????? ? ?????????????? ?????!


From ihholmes at gmail.com  Sat Mar 10 01:55:14 2018
From: ihholmes at gmail.com (Ian Holmes)
Date: Fri, 9 Mar 2018 16:55:14 -0800
Subject: gpg 2.2.5 hangs instead of asking for a passphrase
Message-ID: <CAOZ5s14YQm6TDFXB5_S69_Lhc20+BB3guodR3SJ0WXQYD50GyA@mail.gmail.com>

Hi,

I'm using gpg on macOS High Sierra, installed via homebrew. I have a file
that is CAST5 encrypted. When I try to decrypt it using my previous
homebrew version of gpg (gpg 2.0.30, libgcrypt 1.7.6), I type 'gpg
--decrypt myfile.txt.gpg' and it prints 'gpg5: CAST5 the screen clears, it
prompts me for a passphrase, the prompt screen disappears and my UNIX
prompt screen is restored, and then the decrypted file is displayed.
However, following a homebrew update (to gpg 2.2.5, libgcrypt 1.8.2), now
when I type the same command 'gpg --decrypt myfile.txt.gpg' it just hangs.
I can quit it with Ctrl-C. Symmetric encryption with '-c' seems similarly
broken: it hangs instead of asking for a passphrase.

Any thoughts? Could use some help please!

Cheers,
Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180309/ec759db9/attachment.html>

From patrick at enigmail.net  Sat Mar 10 18:49:44 2018
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sat, 10 Mar 2018 18:49:44 +0100
Subject: OS X - can't open GnuPG-2.2.5.dmg
In-Reply-To: <1b0123f8-59f7-c8fa-a689-7991367cc133__32859.4131199226$1520363226$gmane$org@posteo.de>
References: <1b0123f8-59f7-c8fa-a689-7991367cc133__32859.4131199226$1520363226$gmane$org@posteo.de>
Message-ID: <82a66c1d-eab4-b90f-d7d7-984474977128@enigmail.net>

On 06.03.18 20:06, Stefan Claas wrote:
> Hi,
> 
> just tried to update my GnuPG install on my iMac,
> from the SourceForge repository, but the image
> won't open. The shasum matches and with DiskUtility
> it shows also that the .dmg is o.k.
> 
> Downloaded several times, with the same result. :-(

The file opens fine on my Mac. I suspect that either there is a problem
with your OS (a reboot may help), or your iMac doesn't fulfill the
minimum installation requirements (macOS 10.9 or newer, running in
64-bit mode).

-Patrick


From ben at adversary.org  Sun Mar 11 07:22:15 2018
From: ben at adversary.org (Ben McGinnes)
Date: Sun, 11 Mar 2018 17:22:15 +1100
Subject: [gpgme] generate a wheel of the python bindings
In-Reply-To: <CADHp1Nz5om_XWa4exeZBcRbVRMeF89LnWbdFaOuMpvuu1gZpUA@mail.gmail.com>
References: <CADHp1NwWG2Evek7k+UUvVCf1xQzxyeMdj0RKdCKz+0yQCZ7iiw@mail.gmail.com>
 <20180303233927.nwvqjbx3pcchcq2o@adversary.org>
 <CADHp1Nx6cv4X=-mD0HbrhLNZuhzJYDUHpyorCqO1EC_5DELTHQ@mail.gmail.com>
 <CADHp1Nz5om_XWa4exeZBcRbVRMeF89LnWbdFaOuMpvuu1gZpUA@mail.gmail.com>
Message-ID: <20180311062215.zb2xorbas4nal4fk@adversary.org>

On Wed, Mar 07, 2018 at 12:36:24AM +0900, Matt wrote:
> All problems disappeared with latest source. So everything is ok :)
> Thank you once again

Excellent.  Some of the issues you raised (like oddness in test
output/behaviour) had already been picked up and fixed, as you no
doubt saw.  Not really enough for a new release just yet, but if
anyone has trouble it's a good first step to try the latest updates to
master.

Mind you, the most immediately recent updates haven't been code,
they've been docs (and there's more to come).

> 2018-03-06 3:15 GMT+09:00 Matt <mattator at gmail.com>:
> > Thanks for the detail answer.
> >
> >> With GPGME as a dependency ... Claws or Mutt/Neomutt?
> > Nope, just "alot" :) https://github.com/pazz/alot

I haven't looked, but I'm guessing from the name that it's a variation
on Notmuch, right?


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180311/1db82ebd/attachment.sig>

From stefan.claas at posteo.de  Sun Mar 11 16:14:40 2018
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 11 Mar 2018 16:14:40 +0100
Subject: OS X - can't open GnuPG-2.2.5.dmg
In-Reply-To: <82a66c1d-eab4-b90f-d7d7-984474977128@enigmail.net>
References: <1b0123f8-59f7-c8fa-a689-7991367cc133__32859.4131199226$1520363226$gmane$org@posteo.de>
 <82a66c1d-eab4-b90f-d7d7-984474977128@enigmail.net>
Message-ID: <f30a1c97-e19f-63e4-e04d-9cd8ae660689@posteo.de>



Am 10.03.18 um 18:49 schrieb Patrick Brunschwig:
> On 06.03.18 20:06, Stefan Claas wrote:
>> Hi,
>>
>> just tried to update my GnuPG install on my iMac,
>> from the SourceForge repository, but the image
>> won't open. The shasum matches and with DiskUtility
>> it shows also that the .dmg is o.k.
>>
>> Downloaded several times, with the same result. :-(
> The file opens fine on my Mac. I suspect that either there is a problem
> with your OS (a reboot may help), or your iMac doesn't fulfill the
> minimum installation requirements (macOS 10.9 or newer, running in
> 64-bit mode).
>
Well, i am running 10.11.6 and tried also again with 2.2.4 which works.

Tried also to open the 2.2.5 .dmg with Pacifist but it can't open it either.

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xD68B6EAC6ECF3AB6.asc
Type: application/pgp-keys
Size: 4268 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180311/4f504d24/attachment.key>

From patrick at enigmail.net  Sun Mar 11 17:44:18 2018
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sun, 11 Mar 2018 17:44:18 +0100
Subject: OS X - can't open GnuPG-2.2.5.dmg
In-Reply-To: <f30a1c97-e19f-63e4-e04d-9cd8ae660689@posteo.de>
References: <1b0123f8-59f7-c8fa-a689-7991367cc133__32859.4131199226$1520363226$gmane$org@posteo.de>
 <82a66c1d-eab4-b90f-d7d7-984474977128@enigmail.net>
 <f30a1c97-e19f-63e4-e04d-9cd8ae660689@posteo.de>
Message-ID: <c40aa868-424e-1f76-6484-a28b37958efe@enigmail.net>

On 11.03.18 16:14, Stefan Claas wrote:
> 
> 
> Am 10.03.18 um 18:49 schrieb Patrick Brunschwig:
>> On 06.03.18 20:06, Stefan Claas wrote:
>>> Hi,
>>>
>>> just tried to update my GnuPG install on my iMac,
>>> from the SourceForge repository, but the image
>>> won't open. The shasum matches and with DiskUtility
>>> it shows also that the .dmg is o.k.
>>>
>>> Downloaded several times, with the same result. :-(
>> The file opens fine on my Mac. I suspect that either there is a problem
>> with your OS (a reboot may help), or your iMac doesn't fulfill the
>> minimum installation requirements (macOS 10.9 or newer, running in
>> 64-bit mode).
>>
> Well, i am running 10.11.6 and tried also again with 2.2.4 which works.
> 
> Tried also to open the 2.2.5 .dmg with Pacifist but it can't open it either.

I fear I know what's wrong. For some reason that I still need to
discover, the image is created with the new APFS file system instead of
the HFS+. I'll see how to fix this.

-Patrick



From miro.rovis at croatiafidelis.hr  Sun Mar 11 20:57:13 2018
From: miro.rovis at croatiafidelis.hr (Miroslav Rovis)
Date: Sun, 11 Mar 2018 19:57:13 +0000
Subject: --export-options export-reset-subkey-passwd
In-Reply-To: <d5f61db3-81f5-e902-0f43-82b7e0c76595@grinta.net>
References: <6308661f-1769-3e76-84d4-b25168688cf6@grinta.net>
 <ab1cb679-83b7-00c2-87ee-2290d0f8bfba@grinta.net>
 <87mv6pqzdu.fsf@wheatstone.g10code.de>
 <d5f61db3-81f5-e902-0f43-82b7e0c76595@grinta.net>
Message-ID: <20180311195713.GA7043@gdOv>

Regarding my Devuan forums topic:
Safe GnuPG setup (with offlined master secret key)
https://dev1galaxy.org/viewtopic.php?id=1929
I've only found this email recenty on Gnupg Users ML that actually helped me a
lot to get my hands-on tentative/tutorial right.

This email that I'm replying to, but vaguely, below.

On 180128-17:37-0700, Daniele Nicolodi wrote:
> On 23/08/2017 23:59, Werner Koch wrote:
> > On Sun, 13 Aug 2017 08:17, daniele at grinta.net said:
> > 
> >> Digging a bit more, it seems that the functionality got dropped because
> >> with GnuPG 2.x all key manipulations go through gpg-agent and it does
> >> not (yet?) support password reset on expert.
> > 
> > Unfortunately this is still an open bug:
> > 
> >   https://dev.gnupg.org/T1753
> > 
> > we won't be able to fix it for 2.2.0 but given that it is marked as a
> > bug it can and should be fixed in the soon to be release 2.2 series.
> 
> As a work around I come up with this simple script, which has the sole
> problem of asking the secret subkey passphrase a few times too much, and
> to require to explicitly enter an empty passphrase.
> 
> Let me know if it is excessively dummy or if there is a better way.
> 
> Cheers,
> Daniele
> 
> 
> #!/bin/sh
> 
> set -e
> 
> KEY="$1"
> shift
> 
> # make sure to have a "!" at the end of the key fingerprint to export
> # exclusively the corresponding subkey and not the primary key
> if [ "$KEY" == "${KEY%\!}" ]
> then
>     KEY="$KEY"\!
> fi
> 
> umask 0077
> TMPDIR=$(mktemp -d)
> trap "rm -r $TMPDIR; exit" 0 1 2 3 15
> 
> gpg --export-secret-subkey "$KEY" | gpg --home $TMPDIR --import
> gpg --home $TMPDIR --change-passphrase "$KEY"
> gpg --home $TMPDIR --armor "$@" --export-secret-subkey "$KEY"
> 

I only now, on umptieth read, much better understand this script. Too late to
include it in my already mostly finished tentative/tutorial.

In this post:
https://dev1galaxy.org/viewtopic.php?id=1929#p7915
I linked to the web-location of this email:
https://lists.gnupg.org/pipermail/gnupg-users/2018-January/059887.html
(that I'm replying to from my maibox).

I think my setup (and I had longed for a couple of years to accomplish it!; I'm
a slow learner) works for me fine already I believe, and is safe [1].

And I hoped I'd mostly just thank the developers for this really great tool in
the first place.

OTOH, the FAQ entry that I found some tips at the onset of this days-long GnuPG
setup rework of mine, I believe should be updated:

8.20. How can I use GnuPG in an automated environment?
https://gnupg.org/faq/gnupg-faq.html#automated_use

I'd help, but firstly, I had already stolen too much time from other work of
mine, and secondly, my understanding is not sufficiently clear on these matters
at this time.

Best regards!

---
[1] I set up a good password for both my subkeys, and will probably mostly go
offline, and try to quickly ascertain my system status --logs are most always
"tail -f"-ed on top in real time for me, and will often go offline, physically
disconnecting from the internet, for just the time to type the password to do
the encryption/signing.

So maybe a question to advanced users/devs. Any tips on protection from the
dangers to my subkeys (and subkeys of those who will come along from my
tutorial pages) from the bad place called internet? On defence from keyloggers,
from meltdown/spectre exploits big or small users (ah, I know; kernel with all
the mitigations and updated microcode, but maybe the gentle readers can tell
more yet), and such?
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180311/34428064/attachment.sig>

From gniibe at fsij.org  Tue Mar 13 10:54:25 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 13 Mar 2018 18:54:25 +0900
Subject: OpenPGP card bricked
In-Reply-To: <20180310101020.GA2577@c720-r314251>
References: <20180310101020.GA2577@c720-r314251>
Message-ID: <87a7vcs3la.fsf@fsij.org>

Matthias Apitz <guru at unixarea.de> wrote:
> After a power-off reset of my laptop the OpenPGP Card seems to be
> damaged. The pcscd can't read the card anymore. It gives up with:
>
> ...
> 00006225 commands.c:244:CmdPowerOn Card absent or mute
> 00000052 ifdhandler.c:1213:IFDHPowerICC() PowerUp failed
> 00000017 eventhandler.c:301:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

If it's really hardware problem, I can't help, but...

> What can I do?
[...]
> Identiv uTrust 3512 SAM slot Token

I believe that GnuPG's in-stock driver just works fine with this reader,
because it runs at TPDU level exchange.

Please try without PC/SC-lite, and see how it goes.

With following ~/.gnupg/scdaemon.conf, you can get debug log.

================ ~/.gnupg/scdaemon.conf
verbose
verbose
debug-level guru
debug-all
debug-ccid-driver
log-file /some/where/scdaemon-debug.log
================
-- 


From guru at unixarea.de  Tue Mar 13 15:34:21 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 13 Mar 2018 15:34:21 +0100
Subject: OpenPGP card bricked
In-Reply-To: <87a7vcs3la.fsf@fsij.org>
References: <20180310101020.GA2577@c720-r314251>
 <87a7vcs3la.fsf@fsij.org>
Message-ID: <20180313143421.GA2512@c720-r314251>

El d?a martes, marzo 13, 2018 a las 06:54:25p. m. +0900, NIIBE Yutaka escribi?:
> 
> > What can I do?
> [...]
> > Identiv uTrust 3512 SAM slot Token
> 
> I believe that GnuPG's in-stock driver just works fine with this reader,
> because it runs at TPDU level exchange.
> 
> Please try without PC/SC-lite, and see how it goes.
> 
> With following ~/.gnupg/scdaemon.conf, you can get debug log.
> 
> ================ ~/.gnupg/scdaemon.conf
> verbose
> verbose
> debug-level guru
> debug-all
> debug-ccid-driver
> log-file /some/where/scdaemon-debug.log
> ================

I moved the /usr/local/sbin/pcscd out of the way. The scdaemon writes
the following log:

2018-03-13 15:28:10 scdaemon[2508.802016000] listening on socket '/home/guru/.gnupg-ccid/S.scdaemon'
2018-03-13 15:28:10 scdaemon[2508.802017900] manejador del descriptor -1 iniciado
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 -> OK GNU Privacy Guard's Smartcard server ready
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 <- GETINFO socket_name
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 -> D /home/guru/.gnupg-ccid/S.scdaemon
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 -> OK
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 <- OPTION event-signal=31
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 -> OK
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 <- SERIALNO
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: enter: apdu_open_reader: portstr=(null)
2018-03-13 15:28:10 scdaemon[2508.802017900] pcsc_establish_context failed: no service (0x8010001d)
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: leave: apdu_open_reader => slot=-1 [pc/sc]
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 -> ERR 100696144 Operation not supported by device <SCD>
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 <- RESTART
2018-03-13 15:28:10 scdaemon[2508.802017900] DBG: chan_7 -> OK

Is there some config missing so that scdaemon opens directly the reader?
What does 'pcsc_establish_context failed' mean?

Thanks for your help

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045


From peter at digitalbrains.com  Tue Mar 13 16:00:04 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 13 Mar 2018 16:00:04 +0100
Subject: OpenPGP card bricked
In-Reply-To: <20180313143421.GA2512@c720-r314251>
References: <20180310101020.GA2577@c720-r314251> <87a7vcs3la.fsf@fsij.org>
 <20180313143421.GA2512@c720-r314251>
Message-ID: <9fb5e2fb-b937-cbf7-ffba-1c3ca3b60823@digitalbrains.com>

On 13/03/18 15:34, Matthias Apitz wrote:
> Is there some config missing so that scdaemon opens directly the reader?
> What does 'pcsc_establish_context failed' mean?

A notable difference between the built-in CCID driver and pcscd is probably the
user credentials that open the USB device. Make sure you have write access to
the character device in /dev/bus/usb that corresponds to your smartcard:

$ lsusb
[...]
Bus 001 Device 006: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard
Reader
[...]
$ ll /dev/bus/usb/001/006
crw-rw-r--+ 1 root root 189, 5 Mar 13 15:55 /dev/bus/usb/001/006
$ getfacl /dev/bus/usb/001/006
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/001/006
# owner: root
# group: root
user::rw-
user:peter:rw-
group::rw-
mask::rw-
other::r--

Also, if I were you, I'd clean the smartcard contacts with isopropyl alcohol.
I'm not sure what other cleaning agents would work well, I just use that one.

It could be that your card has just died. Smartcards are not the most robust
devices, and they are subjected to stress usually.

HTH,

Peter.

PS: I'm not 100% sure that libusb opens that particular character device... I
believe it's the correct one, but wouldn't swear on it.

-- 
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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180313/b9d736ef/attachment.sig>

From guru at unixarea.de  Tue Mar 13 16:30:24 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 13 Mar 2018 16:30:24 +0100
Subject: OpenPGP card bricked
In-Reply-To: <9fb5e2fb-b937-cbf7-ffba-1c3ca3b60823@digitalbrains.com>
References: <20180310101020.GA2577@c720-r314251> <87a7vcs3la.fsf@fsij.org>
 <20180313143421.GA2512@c720-r314251>
 <9fb5e2fb-b937-cbf7-ffba-1c3ca3b60823@digitalbrains.com>
Message-ID: <20180313153024.GA3130@c720-r314251>

El d?a martes, marzo 13, 2018 a las 04:00:04p. m. +0100, Peter Lebbing escribi?:

> On 13/03/18 15:34, Matthias Apitz wrote:
> > Is there some config missing so that scdaemon opens directly the reader?
> > What does 'pcsc_establish_context failed' mean?
> 
> A notable difference between the built-in CCID driver and pcscd is probably the
> user credentials that open the USB device. Make sure you have write access to
> the character device in /dev/bus/usb that corresponds to your smartcard:

Please note, this is not Linux but FreeBSD. But you pointed in the
correct direction: missing rw perms in /dev/usb/* device files; I'm in
the group operator, but they have had only 0600 perms; I fixed this to:

# ls -l /dev/usb
total 0
crw-rw----  1 root  operator  0x2c 13 mar.  15:17 0.1.0
crw-rw----  1 root  operator  0x3d 13 mar.  15:17 0.1.1
crw-rw----  1 root  operator  0x40 13 mar.  15:17 0.2.0
crw-rw----  1 root  operator  0x42 13 mar.  15:17 0.2.1
crw-rw----  1 root  operator  0x43 13 mar.  15:17 0.2.7
crw-rw----  1 root  operator  0x44 13 mar.  15:17 0.3.0
crw-rw----  1 root  operator  0x46 13 mar.  15:17 0.3.1
crw-rw----  1 root  operator  0x47 13 mar.  15:17 0.3.2
crw-rw----  1 root  operator  0x48 13 mar.  15:17 0.3.3
crw-rw----  1 root  operator  0x7e 13 mar.  15:26 0.4.0
crw-rw----  1 root  operator  0x80 13 mar.  15:26 0.4.1
crw-rw----  1 root  operator  0x81 13 mar.  15:26 0.4.2
crw-rw----  1 root  operator  0x82 13 mar.  15:26 0.4.3

and this gives more log; see below;

> Also, if I were you, I'd clean the smartcard contacts with isopropyl alcohol.
> I'm not sure what other cleaning agents would work well, I just use that one.
> 
> It could be that your card has just died. Smartcards are not the most robust
> devices, and they are subjected to stress usually.

Thanks for this hint too.


2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: chan_7 <- GETINFO version
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: chan_7 -> D 2.1.19
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: chan_7 -> OK
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: chan_7 <- SERIALNO openpgp
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: apdu_open_reader: BAI=400
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: apdu_open_reader: new device=400
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: using CCID reader 0 (ID=04E6:5816:55511514602745:0)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: idVendor: 04E6  idProduct: 5816  bcdDevice: 0202
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: ChipCard Interface Descriptor:
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bLength                54
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bDescriptorType        33
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bcdCCID              1.10  (Warning: Only accurate for version 1.0)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   nMaxSlotIndex           0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bVoltageSupport         7  ?
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwProtocols             3  T=0 T=1
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwDefaultClock       4800
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwMaxiumumClock     16000
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bNumClockSupported      0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwDataRate          12903 bps
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwMaxDataRate      600000 bps
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bNumDataRatesSupp.      0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwMaxIFSD             252
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwSyncProtocols  00000000 
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwMechanical     00000000 
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwFeatures       000100BA
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:     Auto configuration based on ATR (assumes auto voltage)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:     Auto voltage selection
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:     Auto clock change
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:     Auto baud rate change
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:     Auto PPS made by CCID
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:     TPDU level exchange
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwMaxCCIDMsgLen       271
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bClassGetResponse    echo
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bClassEnvelope       echo
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   wlcdLayout           none
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bPINSupport             0 
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bMaxCCIDBusySlots       1
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: CCID submit transfer (83): 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOn:
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSeq ..............: 1
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   [0008]  00 00
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: CCID: interrupt callback 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: CCID submit transfer again 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: RDR_to_PC_DataBlock:
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSeq ..............: 1
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bStatus ...........: 65
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bError ............: 254
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC
2018-03-13 16:23:16 scdaemon[2508.802017900] reader slot 0: using ccid driver
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: enter: apdu_connect: slot=0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: enter: apdu_reset: slot=0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOn:
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSeq ..............: 4
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   [0008]  00 00
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: RDR_to_PC_DataBlock:
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSeq ..............: 4
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bStatus ...........: 65
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bError ............: 254
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: leave: apdu_reset => sw=0x10009
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: leave: apdu_connect => sw=0x10009
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: enter: apdu_close_reader: slot=0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: enter: apdu_disconnect: slot=0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: leave: apdu_disconnect => sw=0x0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOff:
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSeq ..............: 5
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   [0007]  00 00 00
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: RDR_to_PC_SlotStatus:
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bSeq ..............: 5
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bStatus ...........: 1
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver:   bClockStatus ......: 0x01 (stopped-L)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: libusb_cancel_transfer
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: ccid-driver: libusb_handle_events_completed
2018-03-13 16:23:16 scdaemon[2508.802280500] DBG: ccid-driver: CCID: interrupt callback 3
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: leave: apdu_close_reader => 0x0 (close_reader)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: enter: apdu_open_reader: portstr=(null)
2018-03-13 16:23:16 scdaemon[2508.802017900] pcsc_establish_context failed: no service (0x8010001d)
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: leave: apdu_open_reader => slot=-1 [pc/sc]
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: chan_7 -> ERR 100696144 Operation not supported by device <SCD>
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: chan_7 <- RESTART
2018-03-13 16:23:16 scdaemon[2508.802017900] DBG: chan_7 -> OK



-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045


From phylliswalters1983 at gmail.com  Tue Mar 13 20:17:57 2018
From: phylliswalters1983 at gmail.com (CORY WALTERS)
Date: Tue, 13 Mar 2018 15:17:57 -0400
Subject: Any 
Message-ID: <13877709-EB59-48AC-822D-E4BBBABE6D80@gmail.com>



Sent from my iPhone


From phylliswalters1983 at gmail.com  Tue Mar 13 20:17:57 2018
From: phylliswalters1983 at gmail.com (CORY WALTERS)
Date: Tue, 13 Mar 2018 15:17:57 -0400
Subject: Any 
Message-ID: <13877709-EB59-48AC-822D-E4BBBABE6D80@gmail.com>



Sent from my iPhone


From gniibe at fsij.org  Wed Mar 14 05:03:16 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 14 Mar 2018 13:03:16 +0900
Subject: OpenPGP card bricked
In-Reply-To: <20180313153024.GA3130@c720-r314251>
References: <20180310101020.GA2577@c720-r314251> <87a7vcs3la.fsf@fsij.org>
 <20180313143421.GA2512@c720-r314251>
 <9fb5e2fb-b937-cbf7-ffba-1c3ca3b60823@digitalbrains.com>
 <20180313153024.GA3130@c720-r314251>
Message-ID: <87sh93pam3.fsf@iwagami.gniibe.org>

Hello,

It seems that your smartcard is not working at all.
Possibly, bricked.

The log says (I removed the timestamp and process name):

> DBG: ccid-driver: CCID submit transfer (83): 0
> DBG: ccid-driver: PC_to_RDR_IccPowerOn:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 1
> DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
> DBG: ccid-driver:   [0008]  00 00

The host PC asks the reader (RDR) to power on the smartcard.

> DBG: ccid-driver: CCID: interrupt callback 0
> DBG: ccid-driver: CCID submit transfer again 0

Then, the reader's interrupt transfer notifies to the host for change of
card status.  Host keeps the interrupt transfer, so, submit the transfer
to the USB host controller again.

> DBG: ccid-driver: RDR_to_PC_DataBlock:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 1
> DBG: ccid-driver:   bStatus ...........: 65
> DBG: ccid-driver:   bError ............: 254
> DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC

The reader responds it fails to power on the smartcard.

> reader slot 0: using ccid driver
> DBG: enter: apdu_connect: slot=0
> DBG: enter: apdu_reset: slot=0
> DBG: ccid-driver: PC_to_RDR_IccPowerOn:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 4
> DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
> DBG: ccid-driver:   [0008]  00 00

The host asks again to the reader.

> DBG: ccid-driver: RDR_to_PC_DataBlock:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 4
> DBG: ccid-driver:   bStatus ...........: 65
> DBG: ccid-driver:   bError ............: 254
> DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC

Same failure.  Host gives up.

> DBG: leave: apdu_reset => sw=0x10009
> DBG: leave: apdu_connect => sw=0x10009
> DBG: enter: apdu_close_reader: slot=0
> DBG: enter: apdu_disconnect: slot=0
> DBG: leave: apdu_disconnect => sw=0x0
> DBG: ccid-driver: PC_to_RDR_IccPowerOff:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 5
> DBG: ccid-driver:   [0007]  00 00 00
> DBG: ccid-driver: RDR_to_PC_SlotStatus:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 5
> DBG: ccid-driver:   bStatus ...........: 1
> DBG: ccid-driver:   bClockStatus ......: 0x01 (stopped-L)

And the host asks power off.  The reader replies.

> DBG: ccid-driver: libusb_cancel_transfer
> DBG: ccid-driver: libusb_handle_events_completed
> DBG: ccid-driver: CCID: interrupt callback 3

The host cancels interrupt transfer which watches card status change.

After the failure of internal CCID driver, it tries PC/SC.
-- 


From guru at unixarea.de  Wed Mar 14 16:48:05 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 14 Mar 2018 16:48:05 +0100
Subject: OpenPGP card bricked
In-Reply-To: <87sh93pam3.fsf@iwagami.gniibe.org>
References: <20180310101020.GA2577@c720-r314251> <87a7vcs3la.fsf@fsij.org>
 <20180313143421.GA2512@c720-r314251>
 <9fb5e2fb-b937-cbf7-ffba-1c3ca3b60823@digitalbrains.com>
 <20180313153024.GA3130@c720-r314251>
 <87sh93pam3.fsf@iwagami.gniibe.org>
Message-ID: <20180314154805.GA2777@c720-r314251>


Hello,

Floss-shop.de sent me a new OpenPGP Card V3.3. It shows the same
problem, see the log below. What should I do now? Send the USB-reader
and the card back to them? I'm clueless....

Thanks

	matthias

Mar 14 16:21:34 c720-r314251 kernel: ugen0.4: <Identiv uTrust 3512 SAM slot Token> at usbus0
Mar 14 16:21:34 c720-r314251 root: CCID uTrust, type: ATTACH, system: USB, subsystem: INTERFACE
Mar 14 16:21:34 c720-r314251 root: Unknown USB device: vendor 0x04e6 product 0x5816 bus uhub0


scdaemon-ccid.log:


2018-03-14 16:32:57 scdaemon[2735.802016000] listening on socket '/home/guru/.gnupg-ccid/S.scdaemon'
2018-03-14 16:32:57 scdaemon[2735.802017900] manejador del descriptor -1 iniciado
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 -> OK GNU Privacy Guard's Smartcard server ready
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 <- GETINFO socket_name
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 -> D /home/guru/.gnupg-ccid/S.scdaemon
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 -> OK
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 <- OPTION event-signal=31
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 -> OK
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 <- SERIALNO
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: apdu_open_reader: BAI=400
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: apdu_open_reader: new device=400
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: using CCID reader 0 (ID=04E6:5816:55511514602745:0)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: idVendor: 04E6  idProduct: 5816  bcdDevice: 0202
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: ChipCard Interface Descriptor:
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bLength                54
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bDescriptorType        33
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bcdCCID              1.10  (Warning: Only accurate for version 1.0)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   nMaxSlotIndex           0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bVoltageSupport         7  ?
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwProtocols             3  T=0 T=1
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwDefaultClock       4800
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxiumumClock     16000
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bNumClockSupported      0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwDataRate          12903 bps
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxDataRate      600000 bps
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bNumDataRatesSupp.      0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxIFSD             252
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwSyncProtocols  00000000 
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwMechanical     00000000 
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwFeatures       000100BA
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:     Auto configuration based on ATR (assumes auto voltage)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:     Auto voltage selection
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:     Auto clock change
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:     Auto baud rate change
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:     Auto PPS made by CCID
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:     TPDU level exchange
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxCCIDMsgLen       271
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bClassGetResponse    echo
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bClassEnvelope       echo
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   wlcdLayout           none
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bPINSupport             0 
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bMaxCCIDBusySlots       1
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: CCID submit transfer (83): 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOn:
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 1
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   [0008]  00 00
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: RDR_to_PC_DataBlock:
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 1
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bStatus ...........: 65
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bError ............: 254
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC
2018-03-14 16:32:57 scdaemon[2735.802017900] reader slot 0: using ccid driver
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: enter: apdu_connect: slot=0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: enter: apdu_reset: slot=0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOn:
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 4
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   [0008]  00 00
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: RDR_to_PC_DataBlock:
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 4
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bStatus ...........: 65
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bError ............: 254
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: leave: apdu_reset => sw=0x10009
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: leave: apdu_connect => sw=0x10009
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: enter: apdu_close_reader: slot=0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: enter: apdu_disconnect: slot=0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: leave: apdu_disconnect => sw=0x0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOff:
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 5
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   [0007]  00 00 00
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: RDR_to_PC_SlotStatus:
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 5
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bStatus ...........: 1
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver:   bClockStatus ......: 0x01 (stopped-L)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: libusb_cancel_transfer
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: ccid-driver: libusb_handle_events_completed
2018-03-14 16:32:57 scdaemon[2735.802280500] DBG: ccid-driver: CCID: interrupt callback 3
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: leave: apdu_close_reader => 0x0 (close_reader)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: enter: apdu_open_reader: portstr=(null)
2018-03-14 16:32:57 scdaemon[2735.802017900] pcsc_establish_context failed: no service (0x8010001d)
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: leave: apdu_open_reader => slot=-1 [pc/sc]
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 -> ERR 100696144 Operation not supported by device <SCD>
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 <- RESTART
2018-03-14 16:32:57 scdaemon[2735.802017900] DBG: chan_7 -> OK
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: chan_7 <- GETINFO version
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: chan_7 -> D 2.1.19
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: chan_7 -> OK
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: chan_7 <- SERIALNO openpgp
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: apdu_open_reader: BAI=400
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: apdu_open_reader: new device=400
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: using CCID reader 0 (ID=04E6:5816:55511514602745:0)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: idVendor: 04E6  idProduct: 5816  bcdDevice: 0202
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: ChipCard Interface Descriptor:
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bLength                54
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bDescriptorType        33
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bcdCCID              1.10  (Warning: Only accurate for version 1.0)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   nMaxSlotIndex           0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bVoltageSupport         7  ?
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwProtocols             3  T=0 T=1
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwDefaultClock       4800
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxiumumClock     16000
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bNumClockSupported      0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwDataRate          12903 bps
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxDataRate      600000 bps
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bNumDataRatesSupp.      0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxIFSD             252
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwSyncProtocols  00000000 
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwMechanical     00000000 
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwFeatures       000100BA
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:     Auto configuration based on ATR (assumes auto voltage)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:     Auto voltage selection
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:     Auto clock change
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:     Auto baud rate change
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:     Auto PPS made by CCID
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:     TPDU level exchange
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwMaxCCIDMsgLen       271
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bClassGetResponse    echo
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bClassEnvelope       echo
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   wlcdLayout           none
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bPINSupport             0 
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bMaxCCIDBusySlots       1
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: CCID submit transfer (83): 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOn:
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 1
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   [0008]  00 00
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: RDR_to_PC_DataBlock:
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 1
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bStatus ...........: 65
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bError ............: 254
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC
2018-03-14 16:33:10 scdaemon[2735.802017900] reader slot 0: using ccid driver
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: enter: apdu_connect: slot=0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: enter: apdu_reset: slot=0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOn:
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 4
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   [0008]  00 00
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: RDR_to_PC_DataBlock:
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 4
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bStatus ...........: 65
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bError ............: 254
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: leave: apdu_reset => sw=0x10009
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: leave: apdu_connect => sw=0x10009
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: enter: apdu_close_reader: slot=0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: enter: apdu_disconnect: slot=0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: leave: apdu_disconnect => sw=0x0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: PC_to_RDR_IccPowerOff:
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 5
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   [0007]  00 00 00
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: RDR_to_PC_SlotStatus:
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   dwLength ..........: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSlot .............: 0
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bSeq ..............: 5
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bStatus ...........: 1
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver:   bClockStatus ......: 0x01 (stopped-L)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: libusb_cancel_transfer
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: ccid-driver: libusb_handle_events_completed
2018-03-14 16:33:10 scdaemon[2735.802280a00] DBG: ccid-driver: CCID: interrupt callback 3
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: leave: apdu_close_reader => 0x0 (close_reader)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: enter: apdu_open_reader: portstr=(null)
2018-03-14 16:33:10 scdaemon[2735.802017900] pcsc_establish_context failed: no service (0x8010001d)
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: leave: apdu_open_reader => slot=-1 [pc/sc]
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: chan_7 -> ERR 100696144 Operation not supported by device <SCD>
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: chan_7 <- RESTART
2018-03-14 16:33:10 scdaemon[2735.802017900] DBG: chan_7 -> OK

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045


From ben at adversary.org  Wed Mar 14 18:52:10 2018
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 15 Mar 2018 04:52:10 +1100
Subject: gpg 2.2.5 hangs instead of asking for a passphrase
In-Reply-To: <CAOZ5s14YQm6TDFXB5_S69_Lhc20+BB3guodR3SJ0WXQYD50GyA@mail.gmail.com>
References: <CAOZ5s14YQm6TDFXB5_S69_Lhc20+BB3guodR3SJ0WXQYD50GyA@mail.gmail.com>
Message-ID: <20180314175210.qiussxkrdo37n7fn@adversary.org>

On Fri, Mar 09, 2018 at 04:55:14PM -0800, Ian Holmes wrote:
> Hi,
> 
> I'm using gpg on macOS High Sierra, installed via homebrew. I have a file
> that is CAST5 encrypted. When I try to decrypt it using my previous
> homebrew version of gpg (gpg 2.0.30, libgcrypt 1.7.6), I type 'gpg
> --decrypt myfile.txt.gpg' and it prints 'gpg5: CAST5 the screen
> clears,

Does it really say "gpg5:" or is that a typo from your recollection of
the error?

What's the output of: gpg --version

Copy and paste the whole thing in here.

Also, when you say you're prompted for the passphrase, does that
happen with a GUI pop up on the screen or is that in the terminal?


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180315/c200f4f3/attachment.sig>

From gniibe at fsij.org  Thu Mar 15 01:41:14 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 15 Mar 2018 09:41:14 +0900
Subject: OpenPGP card bricked
In-Reply-To: <20180314154805.GA2777@c720-r314251>
References: <20180310101020.GA2577@c720-r314251> <87a7vcs3la.fsf@fsij.org>
 <20180313143421.GA2512@c720-r314251>
 <9fb5e2fb-b937-cbf7-ffba-1c3ca3b60823@digitalbrains.com>
 <20180313153024.GA3130@c720-r314251> <87sh93pam3.fsf@iwagami.gniibe.org>
 <20180314154805.GA2777@c720-r314251>
Message-ID: <87o9jquq51.fsf@iwagami.gniibe.org>

Matthias Apitz <guru at unixarea.de> wrote:
> Floss-shop.de sent me a new OpenPGP Card V3.3. It shows the same
> problem, see the log below. What should I do now? Send the USB-reader
> and the card back to them? I'm clueless....

All that I can say is:

The reader has features which should work well for OpenPGP card with GnuPG:

> DBG: ccid-driver:   dwFeatures       000100BA
> DBG: ccid-driver:     Auto configuration based on ATR (assumes auto voltage)
> DBG: ccid-driver:     Auto voltage selection
> DBG: ccid-driver:     Auto clock change
> DBG: ccid-driver:     Auto baud rate change
> DBG: ccid-driver:     Auto PPS made by CCID
> DBG: ccid-driver:     TPDU level exchange

(I like TPDU reader, btw.  The simpler is the better.)

When scdaemon asks the reader to power on the smartcard, it fails.

> DBG: ccid-driver: PC_to_RDR_IccPowerOn:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 1
> DBG: ccid-driver:   bPowerSelect ......: 0x00 (auto)
> DBG: ccid-driver:   [0008]  00 00
> DBG: ccid-driver: RDR_to_PC_DataBlock:
> DBG: ccid-driver:   dwLength ..........: 0
> DBG: ccid-driver:   bSlot .............: 0
> DBG: ccid-driver:   bSeq ..............: 1
> DBG: ccid-driver:   bStatus ...........: 65
> DBG: ccid-driver:   bError ............: 254
> DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC

So, it's not something complicated.  Just it doesn't work from the beginning.

Given the situation (the card should be OK and the reader should be OK,
possibly the machine is also OK), most likely, I suspect the contact
between the reader and the smartcard.
-- 


From bernhard at intevation.de  Thu Mar 15 10:27:04 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 15 Mar 2018 10:27:04 +0100
Subject: WKD planned for Purism's laptops and Librem 5 phone
Message-ID: <201803151027.13108.bernhard@intevation.de>

https://puri.sm/posts/purism-collaboration-with-cryptography-expert-werner-koch/

  have joined forces with leading cryptography pioneer, Werner Koch, to   
  integrate hardware encryption into the company?s Librem laptops and 
  forthcoming Librem 5 phone. 
..
   to include encryption by default into its hardware, software, and services.
..
   by default into communications such as email and messaging
   through a new process called Web Key Directory

Congratulations Werner! Good to see OpenPGP, GnuPG and WKD spread!

I take it that it means that email clients for the upcoming Librem 5 phone
and the detail email clients on the laptos will all have WKD support build in?
What other services? Will Purism themselfs offer WKD for their email 
addresses?

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180315/1a94ac0c/attachment.sig>

From guru at unixarea.de  Thu Mar 15 10:53:30 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 15 Mar 2018 10:53:30 +0100
Subject: WKD planned for Purism's laptops and Librem 5 phone
In-Reply-To: <201803151027.13108.bernhard@intevation.de>
References: <201803151027.13108.bernhard@intevation.de>
Message-ID: <20180315095330.GA6478@sh4-5.1blu.de>

El d?a Thursday, March 15, 2018 a las 10:27:04AM +0100, Bernhard Reiter escribi?:

> https://puri.sm/posts/purism-collaboration-with-cryptography-expert-werner-koch/
> 
>   have joined forces with leading cryptography pioneer, Werner Koch, to   
>   integrate hardware encryption into the company?s Librem laptops and 
>   forthcoming Librem 5 phone. 
> ..
>    to include encryption by default into its hardware, software, and services.
> ..
>    by default into communications such as email and messaging
>    through a new process called Web Key Directory
> 
> ...

I have ordered in the crowd funding on October 7, 2017 one of these
Librem 5 phones (~600 Euro) and I'm keen to get hands on it next year in
spring.

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045


From s.maddox at lantizia.me.uk  Thu Mar 15 16:26:10 2018
From: s.maddox at lantizia.me.uk (Steven Maddox)
Date: Thu, 15 Mar 2018 15:26:10 +0000
Subject: Stupid Symantec
Message-ID: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>

Hi,	
	
At the place I work they unfortunately use stupid Symantec's "Encryption
Desktop" (formerly known as PGP Desktop) software.	
	
The desktop portion of that software has an OS/kernel level driver that
watches if you're trying to open a PGP encrypted file... then decrypts
it on the fly and finally passes it to the application that'd normally
open it.	
	
I'm the only Linux desktop user here at work and I only call Symantec
*stupid* because they seem to find it funny to support Ubuntu 14.04 all
the way to 14.04.4 ... but not 14.04.5.  Basically 14.04.5 has a newer
Linux kernel which breaks the driver, if they could just fix that -
they'd also find it is magically fixed for Ubuntu 16.04 too (as it's the
same issue in the kernel that uses too).	
	
This is especially infuriating as they refer to any request to fix this
as a "Feature Request"... which is laughable if you consider the idea of
this happening if Windows got a new service pack, that'd get classified
instantly as a bug to fix.	
	
See... https://support.symantec.com/en_US/article.TECH236718.html	
See... https://support.symantec.com/en_US/article.INFO3856.html	
	
Anyway I can either continue to bitterly rant or convince my employers
to switch product.  Does GnuPG have a similar kernel module/driver for
an as-you-open-a-file type experience?	
	
If this doesn't exist in the main GnuPG project then I'd be happy to be
referred to any 3rd party bits of software (even if commercial or
proprietary) that could?	
	
I understand if the answer *should* be block-level encryption... but
they're intend on file-level.	
	
-- 
Steven Maddox
Lantizia


From psusi at ubuntu.com  Thu Mar 15 18:03:53 2018
From: psusi at ubuntu.com (Phil Susi)
Date: Thu, 15 Mar 2018 13:03:53 -0400
Subject: Stupid Symantec
In-Reply-To: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
Message-ID: <5a1e8221-b598-77bb-63b4-f93e36172b25@ubuntu.com>

On 3/15/2018 11:26 AM, Steven Maddox wrote:
> The desktop portion of that software has an OS/kernel level driver that
> watches if you're trying to open a PGP encrypted file... then decrypts
> it on the fly and finally passes it to the application that'd normally
> open it.	

> Anyway I can either continue to bitterly rant or convince my employers
> to switch product.  Does GnuPG have a similar kernel module/driver for
> an as-you-open-a-file type experience?	

Windows has this feature built in already, why not just use that?



From andrewg at andrewg.com  Thu Mar 15 18:11:15 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 15 Mar 2018 17:11:15 +0000
Subject: Stupid Symantec
In-Reply-To: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
Message-ID: <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>

On 15/03/18 15:26, Steven Maddox wrote:
> 
> The desktop portion of that software has an OS/kernel level driver that
> watches if you're trying to open a PGP encrypted file... then decrypts
> it on the fly and finally passes it to the application that'd normally
> open it.	

...

> If this doesn't exist in the main GnuPG project then I'd be happy to be
> referred to any 3rd party bits of software (even if commercial or
> proprietary) that could?	
> 	
> I understand if the answer *should* be block-level encryption... but
> they're intend on file-level.	

The obvious approach would be to write a FUSE driver. It would be
mounted as an overlay filesystem, and this filesystem would decrypt the
encrypted files on demand into a ramfs, and then re-encrypt (and shred)
on file close.

I saw a commercial product here that might do what you want, but the
documentation is making my brain hurt:

https://www.flam.de/issues/view.php?id=888
http://www.flam.de/en/technology/products/fluc/

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180315/27a3b0d9/attachment.sig>

From dkg at fifthhorseman.net  Thu Mar 15 23:39:55 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 15 Mar 2018 22:39:55 +0000
Subject: Stupid Symantec
In-Reply-To: <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
Message-ID: <87tvthynd0.fsf@fifthhorseman.net>

On Thu 2018-03-15 17:11:15 +0000, Andrew Gallagher wrote:
>> If this doesn't exist in the main GnuPG project then I'd be happy to be
>> referred to any 3rd party bits of software (even if commercial or
>> proprietary) that could?	
>> 	
>> I understand if the answer *should* be block-level encryption... but
>> they're intend on file-level.	
>
> The obvious approach would be to write a FUSE driver. It would be
> mounted as an overlay filesystem, and this filesystem would decrypt the
> encrypted files on demand into a ramfs, and then re-encrypt (and shred)
> on file close.

or, if what you really care about is file-level encryption on a
GNU/Linux desktop and you *don't* care about files being OpenPGP
formatted, you could look into ext4's native encryption features (see
e4crypt(8) and related docs to get started).

     --dkg


From gnupg at raf.org  Fri Mar 16 01:58:45 2018
From: gnupg at raf.org (gnupg at raf.org)
Date: Fri, 16 Mar 2018 11:58:45 +1100
Subject: Stupid Symantec
In-Reply-To: <87tvthynd0.fsf@fifthhorseman.net>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net>
Message-ID: <20180316005845.3rbnxsi33ecl4fgz@raf.org>

Daniel Kahn Gillmor wrote:

> On Thu 2018-03-15 17:11:15 +0000, Andrew Gallagher wrote:
> >> If this doesn't exist in the main GnuPG project then I'd be happy to be
> >> referred to any 3rd party bits of software (even if commercial or
> >> proprietary) that could?	
> >> 	
> >> I understand if the answer *should* be block-level encryption... but
> >> they're intend on file-level.	
> >
> > The obvious approach would be to write a FUSE driver. It would be
> > mounted as an overlay filesystem, and this filesystem would decrypt the
> > encrypted files on demand into a ramfs, and then re-encrypt (and shred)
> > on file close.
> 
> or, if what you really care about is file-level encryption on a
> GNU/Linux desktop and you *don't* care about files being OpenPGP
> formatted, you could look into ext4's native encryption features (see
> e4crypt(8) and related docs to get started).
> 
>      --dkg

yes, luks full disk encryption would be best of course but if
boss says no, ecryptfs file system encryption might be
acceptable. every file in an ecryptfs-mounted file system is
individually encrypted. encrypting their names as well is
optional. and it's easy enough to setup. and i haven't detected
any performance penalty (except when running du, just don't).
and i'm fairly sure ubuntu has this built-in for home directory
encryption but i don't know which versions.

cheers,
raf



From dkg at fifthhorseman.net  Fri Mar 16 02:16:49 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 16 Mar 2018 01:16:49 +0000
Subject: Stupid Symantec
In-Reply-To: <20180316005845.3rbnxsi33ecl4fgz@raf.org>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
Message-ID: <877eqczuny.fsf@fifthhorseman.net>

On Fri 2018-03-16 11:58:45 +1100, gnupg at raf.org wrote:
> Daniel Kahn Gillmor wrote:
>> or, if what you really care about is file-level encryption on a
>> GNU/Linux desktop and you *don't* care about files being OpenPGP
>> formatted, you could look into ext4's native encryption features (see
>> e4crypt(8) and related docs to get started).
>
> yes, luks full disk encryption would be best of course but if
> boss says no, ecryptfs file system encryption might be
> acceptable. every file in an ecryptfs-mounted file system is
> individually encrypted. encrypting their names as well is
> optional. and it's easy enough to setup. and i haven't detected
> any performance penalty (except when running du, just don't).
> and i'm fairly sure ubuntu has this built-in for home directory
> encryption but i don't know which versions.

note that for fike-level encryption, i was not talking about ecryptfs,
but rather about e4crypt.  these are different technologies, and i would
suspect (though i haven't profiled it) that e4crypt would be
significantly more performant than ecryptfs.

fwiw, i think that block-device level encryption (e.g. dmcrypt with
LUKS) is orthogonal to file-level encryption (e.g. e4crypt).  they have
different use cases against different adversaries, and there's no clear
argument that i've seen that you shouldn't use them in concert with one
another.

for example, consider the "fast secure delete" functionality that you
get from file-level encryption -- delete the inode of a file (which
contains the file's key) and then the on-disk data for the file will be
unrecoverable.  this isn't achievable with block-device-level crypto --
as long as the block device is unlocked, the old blocks are still
readable.

        --dkg


From skquinn at rushpost.com  Fri Mar 16 06:03:24 2018
From: skquinn at rushpost.com (Shawn K. Quinn)
Date: Fri, 16 Mar 2018 00:03:24 -0500
Subject: Stupid Symantec
In-Reply-To: <20180316005845.3rbnxsi33ecl4fgz@raf.org>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
Message-ID: <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>

On 03/15/2018 07:58 PM, gnupg at raf.org wrote:
> yes, luks full disk encryption would be best of course but if
> boss says no, ecryptfs file system encryption might be
> acceptable. every file in an ecryptfs-mounted file system is
> individually encrypted. encrypting their names as well is
> optional. and it's easy enough to setup. and i haven't detected
> any performance penalty (except when running du, just don't).
> and i'm fairly sure ubuntu has this built-in for home directory
> encryption but i don't know which versions.
It goes back to at least 14.04, probably much farther. I haven't done
many fresh installs of the older versions. I did two fresh installs of
12.04, with everything since being upgrades (I only use LTS versions now).

-- 
Shawn K. Quinn <skquinn at rushpost.com>
http://www.rantroulette.com
http://www.skqrecordquest.com


From s.maddox at lantizia.me.uk  Fri Mar 16 09:11:24 2018
From: s.maddox at lantizia.me.uk (Steven Maddox)
Date: Fri, 16 Mar 2018 08:11:24 +0000
Subject: Stupid Symantec
In-Reply-To: <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
 <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
Message-ID: <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>

On 15/03/18 17:03, Phil Susi wrote:
> Windows has this feature built in already, why not just use that?

I'm not a Windows user, I mentioned that I'm a Linux desktop user in my
original post.

--

On 15/03/18 17:11, Andrew Gallagher wrote:
> The obvious approach would be to write a FUSE driver

Yeah this would be a cool approach that'd mean less reliance on the
kernel.  However the files we (me and my colleagues) access (although
they're all using Windows PCs) are on SMB/Windows shares... so somehow
the overlay would have to work with that.

--

On 15/03/18 17:11, Andrew Gallagher wrote:
> I saw a commercial product here that might do what you want

I'll take a closer look thanks... although on first glance I can't see
anything about SMB/Windows share support (for remote files it just
mentions SSH).

--

On 15/03/18 22:39, Daniel Kahn Gillmor wrote:
> you could look into ext4's native encryption features

and...

On 16/03/18 00:58, gnupg at raf.org wrote:
> luks full disk encryption would be best

Yeah I just use LUKS on my PC to protect local files, but this is (as
above) for files on SMB/Windows shares... sorry for not mentioning that
sooner.

--

Any other ideas welcome :)

To be honest I was kind of hoping someone would pop up an say there was
a PGP-compatible open source alternative kernel module that did the same
thing!  Perhaps this was something the PGP guys kept closed source and
Symantec have continued to keep it that way since they bought them out?

--
Steven Maddox
Lantizia


From andrewg at andrewg.com  Fri Mar 16 10:04:24 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 16 Mar 2018 09:04:24 +0000
Subject: Stupid Symantec
In-Reply-To: <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
 <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
 <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
Message-ID: <12C06A17-6D55-4AC0-966B-3A548CABFB24@andrewg.com>


> On 16 Mar 2018, at 08:11, Steven Maddox <s.maddox at lantizia.me.uk> wrote:
> 
> Yeah this would be a cool approach that'd mean less reliance on the
> kernel.  However the files we (me and my colleagues) access (although
> they're all using Windows PCs) are on SMB/Windows shares... so somehow
> the overlay would have to work with that.

If you mounted the remote filesystem using smbfs you should be able to mount an overlayfs over the top, just like any other mounted filesystem. 

A


From psusi at ubuntu.com  Fri Mar 16 14:07:06 2018
From: psusi at ubuntu.com (Phil Susi)
Date: Fri, 16 Mar 2018 09:07:06 -0400
Subject: Stupid Symantec
In-Reply-To: <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
 <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
 <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
Message-ID: <e0e48d41-b259-22e0-a150-6afd87de6a81@ubuntu.com>

On 3/16/2018 4:11 AM, Steven Maddox wrote:
> Yeah I just use LUKS on my PC to protect local files, but this is (as
> above) for files on SMB/Windows shares... sorry for not mentioning that
> sooner.

I believe you can enable EFS on the windows server and it will handle
decrypting the file before sending it over SMB.  Then you don't need any
special software or configuration on the clients.



From s.maddox at lantizia.me.uk  Fri Mar 16 14:16:54 2018
From: s.maddox at lantizia.me.uk (Steven Maddox)
Date: Fri, 16 Mar 2018 13:16:54 +0000
Subject: Stupid Symantec
In-Reply-To: <e0e48d41-b259-22e0-a150-6afd87de6a81@ubuntu.com>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
 <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
 <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
 <e0e48d41-b259-22e0-a150-6afd87de6a81@ubuntu.com>
Message-ID: <0133e83c-889e-decd-f246-2da3210aea81@lantizia.me.uk>

I get the impression they want the decryption happening on the end users
machines.

Presumably so that if any users got the idea to just 'upload' a file
online - it'd be the encrypted version of that file.? Course someone can
just get around that by opening an encrypted file - then just saving it
to a new local location :D

But I don't make the rules around here.

Steven Maddox
Lantizia

On 16/03/18 13:07, Phil Susi wrote:
> On 3/16/2018 4:11 AM, Steven Maddox wrote:
>> Yeah I just use LUKS on my PC to protect local files, but this is (as
>> above) for files on SMB/Windows shares... sorry for not mentioning that
>> sooner.
> I believe you can enable EFS on the windows server and it will handle
> decrypting the file before sending it over SMB.  Then you don't need any
> special software or configuration on the clients.
>



From andrewg at andrewg.com  Fri Mar 16 14:15:02 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 16 Mar 2018 13:15:02 +0000
Subject: Stupid Symantec
In-Reply-To: <e0e48d41-b259-22e0-a150-6afd87de6a81@ubuntu.com>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
 <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
 <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
 <e0e48d41-b259-22e0-a150-6afd87de6a81@ubuntu.com>
Message-ID: <BBB02971-594C-4DAA-AEAC-CA56201FA7B5@andrewg.com>


> On 16 Mar 2018, at 13:07, Phil Susi <psusi at ubuntu.com> wrote:
> 
> I believe you can enable EFS on the windows server and it will handle
> decrypting the file before sending it over SMB.  Then you don't need any
> special software or configuration on the clients.

How does that work when the decryption key is on the client?

A


From psusi at ubuntu.com  Fri Mar 16 15:12:07 2018
From: psusi at ubuntu.com (Phil Susi)
Date: Fri, 16 Mar 2018 10:12:07 -0400
Subject: Stupid Symantec
In-Reply-To: <BBB02971-594C-4DAA-AEAC-CA56201FA7B5@andrewg.com>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
 <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
 <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
 <e0e48d41-b259-22e0-a150-6afd87de6a81@ubuntu.com>
 <BBB02971-594C-4DAA-AEAC-CA56201FA7B5@andrewg.com>
Message-ID: <2a79ba04-33b2-cef1-b469-ccddd99566f6@ubuntu.com>

On 3/16/2018 9:15 AM, Andrew Gallagher wrote:
> How does that work when the decryption key is on the client?

I don't think it is on the client.  The private key is stored on the
server and is decrypted when you log in.  At least I think that's how it
works.  I've never actually tried using EFS on a server.



From psusi at ubuntu.com  Fri Mar 16 15:13:08 2018
From: psusi at ubuntu.com (Phil Susi)
Date: Fri, 16 Mar 2018 10:13:08 -0400
Subject: Stupid Symantec
In-Reply-To: <0133e83c-889e-decd-f246-2da3210aea81@lantizia.me.uk>
References: <c29b46f1-d01c-2ea3-fb69-e70c3cf27a23@lantizia.me.uk>
 <c07f4b01-cc82-634e-9da4-e6660bb15bda@andrewg.com>
 <87tvthynd0.fsf@fifthhorseman.net> <20180316005845.3rbnxsi33ecl4fgz@raf.org>
 <2be230cb-4b6c-2a33-4ce1-f23ccc495b53@rushpost.com>
 <2225ce3c-2225-fb71-8380-bdb58d13776f@lantizia.me.uk>
 <e0e48d41-b259-22e0-a150-6afd87de6a81@ubuntu.com>
 <0133e83c-889e-decd-f246-2da3210aea81@lantizia.me.uk>
Message-ID: <72a76b2a-9f64-8c86-3aa2-604ac926b643@ubuntu.com>

On 3/16/2018 9:16 AM, Steven Maddox wrote:
> I get the impression they want the decryption happening on the end users
> machines.
> 
> Presumably so that if any users got the idea to just 'upload' a file
> online - it'd be the encrypted version of that file.? Course someone can
> just get around that by opening an encrypted file - then just saving it
> to a new local location :D

Since it is automatically decrypted when opened, the uploaded file would
be decrypted.




From karel-v_g at tutanota.com  Mon Mar 19 18:57:02 2018
From: karel-v_g at tutanota.com (karel-v_g at tutanota.com)
Date: Mon, 19 Mar 2018 18:57:02 +0100 (CET)
Subject: OpenPGP-Card v3.3 - ECC Curve25519 supported?
Message-ID: <L7zP3bB--3-0@tutanota.com>

Hello!
I have seen that the latest revision of OpenPGP-cards (3.3) supports ECC-keys and is available for sale.
Does this also include curve25519 or "only" Brainpool and NIST?
Thanks for enlightment!
Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180319/336b9c3c/attachment.html>

From gnupg-users.dirk at o.banes.ch  Tue Mar 20 20:41:32 2018
From: gnupg-users.dirk at o.banes.ch (gnupg-users.dirk at o.banes.ch)
Date: Tue, 20 Mar 2018 20:41:32 +0100
Subject: OpenPGP-Card v3.3 - ECC Curve25519 supported?
In-Reply-To: <L7zP3bB--3-0@tutanota.com>
References: <L7zP3bB--3-0@tutanota.com>
Message-ID: <827e11e2-9e22-5fe3-6996-457f9c3e3ec8@o.banes.ch>

Hello Karel,

I do not recommend buying it.
There is a bug in case of someone trying to send you 3DES? encrytped
messages [1][2].
As well it is not really backward compatible and there is no real
documentation how to fix this except of [3]

However Documentation does not state curve25519 but Brainpool [4] (p 32).

best regards

Dirk

[1] https://dev.gnupg.org/T3576
[2] https://wiki.gnupg.org/SmartCard#Known_Bug.28s.29_of_OpenPGPcard
[3] https://lists.gnupg.org/pipermail/gnupg-users/2018-March/060074.html
[4] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.pdf


On 19.03.2018 18:57, karel-v_g at tutanota.com wrote:
> Hello!
> I have seen that the latest revision of OpenPGP-cards (3.3) supports
> ECC-keys and is available for sale.
> Does this also include curve25519 or "only" Brainpool and NIST?
> Thanks for enlightment!
> Karel
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users




From dirk.gottschalk1980 at googlemail.com  Tue Mar 20 23:42:51 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Tue, 20 Mar 2018 23:42:51 +0100
Subject: OpenPGP-Card v3.3 - ECC Curve25519 supported?
In-Reply-To: <L7zP3bB--3-0@tutanota.com>
References: <L7zP3bB--3-0@tutanota.com>
Message-ID: <1521585771.12696.5.camel@googlemail.com>

Hello.

I have one oif this new openPGP Cards v3.3 and yes, they are capable of
nist / brainpool only. curve25519 is not supported.

I use it only with RSA keys for compatiblity reasons. Not everybody
uses ECC capable versions of GnuPG or other compatible openPGP
software.

The card itself works well. I use it for various authentication,
signing and encryption purposes like Email, SSH and in combination with
gpgsm.

Regards,
Dirk


Am Montag, den 19.03.2018, 18:57 +0100 schrieb karel-v_g at tutanota.com:
> Hello!
> I have seen that the latest revision of OpenPGP-cards (3.3) supports
> ECC-keys and is available for sale.
> Does this also include curve25519 or "only" Brainpool and NIST?
> Thanks for enlightment!
> Karel
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180320/8be3b1da/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4571 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180320/8be3b1da/attachment-0001.bin>

From Bobby.Briones at rms.nsw.gov.au  Tue Mar 20 22:10:39 2018
From: Bobby.Briones at rms.nsw.gov.au (BRIONES Bobby)
Date: Wed, 21 Mar 2018 08:10:39 +1100
Subject: GnuPG installation
Message-ID: <4C882FBAEDF86E43AA753655F19F1D954D3FC21924@COREXC01.corp.rta.nsw.gov.au>

Hi,

I have the following questions about the abovementioned package,  can someone help me please:

What access do I need to be able to install the software?
Do I just download the software and install? What about access to our existing folders used in our SFTG/transfer of files?


Regards,

Bobby Briones
Technical Test Analyst
IT | Corporate
T (0288492011)
M (0431459917)

www.rms.nsw.gov.au<http://www.rms.nsw.gov.au/>
Every journey matters

Roads and Maritime Services
Level 4 27-29 Argyle St Parramatta NSW 2150


Before printing, please consider the environment

IMPORTANT NOTICE: This email and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. Roads and Maritime Services is not responsible for any unauthorised alterations to this email or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of Roads and Maritime Services. If you receive this email in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this email if you are not the intended recipient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180321/c5cde3b8/attachment.html>

From edgar at pettijohn-web.com  Wed Mar 21 12:25:13 2018
From: edgar at pettijohn-web.com (edgar at pettijohn-web.com)
Date: Wed, 21 Mar 2018 06:25:13 -0500
Subject: GnuPG installation
Message-ID: <mailman.9.1521631626.30378.gnupg-users@gnupg.org>


On Mar 20, 2018 4:10 PM, BRIONES Bobby <Bobby.Briones at rms.nsw.gov.au> wrote:
>
> Hi,
>
> ?
>
> I have the following questions about the abovementioned package, ?can someone help me please:
>
> ?
>
> What access do I need to be able to install the software?
>

You may want to mention what OS you are using.


> Do I just download the software and install? What about access to our existing folders used in our SFTG/transfer of files?
>
> ?
>
> ?
>
> Regards,
>
> ?
>
> Bobby Briones
> Technical Test Analyst
>
> IT | Corporate
>
> T (0288492011)
>
> M (0431459917)
>
> www.rms.nsw.gov.au
> Every journey matters
>
> ?
>
> Roads and Maritime Services
> Level 4 27-29 Argyle?St Parramatta NSW 2150
>
> ?
>
> Before printing, please consider the environment
>
> IMPORTANT NOTICE: This email and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. Roads and Maritime Services is not responsible for any unauthorised alterations to this email or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of Roads and Maritime Services. If you receive this email in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this email if you are not the intended recipient.

From evan at eklitzke.org  Wed Mar 21 22:48:26 2018
From: evan at eklitzke.org (Evan Klitzke)
Date: Wed, 21 Mar 2018 14:48:26 -0700
Subject: Using gpg-agent --supervised with systemd
Message-ID: <87h8p9yuad.fsf@eklitzke.org>

Hi all,

I am using gpg 2.2.5 and stumbled across the --supervised option while 
reading the man page. I was able to get the ssh-agent functionality 
working perfectly, but I'm having problems with the gpg-agent 
functionality.

I created systemd user units for ssh-agent.socket, gpg-agent.socket, and 
gpg-agent.service. I was able to get this all set up correctly so the 
gpg-agent service knows where its sockets are:

$ sysu status gpg-agent.service
...
Mar 21 14:34:12 t460s systemd[1075]: Started GPG agent.
Mar 21 14:34:12 t460s gpg-agent[2835]: gpg-agent (GnuPG) 2.2.5 starting 
in supervised mode.
Mar 21 14:34:12 t460s gpg-agent[2835]: using fd 3 for std socket 
(/run/user/1000/gpg-agent.sock)
Mar 21 14:34:12 t460s gpg-agent[2835]: using fd 4 for ssh socket 
(/run/user/1000/ssh-agent.sock)
Mar 21 14:34:12 t460s gpg-agent[2835]: listening on: std=3 extra=-1 
browser=-1 ssh=4

That's exactly where I put the sockets, so all good on that front. I was 
also able to figure out how to get pinentry working correctly. I set 
SSH_AUTH_SOCK and indeed, ssh uses the right socket and talks to my 
gpg-agent service.

However, gpg2 is still getting confused and not finding the agent. The 
README file for gpg 2.2 has some hints on why this may be the case:

> Note that gpg-agent now uses a fixed socket.  All tools will start
> the gpg-agent as needed.  The formerly used environment variable
> GPG_AGENT_INFO is ignored by 2.2.  The SSH_AUTH_SOCK environment
> variable should be set to a fixed value.

This is indeed what I see: when I try to use gpg2, it starts its own 
gpg-agent, ignoring my systemd service. I tried different permutations 
of options but can't figure out why this isn't working. Whenever I try 
to decrypt a file, gpg2 thinks there isn't an agent process running, and 
tries to start its own in ~/.gnupg.

What is the trick to making this work correctly?

--
Evan Klitzke                    San Francisco, CA, USA
evan at eklitzke.org                 https://eklitzke.org
pgp: AF91 7318 B8C4 2D11 2721 625D 157E FCAC BC64 8422


From edgar at pettijohn-web.com  Thu Mar 22 00:14:35 2018
From: edgar at pettijohn-web.com (Edgar Pettijohn)
Date: Wed, 21 Mar 2018 18:14:35 -0500
Subject: GnuPG installation
In-Reply-To: <4C882FBAEDF86E43AA753655F19F1D954D3FC8F25A@COREXC01.corp.rta.nsw.gov.au>
References: <EC.AB.03871.02142BA5@mx21.rta.nsw.gov.au>
 <4C882FBAEDF86E43AA753655F19F1D954D3FC8F25A@COREXC01.corp.rta.nsw.gov.au>
Message-ID: <32a6c284-14c7-b63c-ce38-05981e754e01@pettijohn-web.com>



On 03/21/18 15:27, BRIONES Bobby wrote:
> Hi,
> Thanks for responding.
> We are using linux.
>
> Bobby

Which flavor? You will need to find out whatever the package manager is 
for whichever flavor of linux you are using. You will need root 
permissions either through su(1) or sudo(8).

Or you can download and compile yourself. It may be as easy as:

# ./configure && make && make install

>
> -----Original Message-----
> From: edgar at pettijohn-web.com [mailto:edgar at pettijohn-web.com]
> Sent: Wednesday, 21 March 2018 10:25 PM
> To: BRIONES Bobby; gnupg-users at gnupg.org
> Subject: Re: GnuPG installation
>
>
> On Mar 20, 2018 4:10 PM, BRIONES Bobby <Bobby.Briones at rms.nsw.gov.au> wrote:
>> Hi,
>>
>>   
>>
>> I have the following questions about the abovementioned package,  can someone help me please:
>>
>>   
>>
>> What access do I need to be able to install the software?
>>
> You may want to mention what OS you are using.
>
>
>> Do I just download the software and install? What about access to our existing folders used in our SFTG/transfer of files?
>>
>>   
>>
>>   
>>
>> Regards,
>>
>>   
>>
>> Bobby Briones
>> Technical Test Analyst
>>
>> IT | Corporate
>>
>> T (0288492011)
>>
>> M (0431459917)
>>
>> www.rms.nsw.gov.au
>> Every journey matters
>>
>>   
>>
>> Roads and Maritime Services
>> Level 4 27-29 Argyle St Parramatta NSW 2150
>>
>>   
>>
>> Before printing, please consider the environment
>>
>> IMPORTANT NOTICE: This email and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. Roads and Maritime Services is not responsible for any unauthorised alterations to this email or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of Roads and Maritime Services. If you receive this email in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this email if you are not the intended recipient.
> Before printing, please consider the environment
>
> IMPORTANT NOTICE: This email and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. Roads and Maritime Services is not responsible for any unauthorised alterations to this email or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of Roads and Maritime Services. If you receive this email in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this email if you are not the intended recipient.



From mangocats at gmail.com  Wed Mar 21 23:53:07 2018
From: mangocats at gmail.com (Mike Inman)
Date: Wed, 21 Mar 2018 18:53:07 -0400
Subject: gpgme_set_passphrase_cb not cooperating...
Message-ID: <CAAqEqK1Zzz=fvfo2ApaEpqjMQHegnSpU7A_HDhCAR7evOu3n4g@mail.gmail.com>

Hello,

I've been struggling with using gpgme_set_passphrase_cb() in an automated
environment (#include <gpgme.h> C gpgme in a C++ program) - it doesn't seem
to have any effect, I still get the system prompts for passphrases.  The
files encrypt and decrypt as one would expect, but due to the automated
end-use case, the user prompts are not acceptable.

I've tried adding: gpgme_set_pinentry_mode( ctx,
GPGME_PINENTRY_MODE_LOOPBACK ); to the code, and then I don't get the
prompts anymore, but the encrypt function returns without an error code,
and the output (cipher) file is zero length.

This is my encrypt function meat:

{{{

LOG_FAIL_IF_GPGERR( initGpgme() )

LOG_FAIL_IF_GPGERR( gpgme_new( &ctx ) )

// gpgme_set_pinentry_mode( ctx, GPGME_PINENTRY_MODE_LOOPBACK );

gpgme_set_passphrase_cb( ctx, passphraseCallback, NULL );

LOG_FAIL_IF_GPGERR( gpgme_data_new_from_file(  &plain,
fi.filePath().toLatin1().data(), 1 ) )

LOG_FAIL_IF_GPGERR( gpgme_data_set_encoding (   plain,
GPGME_DATA_ENCODING_BINARY         ) )

LOG_FAIL_IF_GPGERR( gpgme_data_new_from_fd  ( &cipher,
outFile.handle()                   ) )

LOG_FAIL_IF_GPGERR( gpgme_data_set_encoding (  cipher,
GPGME_DATA_ENCODING_BINARY         ) )

// recp[0] = settingsKey;

// recp[1] = NULL; // using symmetric encryption instead

LOG_FAIL_IF_GPGERR( gpgme_op_encrypt( ctx, NULL, flags, plain, cipher ) );

gpgme_data_release( plain );

gpgme_data_release( cipher );

gpgme_release( ctx );

outFile.close();

}}}


and, for the moment, the passphrase callback returns a fixed string,
but as far as I can tell, it never gets called in either case:


{{{

extern "C" {

gpgme_error_t passphraseCallback(void *hook, const char *uid_hint,
const char *passphrase_info, int prev_was_bad, int fd);

}


gpgme_error_t passphraseCallback(void *hook, const char *uid_hint,
const char *passphrase_info, int prev_was_bad, int fd)

{ qInfo( "passphraseCallback( hook:%llx uid_hint:%s passphrase_info:%s
prev_was_bad:%d", (long long)hook, uid_hint, passphrase_info,
prev_was_bad );

  char phrase[103];

  strncpy(phrase, "CorrectHorseBatteryStaple", 100);

  strcat(phrase, "\n");


  if ( gpgme_io_writen( fd, phrase, strlen(phrase) ) != 0 )

    return GPG_ERR_USER_1;

  return GPG_ERR_NO_ERROR;

}

}}}


I have used similar code to work with private/public key pairs that
have no passphrase assigned and they seem to be working as expected,
but I think in this application I'd rather use symmetric encryption
with the passphrase obscured in my executable code.


Which versions of gpg/gpgme support passphrase callback setting for
symmetric encryption?  My gpgme_check_version returns 1.5.5 and gpg
--version returns 1.4.18 in Ubuntu 15.10


Any help would be appreciated.


Thanks,


Mike Inman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180321/ee66117f/attachment-0001.html>

From wk at gnupg.org  Thu Mar 22 08:20:59 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 22 Mar 2018 08:20:59 +0100
Subject: gpgme_set_passphrase_cb not cooperating...
In-Reply-To: <CAAqEqK1Zzz=fvfo2ApaEpqjMQHegnSpU7A_HDhCAR7evOu3n4g@mail.gmail.com>
 (Mike Inman's message of "Wed, 21 Mar 2018 18:53:07 -0400")
References: <CAAqEqK1Zzz=fvfo2ApaEpqjMQHegnSpU7A_HDhCAR7evOu3n4g@mail.gmail.com>
Message-ID: <87o9jga84k.fsf@wheatstone.g10code.de>

On Wed, 21 Mar 2018 23:53, mangocats at gmail.com said:

> Which versions of gpg/gpgme support passphrase callback setting for
> symmetric encryption?  My gpgme_check_version returns 1.5.5 and gpg
> --version returns 1.4.18 in Ubuntu 15.10

I doubt that it will work with 1.4.  Note that gpgme prefers an
installed GnuPG 2 version and that may be an too old version or
combination of GnuPG 2 and gpgme.

I would suggest that you run your application with 

GPGME_DEBUG=9:gpgme.log: ./your-application

and check the created log file.  It will have the used gpg version right
at the top and log the entire communication between gpgme and gpg.


Salam-Shalom,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180322/c4993c4a/attachment.sig>

From mangocats at gmail.com  Thu Mar 22 13:58:19 2018
From: mangocats at gmail.com (Mike Inman)
Date: Thu, 22 Mar 2018 08:58:19 -0400
Subject: gpgme_set_passphrase_cb not cooperating...
In-Reply-To: <87o9jga84k.fsf@wheatstone.g10code.de>
References: <CAAqEqK1Zzz=fvfo2ApaEpqjMQHegnSpU7A_HDhCAR7evOu3n4g@mail.gmail.com>
 <87o9jga84k.fsf@wheatstone.g10code.de>
Message-ID: <CAAqEqK2+XgNq=hVRkhve9nX=jNicZzhFXQvK4ug2xzp3QbkSdw@mail.gmail.com>

Thanks Werner,

I did that, saw the call to gpg2 (2.0.28, libcrypt 1.6.3), tried changing
the engine to /usr/bin/gpg ( using  gpgme_ctx_set_engine_info( ctx,
GPGME_PROTOCOL_OpenPGP, "/usr/bin/gpg", NULL ) ) and that worked under
Ubuntu.

Now, my target environment is CentOS 7, and they resolve /usr/bin/gpg with
a link to /usr/bin/gpg2 - which does not play nice with
set_passphrase_cb().  Any suggestions on the best way to untangle that knot?

Mike



On Thu, Mar 22, 2018 at 3:20 AM, Werner Koch <wk at gnupg.org> wrote:

> On Wed, 21 Mar 2018 23:53, mangocats at gmail.com said:
>
> > Which versions of gpg/gpgme support passphrase callback setting for
> > symmetric encryption?  My gpgme_check_version returns 1.5.5 and gpg
> > --version returns 1.4.18 in Ubuntu 15.10
>
> I doubt that it will work with 1.4.  Note that gpgme prefers an
> installed GnuPG 2 version and that may be an too old version or
> combination of GnuPG 2 and gpgme.
>
> I would suggest that you run your application with
>
> GPGME_DEBUG=9:gpgme.log: ./your-application
>
> and check the created log file.  It will have the used gpg version right
> at the top and log the entire communication between gpgme and gpg.
>
>
> Salam-Shalom,
>
>    Werner
>
>
> --
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180322/9ce6e293/attachment.html>

From Bobby.Briones at rms.nsw.gov.au  Wed Mar 21 21:27:02 2018
From: Bobby.Briones at rms.nsw.gov.au (BRIONES Bobby)
Date: Thu, 22 Mar 2018 07:27:02 +1100
Subject: GnuPG installation
In-Reply-To: <EC.AB.03871.02142BA5@mx21.rta.nsw.gov.au>
References: <EC.AB.03871.02142BA5@mx21.rta.nsw.gov.au>
Message-ID: <4C882FBAEDF86E43AA753655F19F1D954D3FC8F25A@COREXC01.corp.rta.nsw.gov.au>

Hi,
Thanks for responding.
We are using linux.

Bobby

-----Original Message-----
From: edgar at pettijohn-web.com [mailto:edgar at pettijohn-web.com] 
Sent: Wednesday, 21 March 2018 10:25 PM
To: BRIONES Bobby; gnupg-users at gnupg.org
Subject: Re: GnuPG installation


On Mar 20, 2018 4:10 PM, BRIONES Bobby <Bobby.Briones at rms.nsw.gov.au> wrote:
>
> Hi,
>
> ?
>
> I have the following questions about the abovementioned package, ?can someone help me please:
>
> ?
>
> What access do I need to be able to install the software?
>

You may want to mention what OS you are using.


> Do I just download the software and install? What about access to our existing folders used in our SFTG/transfer of files?
>
> ?
>
> ?
>
> Regards,
>
> ?
>
> Bobby Briones
> Technical Test Analyst
>
> IT | Corporate
>
> T (0288492011)
>
> M (0431459917)
>
> www.rms.nsw.gov.au
> Every journey matters
>
> ?
>
> Roads and Maritime Services
> Level 4 27-29 Argyle?St Parramatta NSW 2150
>
> ?
>
> Before printing, please consider the environment
>
> IMPORTANT NOTICE: This email and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. Roads and Maritime Services is not responsible for any unauthorised alterations to this email or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of Roads and Maritime Services. If you receive this email in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this email if you are not the intended recipient.

Before printing, please consider the environment

IMPORTANT NOTICE: This email and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. Roads and Maritime Services is not responsible for any unauthorised alterations to this email or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of Roads and Maritime Services. If you receive this email in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this email if you are not the intended recipient.

From mangocats at gmail.com  Thu Mar 22 00:05:57 2018
From: mangocats at gmail.com (Mike Inman)
Date: Wed, 21 Mar 2018 19:05:57 -0400
Subject: Followup: gpgme_set_passphrase_cb not working...
Message-ID: <CAAqEqK0xpNWxiNKHurHS0v5_pnvEUgJ6Ew_6C_K9tD84yN9szg@mail.gmail.com>

FWIW, here's the log entry from an attempt to use gpgme_set_passphrase_cb
on a symmetric encryption.  For some reason I still cannot figure out, my
callback function isn't being used, the system prompt still appears (twice,
once to confirm.)



GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_release: call: ctx=0x17b8980
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_check_version: call: 0=(nil),
req_version=(null), VERSION=1.5.5
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_check_version_internal: call:
0=(nil), req_version=(null), offset_sig_validity=60
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_set_locale: enter: ctx=(nil),
category=0, value=en_US.UTF-8
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_set_locale: leave
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_set_locale: enter: ctx=(nil),
category=5, value=en_US.UTF-8
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_set_locale: leave
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_new: enter: r_ctx=0x7ffc864d3420
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_new: leave: ctx=0x18160a0
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_set_passphrase_cb: call:
ctx=0x18160a0, passphrase_cb=0x44cb20/(nil)
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_new_from_filepart: enter:
r_dh=0x7ffc864d3440, file_name=/home/mike/ft/working/settings/n4sGrass,
copy=1 (yes)
GPGME 2018-03-21 18:58:18 <0x6205>    gpgme_data_new_from_filepart: enter:
r_dh=0x7ffc864d3440, file_name=/home/mike/ft/working/settings/n4sGrass,
stream=(nil), offset=0, length=8
GPGME 2018-03-21 18:58:18 <0x6205>      gpgme_data_new: enter:
r_dh=0x7ffc864d3440
GPGME 2018-03-21 18:58:18 <0x6205>      gpgme_data_new: leave: dh=0x1830c30
GPGME 2018-03-21 18:58:18 <0x6205>    gpgme_data_new_from_filepart: leave:
r_dh=0x1830c30
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_new_from_filepart: leave
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_set_encoding: enter:
dh=0x1830c30, encoding=1
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_set_encoding: leave
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_new_from_fd: enter:
r_dh=0x7ffc864d3430, fd=0x1b
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_new_from_fd: leave:
dh=0x18385e0
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_set_encoding: enter:
dh=0x18385e0, encoding=1
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_data_set_encoding: leave
GPGME 2018-03-21 18:58:18 <0x6205>  gpgme_op_encrypt: enter: ctx=0x18160a0,
flags=0x1, plain=0x1830c30, cipher=0x18385e0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: enter:
filedes=0x1831ca8, inherit_idx=1 (GPGME uses it for reading)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: leave: read=0x1c,
write=0x1d
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x1c, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x1d, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    gpgme_data_get_file_name: call:
dh=0x1830c30, dh->file_name=(null)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: enter:
filedes=0x7ffc864d2ac0, inherit_idx=0 (GPGME uses it for writing)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: leave: read=0x1e,
write=0x1f
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x1e, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x1f, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: enter:
filedes=0x7ffc864d2ac0, inherit_idx=1 (GPGME uses it for reading)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: leave: read=0x20,
write=0x21
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x20, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x21, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: enter:
filedes=0x7ffc864d2ac0, inherit_idx=0 (GPGME uses it for writing)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_pipe: leave: read=0x22,
write=0x23
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x22, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: enter:
fd=0x23, close_handler=0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_close_notify: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: enter:
path=0x1831dd0, path=/usr/bin/gpg2
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 0] = gpg2
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 1] = --enable-special-filenames
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 2] = --no-sk-comments
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 3] = --lc-messages
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 4] = en_US.UTF-8
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 5] = --lc-ctype
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 6] = en_US.UTF-8
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 7] = --status-fd
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 8] = 29
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[ 9] = --no-tty
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[10] = --charset
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[11] = utf8
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[12] = --enable-progress-filter
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[13] = --display
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[14] = :0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[15] = --command-fd
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[16] = 30
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[17] = --symmetric
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[18] = --output
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[19] = -
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[20] = --
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, argv[21] = -&34
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, fd[0] = 0x1d
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, fd[1] = 0x1e
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, fd[2] = 0x21 -> 0x1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, fd[3] = 0x22
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: check:
path=0x1831dd0, waiting for child process pid=25125
GPGME 2018-03-21 18:58:18 <0x6226>      gpgme:max_fds: call: 0=(nil), max
fds=65536 (RLIMIT_NOFILE)
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: enter: fd=0x1d
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: check: fd=0x1d,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: leave: result=0
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: enter: fd=0x1e
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: check: fd=0x1e,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: leave: result=0
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: enter: fd=0x21
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: check: fd=0x21,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: leave: result=0
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: enter: fd=0x22
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: check: fd=0x22,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: leave: result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_spawn: leave: result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_add_io_cb: call:
ctx=0x18160a0, fd 28, dir=1 -> tag=0x1832c40
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_add_io_cb: call:
ctx=0x18160a0, fd 32, dir=1 -> tag=0x1832d90
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_add_io_cb: call:
ctx=0x18160a0, fd 35, dir=0 -> tag=0x1832de0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_nonblocking: enter:
fd=0x23
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_set_nonblocking: leave:
result=0
GPGME 2018-03-21 18:58:18 <0x6205>    gpgme:gpg_io_event: call:
gpg=0x1831c80, event 0x7f909935f860, type 0, type_data (nil)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832e00, need to check
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832e00, handler (0x1830c30, 35)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_data_outbound_handler: enter:
dh=0x1830c30, fd=0x23
GPGME 2018-03-21 18:58:18 <0x6205>      gpgme_data_read: enter:
dh=0x1830c30, buffer=0x1830c3c, size=4096
GPGME 2018-03-21 18:58:18 <0x6205>      gpgme_data_read: leave: result=8
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_write: enter: fd=0x23,
buffer=0x1830c3c, count=8
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_write: check:
646f726b6c79320a                  dorkly2.
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_write: leave: result=8
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_data_outbound_handler: leave
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832e00, need to check
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ w0x23 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832e00, handler (0x1830c30, 35)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_data_outbound_handler: enter:
dh=0x1830c30, fd=0x23
GPGME 2018-03-21 18:58:18 <0x6205>      gpgme_data_read: enter:
dh=0x1830c30, buffer=0x1830c3c, size=4096
GPGME 2018-03-21 18:58:18 <0x6205>      gpgme_data_read: leave: result=0
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: enter: fd=0x23
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: check: fd=0x23,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:18 <0x6205>        _gpgme_remove_io_cb: call:
data=0x1832de0, setting fd 0x23 (item=0x1832e00) done
GPGME 2018-03-21 18:58:18 <0x6205>      _gpgme_io_close: leave: result=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_data_outbound_handler: leave
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, need to check
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x1c ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, handler (0x1831c80, 28)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: enter: fd=0x1c,
buffer=0x18323b0, count=1024
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
5b474e5550473a5d 2050524f47524553 [GNUPG:] PROGRES
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
53202d263334203f 203020300a5b474e S -&34 ? 0 0.[GN
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
5550473a5d205052 4f4752455353206e UPG:] PROGRESS n
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
6565645f656e7472 6f70792058203820 eed_entropy X 8
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
31360a5b474e5550 473a5d2050524f47 16.[GNUPG:] PROG
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
52455353206e6565 645f656e74726f70 RESS need_entrop
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
7920582031362031 360a             y X 16 16.
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: leave: result=106
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, need to check
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x1c ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, handler (0x1831c80, 28)
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: enter: fd=0x1c,
buffer=0x18323b0, count=1024
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
5b474e5550473a5d 204e4545445f5041 [GNUPG:] NEED_PA
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check:
5353504852415345 5f53594d20332033 SSPHRASE_SYM 3 3
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: check: 20320a
                    2.
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_read: leave: result=35
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:18 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:19 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ ]
GPGME 2018-03-21 18:58:19 <0x6205>    _gpgme_io_select: leave: result=0
GPGME 2018-03-21 18:58:19 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:19 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:20 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ ]
GPGME 2018-03-21 18:58:20 <0x6205>    _gpgme_io_select: leave: result=0
GPGME 2018-03-21 18:58:20 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:20 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:21 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ ]
GPGME 2018-03-21 18:58:21 <0x6205>    _gpgme_io_select: leave: result=0
GPGME 2018-03-21 18:58:21 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:21 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=2
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, need to check
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x1c ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, handler (0x1831c80, 28)
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: enter: fd=0x1c,
buffer=0x18323b0, count=1024
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: check:
5b474e5550473a5d 20424547494e5f45 [GNUPG:] BEGIN_E
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: check:
4e4352595054494f 4e203020330a     NCRYPTION 0 3.
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: leave: result=30
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832db0, need to check
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832db0, handler (0x18385e0, 32)
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_data_inbound_handler: enter:
dh=0x18385e0, fd=0x20
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: enter: fd=0x20,
buffer=0x7ffc864d1a10, count=4096
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: check:
8c0d04030302c796 e5e316be0535fec9 .............5..
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: leave: result=16
GPGME 2018-03-21 18:58:22 <0x6205>      gpgme_data_write: enter:
dh=0x18385e0, buffer=0x7ffc864d1a10, size=16
GPGME 2018-03-21 18:58:22 <0x6205>      gpgme_data_write: leave: result=16
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_data_inbound_handler: leave
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, need to check
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x1c ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, handler (0x1831c80, 28)
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: enter: fd=0x1c,
buffer=0x18323b0, count=1024
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: check:
5b474e5550473a5d 2050524f47524553 [GNUPG:] PROGRES
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: check:
53202d263334203f 203820300a5b474e S -&34 ? 8 0.[GN
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: check:
5550473a5d20454e 445f454e43525950 UPG:] END_ENCRYP
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: check: 54494f4e0a
                   TION.
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: leave: result=53
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832db0, need to check
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832db0, handler (0x18385e0, 32)
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_data_inbound_handler: enter:
dh=0x18385e0, fd=0x20
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: enter: fd=0x20,
buffer=0x7ffc864d1a10, count=4096
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: check:
1ea19a1e910ae6fc fc8d2bea1f9ece4c ..........+....L
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: check:
91accf12af3ba8d2 05054d50191f1f   .....;....MP...
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: leave: result=31
GPGME 2018-03-21 18:58:22 <0x6205>      gpgme_data_write: enter:
dh=0x18385e0, buffer=0x7ffc864d1a10, size=31
GPGME 2018-03-21 18:58:22 <0x6205>      gpgme_data_write: leave: result=31
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_data_inbound_handler: leave
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x1832c90, nfds=10, nonblock=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select on [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x1832c90, select OK [ r0x1c r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=2
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, need to check
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x1c ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x1c ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832c60, handler (0x1831c80, 28)
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: enter: fd=0x1c,
buffer=0x18323b0, count=1024
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_read: leave: result=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_close: enter: fd=0x1c
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_close: check: fd=0x1c,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_remove_io_cb: call:
data=0x1832c40, setting fd 0x1c (item=0x1832c60) done
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_close: leave: result=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832db0, need to check
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: enter:
fds=0x7ffc864d2a60, nfds=1, nonblock=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select on [ r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: check:
fds=0x7ffc864d2a60, select OK [ r0x20 ]
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_io_select: leave: result=1
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_run_io_cb: call:
item=0x1832db0, handler (0x18385e0, 32)
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_data_inbound_handler: enter:
dh=0x18385e0, fd=0x20
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: enter: fd=0x20,
buffer=0x7ffc864d1a10, count=4096
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_read: leave: result=0
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_close: enter: fd=0x20
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_close: check: fd=0x20,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:22 <0x6205>        _gpgme_remove_io_cb: call:
data=0x1832d90, setting fd 0x20 (item=0x1832db0) done
GPGME 2018-03-21 18:58:22 <0x6205>      _gpgme_io_close: leave: result=0
GPGME 2018-03-21 18:58:22 <0x6205>    _gpgme_data_inbound_handler: leave
GPGME 2018-03-21 18:58:22 <0x6205>    gpgme:gpg_io_event: call:
gpg=0x1831c80, event 0x7f909935f860, type 1, type_data 0x7ffc864d2ac0
GPGME 2018-03-21 18:58:22 <0x6205>  gpgme_op_encrypt: leave
GPGME 2018-03-21 18:58:22 <0x6205>  gpgme_data_release: call: dh=0x1830c30
GPGME 2018-03-21 18:58:22 <0x6205>  gpgme_data_release: call: dh=0x18385e0
GPGME 2018-03-21 18:58:22 <0x6205>  gpgme_release: call: ctx=0x18160a0
GPGME 2018-03-21 18:58:22 <0x6205>  _gpgme_io_close: enter: fd=0x1f
GPGME 2018-03-21 18:58:22 <0x6205>  _gpgme_io_close: check: fd=0x1f,
invoking close handler 0x7f909936e350/0x1831c80
GPGME 2018-03-21 18:58:22 <0x6205>  _gpgme_io_close: leave: result=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180321/85ec2e44/attachment-0001.html>

From mycraigsl at ymail.com  Thu Mar 22 22:24:04 2018
From: mycraigsl at ymail.com (MyCraigs List)
Date: Thu, 22 Mar 2018 21:24:04 +0000 (UTC)
Subject: Is passphrase correct?
References: <109338900.3858608.1521753844142.ref@mail.yahoo.com>
Message-ID: <109338900.3858608.1521753844142@mail.yahoo.com>

I want to be able to verify that I'm using the correct passphrase associated with an email address of mine.

In other words- I'm trying to make sure I haven't forgotten the passphrase and need a way to test it...preferably using command line (Linux).

How can this be done?

Thank you,

Craig



From aheinecke at intevation.de  Fri Mar 23 09:35:04 2018
From: aheinecke at intevation.de (Andre Heinecke)
Date: Fri, 23 Mar 2018 09:35:04 +0100
Subject: Followup: gpgme_set_passphrase_cb not working...
In-Reply-To: <CAAqEqK0xpNWxiNKHurHS0v5_pnvEUgJ6Ew_6C_K9tD84yN9szg@mail.gmail.com>
References: <CAAqEqK0xpNWxiNKHurHS0v5_pnvEUgJ6Ew_6C_K9tD84yN9szg@mail.gmail.com>
Message-ID: <1585018.SguQZ4F9mc@esus>

Hi,

On Wednesday, March 21, 2018 7:05:57 PM CET Mike Inman wrote:
> FWIW, here's the log entry from an attempt to use gpgme_set_passphrase_cb
> on a symmetric encryption.  For some reason I still cannot figure out, my
> callback function isn't being used, the system prompt still appears (twice,
> once to confirm.)

From the other thread I take it that you are using GPGME with GnuPG-2.0.28 ? 
In the log I don't see the gpg version, but I didn't see it mentioned in the 
other thread that the GnuPG-2.0.x series does not support the passphrase 
callback.

I ran into the same problem some time ago and documented it as a note in the 
GPGME manual. https://www.gnupg.org/documentation/manuals/gpgme/Passphrase-Callback.html#Passphrase-Callback :

"Note: The passphrase_cb only works with GnuPG 1.x and 2.1.x and not with the 
2.0.x series. "

An ugly workaround could be to use some kind of fake pinentry (see the tests 
in GPGME) and configure that in the gpg-agent.conf. But you are probably better 
of bundling a 2.1 / 2.2 Version of GnuPG with your Application.

Best Regards,
Andre


-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180323/73b5677f/attachment.sig>

From johannes at zarl-zierl.at  Thu Mar 22 22:37:22 2018
From: johannes at zarl-zierl.at (Johannes Zarl-Zierl)
Date: Thu, 22 Mar 2018 22:37:22 +0100
Subject: Missing feedback when changing a card pin fails
Message-ID: <4466795.t10R3260g5@mani>

Hi,

I've just spent half an hour scratching my head over an issue that should have 
been simple:

I initialized a new OpenPGP card (v2.1 from Zeitcontrol) and changed the 
(user) pin.

After this, I used the verify command to check whether the pin was working: I 
put my pin into the pinentry dialog, and verified that the retry count 
afterwards was still "3 0 3".
Still, when I was prompted the pin afterwards I got the error "wrong pin". 
Strangely enough, the retry counter did not decrease when entering the pin. 
Entering a different random pin resulted in the retry counter decreasing as it 
should.

[Fast-forward through lots of head-scratching, mild swearing and asking myself 
whether the card was broken.]

In the end the simple truth was that my pin code only had 5 digits, but the 
minimum length is higher. Yes, I know that I *should* know the minimum pin-
code length for my card, and that I *should* use longer pins anyways.

Is it possible to issue some kind of diagnostic for this? I.e. either a 
warning/error message when changing the pin, or at least the "verify" command 
issuing a warning on an incorrect pin?

Btw. my gpg version is 2.2.5.

Cheers,
  Johannes


From peter at digitalbrains.com  Fri Mar 23 13:19:26 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 23 Mar 2018 13:19:26 +0100
Subject: Is passphrase correct?
In-Reply-To: <109338900.3858608.1521753844142@mail.yahoo.com>
References: <109338900.3858608.1521753844142.ref@mail.yahoo.com>
 <109338900.3858608.1521753844142@mail.yahoo.com>
Message-ID: <fe57cb94-4db5-d52e-d6e5-4ae2e0bf646d@digitalbrains.com>

On 22/03/18 22:24, MyCraigs List via Gnupg-users wrote:
> In other words- I'm trying to make sure I haven't forgotten the
> passphrase and need a way to test it...preferably using command line
> (Linux).

--8<---------------cut here---------------start------------->8---
$ echo test | gpg -r '<peter at digitalbrains.com>' -e | gpg -d
gpg: peter at digitalbrains.com: Verified X signatures in the past 19 months.
     Encrypted Y messages in the past 15 months.
gpg: encrypted with 2048-bit RSA key, ID 26F7563E73A33BEE, created
2009-11-12
      "Peter Lebbing <peter at digitalbrains.com>"
test
--8<---------------cut here---------------end--------------->8---

The fact that "test" shows up at the end proves that I could decrypt the
message, and that proves my passphrase was correct.

Note that I used my e-mail address as the "recipient" of the encrypted
message, but this might match multiple keys. Use your fingerprint to
uniquely select the correct key to check the passphrase for. The long
key ID is an okayish method of specifying it as well. Don't use the
short key ID.

--8<---------------cut here---------------start------------->8---
$ gpg --keyid-format long -k '<peter at digitalbrains.com>'
pub   rsa1024/ADD8D49B3E4FCA14 2006-03-31 [SC] [revoked: 2009-11-12]
      F8D07102A4F52BD8DC1A7786ADD8D49B3E4FCA14
uid                 [ revoked] Peter Lebbing <peter at digitalbrains.com>

pub   rsa2048/AC46EFE6DE500B3E 2009-11-12 [C] [expires: 2019-10-13]
      8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E
uid                 [  full  ] Peter Lebbing <peter at digitalbrains.com>
sub   rsa2048/969E018FDE6CDCA1 2009-11-12 [S] [expires: 2019-10-13]
sub   rsa2048/26F7563E73A33BEE 2009-11-12 [E] [expires: 2019-10-13]
--8<---------------cut here---------------end--------------->8---

The fingerprint is the really long hexadecimal number below the "pub"
line of the key you're looking for. The long key ID is the number after
"pub rsa2048/", and actually is just the last 16 digits of the fingerprint.

HTH,

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180323/90618a84/attachment.sig>

From wk at gnupg.org  Fri Mar 23 15:43:07 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 23 Mar 2018 15:43:07 +0100
Subject: gpgme_set_passphrase_cb not cooperating...
In-Reply-To: <CAAqEqK2+XgNq=hVRkhve9nX=jNicZzhFXQvK4ug2xzp3QbkSdw@mail.gmail.com>
 (Mike Inman's message of "Thu, 22 Mar 2018 08:58:19 -0400")
References: <CAAqEqK1Zzz=fvfo2ApaEpqjMQHegnSpU7A_HDhCAR7evOu3n4g@mail.gmail.com>
 <87o9jga84k.fsf@wheatstone.g10code.de>
 <CAAqEqK2+XgNq=hVRkhve9nX=jNicZzhFXQvK4ug2xzp3QbkSdw@mail.gmail.com>
Message-ID: <87605m97k4.fsf@wheatstone.g10code.de>

On Thu, 22 Mar 2018 13:58, mangocats at gmail.com said:

> Now, my target environment is CentOS 7, and they resolve /usr/bin/gpg with
> a link to /usr/bin/gpg2 - which does not play nice with
> set_passphrase_cb().  Any suggestions on the best way to untangle that knot?

Assuming this is GnuPG >= 2.1 you use:

    gpgme_set_pinentry_mode (ctx, GPGME_PINENTRY_MODE_LOOPBACK);

and the callbacks will be activated again.  You can always call this
fucntion, gpgme knows when to actually pass the required option to gpg.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180323/9b4dabbc/attachment.sig>

From dirk.gottschalk1980 at googlemail.com  Sat Mar 24 00:31:16 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Sat, 24 Mar 2018 00:31:16 +0100
Subject: Is signing a file with multiple keys possible
Message-ID: <1521847876.3407.6.camel@googlemail.com>

Hello.

Is it possible to sign a file with multiple keys?

For Example: John, Harry and Sally wrote a file, lets assume it is a
text file. Now all of them want to sign this file, so that when
verifying it, all three signatures are visible.

Is this possible?

I tried with --clearsign, but that doesn't work, because the former
signatures are disabled by the latest signing process.

Is there any way to add a signature instead of overriding the former
Signature?

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180324/3e307cc1/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4571 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180324/3e307cc1/attachment-0001.bin>

From dirk.gottschalk1980 at googlemail.com  Sat Mar 24 01:36:45 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Sat, 24 Mar 2018 01:36:45 +0100
Subject: Writing DER certificates to Zeitcontrol Cards
Message-ID: <1521851805.3407.18.camel@googlemail.com>

Hello.

Yes, it's me again with another question.

I'm trying to import certificates in DER format to Zeitcontrol OpenPGP-
Cards (v2.1 and v3.3) and get this error message:

gpg/card> writecert 3 < cert.der
gpg: error writing certificate to card: Kartenfehler

The last word says "card error".

Are these cards not capable of getting certs written on, or am I missing something?

The Admin-Pin is correct, so this could not be the problem.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180324/508f2f33/attachment.sig>

From dirk.gottschalk1980 at googlemail.com  Sat Mar 24 02:04:29 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Sat, 24 Mar 2018 02:04:29 +0100
Subject: Is signing a file with multiple keys possible
In-Reply-To: <20180324004443.GA24855@breadbox.private.spodhuis.org>
References: <1521847876.3407.6.camel@googlemail.com>
 <20180324004443.GA24855@breadbox.private.spodhuis.org>
Message-ID: <1521853469.7151.2.camel@googlemail.com>

Hello Phil.

Am Freitag, den 23.03.2018, 20:44 -0400 schrieb Phil Pennock:
> On 2018-03-24 at 00:31 +0100, Dirk Gottschalk via Gnupg-users wrote:
> > Is it possible to sign a file with multiple keys?
> 
> Yes.  Slightly lower-level operations than normal signing, but not by
> much, you just need to know about enarmor/dearmor and how signatures
> are
> put together.
> ...

Thank you very much. It's like cahining up PEM Certs in OpenSSL. Why
didn'z I even think about this? The Format is so similar.

Thanks,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180324/14589f49/attachment.sig>

From gnupg-users at spodhuis.org  Sat Mar 24 01:44:44 2018
From: gnupg-users at spodhuis.org (Phil Pennock)
Date: Fri, 23 Mar 2018 20:44:44 -0400
Subject: Is signing a file with multiple keys possible
In-Reply-To: <1521847876.3407.6.camel@googlemail.com>
References: <1521847876.3407.6.camel@googlemail.com>
Message-ID: <20180324004443.GA24855@breadbox.private.spodhuis.org>

On 2018-03-24 at 00:31 +0100, Dirk Gottschalk via Gnupg-users wrote:
> Is it possible to sign a file with multiple keys?

Yes.  Slightly lower-level operations than normal signing, but not by
much, you just need to know about enarmor/dearmor and how signatures are
put together.

> For Example: John, Harry and Sally wrote a file, lets assume it is a
> text file. Now all of them want to sign this file, so that when
> verifying it, all three signatures are visible.

------------------------8< multi-sign recipe >8-------------------------
curl -LO https://pt-dummy-app.herokuapp.com/poetry/if.txt

laptop$ gpg --detach --sign if.txt
laptop$ mv if.txt.sig if.txt.sig-laptop
securebox$ gpg --detach --sign if.txt
securebox$ mv if.txt.sig if.txt.sig-securebox

cat if.txt.sig-laptop if.txt.sig-securebox | gpg --enarmor > if.txt.asc

gpg --verify if.txt.asc
------------------------8< multi-sign recipe >8-------------------------

If the individual signatures are ASCII-armored, then use `gpg --dearmor`
to turn them into binary format.  Multiple signatures are just one after
another: there's no container _around_ them, no special merging tools
needed.

In the above example, the securebox is using:
  local-user 0xlong_subkey_1!
  local-user 0xlong_subkey_2!
in ~/.gnupg/gpg.conf to generate two signatures, so that I sign with
both EDDSA and RSA.  Thus the resulting `if.txt.asc' has _three_
signatures.

I've attached the combined signature.  You should be able to grab the
famous poem from the URL above and verify my signatures upon the text.

-Phil
-------------- next part --------------
-----BEGIN PGP ARMORED FILE-----
Comment: Use "gpg --dearmor" for unpacking

iQEzBAABCAAdFiEEq4gt1kA1okdY9paI0jG9pqefzuAFAlq1nX4ACgkQ0jG9pqef
zuAKlgf+P+trdLPknA/sNyNwAIbJoUzpqLxGxxaLT/0ZDrdOlgLsAXqTvYmMljEu
SBQiRLvfv+lGhKKnvZVWolpb4EsNZFFoqdsV65NnhVrFTw6wBQrrWgcHzP1WjGd9
Bw7AWLQzwmJUj3eULGJMce5k8W/aOzvbcJR7d7Kh66Sk+uuKsHznBHu0/3kr5XJ4
4tvyC4DfHyJ5xA2l+EV7mWDpPX7vaAnjs9fwKmXM9DXHP2aAeTW5w/ie3Sa1JW7D
P+hH1eTH2esJWxq9gvhFk8ubdlVjKcdJOpcbvSBvqb4EIx2J4G574/CWTPdDJtl+
dPguQ9NdhuDl3qVyIhwsip3bNKulhoh1BAAWCAAdFiEETlwXnn/8Tb+ObBMvURBO
Zo3QRIEFAlq1nb8ACgkQURBOZo3QRIEKuQEAkQmM+EVWoXYf0t9OyJZuW8A3OfBT
e4709WsddU83xAEA/RnAi9QAB/C5XyURCbcMsjshzHnj1oUjc0eChywebf8PiQIz
BAABCAAdFiEExpOgNOHtbulUyuLaE9rZnH5BUZwFAlq1ndcACgkQE9rZnH5BUZxX
4Q/9GY9PNo8c4E/C6no0LG2KUoYI1edDP2OjMJCj5r09URxR670a3lSjeztauewt
fIwX955lNuqsQUnz0asGh4PugNTN1NLCy99hDKYoY7Aczc3c5XhvJTrwJZiFXQh0
t1e16Qlmvu5FQmHygFCVrtRwZB3ZhEiKVwmzSN0MJkRQNDL0Hz3iPkp4LZF3zDwW
op7jwVJFN85qoavcxh/pYrBsOd7UNIvxePhw0joxne4gA1u0G54YKlIopWUc7ECB
ExYt0LciIfpolKQ1pBWDCchG/SrviLlPOVyTM/803IP8lnUD56QEPKck9QlwHzIP
ooVuPUWKM7vqGFYXO6ttFfurf2eVa/3qmTK5DWmmnDS9bxWjLxsebEBiTqmTqyHM
zVj1kXgPUjP5zgqpwkx4SNZCmvCC74x42VFOQ1c72kLf8i5K+q2shVjTQRkNhG5D
HA2KW0bvK6OE5BD3jbgx/USrb18N7MeVVNSZQ8eLbJ5vp9ee9ERnv7gM3UK+7++H
rAA9zTEyTtMeOdGnAv/cBpbOcpQK0LSh63BWZvTQF9N3bRbQ2qMQnYFMESOGvS5p
2mZPYYkWbjjoEmeqibbsr8TNl8gC0B9fFPuTEwonQsbRQPAYnuawgGesDUPtbOon
hh/i4/Co1NW2kf7JcJ0HtneASL7E/DIvGObFxQyBNaFBm8A=
=mISS
-----END PGP ARMORED FILE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180323/6aa14c14/attachment.sig>

From dkg at fifthhorseman.net  Fri Mar 23 21:46:37 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 23 Mar 2018 20:46:37 +0000
Subject: Using gpg-agent --supervised with systemd
In-Reply-To: <87h8p9yuad.fsf@eklitzke.org>
References: <87h8p9yuad.fsf@eklitzke.org>
Message-ID: <87d0zuo6z6.fsf@fifthhorseman.net>

On Wed 2018-03-21 14:48:26 -0700, Evan Klitzke wrote:
> I am using gpg 2.2.5 and stumbled across the --supervised option while 
> reading the man page. I was able to get the ssh-agent functionality 
> working perfectly, but I'm having problems with the gpg-agent 
> functionality.
>
> I created systemd user units for ssh-agent.socket, gpg-agent.socket, and 
> gpg-agent.service. I was able to get this all set up correctly so the 
> gpg-agent service knows where its sockets are:

it sounds like you might have created the systemd unit files yourself.
If you're running GnuPG from a distribution-supported package, that
package should have shipped them for you already (see for example the
packaging in debian).

even if you're building it yourself, or if your distro doesn't ship
them, i recommend starting from the example unit files in
doc/examples/systemd-user/ in the source tree.  can you compare those
unit files with your own unit files?

> $ sysu status gpg-agent.service

I'm assuming that sysu is some sort of local alias for "systemctl
--user" please let the list know if that's not the case.

> ...
> Mar 21 14:34:12 t460s systemd[1075]: Started GPG agent.
> Mar 21 14:34:12 t460s gpg-agent[2835]: gpg-agent (GnuPG) 2.2.5 starting in supervised mode.
> Mar 21 14:34:12 t460s gpg-agent[2835]: using fd 3 for std socket (/run/user/1000/gpg-agent.sock)
> Mar 21 14:34:12 t460s gpg-agent[2835]: using fd 4 for ssh socket (/run/user/1000/ssh-agent.sock)
> Mar 21 14:34:12 t460s gpg-agent[2835]: listening on: std=3 extra=-1 browser=-1 ssh=4

these are not the standard socket locations, which is probably why gpg
isn't finding them for you.

> What is the trick to making this work correctly?

try using the shipped user service units instead :) If that doesn't work
for you, or if you have any suggestions for improvements, i'm happy to
help review and debug.

Regards,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180323/f1f80a4f/attachment.sig>

From thomas.jarosch at intra2net.com  Sat Mar 24 14:19:25 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Sat, 24 Mar 2018 14:19:25 +0100
Subject: Is signing a file with multiple keys possible
In-Reply-To: <1521853469.7151.2.camel@googlemail.com>
References: <1521847876.3407.6.camel@googlemail.com>
 <20180324004443.GA24855@breadbox.private.spodhuis.org>
 <1521853469.7151.2.camel@googlemail.com>
Message-ID: <17b42943-8a85-0b92-2928-2a82ce9fb4c6@intra2net.com>

Hi Dirk,

On 03/24/2018 02:04 AM, Dirk Gottschalk via Gnupg-users wrote:
>>> Is it possible to sign a file with multiple keys?
>>
>> Yes.  Slightly lower-level operations than normal signing, but not by
>> much, you just need to know about enarmor/dearmor and how signatures
>> are
>> put together.
>> ...
> 
> Thank you very much. It's like chaining up PEM Certs in OpenSSL. Why
> didn't I even think about this? The Format is so similar.

it's even easier when two or more people sign at the same time,
just supply "-u KEYID" multiple times.

At $dayjob our software updates are signed with two smartcards
(four eye principle). Here's the relevant part from the sign script:

gpg_cmd = ['/usr/bin/gpg2', '--personal-digest-preferences', 'sha256']
for gpg_id in gpg_sign_ids:
    gpg_cmd.extend(['-u', gpg_id])
gpg_cmd.extend(['--sign', shlex.quote(target_file)])

Cheers,
Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180324/f29c8460/attachment.sig>

From mac3iii at gmail.com  Sat Mar 24 23:26:25 2018
From: mac3iii at gmail.com (murphy)
Date: Sat, 24 Mar 2018 18:26:25 -0400
Subject: compilation error for libgpg-error-1.28 on armhf
Message-ID: <0e6f0a7c-75b6-20ae-0aea-448b4448ffda@gmail.com>

Hi - does anyone know how to force speedo to compile using
libgpg-error-1.27 for the latest version of GnuPG (2.2.5)?? I came
across a bug in libgpg-error-1.28 while using the speedo method on a
Raspberry Pi 3 running the latest 'Jessie' Raspbian:

/home/pi/Downloads/gnupg-2.2.5/PLAY/src/libgpg-error/src/logging.c: In
function '_gpgrt_log_printhex':
/home/pi/Downloads/gnupg-2.2.5/PLAY/src/libgpg-error/src/logging.c:1153:49:
error: incompatible type for argument 4 of '_gpgrt_logv_printhex'
???? _gpgrt_logv_printhex (buffer, length, NULL, NULL);
???????????????????????????????????????????????? ^~~~
/home/pi/Downloads/gnupg-2.2.5/PLAY/src/libgpg-error/src/logging.c:1097:1:
note: expected 'va_list {aka __va_list}' but argument is of type 'void *'
?_gpgrt_logv_printhex (const void *buffer, size_t length,
?^~~~~~~~~~~~~~~~~~~~

This has been identified previously by dkg and is being worked:

https://www.mail-archive.com/debian-bugs-dist at lists.debian.org/msg1592390.html

As a work-around I found everything compiles nicely if libgpg-error-1.27
is used instead.? But then I cannot use the beloved speedo method!? Is
it possible to easily make speedo use v1.27?

Best Regards - Murphy


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180324/02a2b3c2/attachment-0001.sig>

From wk at gnupg.org  Tue Mar 27 17:34:03 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Mar 2018 17:34:03 +0200
Subject: compilation error for libgpg-error-1.28 on armhf
In-Reply-To: <0e6f0a7c-75b6-20ae-0aea-448b4448ffda@gmail.com> (murphy's
 message of "Sat, 24 Mar 2018 18:26:25 -0400")
References: <0e6f0a7c-75b6-20ae-0aea-448b4448ffda@gmail.com>
Message-ID: <871sg55y8k.fsf@wheatstone.g10code.de>

On Sat, 24 Mar 2018 23:26, mac3iii at gmail.com said:

> it possible to easily make speedo use v1.27?

After the first attempt modify the downloaded swdb.lst file and add
  CUSTOM_SWDB=1
to the make -f ... line.  That should by pass the integrity check and
download the version you entered there.

I try to get a 1.29 out this week.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180327/08a7b736/attachment.sig>

From wk at gnupg.org  Tue Mar 27 17:41:05 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Mar 2018 17:41:05 +0200
Subject: Is signing a file with multiple keys possible
In-Reply-To: <1521847876.3407.6.camel@googlemail.com> (Dirk Gottschalk via
 Gnupg-users's message of "Sat, 24 Mar 2018 00:31:16 +0100")
References: <1521847876.3407.6.camel@googlemail.com>
Message-ID: <87woxx4jce.fsf@wheatstone.g10code.de>

On Sat, 24 Mar 2018 00:31, gnupg-users at gnupg.org said:

> For Example: John, Harry and Sally wrote a file, lets assume it is a
> text file. Now all of them want to sign this file, so that when
> verifying it, all three signatures are visible.

If you use binary detached signatures (-sb) this is pretty easy.  You
can simply concatenate the signature files.  We do this for gnupg
releases.  gnupg/build-auc/append-signature.sh is a script which helps
with this workflow.

If the messages are armored you need to de-armor (gpg --dearmor) them
first, concatenate and en-armor them.  Finnally fix up the armor lines.


Shalom-Salam,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180327/2146aa45/attachment.sig>

From mangocats at gmail.com  Tue Mar 27 21:44:18 2018
From: mangocats at gmail.com (Mike Inman)
Date: Tue, 27 Mar 2018 15:44:18 -0400
Subject: Features vs versions
Message-ID: <CAAqEqK2oW2tCgaWArg_4zc0hmOJ6ST95RUWxLm9pNQJ3BQ3TeQ@mail.gmail.com>

Hi,

I'm working with libgcrypt in a CentOS 7 distribution that includes version
1.5.3... I'd like to use GCRY_CIPHER_MODE_CCM but this
https://markmail.org/message/pavkgenzrd4mmbpu makes me think that it isn't
available in 1.5.3?

Is there an easy table of what features became stable in libgcrypt vs when?

I see the old releases here: https://github.com/gpg/libgcrypt/releases but
it's a little cumbersome to download and search the source, and even then
that's not always a good way to judge stability.

Thanks,

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180327/74cbf908/attachment.html>

From gaugendre at gmail.com  Tue Mar 27 11:04:22 2018
From: gaugendre at gmail.com (Gabriel Augendre)
Date: Tue, 27 Mar 2018 11:04:22 +0200
Subject: git commit signing: Asked for smartcard as it's plugged in
Message-ID: <CAJZSXfU3WCUcief_uZuHk4t8fepkt5En=ZNVknfuuLaj24OXDw@mail.gmail.com>

Hello,

This question has originally been posted to GPGTools support [1], who
redirected me there.

I'm trying to use GPGTools for git commit signing, using a MacBook Air
(macOS 10.13.3) and gpg version 2.2.3.

I used this tutorial [2] (I guess, it was a while ago) to generate a
key pair and add subkeys to my yubikey.

Whenever I need to sign a git commit, I need to plug my Yubikey in and
type the pin code. That works perfectly just after logging into my
session, but if the computer goes to sleep (that's my guess, not sure
about that) and I wake it up and try to sign another commit, GPGTools
pinentry keeps asking to plug the yubikey in even though it's already
there.

As a workaround, I'm forced to go to the terminal, killall gpg-agent
and then retry the operation, then it works. Do you have any idea why
that happens ?

Best regards,
Gabriel

[1] https://gpgtools.tenderapp.com/discussions/problems/69206-asked-for-smartcard-as-its-plugged-in
[2] https://www.yubico.com/support/knowledge-base/categories/articles/use-yubikey-openpgp/


From gniibe at fsij.org  Wed Mar 28 02:00:02 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 28 Mar 2018 09:00:02 +0900
Subject: git commit signing: Asked for smartcard as it's plugged in
In-Reply-To: <CAJZSXfU3WCUcief_uZuHk4t8fepkt5En=ZNVknfuuLaj24OXDw@mail.gmail.com>
References: <CAJZSXfU3WCUcief_uZuHk4t8fepkt5En=ZNVknfuuLaj24OXDw@mail.gmail.com>
Message-ID: <87bmf93w8t.fsf@iwagami.gniibe.org>

Gabriel Augendre <gaugendre at gmail.com> wrote:
> Whenever I need to sign a git commit, I need to plug my Yubikey in and
> type the pin code. That works perfectly just after logging into my
> session, but if the computer goes to sleep (that's my guess, not sure
> about that) and I wake it up and try to sign another commit, GPGTools
> pinentry keeps asking to plug the yubikey in even though it's already
> there.

I think that this is related to the bug report:

    https://dev.gnupg.org/T3825

I found that there are (at least four) different issues; Device firmware
problem, GnuPG scdaemon problem, PC/SC problem for GNU/Linux, and Linux
kernel problem.

Since your case is on macOS, latter two are not relevant.

I think that Yubikey somehow doesn't work well for USB suspend.  For
this problem, please contact the manufacturer.

I fixed a problem of GnuPG scdaemon and implemented work around for
device problem.  It will be in 2.2.6.  With the fix and the work around,
scdaemon tries to reset device after such a failure.  So, you won't need
to manually re-plug your device, but PIN input will be required, since
the device will be reset.

For GNU/Linux, I'd recommend to use internal CCID driver, instead.  It
seems that PC/SC development doesn't have an interest for suspend/resume.

The kernel problem is here:

    https://www.spinics.net/lists/kernel/msg2757378.html

Since it is a kind of corner case which has been there long time, I
could not expect fix will be included soonish (or even getting
attention).  Thus, I changed scdaemon using pipe instead of signal (in
forthcoming 2.2.6).
-- 


From wk at gnupg.org  Wed Mar 28 09:02:47 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Mar 2018 09:02:47 +0200
Subject: Features vs versions
In-Reply-To: <CAAqEqK2oW2tCgaWArg_4zc0hmOJ6ST95RUWxLm9pNQJ3BQ3TeQ@mail.gmail.com>
 (Mike Inman's message of "Tue, 27 Mar 2018 15:44:18 -0400")
References: <CAAqEqK2oW2tCgaWArg_4zc0hmOJ6ST95RUWxLm9pNQJ3BQ3TeQ@mail.gmail.com>
Message-ID: <87d0zo4r8o.fsf@wheatstone.g10code.de>

On Tue, 27 Mar 2018 21:44, mangocats at gmail.com said:

> Is there an easy table of what features became stable in libgcrypt vs when?

In general I would suggest to grep the NEWS file.  However, I justed
figured that we forgot to announce support for new modes in the NEWS
file for 1.6.

Support for CCM was added in Octover 2013 and for GCM in November.  Thus
these modes are available since 1.6.0.

BTW, https://en.wikipedia.org/wiki/Libgcrypt has a maintained table of
supported algorithms in the stable version.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180328/63d6e38e/attachment.sig>

From gaugendre at gmail.com  Fri Mar 30 18:18:46 2018
From: gaugendre at gmail.com (Gabriel Augendre)
Date: Fri, 30 Mar 2018 18:18:46 +0200
Subject: git commit signing: Asked for smartcard as it's plugged in
In-Reply-To: <87bmf93w8t.fsf@iwagami.gniibe.org>
References: <CAJZSXfU3WCUcief_uZuHk4t8fepkt5En=ZNVknfuuLaj24OXDw@mail.gmail.com>
 <87bmf93w8t.fsf@iwagami.gniibe.org>
Message-ID: <CAJZSXfU6DivU8NH3dyB0j=3Hys8Og8Q9ukTkqf9uyO73y2vNtQ@mail.gmail.com>

Thanks for your detailed answer !
I'll wait for 2.2.6 to be released and I'll keep you posted.

Best regards,

Gabriel


From chrisbcoutinho at gmail.com  Sat Mar 31 02:54:27 2018
From: chrisbcoutinho at gmail.com (Chris Coutinho)
Date: Sat, 31 Mar 2018 02:54:27 +0200
Subject: Importing existing key as subkey
Message-ID: <20180331005427.hpthmdxmxsxixq3u@tumbleweed>


Hello,

I'm trying to consolidate my various master keys into a single master 
with subkeys. On my 'old' computer with gpg2.0 (openSUSE 42.3) I was 
able to export the secret key and split it up with `gpgsplit`.  On my 
new machine (openSUSE Tumbleweed), the `gpgsplit` command is 
unavailable, and I'm curious if that functionality has been removed or 
named to something else between the two versions.

Longer version:

I have an existing key generated using gpg2.0 that I would like to 
import as a subkey to my main master key, which is on a computer with 
gpg2.2. For the most part I'm following this SO answer:

	https://security.stackexchange.com/a/62480/172661

I've been able to split up the 'old' key (step 1) into its constituent 
packets using `gpg --export-secret-keys XXXXXXX | gpgsplit -vp XXXXXXX_` 
and transport them to my main computer. From there I created some dummy 
slots in my master. I'm stuck at step four where I need to split up my 
master key into its packets because gpgsplit is missing, and apparently 
not to be found in a gpg-related tool in the main repositories.

I realize this answer might be out-of-date (2014), but I haven't found 
anything thus far as thorough about consolidating. If someone can point 
me to another resource on this topic, I would certainly appreciate it.

Best Regards,

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180331/53801d01/attachment-0001.sig>

From dirk.gottschalk1980 at googlemail.com  Sat Mar 31 17:12:50 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Sat, 31 Mar 2018 17:12:50 +0200
Subject: Again: Writing DER certificates to ZeitControl Cards
Message-ID: <1522509170.6124.4.camel@googlemail.com>

Hello.

I asked this Question a while ago, but unfortunately didn't get any
response. So, I ask again and I'm in hope that somebody here knows any
Answer to this. I just want to know if the cards do not support it, or
is somebething wrong with my setup?

I'm trying to import certificates in DER format to Zeitcontrol OpenPGP-
Cards (v2.1 and v3.3) and get this error message:

gpg/card> writecert 3 < cert.der
gpg: error writing certificate to card: Kartenfehler

The last word says "card error".

Are these cards not capable of getting certs written on, or am I
missing something?

The Admin-Pin is correct, so this could not be the problem.

By the way, I'm using a ReinerSCT CyberJack RFID standard via PCSCd.
Anything works well, except of writing x509 certificates in DER format
to the card.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180331/4bb0c9b2/attachment.sig>