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.

We are now generating a key with whatever defaults gpg uses.

Well I guess T6805 is now the followup ticket that I did not create when I just closed this issue as Wontfix. Ingo can you take T6805 and do what you wrote in your last message here?

For reference, here is a link to the gpgme homebrew formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/gpgme.rb

Just to clarify, PIP wasn't used to install the .egg package. The package was built and installed via Homebrew. The error message occurs when using basic PIP commands such as pip list or pip freeze. PIP is picking up the gpgme egg from the shortcut included in the site-packages directory.

We don't use or suggest the use of PIP or other insecure software distribution systems.