Re: gpgme_op_verify regression with gnupg 2.2.6?

[Werner Koch]

On Thu, 12 Apr 2018 10:17, thomas.jaro...@intra2net.com said:

> -> to me it seems gnupg 2.2.6 exits with failure
> once it encounters an unknown public key.
>
> Is this behavior to be expected or considered a regression?

Good question.  I implemented the

> "gpg: Emit FAILURE status lines in almost all cases.  [#3872]"

to help Enigmail but they are also parsed by gpgme in a way that make
gpgme fail.  So yes, this is clearly a regression.  The question is
whetrhe to fix it: 

 a) In GPGME
 b) In GnuPG
- either send FAILURE status lines only in severe situations
  (e.g. bad option argument)
- or figure out why the NO_PUBKEY also used log_error which causes
  an exit code != 0 and thus the FAILURE status line.

I need to think about - I considere this a severe problem.
 

Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: packet syntax

[Werner Koch]

On Thu, 12 Apr 2018 05:29, ed...@pettijohn-web.com said:

> did a hexdump of the file and the first word is `99' which in binary
> would be `10011001'. I was expecting to encounter `11000110'.  I'm

OpenPGP (RFC-4880) has several ways to encode a packet header.  This
first byte is called the CTB and reads:

  0x10011001 
 !##-  0x01  = 2 length bytes follow.
 !!--- 0x06  = Public key
 ! Clear = Old style CTB
  0x11000110  
 !^^
 !!--- 0x06 = Public Key
 ! Set  = New style CTB

For a new style CTB the length bytes are Hufmann like encoded.  Bit 7 is
always set.  A basic parser can be found in gpgme/src/data-identify.c


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: packet syntax

[FuzzyDrawrings via Gnupg-users]

Edgar Pettijohn wrote:

> the first word is `99' which in binary would be 
> `10011001'. I was expecting to encounter `11000110'.

You were expecting the packet header to be written in the "new" format, but it 
is actually written in the "old" format (indicated by it beginning with "10" vs 
"11"). See RFC-4880 section 4.2.

Public key packets have a Tag ID of 6, and the "new" format isn't required 
unless the packet has a Tag ID greater than 15. 

-fuzzy

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

Re: gpgme_op_verify regression with gnupg 2.2.6?

[Thomas Jarosch]

On Wednesday, 11 April 2018 10:03:42 CEST Thomas Jarosch wrote:
> Error output from gpgme_op_verify():
> 
> gpgme_op_verify error: General error

thanks to Werner's hint with GPGME_DEBUG in another gpgme related thread,
I was able to generate a short log file for gnupg 2.2.5 and gnupg 2.2.6.

Here's the relevant part:

*** gnupg 2.2.5 ***
_gpgme_io_read: enter: fd=0x5, buffer=0x9fab6b8, count=1024
_gpgme_io_read: check: 5b474e5550473a5d 2056455249464943 [GNUPG:] VERIFIC
_gpgme_io_read: check: 4154494f4e5f434f 4d504c49414e4345 ATION_COMPLIANCE
_gpgme_io_read: check: 5f4d4f4445203233 0a5b474e5550473a _MODE 23.[GNUPG:
_gpgme_io_read: check: 5d204e4557534947 0a5b474e5550473a ] NEWSIG.[GNUPG:
_gpgme_io_read: check: 5d20455252534947 203531324545 ] ERRSIG 512EEDD
_gpgme_io_read: check: 3535393830434335 4220312038203030 55980CC5B 1 8 00
_gpgme_io_read: check: 2031343838393836 35313020390a5b47  1488986510 9.[G
_gpgme_io_read: check: 4e5550473a5d204e 4f5f5055424b4559 NUPG:] NO_PUBKEY
_gpgme_io_read: check: 203531324545 3535393830434335  512EEDD55980CC5
_gpgme_io_read: check: 420a  B.
_gpgme_io_read: leave: result=146
_gpgme_io_select: enter: fds=0x9fac1a8, nfds=10, nonblock=0
_gpgme_io_select: check: fds=0x09fac1a8, select on [ r0x5 ]
_gpgme_io_select: check: fds=0x09fac1a8, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x9fac190, need to check
_gpgme_io_select: enter: fds=0xbfca2504, nfds=1, nonblock=1
_gpgme_io_select: check: fds=0xbfca2504, select on [ r0x5 ]
_gpgme_io_select: check: fds=0xbfca2504, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x9fac190, handler (0x9faa8e8, 5)
_gpgme_io_read: enter: fd=0x5, buffer=0x9fab6b8, count=1024
_gpgme_io_read: leave: result=0
_gpgme_io_close: enter: fd=0x5
_gpgme_io_close: check: fd=0x5, invoking close handler 0xb76790a0/0x9faa8e8
  _gpgme_remove_io_cb: call: data=0x9fac180, setting fd 0x5 (item=0x9fac190) 
done
_gpgme_io_close: leave: result=0
gpgme:gpg_io_event: call: gpg=0x9faa8e8, event 0xb7665150, type 1, type_data 
0xbfca2574
GPGME 2018-04-12 10:03:58 <0x02d6>  gpgme_op_verify: leave
GPGME 2018-04-12 10:03:58 <0x02d6>  gpgme_op_verify_result: enter: ctx=0x9faaf60
GPGME 2018-04-12 10:03:58 <0x02d6>  gpgme_op_verify_result: check: 
ctx=0x9faaf60, sig[0] = fpr A93971254B380E6EE4CDF80F32064F2D0D3C2EB1, summary 
0x3, status Success


*** gnupg 2.2.6 ***
_gpgme_io_read: enter: fd=0x5, buffer=0x8ebe6b8, count=1024
_gpgme_io_read: check: 5b474e5550473a5d 2054525553545f55 [GNUPG:] TRUST_U
_gpgme_io_read: check: 4c54494d41544520 30207067700a5b47 LTIMATE 0 pgp.[G
_gpgme_io_read: check: 4e5550473a5d2056 4552494649434154 NUPG:] VERIFICAT
_gpgme_io_read: check: 494f4e5f434f4d50 4c49414e43455f4d ION_COMPLIANCE_M
_gpgme_io_read: check: 4f44452032330a5b 474e5550473a5d20 ODE 23.[GNUPG:] 
_gpgme_io_read: check: 4e45575349470a5b 474e5550473a5d20 NEWSIG.[GNUPG:] 
_gpgme_io_read: check: 4552525349472035 313245453535 ERRSIG 512EEDD55
_gpgme_io_read: check: 3938304343354220 3120382030302031 980CC5B 1 8 00 1
_gpgme_io_read: check: 3438383938363531 3020390a5b474e55 488986510 9.[GNU
_gpgme_io_read: check: 50473a5d204e4f5f 5055424b45592035 PG:] NO_PUBKEY 5
_gpgme_io_read: check: 313245453535 393830434335420a 12EEDD55980CC5B.
_gpgme_io_read: check: 5b474e5550473a5d 204641494c555245 [GNUPG:] FAILURE
_gpgme_io_read: check: 206770672d657869 742035353434  gpg-exit 335544
_gpgme_io_read: check: 0a33.
_gpgme_io_read: leave: result=211
_gpgme_io_select: enter: fds=0x8ebf1a8, nfds=10, nonblock=0
_gpgme_io_select: check: fds=0x08ebf1a8, select on [ r0x5 ]
_gpgme_io_select: check: fds=0x08ebf1a8, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x8ebf190, need to check
_gpgme_io_select: enter: fds=0xbfd548b4, nfds=1, nonblock=1
_gpgme_io_select: check: fds=0xbfd548b4, select on [ r0x5 ]
_gpgme_io_select: check: fds=0xbfd548b4, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x8ebf190, handler (0x8ebd8e8, 5)
_gpgme_io_read: enter: fd=0x5, buffer=0x8ebe6b8, count=1024
_gpgme_io_read: leave: result=0
_gpgme_cancel_with_err: enter: ctx=0x8ebdf60, ctx_err=33554433, op_err=0
  _gpgme_io_close: enter: fd=0x5
  _gpgme_io_close: check: fd=0x5, invoking close handler 0xb76e80a0/0x8ebd8e8
_gpgme_remove_io_cb: call: data=0x8ebf180, setting fd 0x5 (item=0x8ebf190) 
done
  _gpgme_io_close: leave: result=0
  gpgme:gpg_io_event: call: gpg=0x8ebd8e8, event 0xb76d4150, type 1, type_data 
0xbfd548c8
_gpgme_cancel_with_err: leave
gpgme_op_verify:1176: error: General error 


-> to me it seems gnupg 2.2.6 exits with failure
once it encounters an unknown public key.

Is this behavior to be expected or considered a regression?


>From the 2.2.6 changelog it sounds like this change:

"gpg: Emit FAILURE status lines in almost all cases.  [#3872]"


Versions used for the test:

gnupg-2.2.6
gpgme-1.8.0 (also 

Re: dirmngr timeout

[Laszlo Papp]

On Wed, Apr 11, 2018 at 8:09 PM, Werner Koch  wrote:

> On Tue, 10 Apr 2018 17:19, lp...@kde.org said:
>
> > Proxy request sent, awaiting response... 200 OK
> > Length: 58162 (57K) [application/pgp-keys]
>
> Okay that works.  Now we need to see why dirmngr has a different idea.
> When we first talked on IRC, someone else reported that he had no
> problems with that configuration - but it might not be fully the same.
> Thus I need to try replicating the problem myself - will take some time,
> though.
>
> Do you have the envvar http_proxy set?  If so you also need to have
>
> honor-http-proxy
>
> in your dirmngr.conf.
>

That is an interesting idea as one would think that the environment
variables would be respected by default rather than opting in.

honor-http-proxy did not work, but --http-proxy host[:port] did. Thank you
for pointing me to this direction.

This makes me think that dirmngr does not understand the environment
variable by default, given that it does not work "by default" and when I
try to reinforce this with honor-http-proxy. Is this information lost when
gpg launches dirmngr? If so, should it not be retained?

Is there a command line option for gpg, like for sudo (-E) and similar
software applications, to pass on all the environment variables properly if
this is the issue?

gpg is also used in my docker build process, so the best would be to
respect the environment variable by default. Are there any objections to
that? If so, what exactly?



> Salam-Shalom,
>
>Werner
>
> --
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpgme_op_verify regression with gnupg 2.2.6?

[Werner Koch]

Hi,

I think I will fix it in GnuPG.  Attached is an already pushed fix.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
From e2bd152a928d79ddfb95fd2f7911c80a1a8d5a21 Mon Sep 17 00:00:00 2001
From: Werner Koch 
Date: Thu, 12 Apr 2018 11:49:36 +0200
Subject: [PATCH GnuPG] gpg: Relax printing of STATUS_FAILURE.

* g10/gpg.c (g10_exit): Print STATUS_FAILURE only based on passed
return code and not on the presence of any call to log_error.
--

This fixes an actual regression in GPGME where FAILURE is considered
for example by a signature verify operation.  The operation will simply
fail and not just record that that a signature could not be verified.
In particular for files with more than one signature a log_error if
often called to show that a pubkey is missing for one of the
signatures.  Using that log_error is correct in that case.

Fixes-commit: 0336e5d1a7b9d46e06c838e6a98aecfcc9542882
Signed-off-by: Werner Koch 
---
 g10/gpg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/gpg.c b/g10/gpg.c
index fbbdd92..aaeddee 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -5111,7 +5111,7 @@ g10_exit( int rc )
   /* If we had an error but not printed an error message, do it now.
* Note that write_status_failure will never print a second failure
* status line. */
-  if (log_get_errorcount (0))
+  if (rc)
 write_status_failure ("gpg-exit", gpg_error (GPG_ERR_GENERAL));
 
   gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);
-- 
2.8.1



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

Re: gpgme_op_verify regression with gnupg 2.2.6?

[Thomas Jarosch]

Hi Werner,

On Thursday, 12 April 2018 11:53:33 CEST Werner Koch wrote:
> I think I will fix it in GnuPG.  Attached is an already pushed fix.

with that fix applied on top of gnupg 2.2.6 vanilla,
one gpgme 1.10.0 unit test fails:

t-verify.c:239: GnuPG: General error
FAIL: t-verify

Sorry for raining on your parade :)

Cheers,
Thomas




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

Re: packet syntax

[edgar]

On Apr 12, 2018 3:39 AM, Werner Koch  wrote:
>
> On Thu, 12 Apr 2018 05:29, ed...@pettijohn-web.com said:
>
> > did a hexdump of the file and the first word is `99' which in binary
> > would be `10011001'. I was expecting to encounter `11000110'.  I'm
>
> OpenPGP (RFC-4880) has several ways to encode a packet header.  This
> first byte is called the CTB and reads:
>
>   0x10011001 
>  !##-  0x01  = 2 length bytes follow.
>  !!--- 0x06  = Public key
>  ! Clear = Old style CTB
>   0x11000110  
>  !^^
>  !!--- 0x06 = Public Key
>  ! Set  = New style CTB
>
> For a new style CTB the length bytes are Hufmann like encoded.  Bit 7 is
> always set.  A basic parser can be found in gpgme/src/data-identify.c
>

Cool. I'll check that out.

Thanks
>
> Shalom-Salam,
>
>    Werner
>
> -- 
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: packet syntax

[edgar]

On Apr 12, 2018 2:30 AM, FuzzyDrawrings via Gnupg-users  
wrote:
>
> Edgar Pettijohn wrote:
>
> > the first word is `99' which in binary would be 
> > `10011001'. I was expecting to encounter `11000110'.
>
> You were expecting the packet header to be written in the "new" format, but 
> it is actually written in the "old" format (indicated by it beginning with 
> "10" vs "11"). See RFC-4880 section 4.2.

This is what I thought I was seeing, but thought I read somewhere that gpg 
creates version 4 packets.  Thanks.
>
> Public key packets have a Tag ID of 6, and the "new" format isn't required 
> unless the packet has a Tag ID greater than 15. 
>
> -fuzzy
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpgme_op_verify regression with gnupg 2.2.6?

[Thomas Jarosch]

On Thursday, 12 April 2018 12:56:30 CEST Thomas Jarosch wrote:
> Hi Werner,
> 
> On Thursday, 12 April 2018 11:53:33 CEST Werner Koch wrote:
> > I think I will fix it in GnuPG.  Attached is an already pushed fix.
> 
> with that fix applied on top of gnupg 2.2.6 vanilla,
> one gpgme 1.10.0 unit test fails:
> 
> t-verify.c:239: GnuPG: General error
> FAIL: t-verify

forgot to mention: The test doesn't fail when the patch is not applied.

Cheers,
Thomas




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

Re: gpgme_op_verify regression with gnupg 2.2.6?

[Werner Koch]

On Thu, 12 Apr 2018 12:56, thomas.jaro...@intra2net.com said:

> t-verify.c:239: GnuPG: General error
> FAIL: t-verify

That turns out to be more complicated than on first sight.  This error
is from checking that BAD signature - in this case gpg emits a BADSIG
status line and calls exit with failure; in trun a STATUS_FAILURE is
triggred.  

Now that could be fixed GnuPG but at quite some pales.  Not the right
solution.  I need to apply fixes to GPGME as well.  And that should also
be backported to a 1.10.1 (actually I planned to release 1.11.0 this
week).

Please stay tuned for a GPGME fix.  I hope that you can test it too.

> Sorry for raining on your parade :)

Bug fixing introduces delays ;-)


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: dirmngr timeout

[Laszlo Papp]

On Thu, Apr 12, 2018 at 9:30 AM, Laszlo Papp  wrote:

>
>
> On Wed, Apr 11, 2018 at 8:09 PM, Werner Koch  wrote:
>
>> On Tue, 10 Apr 2018 17:19, lp...@kde.org said:
>>
>> > Proxy request sent, awaiting response... 200 OK
>> > Length: 58162 (57K) [application/pgp-keys]
>>
>> Okay that works.  Now we need to see why dirmngr has a different idea.
>> When we first talked on IRC, someone else reported that he had no
>> problems with that configuration - but it might not be fully the same.
>> Thus I need to try replicating the problem myself - will take some time,
>> though.
>>
>> Do you have the envvar http_proxy set?  If so you also need to have
>>
>> honor-http-proxy
>>
>> in your dirmngr.conf.
>>
>
> That is an interesting idea as one would think that the environment
> variables would be respected by default rather than opting in.
>
> honor-http-proxy did not work, but --http-proxy host[:port] did. Thank you
> for pointing me to this direction.
>
> This makes me think that dirmngr does not understand the environment
> variable by default, given that it does not work "by default" and when I
> try to reinforce this with honor-http-proxy. Is this information lost when
> gpg launches dirmngr? If so, should it not be retained?
>
> Is there a command line option for gpg, like for sudo (-E) and similar
> software applications, to pass on all the environment variables properly if
> this is the issue?
>
> gpg is also used in my docker build process, so the best would be to
> respect the environment variable by default. Are there any objections to
> that? If so, what exactly?
>

It looks like if I run dirmngr manually, as follows, with honor-http-proxy,
gpg works:

dirmngr --daemon

But when it is run as dirmngr --supervised, gpg does not seem to work until
the http-proxy is specified in the config explicitly.



>  Salam-Shalom,
>
>>
>>Werner
>>
>> --
>> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
>> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>>
>> ___
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>
>>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Errors while creating an g13 encrypted container.

[Werner Koch]

On Thu, 12 Apr 2018 17:16, gnupg-users@gnupg.org said:

> g13: running '/usr/bin/encfs' in the background

IIRC, the author of encfs said that it should not anymore be used.
Given that, I have not tested encfs based container in a long time.  I
use dm-crypt containers instead.

> g13: running 'encfs-1' failed (exitcode=-1): Allgemeiner Fehler

Did encfs remove dthe patch I once got upstream?  That could be a reason
for this.  For quick debugging, I would suggest to employ strace.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Errors while creating an g13 encrypted container.

[Dirk Gottschalk via Gnupg-users]

Hi.

Am Donnerstag, den 12.04.2018, 21:08 +0200 schrieb Werner Koch:
> On Thu, 12 Apr 2018 17:16, gnupg-users@gnupg.org said:

> > g13: running '/usr/bin/encfs' in the background

> IIRC, the author of encfs said that it should not anymore be used.
> Given that, I have not tested encfs based container in a long
> time.  I
> use dm-crypt containers instead.

Oh, good to know.

So I tested it with dm-crypt and got another error:

---
$ g13 -r 764C2156D8AC31D0 --type dm-crypt --create container.g13 
g13: can't connect to 'g13-syshelp': IPC "connect" Aufruf
fehlgeschlagen G13
g13: (is userv and its gnupg-g13-syshelp script installed?)
g13: error creating a new container: IPC "connect" Aufruf
fehlgeschlagen 
---

GnuPG 2 is installed with all dependencies. Installed versions:

---
# dnf list "gnupg2*"
Installierte Pakete
gnupg2.x86_64  2.2.5-1.fc27  
gnupg2-smime.x86_64 2.2.5-1.fc27
---

There is neither a command or package named userv, nor a script called
'gnupg-g13-syshelp' in the repositories. The binary g13-syshelp is
available.

Has anybody some suggestions? or should I file a bug report against the
RPM package?

Thanks.

Regards,
Dirk



-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350

signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Errors while creating an g13 encrypted container.

[Dirk Gottschalk via Gnupg-users]

Hello,

we are trying to exchange files in encrypted containers. But when I
create such a container, g13 throws the following errors:

$ g13 -r 764C2156D8AC31D0 --create container.g13 
g13: DBG: used keyblob size is 61
g13: running '/usr/bin/encfs' in the background
g13: DBG: starting runner thread
g13: got prompt 'create_root_dir'
g13: DBG: sending command  -->y<--
g13: got prompt 'create_mount_point'
g13: DBG: sending command  -->y<--
g13: got prompt 'config_option'
g13: DBG: sending command  --><--
g13: got prompt 'new_passwd'
g13: got status 'fuse_main_start'
g13: DBG: runner thread noticed cancel flag
g13: DBG: runner thread closed status fp
g13: DBG: runner thread waiting ...
g13: Fehler bei Ausführung von `encfs-1': beendet
g13: running 'encfs-1' failed (exitcode=-1): Allgemeiner Fehler
g13: DBG: runner thread waiting finished
g13: DBG: runner thread releasing runner ...
g13: failed to remove mount with rid 1 from mtab: Nicht gefunden
g13: DBG: runner thread runner released
g13: g13 (GnuPG) 2.2.5 angehalten

Am I doing something wrong in the creation command?

Regards,
Dirk


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350

signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users