In practice, calling gpgme_get_key() will often pick up most changes because GPGME asks the underlying GPG agent daemon, which may re-read the keyring. That gives the impression that a long-lived context automatically reflects live updates. However, as aheinecke noted, some updates can still go unnoticed in a single gpgme_ctx_t, so it isn’t a strictly frozen snapshot nor a perfectly live view—behaviors are mixed.

In T7620#201528, @aheinecke wrote:

Maybe we should make the documentation clearer about context key reuse. But the context is specifically designed to cache information about a key, so as to avoid memory overhead. I learned early on that its best for each new operation to use a new context. A context is basically an instance of gpg or gpgsm. So you start one process, ask it for a keylist, keep the process running, start another process, modify the key database, and then ask the first process again about his worldview. Either the first process is a bit confused because it has read data and then that data changed (what happens here) or it has no idea about the change since it was efficient and only read the database once. But here in this example you should be able to reproduce this also by making any other modifications to the key, adding other subkeys, userids etc. That GPGME even notices the secret key is more of a side effect of how the programming works because the GPGME gpg process will ask the gpg-agent (so a third process).

In T7673#201735, @werner wrote:

We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

I updated the version database. We now have entries for "gpg4win", "gpd", and "vsd"

I'm wondering whether gpgme v1 will still be supported? Or it will be abandoned from now on.

I see, I had rfc2440 in mind which says:

By convention, it includes  an RFC 822 mail name, but there are no restrictions on its content.

thus 4880 refined it a bit. But in practice it is not the same because it is utf8 and not punycode or whatever. let's close this bug because they way it is used will work with all mail clients.

Let's have a look at the section of RFC4880 linked by the reporter:

A User ID packet consists of UTF-8 text that is intended to represent
the name and email address of the key holder.  By convention, it
includes an RFC 2822 [RFC2822] mail name-addr, but there are no
restrictions on its content.  [...]

Let's have a look at the spec (rfc2822 3.4):

address         =       mailbox / group

OK, fixed in rG27e6622322b5: scd: Take care of possible buffer overflow in do_auth.

The problem was: In scdaemon, PKSIGN with OPENPGP.3 didn't work well for Ed25519 (done by do_auth function in app-openpgp.c), when --hash=sha512 (not SHA1).

So I’ve played a bit with agent/pkdecrypt.c. I don’t claim to understand everything that is going on there, but:

No other processes that I have seen. However please see this last update by Kulbarsch. https://github.com/cri-o/cri-o/issues/8906#issuecomment-2936351035

We should also add a check that INDATALEN is > 15 to make the function robust against bad args.

I located the bug in scdaemon.

@sj98ta
Does cri-o invokes processes (other than the ones of gpgme) by its threads?

I am not sure that I am clear on what you are asking. I am not an expert on cri-o, but is does seem that there are multiple processes (threads), which all call gpgme_op_verify There are also calls to gpgme_op_import

@sj98ta Please let us know if cri-o invokes other processes (except the ones by gpgme) or not.
If cri-o invokes other processes (by other threads), my theory matters; With the interference by other processes holding pipe file descriptors, gpgme keeps polling pipe file descriptors.