As Dashamir Hoxha in the mailinglist gnupg-users mentioned, even with the
--quiet flag enabled, there still is logging output after/during the validation
of the trust-db.

When the user enables the --quiet flag, there should be no log_info output to
the stdin. At most points in the code its managed like in ./g10/trustdb.c:970
(Commit b752d2c93778e6a1c1de3eddf8fc725b0ddd354e in master from the public Git).
But after the silenced output there, it goes into the validate function, where
still is a log_info output in ./g10/trustdb.c:2057 (Same commit as mentioned
above).

relevant to T1424

I have not tried this on 2.1.

To reproduce

% gpg --recv-keys 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

74D1153FB159BB3D1BAC641CAC504BE650012B98

    % gpg --edit-key 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
    tsign with 2 (I trust fully), depth 1, domain "aclu.org"
    Check validity of 74D1153FB159BB3D1BAC641CAC504BE650012B98

If you make the trust signature without a domain specified,
74D1153FB159BB3D1BAC641CAC504BE650012B98 will appear as "full". With the domain
specified, it appears as "unknown".

That's excellent! I tried with no luck to find a roadmap on when 1.7 could be released;
do you have any ETA? How could I help to make it happen?

Thanks!

It is fully supported but you need to link agains libgcrypt 1.7 which has not
yet been released.

You should not change a cipher algo because the OpenPGp preference system takes
care of it. If you really want to do it, you need to change the config files
directly. See also the FAQ.

Hi Clint,

Out of curiosity, have you tried this on 2.1?

I realize this is probably very easy to reproduce, but could you nevertheless
list the commands that you used to show the bug?

Thanks!

Here is the actual error. how to overcome in AIX 6.1
Some of the users have bash shell and some have ksh.

#gpg-connect-agent 'getinfo version' /bye
gpg-connect-agent: can't connect to the agent: IPC connect call failed

This has been fixed (see the message from Werner today on gnupg-devel with
message-id <87bn6mr28v.fsf@wheatstone.g10code.de>)

I have only been pulling from .tar.gz files.

Werner pointed out that the quick integrity check is not used due to an attack
by Mister and Zuccherato. However, this attack does not make use of any
information from the PK-ESK packet. It just uses the session key. As such, the
quick integrity check should not be done in the dek->symmetric case either.

I think it is possible to fix this issue so that we can use the quick integrity
check in the future. My post about this to the openpgp group is here:
http://mailarchive.ietf.org/arch/msg/openpgp/A_r93YIukOqzvrmd44F-Jl3dHbc .

My suggestion is a not-backwards compatible change. For messages that currently
exist, it is acceptable to do the quick integrity check if we can rate limit the
oracle (to recover the first two bytes from N blocks costs (N+1) * 2^15
decryption attempts). This is definitely safe, as Mister and Zuccerato point
out, in the interactive case. Do we have a way to reliably detect this?

Sorry, I was using --check-trustdb as a shorthand for the actual function.

I think that I fixed this issue in master. If you have time, please test, from
git repo.

bkuptocard had been not implemented, but it was finally implemented in 2.1.11.
If any problem, please let us know.

I cannot reproduce this with current master and a Yubikey4. Can you please
retry with the current master?

Also, are you sure that you are not mixing GnuPG components you compiled with
the ones provided by your operating system? Also, what made you try to compile
GnuPG in the first place?

Please open a separate bug for the other issue. No 'by the way's in bug reports
please.

Fixed in eea139c.

On Sunday 06 March 2016 at 15:18:54, Neal Walfield via BTS wrote:

is for --check-trustdb

Thanks for reporting this. The right solution is for --check-trustdb to ignore
legacy keys.

If i remove the com-certs I get the exact same behavior as I'm seeing on windows.

aheinecke@esus ~/a/e/src> export GNUPGHOME=$(mktemp -d)
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keybox '/tmp/tmp.hyElMR6oUi/pubring.kbx' created
aheinecke@esus ~/a/e/src> gpg2 --import
~/arbeit/gpg4win/zertifikate/testuserA-pub.asc
gpg: /tmp/tmp.hyElMR6oUi/trustdb.gpg: trustdb created
gpg: key 6CFBC912: public key "Test UserA <testusera@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keydb_search failed: Invalid argument

From the debug output it looks to me that gnupg is using keyring functions to
work with the keybox.

I can reproduce this now without Kleopatra and on GNU/Linux:

export GNUPGHOME=$(mktemp -d)
gpgsm -k

< imports /opt/gnupg/share/gnupg/com-certs.pem >
(this is not done on windows so maybe the errors differ because of that)

gpg2 --import ~/arbeit/gpg4win/zertifikate/testuserA-pub.asc

Result:

gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_get_keyblock failed: Value not found
gpg: [don't know]: invalid packet (ctb=00)
gpg: /tmp/tmp.f5ub2ZRYC0/pubring.kbx: copy to
'/tmp/tmp.f5ub2ZRYC0/pubring.kbx.tmp' failed: Invalid packet
gpg: error writing keyring '/tmp/tmp.f5ub2ZRYC0/pubring.kbx': Invalid packet
gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_search failed: Invalid packet
gpg: key 6CFBC912: public key "[User ID not found]" imported
gpg: [don't know]: invalid packet (ctb=00)
gpg: error reading
'/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc': Invalid packet
gpg: import from '/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc'
failed: Invalid packet
gpg: Total number processed: 0
gpg: imported: 1

gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.7.0-beta307

I'll try now with git master.

The debug output from gnupg for an import that caused a corruped keybox.

It's not for the attached pubring.kbx but I have the file that was generated If
you need it.

What I did in the log was to start kleopatra (The output of process is 2428 is
likely the debug output of the initial keylisting kleopatra did)

Then imported a test key and afterwards closed kleopatra.

Fixed in ec412b9d.

Fixed in c7cb4008. This will take effect next the web site is published.

This is a feature of the org-mode export. I'm looking into this.

Yes you are using pinentry, and we need to know what kind of pinentry (there are
several flavors) and which version you are using in order to help you.

Please do 'pinentry --version' and report the output.

To see whether this pinentry is the one you are using, or to play around with it
and the variants, you can do:

echo -e "SETDESC Does this look like your pinentry window?\nGETPIN" | pinentry

You can try replacing pinentry with pinentry-qt for example.

D344: 787_fix-2235.patch

I believe your problem is fixed in 9f0ba508. With that change I was able to
build gnupg-2.1.11 using speedo in a very minimal Debian jessie chroot.

To test this change, please apply the attached patch (generated using 'git diff
gnupg-2.1.11 dirmngr/Makefile.am' from gnupg master).

If the problem persists, feel free to reopen this bug.

That particular problem is fixed in 9a1778ab. Can you be more specific on the
other problem(s)?

Thanks for the patch, but I decided to fix it by skipping the test instead.

Fixed in a883d4c0.

The reason that we encrypted the SED packet with AES256 is that is the preferred
cipher in my public key. I think that the cipher for the s2k function should be
chosen similarly.

Merged, thanks!

Fixed in 3e1b451c.

I could reproduce this with gnupg-2.0.29. I will have a look.

Hi Arthur,
sorry for the late reply:

Outlook 2010 has new code for supporting OpenPGP and S/MIME,
we will tackling the problem differently there.
I think that the last code for GPgOL for Outlook 2007 uses
encryption.

If this is still relevant for you: Can you retest?

Hi,

as the extended support period of Outlook 2003 ended in 2014,
we will not get around fixing this for Outlook 2003.

Please open a new issue, if you encounter problems with a more recent version.

Best,
Bernhard