Thanks. Confirmed - no crash with the beta5 dll.

Argh! From the log it looks very much like another incarnation of the issue fixed in T3960 (Same underlying reason)

Good idea, but I've already tried it. Tried once again and freeze still occurs.

Webhelp version of the Python bindings HOWTO is currently available here:

Hi and thanks. Yes, I consistently reproduce. Here's the log file.

As a work-around for this bug I've ported the HOWTO from org-mode to DITA XML and will generate a webhelp-responsive (i.e. searchable) version to put on another website (an Amazon S3 bucket since it will be reliable and cheap) in the interim.

Okay, so maybe this has nothing to do with T3748 then…

That comes directly from pthread_attr_init - need to check what's special on HP/UX here.

Do you have any other implementation to test against?

Above command freezes with 100% CPU, too.

Thanks for your report!

A smartcard may do several dozen operations per second and thus spawning a tool each time is not the best option. A generic notification scheme would be better. OTOH, notifications about secret key operations may accidentally create an oracle - which is not good.

Org-Mode was updated to today's release and further testing was conducted.

cross-sign is also missing.

If you never explicitly changed the default trust model, then I would expect you are not using TOFU, but the presence of a tofu.db file strongly suggests that you are indeed using it.

I'm not sure. How to check it? In man gpg I only see instructions on how to change the trust model. ~/.gnupg/gpg.conf does not have any trust model related entry. I have ~/.gnupg/tofu.db file however.

This looks reminiscent of a bug previously seen in GPA (T3748).

It seems that Debian does not install te required libgpg-error correctl.

Zertifikat erneuert.

I've already sent jens a mail this morning.

I understand the Problem. Your recipient formatted the reply in such a way that GpgOL does not detect that the original message is Quoted, verifies it and shows only the verified part.

Great! I did not notice this feature!
Is it on purpose that this is not shown by hitting TAB in the --edit-key command prompt (and auto-completion)?

The fingerprint is required because that is the unique identifier for a key. Without that we would need to presetn a menu to select between keys. This would make scripting complicated again. On the command line c+p is easy enough to hget the fingerprint. c+P is also the reason why we print the fingerprint by default without spaces.

You are lucky. This has been possible for quite some time and since 2.2.6 it is an official part of the API. See T3816

But why is that the case for OpenPGP Signatures, then? The difference does not make sense to me.

The key receives fully trust and thus we get the "green" flag plus the "expired" flag. In my test with OpenPGP the key was not trysted and thus we did not got only the "expired" flag. At some distant past we agreed on these rules.

gpgsm behaves exactly as gpg and as explain in doc/DETAILS. VALIDSIG is issues even for signatures done by an expired certificate. Let me check whey GPGME claims "green" here while it does not not an expired OpenPGP signature.

Wait. Users should not have the ability in the GUI to mess with the CRL cache. That is internal / private stuff. And something for developers, so this should be removed from the GUI altogether.

I think this issue is important as GPGME should not report "Green" / Everything OK in that case and only have the EXPKEYSIG in details.

1. Create Mail and sign with PGP/inline activated
2. Send mail to someone else who does not use gpg etc.
3. Get a response including full quote of your email

I changed the priority to 'Normal'. The problem now is not the libssh usage, but how we can assume use of secure memory by random generator(s).

By libssh upstream, the problem has been fixed: commit-72f6b34

Thanks for your report. Are you sure that "Allow HTML" makes the difference?

As I link this Ticket often when talking about this limitation. Here is a short animation to show what is meant by moving but not opening a mail:

I'm not sure I understand your Problem. For me it works as it should.

Here is the function:
https://git.libssh.org/projects/libssh.git/tree/src/dh.c#n227

Am I right to assume that the test suite is terminating and restarting libgcrypt? Although we have features for this, I am still not convinced that this is a proper use of libgcrypt. There are just too many cases how this can fail. Unix is not designed to use shared libraries in so-called "plugins". I need to look closer at the libssh code.

It would be better not to require gcry_control(GCRYCTL_CLOSE_RANDOM_DEVICE). Automatic handling through gcry_control(GCRYCTL_TERM_SECMEM) would be better.

The patch D461 makes gcry_control(GCRYCTL_CLOSE_RANDOM_DEVICE) free the allocated secure memory.

It assumes a change of libssh like:

Here is my patch: D461: jent random requires finalizer to deallocate secure memory

I downloaded it and I' m using it.
Nice feature the "notepad".... easier for encrypt/sign.

The latest Version of Kleopatra has a "Notepad" View that should do what you want. E.g. If you decrypt something in there it preselects the keys the message was encrypted to when you encrypt it again.

In T3963#114101, @aheinecke wrote:

OOooh yeee.
Ok. Didn't know how bad gpg4usb really is.
I looked into it. Gpg4usb distributes their own binary GPGME version https://github.com/gpg4usb/gpg4usb/tree/master/linbuild/lib I don't even know which version that is. They are in violation of the GPL as they don't offer the source code of that GPGME version.

So, don't use it please what they do is horrible from a security standpoint. Try using Kleopatra (which I personally maintain). And if it does not work for your use case please let us know what your use case is and we can try to make it better for you. :-)

But indeed for gpg4usb you can't expect help here. They are very likely shipping a horribly outdated version with bugs that have since been fixed.

Workaround is to click cancel so that the next key is tried; right?