Re: gpgme_op_verify regression with gnupg 2.2.6?

[Kristian Fiskerstrand]

On 04/16/2018 02:14 PM, Werner Koch wrote:
>> Could gnupg 2.2.7 detect if gpgme is installed at all and if it is,
>> make sure it's at least version 1.10.1 / 1.11.0?
> :-) - No.

Speaking for Gentoo we can do this on distribution level by adding a
blocker on the lower version if needed.

-- 

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

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

"History doesn't repeat itself, but it does rhyme."
(Mark Twain)



signature.asc
Description: OpenPGP digital 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?

[Werner Koch]

On Mon, 16 Apr 2018 11:44, thomas.jaro...@intra2net.com said:

> I'm wondering how to prevent other people from running into this issue.

I wondered whether I should send out a notice to the announce list but I
doubt that those with problems will read it.  I will add a pointer to
the NEWS entry at gnupg.org with the patch because I assume that will
fast show up in searches.

Given that 1.11.0 is close to a release we decided this morning not to
release a 1.10.1.  GnuPG 2.2.6 is  new enough so that it will be used
only be folks who would also built GPGME from source and thus either the
patch or the forthcoming 1.11.0 should be okay.

> Could gnupg 2.2.7 detect if gpgme is installed at all and if it is,
> make sure it's at least version 1.10.1 / 1.11.0?

:-) - No.


Shalom-Salam,

   Werner

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


pgphImc4wzd3S.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]

Hello Werner,

On Friday, 13 April 2018 12:16:22 CEST Werner Koch wrote:
> On Thu, 12 Apr 2018 15:26, w...@gnupg.org said:
> > Please stay tuned for a GPGME fix.  I hope that you can test it too.
> 
> I pushed a fix as weel as a new test to the master branch.  I may also
> release a 1.10.1 to fix this.  The attached pacth should apply to 1.10.0
> and maybe also to 1.9.

all tests pass fine with the additional fix for gpgme. Thanks!

I'm wondering how to prevent other people from running into this issue.

Could gnupg 2.2.7 detect if gpgme is installed at all and if it is,
make sure it's at least version 1.10.1 / 1.11.0?

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 15:26, w...@gnupg.org said:

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

I pushed a fix as weel as a new test to the master branch.  I may also
release a 1.10.1 to fix this.  The attached pacth should apply to 1.10.0
and maybe also to 1.9.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
From 9aa33a99701e189d7fc0ff7322fc9e21e35b73fa Mon Sep 17 00:00:00 2001
From: Werner Koch 
Date: Thu, 12 Apr 2018 20:36:30 +0200
Subject: [PATCH] core: Tweak STATUS_FAILURE handling.

* src/op-support.c (_gpgme_parse_failure): Ignore failures with
location "gpg-exit".
--

Signed-off-by: Werner Koch 
---
 src/op-support.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/op-support.c b/src/op-support.c
index 817c569..8269ce2 100644
--- a/src/op-support.c
+++ b/src/op-support.c
@@ -398,7 +398,13 @@ _gpgme_parse_plaintext (char *args, char **filenamep)
 
 
 /* Parse a FAILURE status line and return the error code.  ARGS is
-   modified to contain the location part.  */
+ * modified to contain the location part.  Note that for now we ignore
+ * failure codes with a location of gpg-exit; they are too trouble
+ * some.  Instead we should eventually record that error in the
+ * context and provide a function to return a fuller error
+ * description; this could then also show the location of the error
+ * (e.g. "option- parser") to make it easier for the user to detect
+ * the actual error. */
 gpgme_error_t
 _gpgme_parse_failure (char *args)
 {
@@ -416,6 +422,8 @@ _gpgme_parse_failure (char *args)
 *where = '\0';
 
   where = args;
+  if (!strcmp (where, "gpg-exit"))
+return 0;
 
   return atoi (which);
 }
-- 
2.8.1



pgpeKYvu_tuKD.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?

[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: 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?

[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: 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?

[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: 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