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.

All not good.

To be honest I'm a bit pigheaded here. 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.

The Problem for me is that QGpgME will never emit current + total progress
because it always provides Data through callbacks. And GpgME++ also is pretty
much designed for this in the Dataprovider interface. I dislike maintaining half
working / weird behaving code so I looked into possible ways to fix that.

What I did then was to take a look at gnupg's progress code and saw that total
is modified by --set-filesize. So I thought "awesome there is a mechanism to
provide gnupg with the total filesize even if callbacks are used" and did that.
I still think that this is great, and a good solution (no changes to gnupg
required etc.).

You try to do something which does not make sense. would have exact numbers
they do not tell you anything valid. It might be that
large parts of the file are compressed into just a few bytes and thus your
progressbar makes a huge leap at one time and later it gets slow again despite
that these are only a few 100 MiB (compared to the 10 GiB or zeroes).

I'm not trying to have a 100% reliable progress or a second exact estimate of
when a job is finished. But I want to show some general information "Ok the task
is 90% done, just stay tuned a bit longer"

This is User Interface basics. If you have a long running task (and crypo tasks
can easily run into minutes / hours) show _some_ progress indication. Due to the
pecularities / bugs of the API Kleopatra just shows "I'm working". This is very
bad User Interface and I would like to fix that. And Ideally my fix for this
would be where the Problem happens and not a workaround for the problem in the
user interface.

All not good. You try to do something which does not make sense. Even if you
would have exact numbers they do not tell you anything valid. It might be that
large parts of the file are compressed into just a few bytes and thus your
progressbar makes a huge leap at one time and later it gets slow again despite
that these are only a few 100 MiB (compared to the 10 GiB or zeroes).

Always returning KiB would work for me as a compromise I don't know otherwise
that the switch from Bytes to KiB happened because I have no total.

Makes the code for QGpgME / GpgMEpp users more complicated though as they need a
mapping of progress to input file size. With the --set-filesize patch It would
be nicer as I could just handle this generically in GpgMEpp if an input is
seekable It would provide GnuPG with the size information and afterwards we have
progress where current and total could be used for relative progress calculation:

if (dp->isSupported(DataProvider::Seek)) {

off_t size = seek(0, SEEK_END);
seek(0, SEEK_SET);
gpgme_data_set_file_size(d->data, static_cast<unsigned long long>(size));

}

What do you think of changing GnuPG's PROGRESS interface to always return KiB
and cap that value before it overflows? We would also cap in GPGME in case
gpgme is a 32 bit application and gnupg is 64 bit (or Windows).

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

(It is not NCURSES_INCLUDE, but NCURSES_CFLAGS should be set by
PKG_CHECK_MODULES.)

Thanks!

I note that if i restart dirmngr it will just choose a new member of the pool
and that member will work.

What operating system are you using?

I'm using Gentoo.

(referring to the discussion you linked):

pkg-config ncursesw --cflags returns "-I/usr/include/ncursesw", which is the
correct path. However, this include is not listed in the gcc command line (see
initial message).

I'm no expert in make nor autotools, but looking at pinentry/Makefile $COMPILE
uses $INCLUDES and $AM_CPPFLAGS. However $INCLUDES is not defined and
$AM_CPPFLAGS only adds -I../secmem. Also, nothing seems to use the variable
$NCURSES_INCLUDE (which is set to the pkg-config value "-I/usr/include/ncursesw").

This leads me to the wild guess that the pkg-config definitions for ncurses are
ignored by configure (or however sets up the Makefile). Instead the default
include directory /usr/include is used which has the wrong curses.h header. I
would like to submit a patch, but I sadly have no knowledge about make and automake.

I explained this already on the mailing list: gpg takes data from stdin but
sometimes need to ask on the tty for a passphrase or confirmation. If you do
not want this use --batch and --with-colons.

The --edit-key interface cannot be operated via stdin because this is a human
only interface. To automate --edit-key you need to use --status-fd and
--command-fd and apply an FSM for processing. This is required to keep the API
stable and to allow extending the --edit-key interface.

GnuPG 2.1 also has a bunch of new commands (--quick-foo) which can be used to do
the most common operations directly from the command line.

Well, the man page states

  --yes  Assume "yes" on most questions.

Note the "most" ;-)

I agree that there is no clear pattern. I tried to make use of --yes in way to
minimizes surprising loss of data. Can certainly be improved.

Can you please tell us what version of ssh you are using (ssh -V)?

Please describe the bug and your patch here. A long title is not a sufficient
description. tia.

Fixed in 135185b7.

Ok, there are no significant patches on top of pygpgme. Note that pygpgme is not really
maintained, and that we neither develop nor support pygpgme. But seeing that dnf is important to
Fedora, let's figure this out.

It would be nice if you could try to reproduce the problem without pygpgme though, just to make a
more minimal test case. I see the exception is thrown during some import. This is how I strace
gnupg to see what ioctls it is issuing:

% strace -eioctl g10/gpg --import ../tests/openpgp/samplekeys/ecc-sample-1-pub.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 0BA52DF0BAA59D9C: public key "ec_dsa_dh_256 <openpgp@brainhub.org>" imported

• SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=26716, si_uid=1000, si_status=0,

si_utime=0, si_stime=0} ---
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
gpg: Total number processed: 1
gpg: imported: 1
+++ exited with 0 +++

Note that if you try to strace your gpgme-based application, you need to pass '-f' to strace to
follow forks.

I have grepped through gpgme and gnupg, and it looks like gnupg is only doing ioctls to terminals,
so maybe your container setup is doing something funny to terminals. But let's see what the strace
shows.

Fixed in 2f1f1f06.

Grabbing the pointer might have unexpected repercussions though, e.g. one isn't
able to move windows around anymore. Let's see how it turns out.

What operating system are you using?

We had the exact same patch committed (21e83f42) and later reverted (f0db3192).
Discussion: https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/030051.html

Will be a week or so. Had to power off my server due to "flooding" nearby.

This is really weird. Merely not adding the password reveal button to the hbox
'fixes' this problem. Therefore, I don't believe that the patch introduces the
bug, it merely makes it manifest itself.

I looked around in the related gtk bits, but I believe the problem might be in
the X server, or the asynchronous interaction with it. I don't believe it is
worth digging further into X.

Workaround committed in ad390f29.

Indeed, thanks for the analysis!

Fixed in 40365b28.

This is fixed now. Was a problem with an incorrect port from KTemporaryFile to
QTemporaryFile for qt5

Fixed in c971ff08.

D198: 866_gnupg-2.1.14.diff

With T1590 irrelevant, issues 1862, 1970, and 2336 resolved (very special
thanks to everyone who helped in fixing them!), this is the only problem left in
version 2.1.14 that forces me to use a patched version of gpgsm for my webmailer.

My patch from 2014-04-30 works, but by mistake ("if (cmp < 0)" in place of "if
(cmp > 0)" it selects not the newest but the oldest one of the ambiguous
certificates what is bad in the DFN PKI because an older one of the certificates
is revoked, so I attach a new patch against 2.1.14.

Sorry for not providing further infos, I did not find the time before now.
I just tested with version 1.7.2; there the problem has disappeared.

I guess this change mentioned in the change log is the relevant one:
+2016-07-01 Jussi Kivilinna <jussi.kivilinna@iki.fi>
+
+ Fix static build.
+ * tests/pubkey.c (_gcry_pk_util_get_nbits): Make function 'static'.

Thank you very much, the case can be closed.

Ok, I can record such files. Will there be any confidential information contained in
these logs?

Here is the info about Fedora patches
https://www.rpmfind.net/linux/RPM/fedora/secondary/devel/rawhide/src/p/pygpgme-0.3-15.fc24.src.html

On Wed, Jul 27, 2016 at 1:24 PM, Justus Winter via BTS
<gnupg@bugs.g10code.com> wrote:

I see that you are using pygpgme, is that correct?If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?