this also affects version 2.1.15 (latest gpg4win beta) and 1.1.1 (latest gpg4win
stable)

Okay, if this transfers line endings because of the textmode read, it will
depend on the contents of the CRL in question. This explains why the defect was
not seen in earlier testing.

And pem does not work for this (I guess and tried on a GNU system).
It is okay that pem does not work, because this is a rarely used function I think.

D381: 870_0001-dirmngr-Open-CRL-s-in-binary-mode.patch

Woops didn't want to submit the last message as I had already looked into it myself.

This was reproducible using libksba's t-crl-parse with our root ca's clr but not
with an example file lying next to it.

Turned out that t-crl-parse opened the file in text mode. Conversion errors then
caused an invalid (too large read). When switching to binary mode it worked as
expected.

Dirmngr used the same. I've tested that crl parsing worked with the attached patch.

Now I get:
dirmngr[780]: error fetching certificate by subject: Configuration error
dirmngr[780]: crl_parse_insert failed: Missing certificate

But I think that is a different error as I get the same one when trying to
import the CRL on an empty homedir and parsing works now.

2.1.11 is not in the latest beta. Should be 2.1.13.

For testing / reporting it is also better to download the latest version from
gnupg.org
https://gnupg.org/download/index.html

Right. Putting armor into gpg.conf is a very bad idea. Don't assume that. If
users want to shoot into their own foot, let them do so.

I have seen that but pretty pelase describe it here so that we can also work
with email.

Detail info in https://trac.macports.org/ticket/51708
OS: PPC Tiger, Mac OS X 10.4.11
The build process is automated by macport.

I see. So, how can I reliably know whether the output of my program is going to
be ascii or binary (to append either .asc or .gpg)? I should just assume that
'armor' will not be in gpg.conf?

Can you please test with 2.1.15?

If a user forces all output of gpg to be armored, it is not gpgme's task to
revert this.

Putting armor into gpg.conf is as bad an idea as putting encrypt into gpg.conf.

gpgme_get_armor() returns gpgme's current state.

Please describe exactly how you build Libassuan. Compiler, OS etc, error message.

You are right. Fixed with commit 68fba3d.

--use-agent is a dummy option in GnUPG 2.1 - it has no effect.

1.4 has been released - waiting for 2.0

I used your workaround and haven't been running into problems since. Unfortunately, I
don't currently have the time at hand to give it a thorough test run. If I do, I will
keep you updated.

gpg2 --use-agent --decrypt encrypted.asc
...
gpg: decryption failed: No secret key
FAIL

--use-agent --decrypt encrypted.asc
..
You need a passphrase to unlock the secret key for
...SUCCESS

This for example makes enigmail fail, and to make things worse: enigmail refuses
to work with gpg1

Using:
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
on Ubuntu 16.04.1 LTS

I have multiple keys in .gnupg, this might be triggering the problem.

Indeed; this look like a corrupted file. Please restrore from abckup.

ping

Could you verify that the problem has been solved (in 2.1.14)?

Already fixed in the repo. It is only a warning and harmless in this case.
Thanks.

Thanks for testing.

Fixed for the next version with 037a5a7ed

I've made new container and can't repeat the bug. gpgme
components got updated in Fedora.

Interesting...

The Kaspersky issue is about Outlook 2007... Is that supposed bug really already
THAT old?!

This could be a nasty one. The crash occurs after the data structure of the mail
was unloaded in outlook and GpgOL already completely detached it's event
handlers from the object and frees up the memory. GpgOL is not executing any
code when the crash occurs. That outlook blames GpgOL is likely because it jumps
into an invalid memory region that was allocated for GpgOL but is no longer
valid. This shouldn't happen though as we have already successfully unregistered
all our callbacks.

So I currently think that somehow when using send from explorer outlook through
some side effect / bug does a callback into GpgOL's event handling code which
was already destroyed. I'll try to confirm that theory on monday by keeping the
event handlers around after the unload event occurred.

Also does not appear that we are the first ones with that problem:
https://forum.kaspersky.com/index.php?showtopic=225375

:-/

Added support for the newly added size-hint to gpgmepp and kleopatra. Works
nicely, although progress could update a bit more often for my taste but its soo
much better then the old "no progress at all" that I don't want to complain ;-)

Thanks!

Thanks! :-)

Thanks for the report. I am able to reproduce the problem.

Looking into it.

Can you please test if the following patch that has been committed recently

fixes your problem?

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commitdiff;h=2227f67af53f38d3d7f97760f2553d2c9ed05969

Cloning the git repository (commit id 2227f67af53f38d3d7f97760f2553d2c9ed05969)
followed by

autogen.sh
./configure --enable-maintainer-mode
make

works, i.e. the warning/error is not present any more.
So this patch seems to fix the issue.

The command line for gcc backs this observation (note the includes):

gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/ncursesw -I../pinentry -Wall -g
-O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k
-Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaratio
n-after-statement -Wno-pointer-sign -Wpointer-arith -MT pinentry-curses.o -MD
-MP -MF .deps/pinentry-curses.Tpo -c -o pinentry-curses.o pinentry-curses.c

I do not agree, but let me see what we can. A new --input-size-hint might be an
option.

Fixed in 72fa314b.

--set-filesize is used for an entirely different purpose - That it is also used
in progress is only related tothat other purpose (pre-generated OpenPGP packets
as input)

But is there any problem using it this way? I didn't see one.

If you know the file size in advance, you can pass the entire file to gpgme and
there is no need to use a pipeline.

GpgME++ provides an interface for a DataProvider class. While this is of course
inherited from Marc I find this kinda nice to use in code. If you implement the
DataProvider interface you can use that as input for GpgME.
QGpgME then provides a DataProvider for QIODevice based classes. E.g. A QFile, a
QBuffer etc. that way you can easily pass a QFile or QByteArray or a QString to
GpgME and get it encrypted. Very convenient API.

If you want a pipeline/stremaing, gpg won't
assume anything about the input file size. telling it that size is an ugly hack.

But e.g. I have a 1GB Mail I wish to decrypt, that is stored in some internal
format I know the size, but you are sugessting that I should cut out the
encrypted / signed part, save it to files and then pass the files to gpgme?

Mean while I added a Units arg to the PROGRESS status line, so that we can do
further tweaking in gpgme and won't need to mess with gnupg. Maybe we can
eventually find a solution which affects only gpgme.

Yes I've seen that and I think it might be useful but it does not solve the
problem that gnupg is not statusing the total for callback / piped operations.

If you really want a percent indication, why not using a file watcher in Kleo
and stat(2) the file.

Yes, that is what I meant by:

msg8719:

I could work around the problem in
Kleopatra by just assuming for files > 1MiB the progress is always scaled and
live with a slight jump after MiB.
And then calculate progress based on the Input size (as total) Kleopatra knows.

But that would be a workaround for "GpgME does not let me do what I want to do"
Maybe we need an "gpgme_add_engine_cmd_line_args" hack interface in GpgME to
give callers the flexibility to do add arbitrary arguments to gpgme engine
calls. This could probably reduce the "GpgME is a hindrance" perception.

Maybe we should phone about this.

Actually, I'd argue that tdbio_set_dbname did not handle this case correctly. In
any case, if you must create some temporary gnupghomes, deleting the whole
directory might be both easier and more robust.

Fixed in a27410a2.

Done in master.

version.texi is such an annoyance. I'll take care of it and will replace it
with a different annoying thing.

--set-filesize is used for an entirely different purpose - That it is also used
in progress is only related tothat other purpose (pre-generated OpenPGP packets
as input)

If you know the file size in advance, you can pass the entire file to gpgme and
there is no need to use a pipeline. If you want a pipeline/stremaing, gpg won't
assume anything about the input file size. telling it that size is an ugly hack.

Mean while I added a Units arg to the PROGRESS status line, so that we can do
further tweaking in gpgme and won't need to mess with gnupg. Maybe we can
eventually find a solution which affects only gpgme.

If you really want a percent indication, why not using a file watcher in Kleo
and stat(2) the file.