Re: GPG is not working because of gpg.conf

2018-03-05 Thread MFPA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 5 March 2018 at 6:30:16 PM, in
, 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  

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

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWp21NV8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+jUMAQDR/irt5ixECYg64F+f4qwgZ11hqsIqforEmBcmSIUkhgD/QarLecFOL2Yg
0O1X2zuOHqKStjOTalJXGPisivbsoAGJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWp21NV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
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-


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


Re: GPG is not working because of gpg.conf

2018-03-05 Thread Ben McGinnes
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


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


Re: [gpgme] generate a wheel of the python bindings

2018-03-05 Thread Matt
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

agent losing connection to socket

2018-03-05 Thread Philipp Gesang
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



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


Re: enigmail with pgp 2.2.4

2018-03-05 Thread Dmitry Gudkov
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:
> 
> 
> 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.
> 



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


Re: GPG is not working because of gpg.conf

2018-03-05 Thread Werner Koch
On Mon,  5 Mar 2018 10:41, ba...@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.


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


Re: GPG is not working because of gpg.conf

2018-03-05 Thread Peter Lebbing
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 



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


Re: [FEATURE REQ] Keygrips in --card-status

2018-03-05 Thread Peter Lebbing
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 



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


Re: enigmail with pgp 2.2.4

2018-03-05 Thread Peter Lebbing
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:


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 



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


using the SSH secret key fails sometimes

2018-03-05 Thread Matthias Apitz

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 
D2760001240102010005532B
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 
D2760001240102010005532B
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=D2760001240102010005532B
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S SERIALNO 
D2760001240102010005532B
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 
D2760001240102010005532B
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 
0005532B
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=D2760001240102010005532B
2018-03-05 10:53:40 scdaemon[1036.802017e00] DBG: chan_13 -> S SERIALNO 
D2760001240102010005532B
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 
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, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/   
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

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


Re: GPG is not working because of gpg.conf

2018-03-05 Thread Basix
On Sun, 04 Mar 2018 19:59 +0100, Werner Koch  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

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