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.

FWIW, OpenPGP's S2K and PKCS's PBKDF2 are very similar and don't make a difference except that we have calibration code for S2K in gpg-agent.

The change werner mentioned previously is eaba8d58acda66f428870794115cb22c2590ec5e, but this is based on Elgamal. RFC4880 since then specified S2K, and better approaches are available, too (at least PBKDF2 is in libgcrypt). These could be used with HKDF for RSA and other asymmetric key generation methods.

No way to test on El Capitain anymore. It works on Sierra.

@werner do you have any updates on this?

Is this still an issue?

We can do this with estream now.

Please take such discussions to the mailing lists. As soon as a resolution has
been found please update the status of this bug.

gpgkey2ssh has been removed from master (2.1)

There are still problems with libtool; see recent Debian problems on building
gnupg for Windows. Thus we won't chnage libtool for 1.7.0.

Fixed in
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=5168b97fb5e2eebdc99b40f96f9b6289647e87d2

Please test.

I think that we could add -lrt in configure script.
Solaris also has a problem for lock object.

Its pthread_mutex_t seems have alignment of 8-byte.
In posix-lock-obj.h, we will have a padding after vers and the union u.
So, it fails at assert (!"sizeof lock obj");

Reference:
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/types.h

Some more infos:

https://www.openkeychain.org/faq/#importing-your-own-key-from-gnupg-fails
says that this is a problem for a number of people.

Werner told me that porting the fix back would mean to basically
migrate 2.0 to 2.1, which is useless because 2.1 is already 2.1.

Another possibility would be to change --export to mix public keys (certs)
with secret keys. This would create other problems and thus is not
adviable for a stable version.

So I think this is "won't fix" because it (technically) does not make
sense to fix in 1.4 or 2.0. Solutions: Use 2.1 or wait for 2.2.
As importing implementation: Be tolerant for this problem man use the cert
information if you can.

This tool has now been marked as deprecated in the documentation.

I reviewed this issue. I've identified three issues that the reporter is
complaining about:

• Can't create a key with a passphrase (this works)
• Can't import a key that is not protected by a passphrase (this works)
• Can't export a key without protecting it with a passphrase (this is not allowed)

I also moved my mouse between screens in my multi-head setup and gpg did not crash.

I'm marking this issue as resolved.

At least with 2.1.9, it is possible to create a key without a passphrase:

$ gpg2 --gen-key
gpg (GnuPG) 2.1.10-beta132; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Empty
Email address: empty@testing.org
You selected this USER-ID:

    "Empty <empty@testing.org>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
Please enter the passphrase to
protect your new key
Passphrase:
Repeat:
You have not entered a passphrase - this is in general a bad idea!
Please confirm that you do not want to have any protection on your key.

Yes, protection is not needed
Enter new passphrase

[ye]? y

gpg: key BC364B3A marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, TOFU+PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2015-11-18
pub rsa2048/BC364B3A 2015-11-18

Key fingerprint = 6766 A52A 3E04 F09B E6F7  F80C 920C 9361 BC36 4B3A

uid [ultimate] Empty <empty@testing.org>
sub rsa2048/906F39F0 2015-11-18

It is also possible to import a secret key that doesn't have a passphrase:

$ gpg --no-options --gen-key
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:

(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)

Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.

   0 = key does not expire
<n>  = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years

Key is valid for? (0) 10
Key expires at Sat 28 Nov 2015 01:21:43 PM CET
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:

    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Empty Passphrase
Email address:
Comment:
You selected this USER-ID:

    "Empty Passphrase"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.

You don't want a passphrase - this is probably a *bad* idea!
I will do it anyway. You can change your passphrase at any time,
using this program with the option "--edit-key".

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 201 more bytes)
...+++++
..+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.............+++++
.+++++
gpg: unable to use unknown trust model (7) - assuming PGP trust model
gpg: key 4240CFD8 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: public key of ultimately trusted key BC364B3A not found
gpg: public key of ultimately trusted key 41A7057B not found
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2015-11-28
pub 1024R/4240CFD8 2015-11-18 [expires: 2015-11-28]

Key fingerprint = 4E0D 8EED 3567 4228 7F44  C7D7 92BE 30B6 4240 CFD8

uid Empty Passphrase
sub 1024R/D6CF583D 2015-11-18 [expires: 2015-11-28]

$ gpg --no-options --export-secret-key 4240CFD8 > 4240CFD8.sec
$ gpg2 --import 4240CFD8.sec
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 4240CFD8: public key "Empty Passphrase" imported
gpg: key 4240CFD8: secret key imported
gpg: Total number processed: 3
gpg: imported: 1
gpg: secret keys read: 3
gpg: secret keys imported: 2
gpg: 3 marginal(s) needed, 1 complete(s) needed, TOFU+PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2015-11-18
$ gpg2 -K 4240CFD8
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
sec rsa1024/4240CFD8 2015-11-18 [expires: 2015-11-28]
uid [ultimate] Empty Passphrase
ssb rsa1024/D6CF583D 2015-11-18 [expires: 2015-11-28]

Gpg4win installers have been code-signed with Authenticode for years and thus are
as securely authenticable as you trust the Microsoft code signing certificate chain
. (If the Microsoft code-signing certificate chaing is broken, your system is wide
open as it secures a lot.)

Gpg4win and GnuPG binaries are signed and additional available over TLS channels
(which provides less integrity protection.)

Comitted in a958ffd.

Duplicate of T1495

The new URL is now also an old URL.

Based on aheinecke's comments I'm closing this.

Kgpg is unmaintained upstream (meaning KDE) Afaik it does not work with gnupg 2.1

We (talking as a kdepim developer here) are currently in the process of removing
libkgpg dependencies in the hope to remove Kgpg altogether. You should use
Kleopatra and nag the Kleopatra developers (me) about features of KGpgp you will
miss in Kleopatra.

This bug has nothing to do with Gpg and should be filed on bugs.kde.org against
kgpg (but as I said it's unmaintained so you probably should not bother)

Hi Neal,

A minor heads up.

I have appended the following to KGpg Failure to AutoStart bug report in the
hope it allows the devs to think about the nature of this problem's root cause
from a broader perspective:

Additionally, note re: the failure of KGpg to AutoStart:

All of the testing I've described in this bug report, and on the Fedora Forum
link, was performed using a native Fed 22 system installed on a HDD. On this
HDD-based system, I had previously run Fed 21, and used fedup to arrive at Fed 22.

However, I also run Fed 22 as a Guest OS in both VBox and KVM. Installation of
both of these virtual Guests was accomplished using the Fed 22 KDE Spin *.iso.

IIRC, when Fed 22 is first cleanly installed from the *.iso, the gpg2 version
installed is: 2.1.14. After the first: dnf upgrade is performed, gpg2 version
2.1.15 gets pulled in.

Despite these differences, in all three of my Fed 22 installations, KGpg fails
to AutoStart, despite being enabled.

Hi Neal,

Some positive progress to report. A workaround to brute force KGpg to AutoStart
on Fed 22 has been identified in the Fedora Forum where I've been working this
issue.

I have already appended this information to the official bug report in the hope
it helps the devs identify the underlying root cause.

I copy the workaround here so other users of this site and Fed 22 have a process
they can try if desired.

As a workaround to KGpg's failure to AutoStart, this brute force method works on
my Fed 22/KDE system:

1. Manually start kgpg from Konsole:

$ kgpg

2. Ensure ~/.config/autostart is empty. My autostart directory contained one

file , so I did:

mv /home/<username>/.config/autostart/kgpg.desktop /home/<username>

3. Copy the default startfile to the local user's autostart folder to override

defaults:

cp /usr/share/autostart/kgpg.desktop /home/<username>/.config/autostart/

4. Edit the ".config/autostart/kgpg.desktop" file by setting autostart to "true"

(from it's default value of 'false")

X-KDE-autostart-condition=kgpgrc:User Interface:AutoStart:true

5. Save, Close, Logout

6. Following Login, note that KGpg is 'autostarted'. This means the KGpg icon is

available in the System Tray, under Status & Notifications, and KGpg has been
assigned a PID, and is running. Clicking on the KGpg icon shows that all KGpg
functions work correctly.

This brute force method is also known to survive subsequent logouts - logins,
and reboots.

Hi Neal,

I have spent several days debugging this AutoStart failure within the Fedora
Forum. However, none of that effort has yielded any useful information.

Therefore, I have filed a bug report on Fedora's bug tracker covering this
topic, available here:

https://bugzilla.redhat.com/show_bug.cgi?id=1245732

I will let you know the outcome.

I don't know what you mean by "documented the issue". The best thing to do is
to report the bug in the KGpg or Fedora bug tracker.

Hi Neal,

I understand your position on this issue.

As an interim heads up, I have documented this issue in the Fedora Forum. As my
post is only a few hours old, I'll keep an eye on it, and will be sure to let
you know if anything interesting shakes out.