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

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 :)

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?

Fixed in master. Will be ported to 1.6.

Fixed in master.

Fixed with 1700

Duplicate of T1700

Thanks for looking at this. However, please do not file separate bug reports
for similar problems. This is just too much overhead. Frankly, I 'd would
appreciate that such audit results are send to the mailing list.

The suggested fix is not suitable because this function or its callers returns
an error code and should just do this. An assert is only to be used to make
sure that nothing unexpected happens. You have shown that this may indeed
happen (by using wrong call args or a malloc failure) and thus this needs more
work. Given that such NULL dereference are not a critical security problems,
this won't be fixed for old Libgcrypt versions as 1.5. Instead I will apply a
fix to master (1.7) and backport it to stable (1.6).

D215: 464_elgamal.patch

D214: 463_dsa.patch

D213: 462_sexp.patch

Updated by 1697.

FWIW, I checked my POSIX 2001 standard and it does not define -p. The
GNU manual for uname however has to say:

`-m'
`--machine'

     Print the machine hardware name (sometimes called the hardware
     class or hardware type).

`-p'
`--processor'

Print the processor type (sometimes called the instruction set
architecture or ISA).  Print `unknown' if the kernel does not make
this information easily available, as is the case with Linux
kernels.

Fix has been pushed for 1.6 and master. Thanks,

Thanks for that good description. Fixes pushed to master and 1.6. I can't test
it, though.

Resolved according to freebsd tracker.

Well, on FreeBSD 10 "uname -p" works the same as "uname -m". It is not POSIX
though.

WTF happened to config.guess? Upstream's ChangeLog has these entries:

2011-08-20 Ben Elliston <bje@gnu.org>

• config.guess (*:FreeBSD:*:*): Switch on ${UNAME_PROCESSOR}.
• testsuite/config-guess.data: Remove hard to test FreeBSD cases.

2006-04-26 Bruno Haible <bruno@clisp.org>

	    Ben Elliston  <bje@gnu.org>

• config.guess (amd64:FreeBSD:*:*) Detect as x86_64.
• testsuite/config-guess.data: Add test case.

Thus in 2006 support form and64 was added and in 2011 the faulty
"uname -p" was implemented and test cases removed. I assume that
everyone patched similar to what you suggested. However, the correct
thing is to fix config.guess.

Unfortunately I do not have access to any FreeBSD box right now (the
FreeBSD in the gcc compile farm is offline). Can you do some tests on
several FreeBSD boxes or give me access to a test box?

What are the patches to configure I see in the build log? And why are
the M4 files are patched - they are not used after configure has been
created? I would also like to see the config.rpath to see how it has been
changed.

Feel free to continue by private mail.

No, FreeBSD has amd64 as uname -m value.

That should not be required. Did you explicitly specify host with
configure?

config.guess has this code:

*:FreeBSD:*:*)

UNAME_PROCESSOR=/usr/bin/uname -p
case ${UNAME_PROCESSOR} in

	    amd64)
		echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;

to map "amd64" to "x86_64" and config.sub called with "amd64" also
returns the canonical "x86_64". Thus everything should be fine.

(I think "amd64" would have been the better and easier to type name,
but the GCC developers settled for "x86_64").

D201: 439_patch-configure.diff

By patching configure it's possible to connect the cipher/*-amd64.S to the build.

See attached.

You better take that to ArchLinux. We can't debug the system for you. Of
course I will help fixing the problem if you post your findings to gnupg-devel.

Issue also occurs in 1.6.1.

D191: 426_darwin_ppc.diff

Thanks, it's no problem to wait until 1.6.2. I just tested the patch and it's
working as intended.

Oh no!

I recall that I looked up the commit id this morning but obviously was disturbed
and thus didn't actually complete the cherry-pick. Sorry. I just pushed the
change. We need to wait some time before we can do a 1.6.2.

I attach a patch for 1.6.1.

D187: 422_0001-cipher-Take-care-of-ENABLE_NEON_SUPPORT.patch