Too similar to T7004 I have disabled this user.

Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022

@jmrexach I think I undestand now @TobiasFella can you have a look please?

Hi,
please use English in this tracker. At least using an online translation service.

gpg --list-packets shows this:

Hi,
To reproduce this just change an item in the filter list: The contents of the window changes but NOT the name (title) of the window (only in the leftmost tab).

I cannot reproduce this. If I right click the tab I can rename it just like every other tab. The tabs do not change their names based on the current filter that is used that is only their default name. And the default for the first Tab is "All Certificates"

Yes, basically these actions check if the underlying document is there and if not they make themself invisible. But then they should not be in the menu in the first place. But I believe the impact of this is rather low.

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

In T6977#183049, @Karam wrote:

Uploaded the corrupted file.

Uploaded the corrupted file.

It seems to pass for me with gnupg-2.2.41 but fails with gnupg-2.2.42?

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.

I was wrong for the semantics of proxy->outtoken. It is zero when run_proxy_connect is called and enabled during the negotiation.

@hlein Thanks a lot for quick testing.

Thank you @gniibe! Applied the rG848546b05ab0: dirmngr: Fix the regression of use of proxy for TLS connection. changes here, and 2.4.4 works here now.

IIUC, the code for keep_alive is for negotiation of proxy. If so, something like this is the fix:

Right. I was wrong assuming the code in 2.2 branch is stable (that is: well tested).

Per https://dev.gnupg.org/rG04cbc3074aa98660b513a80f623a7e9f0702c7c9#83517, it looks like the fix might be incomplete?

These actions/commands or, more precisely, the documents those commands show, are only available in the commercial GnuPG VS Desktop release.

Thank you for the report. There was a problem in: rG845d5e61d8e1: dirmngr: Cleanup the http module.
Pushed the fix in: rG04cbc3074aa9: dirmngr: Fix proxy with TLS.

@Jakuje, you are right. This is a plain error and we should do a new release to avoid false errors.

Thank you, applied.

You have to restart once. Then it goes away. We can't do much about this since we load the icons etc. at startup and don't have dynamic color changing. It might be better with the next Version which will update our UI Framework but no promises. I leave it open for now so that is a known issue.

Ikloeker is our resident accessibility expert and Kleopatra has a certificate for accessible software so I agree that we should not change it. Or is there a specific issue / condition for you that makes this extra hard to read?

For accessibility the contrast between text and background must be high. Therefore, I don't think we should change the color. In any case, you get what you asked for: A dark (green) background color.

Applied the change. I write the ChangeLog entry by commit message.

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

Check https://community.kde.org/Get_Involved/translation for information how to contact the translators and/or become active in translation.

The additional debug info are:

gpgsm: DBG: p12_parse:1998: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2006: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2021: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2054: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2061: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2069: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2081: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: error parsing or decrypting the PKCS#12 file
gpgsm: total number processed: 4
gpgsm:              unchanged: 4

Is this issue resolved?

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

Could you write a quick patch file for that? (I don't have a working source build, I am using the Fedora spec file + patches)

The old debug output is in genral okay but what I would do is to add a couple of log_debug calls like

Does the run-verify example (in gpgme/tests) hang when verifying a corrupted file?

@werner I managed to recover the old .p12 that has the error. And this is still replicable. Is there a debug flag that would be useful or can we setup some private live-debugging for this?

Closing this outdated ticket

I'm attaching a proposed patch. We should decide whether this is the correct encoding to use for SHAKE128 and SHAKE256, because they are variable-length output functions and there is an alternative encoding that has a field for the length, which is likely better suited, but currently not really well supported by libgcrypt (since this would be dynamic content in the ASN.1 encoding).

I would have expected an error message right after

I agree. Any automatic use of the embedded filename will be potentially problematic security-wise. The only safe use is probably as a value in an interactive dialog, and even then, only if the user doesn't accept a dangerous value.

This was reported again 3 years later as T4704, and finally fixed in gnupg-2.4.4, released last week.

The patch supplied here should apply to STABLE-BRANCH-2-4, but it should also be easy enough to backport to STABLE-BRANCH-2-2 and STABLE-BRANCH-1-4. For GnuPG master, i recommend actually removing the option.

Unfortunately I have deleted the .p12 with the CA chain, and I don't know how I've generated it. It also contained my production certificates so, kinda sensitive to upload here.

Okay, I push the change for the extended salt size. Regarding the import of CA certificates, I have not seen any problems. In fact it is pretty common. Did you test with with 2.4.4. A test file would be helpful.

Ok, I have tried again the series of workarounds that I initially posted on the main description, and I managed to fix it by striping the CA certificates. So the current issues here are:

• Allocated salt is too small. https://dev.gnupg.org/T6757#182217 fixes for now
• Cannot import a .p12 that includes CA certificates as well

Fixed by changing server as noted above.

Thanks for all the help @gniibe.

It should not be removed as I believe it is required to be compliant:

Thank you for the fix. Pushed the change modifying the commit log for the ChangeLog entry.

I'm afraid that your particular configuration would cause the problem of the negotiation.

Server is nginx with the following settings

We got a bit further, not sure what debug level you want, guru I've found to be too excessive:

Can you please try this patch:

After applying patch to nPth 1.6 no semaphore leaks detected. Tested with GnuPG-2.3.3.
There has been positive feedback from production environment as well.