Ah, I understand. I currently have two keyrings (the default keyrings and
debian-keyring.gpg) in my user account. So I will export the keys from
debian-keyring.gpg and import them into my regular keyring.

But this is a different topic from the one described here:
This issue is about allowing gpgme to use exactly one different keyring (not an
additional keyring) that is different from the default keyring or other keyrings
configured in the user's gpg.conf.

So it is just about allowing in gpgme what is already possible via the command
line. Or maybe you would prefer to allow passing command line options to gpg via
gpgme to avoid the wrapper script mentioned below?

I have explained this several times over the last decade. The primary reason is
that it is not possible to keep a consistent vewi on the localally availabale
keys when a user is allowed to remove and add storage at will without gpg having
any control over it. You may end up with duplicated keys and gpg will only
update one of them. The next time the keyrings are "mounted" in a different
order and key is used for update. This leads to all kinds of problems. This is
not a distributed database with a 3 -phase commit system.

I have proposed a solution gor 2.3 based a on central key managing daemon, which
then has the chance to track changes. Interesting fact is that aheinecke has
strongly opposed that idea.

Besides the WKD scenario Andre describes, there are already many existing uses
of a separate keyring where having other keyrings configured via
~/.gnupg/gpg.conf already conflicts with the intended use, except when using
--no-options:

1. /etc/apt/trusted.gpg
2. /usr/share/keyrings/debian-keyring.gpg
3. our company's keyring with acceptable keys for encryption of certain

sensitive information

Basically everywhere where multiple users use a single keyring, often with
"--trust-model always", where you do not want additionally configured keyrings
to disturb the result and give a false sense of security.

Please explain why this a Bad Thing[tm] and what the correct workflow would be.

The keyring is a property of GnuPG and you should not mess around with it. Use
--export and --import to add keys. Extending the bad behaviour of using
multiple keyrings would be Bad Thing.

Fixed with commit df08a0c. Thanks.

This is resolved. we have WITH_TOFU_INFO now.

This is fixed in 3703a4723899d7563937b4b99f5bbe4dd8d3dfed. We will release a
minor update really soon now.

Fixed in 1e6073ff.

Fixed in 1.7 with gpgme_op_keysign.

I pushed Ueno's patches for gpgme. In particular
dee56820cabde60c43c9bf8281b8d411cb2ad644

I agree that this is a practical problem.

I think it would be the right thing.

I'm developing Schleuder, the OpenPGP-featuring mailing list manager.
If I'm receiving an empty list of public keys from GPGME I currently don't know
if there are no keys, or if the keyring couldn't be read. Thus I can't properly
decide what to do: try to fetch keys? I would run into the same problem when
trying to import them. Return an error message? Which one?

This has led repeatedly to confusion e.g. when people imported a key into a
schleuder-list's keyring in the shell as root, which results in changed
ownership of the keyring-files by gpg. Next Schleuder couldn't read the keyring
anymore and maybe refused operation because it couldn't verify any incoming
email any more — instead of giving a helpful error message that points to the
cause: lacking filesystem permissions.

Currently my only chance is to manually check the permissions of all files that
might be involved in an operation. That is working around a bug, in my eyes.

You mean you want something like EACCES instead of an empty listing? I am not
sure whether this is the right thing to do. Can please you describe your use case?

Oops; forgot to add the fix to 1.7.0

Do you have an idea when you would try to fix this? Within the next weeks or
rather months?

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

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.

Thanks for testing.

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

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!

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

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

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.

PNGs are noe rejected.

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.

Fixed with commit b5e16b0

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).

I changed this ussie to a feature request.

Debian's codesearch shows that gpgme_op_assuan_transact is only used by gpa and
a configure test in kdelibpim for its own copy of gpgme. In gpa it is harmless
to enable this. The only effect is that a status line callback will see a
status keyword "#" and status callbacks should always ignore unknown status lines.

Let's enable it by default.

This was already mentioned in T2360 so let's not clutter the tracker.
Resolved as duplicate.

Duplicate of T2360

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.

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?

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?

While the detection works now to distinguish between PGP and S/MIME data it
might be more robust if it would do some more sanity checking on the packet.

E.g. PNG Graphics are detected as PGP Signatures because they start with 0x89

But this is not super neccessary as for the use case of file extension support
valid data will be detected correctly.

This is a GnuPG problem:

teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg && gpg2 --verify --with-colons --status-fd=1 /tmp/testmsg && sleep 1 && gpg2 -
-verify --with-colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alfa Test (demo key) <alfa@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key) <alpha@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain the past 1~second.