ok sir, i will abide by what you say.

I include both of you as i noticed that you both are active code checkers in
Gcrypt, thats the only reason, anyways thanks for lookup.

To disable the visibility feature the GCRY_USE_VISIBILITY macro is used. That
is figured out by configure and thus the place to fix it. I can't accept this
patch.

If you use gpg without a command option, gpg tries to figure out what
to do. Now if that file looks like an OpenPGP packet, gpg assumes it
is one and tries to decrypt and verify it.

If you want to verify a signature you need to run gpg with the proper
command, i.e.

  gpg --verify FILENAME

Thus this is clearly a usage error.

Right, some Unicode characters may mess up the output, this is a well
known problem and iirc there is another bug report on this.

Please continue a discussion at the gnupg-users mailing list.

An no reminders after 3 days please. We are all unpaid volunteers.

Such leaks won't be fixed in an old branch. Please report only for stable and
master. Is there a reason why you always include aheinecke in the nosy list?
And please do not assign a bug to a specific person - keep it unspecified.

Meanwhile implemnted in all branches.

Reminder for bug review.

Reminder for bug review.

Reminder for bug review.

On 32 bit, a problem was just discovered in the kernel development branch: see
discussion in https://lkml.org/lkml/2014/8/26/59.

The base line is that the bit shift in drbg_max_addtl and drbg_max_requests are
stored in a size_t which is 32 bit on 32 bit machines. Yet, the bit shift is
larger than 32 bit. It will be fixed in the next installment of the patch.

D245: 481_elgmal.patch

D243: 480_pubkey.patch

File: cipher/pubkey.c

Bug No. : 1

Function: gcry_pk_encrypt
Line of error: 2879

Resource leak occurs as variable "data" with assigned memory is not freed
before going out of scope , which causes memory leak.

Libgcrypt version 1.5.4 code:

  rc = sexp_data_to_mpi (s_data, &data, &ctx);
  if (rc)
    goto leave;

-> here when the code flow jumps to leave,"data" goes out of scope ,which
despite of being allocated memory is not freed before going out of scope.

Recommended Code:

rc = sexp_data_to_mpi (s_data, &data, &ctx);
if (rc)

    {
      mpi_free (data);
      data = NULL;
      goto leave;
    }

Here it is ensured that "data" is freed ,preventing any chances of leak

Bug No. : 2

Function: gcry_pk_genkey
Line of error: 3623

Resource leak occurs as variable "string" with assigned memory is not freed
before going out of scope , which causes memory leak.

Libgcrypt version 1.5.4 code:

   if (!arg_list)
        {
          rc = gpg_err_code_from_syserror ();
          goto leave;
        }

-> here when the code flow jumps to leave,"string" goes out of scope ,which
despite of being allocated memory is not freed before going out of scope.

Recommended Code:

if (!arg_list)

{
  rc = gpg_err_code_from_syserror ();
  gcry_free (string)
  goto leave;
}

I am attaching a patch for the above raised bugs.

D244: 479_pubkey.patch

Now for 2.2.2 we've switched to a new dedicated buildsystem with a fully updated
debian wheezy whereas the old buildsystem was a debian unstable snapshot with
the same mingw Version: 2.0.3-1
I could not find an upstream bug or any indication that there was a fix for this.

But with beta-37 of 2.2.2 I was able to use wildcards on the command line.
I am out of my wits why this works now.

Emanuel: can you confirm that wildcards now work on the command line so that we
can mention this in the news and maybe look at integrating the patch into gnupg?
I'd like a different pair of eyes on that behavior. Maybe I've just messed up my
testsystem.

I've commited the patch to gpg4win so it will be part of the 2.2.2 release.

Thanks for summing up the other problems. I've added a reference to this issue
to the "Improve encoding handling" point in the backlog:
http://wiki.gnupg.org/Gpg4win/Wishlist

D241: 478_primegen.patch

D242: 477_primegen.patch

Thanks for the feedback!

Not sure but everything seems to be working in the 2.2.2-beta relase.

Thanks Andre for the patch!

I managed to build gpg4win with the patch added and I verified that it seems to
solve the problem reported by me and also in Issues 1373 and 1674!

But I'd like to summarize the problems related to the charset / codepage on MS
Windows of which I am aware, as a reminder:

1. incorrect display of GPG 2 output translated into another language (also

reported in Issue 1373 and Issue 1674): fixed by your patch;

2. passphrases (both for secret keys and symmetrical encryption) with non ASCII

characters set using GPG 1.4.18 are considered not valid using GPG 2.0.26 and
vice versa

3. incorrect display of filenames with non ASCII characters (also in Issue 1409)

4. GPG 2.0.26 and 1.4.18 ignore or weirdly comply with --utf8-strings, --no-

utf8-strings or --charset options for utf-8 encoding of encrypted filenames (see
Issue 1409)

5. charset weirdness searching keyserver for some non-ASCII user IDs under non-

UTF-8 locales (see Issue 1514 - although relates to Linux it seems to occur also
on Windows, both CLI and GPA but not Kleopatra)

Hope this will help to improve the great GnuPG :-)

The user shell is ksh.

The gunpg2 memory fault error apears when i'm using libassuan version 2.1.1
(installed from perlz.org link)

I compiled gnupg-2.0.26 with libassuan-2.1.2 and the gnupg2 does not crash but
instead is just blocked waiting for something no matter what the gpg-agent is on
or off.

/opt/freeware/bin/gpg-agent &

[1] 31654070

jobs

[1] + Running /opt/freeware/bin/gpg-agent &

/opt/freeware/bin/gpg2 --gen-key

gpg (GnuPG) 2.0.26; Copyright (C) 2013 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.

Warning: using insecure memory!
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?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 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)
Key does not expire at all
Is this correct? (y/N) y

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

Real name: keytest01
Email address: catalin.mocanu@ing.ro
Comment: keytest with gpg-agent up
You selected this USER-ID:

    "keytest01 (keytest with gpg-agent up) <catalin.mocanu@ing.ro>"

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

[Comment: Here I'm waiting 4-5 minute and nothing is happening]

[2] + Stopped (SIGTSTP) /opt/freeware/bin/gpg2 --gen-key

jobs

[2] + Stopped (SIGTSTP) /opt/freeware/bin/gpg2 --gen-key
[1] - Running /opt/freeware/bin/gpg-agent &

Any hints?

D240: 476_patch-src_visibility.h

D239: 475_patch-ad

D238: 474_patch-ab

D231: 473_v7-0007-User-interface-to-DRBG.patch

D232: 472_v7-0006-DRBG-specific-gcry_control-requests.patch

D233: 471_v7-0005-Function-definitions-for-gcry_control-callbacks.patch

D234: 470_v7-0004-Invoke-DRBG-from-common-libgcrypt-RNG-code.patch

D235: 469_v7-0003-Function-definitions-of-interfaces-for-random.c.patch

D236: 468_v7-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

D237: 467_v7-0002-Compile-DRBG.patch

resolved as invalid.

Should be fixed in 1.2.1 (part of gpg4win-2.2.2-beta)

Are you sure that the case sensitivity was the problem here and not the general
Problem that Exchange Addresses were not looked up correctly?

It would be helpful if you could test this with gpgol 1.2.1 (part of
gpg4win-2.2.2-beta) if this is still an issue I'll look into it.

Hi Jon,
can you check this please with the current gpg4win-2.2.2 beta? I've fixed some
object resolution bugs there when Sender / Recipient addresses were not SMTP only.

Thanks

This should be working with gpgOl 1.2.1

As I don't have a test set up I'm setting this to resolved until someone complains.

To go into master.

Please send a DCO to gcrypt-devel and ask for a review of the code.

fixed. Thanks.

Done for master and 1.6.

Okay, but probaly only in master.

ported to 1.6.

Yes you may , as it would be quite helpful in further vigilance :)

Good anlysis. Thanks.
Feel free to put it as a patch into gpg4win.
I need to look closer at it because we have have the gettext code also in
libgpg-error. You should also send a DCO for GnuPG.

This is a false positive of your scanner. BUFFER may very well be NULL if the
caller used NULL for the buffer arg (which is the format string). Using NULL
for the format is not defined (cf. printf).

The condition testing BUFFER before calling is merely a general failsafe pattern
of a commly used code snippet.

If it helps you scanner to avoid such fails positive I can do an explicit check
for buffer being NULL. Shall I do that?

Pretty picture.

D211: 465_0001-Let-wchar_to_native-convert-to-console-codepage.patch

I've taken a look at this. The problem is that the working conversion code in
jnlib/utf8conv.c is not used on Windows but instead jnlib/w32-gettext.c does
it's own conversion to wchar and then back from wchar to the native codepage
which is simpler and should work.

But the conversion back used the wrong codepage. CP_ACP instead of the codepage
retuned by GetConsoleOutputCP. jnlib/utf8conv.c actually had a comment
explaining why it is neccessary to use GetConsoleOutputCP.

With this changed (see attached patch) I get correct output and can verify /
sign files with non-ascii filenames.

I think gnupg master behaves differently though and I don't have a test setup
for this so the patch is only against STABLE.

Werner any objections into including this patch into GnuPG / Gpg4Win?