Arghh, a GPGME_DEBUG=3 which shows basic I/O preparation does not exhibit the bug.

Fixing gpg is easy but there is some bug lingering in gpgme which might be a recent regression. An strace shows

gpg --list-packets shows this:

In T6977#183049, @Karam wrote:

Uploaded the corrupted file.

Uploaded the corrupted file.

Can you make this corrupted file available to us?

Hello,
So after testing on gpgme-1.17.1, with run-verify under tests as you mentioned, with corrupted file it hangs forever.
Now we can say it's a bug in gpgme_op_verify.

We provide the examples for a reason. Actually, two reasons: To test our changes ourselves. And to provide working examples for others. If your code doesn't work then you'll have to figure out where the example and your code differ. If the example doesn't work then we'll have a look.

@Karam, please test as suggested by @ikloecker.

@werner I 'm not passing nullptr to gpgme_data_release.
@ikloecker Honestly I didn't test it.
Is there anything wrong with code ? have anyone encountered such behavior ?
I was trying adding a timeout as a workaround for gpgme_op_verify to avoid hanging but it depends on the file size and how much it will take to verify it signature...

Oh well, it does not use the c++ binding .

Yes that probably gets lost along the way, where we communicate with scdaemon to generate the key. Needs to be tracked down. Such things can be very confusing to users. Especially if that increases the PIN Retry counter!

Just a reminder, this is important for 384 bit keys (see T6379).

I think this is resolved now.

The problem has been addressed for all OpenPGP crypto operations on files.

This is currently not possible (blocked by T6927: gpgsm: Accept file names for input and output in server mode).

All non-archive jobs have been extended to allow reading the input directly from files and to allow writing the output. directly to files.

gpg 2.4 now returns ERROR status lines for failed --quick-add-subkey and --quick-add-adsk.

I did not relaize that when we originally implemented that feature we already exposed it through GPGME. So this has been fixed since 2020.

Done. I have verified with the test runner run-verifyopaquejob that verification still works and that the warning is gone.

I would use ALGO of gpgme_createsubkey to pass the fingerprint of the ADSK. This can be justified because the algorithm is an implict property of the fingerprint. Obviously we also nee a new flag to do switch to this behaviour. A new GPGME_CREATE_ADSK comes to mind.

In T6880#180682, @TobiasFella wrote:

In the C++/Qt parts:
I think we then don't really *need* anything, since we can just set the fingerprint in the context for the job, but it would make sense to introduce a function that wraps this into a nice API.

My concept would be to:

• add a GENKEY_EXTRAFLAG_ADDADSK for _gpgme_engine_op_genkey and gpg_genkey (or do that more implicitely, e.g., by detecting !USERID && KEY && PUBKEY) and pass the subkey fingerprint in pubkey
• use gpgme_op_createsubkey; pass the adsk fingerprint in a new variable in context

For the similar task to add an existing subkey to a key we have GpgAddExistingSubkeyEditInteractor. This uses the much more complicated gpg --edit-key interface. Maybe we want to avoid this.

Before adding code please first come up with a description of the planned API extension.

Werner and Tobias are both correct. If a new subkey is generated from scratch then gpg uses the current time as key creation time and sets the expiration date (in the internal in-memory representation of a public key) to the key creation time plus the expiration value.

Sorry, I should have been more precise in my description of the problem. Specifically with --quick-addkey, gpg's behavior seems to be that the expiration, when given using seconds=... is treated as seconds from now.

FWIW, when updating the expiration time gpg does this:

My explanation of gpgme's behavior was not quite correct: Specifically in the QGpgMEQuickJobs for creating (sub)keys, the API uses QDateTimes, which are then converted to seconds since epoch.

That's both not correct. gpg takes the expiration time in seconds since creation time. For a new key this is close to the corrent time but not really. For an prolonging an expiration, this is of course different - the creation time of the key needs to be taken in account. I recall that we once had a discussion and agreed to keep it at time after the creation of the key. This avoids problems with the expiration going negative.

Ack, I was not sure if we fixed it and forgot to add the commit here.

I haven't looked into it and I think this has really low priority. I'm pretty sure it's a problem with a the out-of-correct-order destruction of (static?) objects on shutdown. If I remember correctly then it is triggered by the DeviceInfoWatcher.

Ingo do you know if we have fixed this?

Okay, I known do the same what we do for a single root certificate, that is mark it as "not trusted" ('n').

My very simple patch for this would be:

works, VS-Desktop-3.1.90.287-Beta

This is a generic parent task and does not require workboards for specific branches.

I'd prefer to not use the spawn helper at all. All currrent Windows versions allow to decide which handles are to be inherited and thus there is no more need for the helper.

As discussed in chat has nothing to do with only signing. Only that signing makes it easier to get errors by cancelling pinentry or entering bad passwords.

You are creating a signed archiv? Why - gpgtar is used for encryption.

I reprodcued this with a simple: "gpgtar --status-fd 2 --verbose --create --sign -u foo@bar vimfiles > foo.tar.gpg" on the command line. Which gives me the proper status lines but then ends up in kleo with general error.

I tested it some more. Gpgtar reports proper erors like:

Ok closing, remaining issue is in T6813

After reading the initial description of this, I think that might even be a yet a different bug. For which we then would not yet have a ticket. :)

The issue for that is: https://dev.gnupg.org/T6566 so I think this can be resolved here?

No it is just not properly selected after generation but it is there. I think there might even be an issue for that already. But definitely not something related to vsd 3.2

With VS-Desktop-3.1.90.277-Beta the generated key is the default RSA 3072.

That sounds very good.