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?

I 'll try GPA and Kleopatra, I hope will do the same tasks.
thanks anyway.

I suspect gpg4usb is a dead project anyway. I've been on their mailing list for a while and according to my records the last post from the pseudonymous author(s) is from October, 2016. I'm not sure how much of that GPL breach is intentional or just a result of web services going offline and not being restored.

The Python portion of this is done, the tests will now create a key with an expiration a few years shy of the 2106 end date (NYE 2099).

It seems to be 1.1.6 from 2010 or so. They use gpg 1.4.20 which misses a critical security fix.

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.

I'll volunteer to look into it. IMO "Invalid Crypto Engine" points definitely to a GPGME bug and I want to know whats going on there.

Thank you for the quick turn-around! I especially appreciate the difficulty of out-of-release-cycle changes.

This bug tracker does not support gpg4usb - please use their bug tracker.

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

This crash was new in Gpg4win-3.1.0 introduced with: dc48589b3d429d7d156c75b4e7bc784b140f40ce

Thank you for the report. I can reproduce the problem. I extended the title a bit so that its easier to find for others who might also see this.

@dcialdella Well as you are here already you can open one here. Alternatively I would have thought Ubuntu's Launchpad.

Hi Carlos,

Do not define NDEBUG - defining this is a bad idea. Anyway, I will fix that problem.

Hello Andre;

Apparently PpgOL (gpg4win 3.1.0) works well in some computers in the computer department, you have to trust God to work well with the end users of the institution, I wanted to ask when it comes out another version of Gpg4win for Outllok?

And I have another question; How can PpgOL be used on Iphone and Android phones? Is there any tool to decipher encrypted emails on the phone?

Thank you
De: aheinecke (Andre Heinecke) [mailto:noreply@dev.gnupg.org]
Enviado el: viernes 27 de abril de 2018 00:56
Para: Carlos Garcia (TI HN) <cgarcia@asjhonduras.com>
Asunto: [Task] [Updated] T3938: GpgOL: Automatic way to "force enable" it in the registry

aheinecke added a commit: rO8635193d0108: Disable OL 2013 / 2016 resiliency for us.

TASK DETAIL
https://dev.gnupg.org/T3938

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: Carlos, aheinecke, Mak, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

@aheinecke thanks for the post.
When you said "open a new issue" is create here or in Ubuntu forums a new issue ?
I'll do. when ?
I imagine ni some weeks will be solved but I use the tool everyday for secure text.

Released today.

Both CRL downloads and the error handling / reporting is much improved in Gpg4win-3.1.1

This is resolved in my opinion. I've tested with some larger CRL's and it worked on Windows.

I thoroughly tested this again with the released versions. Works very nicely, including the timeout.