CC does not offer such an option as the GPL does.

It may be preferable to get that under 4.0 or later, so you don't need to contact every contributor again if in some years there is intention to switch to a newer version released by Creative Commons.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

I don't see it as a priority right now. We should keep it in mind for T3811 .

The problem only occurs with the gtk platformtheme.

Hi, gpg4o does not send PGP/MIME (the proper format for including attachments and no encoding problems). As such it does not have the Problem described here. You can use "Send PGP Mails without attachments as PGP/Inline" in the options of GpgOL to have something similar. This will also work for Kopano.

I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.

The problem with mnemonics based on words is that they are language dependent and only a small part of the world is fluent enough in English to spell/use them correctly. Thus anything based on ICAO spelling (Alfa, Bravo,...) is a better choice than arbitrary words from one language. Even if that meas to write down a longer string. A CRC is of course very useful.

It would be great if this feature were implemented with a mnemonic code option, with a built in checksum, as described in bip39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Using the same bip39 standard (and perhaps others, as alluded to in T3497) would also improve compatibility with existing crypto key storage devices (i.e. cryptocurrency wallets used as smart cards).

Good news! :)

Just as a note as you were the first to report this: I've finally found a solution. In the next version it will be possible to move around crypto mails. Hopefully your wife can then use GpgOL :-)

A new Idea which I'll have to test:
Register an event handler for each folder in which a decrypted item is read. "Mailitem->parent" In this event handler listen to the beforeitemmove event. In that event then close the mail / discard the decrypted contents.

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 got an Idea how to improve the situation here. But its very complex and might break Outlook even for unencrypted mails. So it's very invasive.

@dkg thanks for the link.

The severe delay caused by check-trustdb continues to cause problems elsewhere in the ecosystem. It would be great to try to address this so that GnuPG was more responsive for routine tasks like importing a single key.

I experienced this issue today while cleaning up my keychain. I recently switched from pgp to tofu+pgp trustmodel and this caused me the above error when doing:

Can't reproduce and there were tons of fixes to gpgol in the meantime -> invalid.

I'm closing this as a duplicate of T3459 even if this bug is older we used it to discuss side topics.

Hi, sorry this is a known issue. To quote the README:

Ok, I implemented this for Inline messages. The resulting armored literal data packet is encrypted as PGP/MIME message. I'm not sure this is what we want.

Is this even something that we can control?

Ok. Lets put this problem back until we have a possibility to encrypt through filters so that can maybe enable this just for some kind of reenecrypt workflow.

I can't reproduce this I even tried to completly remove TCP/IP from the DCOM Protocols. No problems.

As others have pointed out, we don't implement the Bell-Lapadula model.

Well, iff we implement that for gpg we also need to implement it for gpgsm.

A decision must be made what the desired behaviour should be.

T3252 is about meta data for each key.

I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.

The revert was done in 7195b94345b0bb937477dc47fc5ec27fb108a099.