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?

AIX required a patch for Npth library for fork.
Please test again with npth 1.3 when it will be released.
I tested with 2.1.14, all go well successfully (make check no errors) with
patched version of Npth library.

I confirmed that with patched npth, 2.1.14 with
c49c43d7e4229fd9f1bc55e17fa32fdc334dbef6 builds well and "make check" goes
successfully (on AIX 7.1 with gcc 4.8.1).

Please test again when npth 1.3 will be released.

I confirmed on AIX 7.1 with GCC 4.8.1, libgcrypt 1.7.2 builds well. "make
check" goes success with no errors.
I'm closing this again, because the particular problem of typedef has been fixed.
If you have another issue, please open another report.

This particular problem of assertion error, it was fixed in 1.22. So, I close this.
We also have T2378 for a possible change for Solaris/sparc. Please continue
there.

I believe that it's fixed in 1.22. Closing.

Closing, as I confirmed that -lrt is not needed any more in Solaris Userland
project:
https://hg.java.net/hg/solaris-userland~gate

You can have a configuration file like:

.gnupg/gpg-agent.conf

enable-ssh-support
debug-level guru
debug-all

log-file /run/user/1000/gpg-agent.log

and

.gnupg/scdaemon.conf

debug-level guru
debug-all
debug-ccid-driver

log-file /run/user/1000/scd.log

so that the interactions can be recorded with debug information.

An option like --stdout-as-tty may also be needed,
for completeness, to avoid /dev/tty writes.

Fixed in 2.1.14 with the switch to Scheme-based tests.

import-clean does call the same code, but it behaves differently for the key you
mention. I created a test key that does get cleaned up upon import.

Merged in 583a464c, thanks!

Note that we prefer contributions sent to the mailinglist using git send-email.

Thanks for the report.

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?

Let's try to figure out which ioctl fails. Could you try to strace this process?

IMHO, it's pretty uncommon from the packaging point of view to deliver
different generic header files for different platforms (one can meet
platform related ifdefs much often). It necessarily moves the platform
decision rules into the source code of the library consumer.