So after taking this down to where it was only patching status.h and mainproc.c to add a write_status_output() I realized the whole issue is down to status-codes.h not being updated automatically if you apply a patch to status.h in a released version.

Having looked at the build log again after applying the patch, I see the first test failing is

Oh wow. It seems you have already coded the feature request. I didn't want to generate work for you and offered to submit a patch. Not that I am complaining.;-) Thank you!

Those options where originally intended for debugging but your suggestion makes sense. I also add this to most other tools.

The patch is part of 1.7 - please test and in case of problems feel free to re-open.

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Yes we could add that. Okular has this actually. For now we were Happy to go with the system default in the last version :)

This seems to depend on the Platform theme. Under Windows I get the same results as you on linux It works fine with me

Since there are some files that would simply have to be created each time under $GNUPGHOME, I've been thinking a bit more about what sort of approach to take for "fallbacks."

That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal

Funnily enough, runtime sockets already adhere to the XDGBDS somewhat by using $XDG_RUNTIME_DIR/gnupg as their path, while everything else uses strictly $GNUPGHOME or ~/.gnupg with no other alternative. Of course, I completely understand that the priority for this is rather low, but I am still happy to look into providing a patch myself that would add these fallbacks if it would help expedite the whole process.

Portable Apps are a Bad Idea because they bypass important security mechanisms. In any case please tak such discussions to a mailing list and please do not use the bug tracker for this. The audience of bug reports is pretty limited.

Talked to werner about this. We will but the list of signed files into the Gpg4win repo proper to that signing is part of the normal Gpg4win release (of course only if you have a signing key configured)'

Werner wants the import via gpg-agent

In master, I applied changes for include files which don't harm current target of MinGW-64.

It's true that under $GNUPGHOME (~/.gnupg/), there are multiple things: configuration files, user-specific data files (private keys, public keys, the trust database, and revocation certificates), user-specific state files (like the lock files and random seed), possibly runtime sockets, and executable/script for card reader. Some careful handling might be needed for making backup and doing version control for that.

Yeah I also signed all the binaries for the last Gpg4win release (4.2.0). I think we should support the case that only signed binaries are allowed on a system.

I guess that's what it is called. A person in the forum told that GpgOL could not be loaded in Outlook and saw that the signature is missing in the new version. But it was there in version 4.2.0. With the command Get-AuthenticodeSignature I could confirm that this is the case.

You mean the Authenticode signature? Afaics, only the gnupg files come with such signatures.

So I cherry-picked this onto 2.4.4 and I ended up with a failing build due to failed tests (it built fine without the patch)

This is referenced from https://nvd.nist.gov/vuln/detail/CVE-2022-3219 for CVE-2022-3219. Can this please be fixed?

We check the actual used signature and the corresponding (sub)key. Whether you trust this key is a different thing and we are not able to check that. Note that the same subkey may be used with different primary keys. The whole point of gpgv is to that you pass a list of trusted keys - actually this makes this new option superfluous but in gpg it makes sense. It was easy to add it to gpgv, though.

Checking if the file already exists doesn't help. In fact, typically the file (containing the shadow key for the card key) will already exist. But one could check if there is already a private key with this keygrip. Then restoring could be refused, so that the worst that can happen is that the shadow key (which can be recovered from the smart card) is overwritten with a corrupt file.

I think the attack ingo talks about would mostly be covered by checking if the file already exists before moving it into the private directory.

Do note there could be subkeys as well.

Fixed in 0.3.2.

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

These gpgsk files are standard private-keys-v1 files with an additional Backup-info line showing for example the keygrip.
There are no certificates in the file, thus we can either use gpg or gpgsm as driver.

Hard to test without instrumenting the code.

Tested during development.

@alexk and me tested this. The core functionality works.

Works for the two sample RSA cards. Ticket may eventually be re-opened if we run into problems with ECC cards.

Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24

It is already implemented and will soon show up in 2.4.4 -)

Sorry, we won't do that. Please search on the Net for reasons why this is not a good idea. In any case you better move to Ed25519 or - if you really feel like this - to X448. The GnuPG FAQ als gives a rationale why larger keys are not useful.

• To configure a keyserver none I have now T6950: Kleopatra: Usability improvements for directory services configuration
• For tarball naming I created T6952: Gpg4win build system: Include commit hash in tarballs from gen-tarball.sh
• For the about dialog I have T6953: Kleopatra: show commit id in about dialog

In T6946#181608, @werner wrote:

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

But thanks for reporting! I really like feature requests so please do not feel discouraged to request more features.

Sorry, but this is a "Wontfix" we do not support this by choice. We think that adding photos to certificates both gives a wrong sense like "I know that picture, iit must be this person" and also increases the sizes of the certificates a lot. It is in our opinion a misfeature in the OpnePGP specificationl.

I noticed the Debian bug and was about to answer but a feature request is also a good thing.

In T6708#181592, @werner wrote:

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

Sorry, it was my fault building the test installer.

To be clear: This ticket is only about GnuPG (more precisely dirmngr) and the changes are included in VSD and Gpg4win.

Hi, ebo I would still think this is resolved. Because it was never meant that the user manually enters the value of "none" because there is no hint for the user that "none" is a reserved word. It should either be administratively configured which does not make much sense for Gpg4win or provided by the distribution. If left empty the default of GnuPG should be used. If we really want users to deactivate keyserver access by using "none" in the dirmngr.conf a much better solution would be a checkbox for this. In that case I would open a new issue.