Does the patch work for you?

1.6.2 with the fix was released in August

Released with 1.6.2. on August 21.

One is an enum, the other an int - not a problem according to the C specs.

D273: 534_fix_return_type__gcry_vcontrol.patch

Hello werner, a gentle reminder for this bug, have a look, if possible, it has
been over 3 months now.

guys i need a help with my Iphone 4 , my girfriend ask me for an app and put
a cable on the mobile nad ask me for the ID now i can not take it out from
the mobile Any sugestions please ?????

Hello werner,if possible have a look.

We won't do that. The risk of introducing real bugs is much higher than
detecting possible bugs. You would need to analyze each warning en details. I
did this once but decided to remove the warning from the standard set of cc
options. If you want to dicusss this or post your resuls please do this on
gnupg-devel - this has a much higher chnace that more eyeballs are looking at it.

D263: 517_0004-Make-rsa-FIPS-186-4-compliant.patch

D264: 516_0003-PBKDF-Add-the-omitted-step-from-pksc5v2.1-specificat.patch

D265: 515_0002-Make-ecdsa-FIPS-186-4-compliant.patch

Hello, Werner, Kindly have a look at this bug and patch,as and when you are
free. Thanks.

Sorry, cross-compiling from Windows to Windows is not supported. You need a
POSIX platform and mingw to build for Windows.
Changing this is probably possible but I do not have the time to care about this.

As a starting point, look at src/mkheader.c .

I will add a category for libgpg-error

D250: 508_07-gen_w32.patch

I guess that problem because gpgrt_lock_t is generates using gen-posix, but
used win32 lock objects (critical sections). I tried to patch generation
using gen-w32 and looks like that generator is unfinished just now. i made
ugly "fix" which will generate gpgrt_lock_t like in posix. patch in attach.
But i worried that alignment should be rechecked and initialization with
GPGRT_LOCK_INITIALIZER

I've contacted jmmv and he wrote:
"This was a long time ago and I don't remember. The newly proposed patch sounds
good though."
So please go ahead with your version.

The patch v10 should now cover all change requests from Werner as documented in
the cover-letter.

However, I am not fully sure about the interface yet: the GCRY_DRBG_REINIT is
now solely limited to normal DRBG use. I do not see how that can be merged to
existing random interfaces.

The CAVS test interface is now isolated to the control value 75 similarly to the
X9.31 testing approach. However, the current approach triggers a compile time
warning about the undefined enum 75.

See [1] in libgcrypt/test/ for a test application that uses the DRBG in normal
mode and in CAVS test mode -- search for gcry_control.

Tested:

• 32 / 64 bit
• CAVS testing on both arches
• brief stess testing by creating 200 MB of data and checking it with ent to see

that the output function is not broken

[1] http://www.chronox.de/drbg/drbg-20140907.tar.bz2

D216: 500_v10-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

Thanks.

re: indent: You mixed prototype and functions and thus by quickly browsing the
source I noticed the prototype - which are correct.

re: API it is a bit hard to check from just the patches. Thus I suggest that I
apply your next patch and then look again at it.

re: reregssion test: We can use a secret API for that so that it is not part of
the stable ABI. See for example tests/fipsdrv.c:init_external_rng_test

Please do not use C99 feature like // and struct init using symbols. I am
willing to fix that, though.

re GPL: will do

re one patch: will do

I will make also the requested code changes. Though, the indentation makes me
wonder. As I am not used to this indentation, I used the help of indent wit the
following command as specified on the GNU home page: indent -nbad -bap -nbc -bbo
-bl -bli2 -bls -ncdb -nce -cp1 -cs -di2 -ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs
-psl -nsc -nsob. Now, what is wrong with the indentation?

Re reusing the API: I am wondering where I do not reuse the API? The normal
usage is via the gcry_randomize function. The external hook is used for:

1. changing the type of DRBG (note, the code implements many random number

generators)

2. allowing the use of the personalization string / additional info string (I

would not know how to use that with gcry_randomize.

3. allow the CAVS testing to be performed.

If you have suggestions on how to cover that using existing APIs, I would be
very much interested in it.

One last thing: Libcrypt is under the LGPLv2+ but your alternative license is
under an unspecified version of the GPL. Can you change the alternative license
to the "GNU Lesser General Public License as published by the Free Software
Foundation; either version 2.1 of the License, or (at your option) any later
version."?

I would also prefer one patch and not a set of patches.

I have alsready pushed the GCRYCTL_DRBG_REINIT constant so that the value is
reserved.

The patch needs some rework: At a first glance gcrypt.h has new strucures using
symbols not from the gcrypt name space (_gcry or gcry prefixes). I noticed
quite some other Linux specific stuff like __u8 instead of unsigned character,
different indentation, and remove of page breaks (^L).

I have not looked at the API but I wonder why you don't re-use the existing
random API. Adding new functions for your RNG is not a good idea - unless there
is a real good reason for it. Exposing internals in the API is a no-go.

D246: 498_0001-asm-Allow-building-x86-and-amd64-using-old-compilers.patch

Please try the attached patch

Changes v9:
drbg_int2byte replaced by drbg_cpu_to_be32 and the use of be_bswap32
and be_bswap64 for converting an integer into a character string.
Besides performance increase, it fixes the conversion on 32 bit machines.

Tested:

• on 64 and 32 bit

• CAVS on both arches

• sanity tests on 32 and 64 bit

D217: 497_v9-0007-User-interface-to-DRBG.patch

D218: 496_v9-0006-DRBG-specific-gcry_control-requests.patch

D219: 495_v9-0005-Function-definitions-for-gcry_control-callbacks.patch

D220: 494_v9-0004-Invoke-DRBG-from-common-libgcrypt-RNG-code.patch

D221: 493_v9-0003-Function-definitions-of-interfaces-for-random.c.patch

D222: 492_v9-0002-Compile-DRBG.patch

D223: 491_v9-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

Synology works with outdated software:

spksrc@spksrc:~/spksrc/cross/libgcrypt$
/home/spksrc/spksrc/toolchains/syno-bromolow/work/x86_64-linux-gnu/bin/x86_64-linux-gnu-as
--versionGNU assembler 2.17
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.

config.log: http://pastebin.com/RRM16ZL4

v8 does not compile on 32 bit

Update of the entire patch set to version 8:
Fix the functions drbg_max_addtl, and drbg_max_requests to not overflow
size_t in 32 bit. Furthermore, the per-DRBG option for maximum requests,
maximum request bits and maximum length of additional information is removed
in favor of a global setting. The change only affects drbg.c

Note: only the patch 0001 is changed compared to version 7 of the patch set.

D224: 489_v8-0007-User-interface-to-DRBG.patch

D225: 488_v8-0006-DRBG-specific-gcry_control-requests.patch

D226: 487_v8-0005-Function-definitions-for-gcry_control-callbacks.patch

D227: 486_v8-0004-Invoke-DRBG-from-common-libgcrypt-RNG-code.patch

D228: 485_v8-0003-Function-definitions-of-interfaces-for-random.c.patch

D229: 484_v8-0002-Compile-DRBG.patch

D230: 483_v8-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

I didn't find anyone.
I've just removed this patch from pkgsrc.
We can come back to this later if someone shows interest and can test it.

Well, it was added as a bugfix for Solaris 9, not NetBSD.
http://gnats.netbsd.org/26815

I'll try finding someone who can provide more input if the patch is still needed
or not.

Thanks. I appreciate that you look at the code.

Given that the code in question is preety old and this is the first problem
report on it, I hesitate to apply the patch as is. You you mind if I make it
netbsd specific?

Any reason why stdin and stdout are re-opened earlier than stderr?
I would use

  if (fstat (STDIN_FILENO, &statbuf) == -1 && errno ==EBADF)
    open ("/dev/null",O_RDONLY);
  if (fstat (STDOUT_FILENO, &statbuf) == -1 && errno ==EBADF)
    open ("/dev/null",O_RDONLY);
  if (fstat (STDERR_FILENO, &statbuf) == -1 && errno ==EBADF)
    open ("/dev/null",O_RDONLY);

right after the "Stuart code" line.

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.

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.

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.

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.

D241: 478_primegen.patch