I understand.

See my comment on and fix on the mailing lst.

Unfortunately, version 1.15 breaks on the current version of OS X (10.9):

mv -f .deps/libgpg_error_la-posix-thread.Tpo .deps/libgpg_error_la-posix-thread.Plo
estream.c:3501:1: error: conflicting types for '_gpgrt_fseeko'
_gpgrt_fseeko (estream_t stream, gpgrt_off_t offset, int whence)
^
./gpgrt-int.h:108:5: note: previous declaration is here
int _gpgrt_fseeko (gpgrt_stream_t stream, off_t offset, int whence);

^

estream.c:3527:1: error: conflicting types for '_gpgrt_ftello'
_gpgrt_ftello (estream_t stream)
^
./gpgrt-int.h:110:7: note: previous declaration is here
off_t _gpgrt_ftello (gpgrt_stream_t stream);

^

2 errors generated.
make[3]: * [libgpg_error_la-estream.lo] Error 1
make[3]: * Waiting for unfinished jobs....
mv -f .deps/libgpg_error_la-estream-printf.Tpo .deps/libgpg_error_la-estream-printf.Plo
make[3]: Leaving directory
`/opt/local/var/macports/build/_Users_marius_Development_MacPorts_ports_devel_libgpg-
error/libgpg-error/work/libgpg-error-1.15/src'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/opt/local/var/macports/build/_Users_marius_Development_MacPorts_ports_devel_libgpg-
error/libgpg-error/work/libgpg-error-1.15/src'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory
`/opt/local/var/macports/build/_Users_marius_Development_MacPorts_ports_devel_libgpg-
error/libgpg-error/work/libgpg-error-1.15'
make: *** [all] Error 2

Sure; will include GnuPG 2 in future. The instrumentation process is more
difficult becaus of its structure.

It turned out that the other branches are not affected because mpi_invm has
already been fixed in Libgcrypt. Please disregard my comment of trying the
master version only ;-).

Fixed with commit cd53cdb to be released with 1.4.19. Thanks.

commit 3d250d2

A bogus packet which is shorter than announced by the packet header.
There are many ways of creating bogus packets and keep gpg processing data. In
particular compressed data can create arbitrary long output. Fixing this in old
branches creates the risk of regressions.

I will fix that for master, though.

[please do such work on master and not on an old stable branch. It is much
easier to backport stuff than to forward port it.]

I just release 1.15. Tested on Linux, Netbsd and AIX. Let me know if it works
for you.

Please do not distribute 1.14 anymore.

Right, this works for Unix. For Windows it won't work. Due to this report I
also found a more severe problem: fseeko uses off_t and thus we will run into
the usual problems that on Linux x86 we have two ABIs - one with a 64bit off_t
and one with a 32bit off_t. The same thing as with gpgme.

A fix would require an ABI chnage. However, due to the newness of the stream
interface, I think it is fine to view this as a simple bug and release 1.15 with
a fixed API - using a 64 bit type instead of off_t.

Thus please stay tuned for 1.15

D247: 502_patch-src-gpg-error.h.in.diff

After a bit of research I cam up with the same solution, i.e. adding

#include <sys/types.h>

to gpg-error.h.in. See attached diff file.

It has been tested and found to work and committed.

Thanks.

Oh well, the ssize_t problem. Including sys/types.h should help but we would
run into problems on Windows. We had the same problem in GPGME which we fixed
by adding sys/types.h to gpgme.h and use other hacks to make it work with windows.

Are you able to build gpgme?

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.

To use --multifile with files on the command line. Such a use will suddenly
break. This is the same as using grep on a large number of files - only rookies
do that.

Fortuntately g_rand_new is only used by the dbus support and by tests. Thus we
can easily revert to the old state.

FWIW: Changing the semantics of an existing function to suddenly claim
"cryptographically secure" is a questionable move. You can't rely on it and the
name of the function indicates that it is a wrapper around the usual rand
function. If a CSRNG is needed, an approriate function needs to be added.

Retrying the passwd command several times inside "gpg --card-edit" consistently
fails no matter what I do before.
However, using "gpg --change-pin" only fails at most once in a row: the first
time it fails with general after the first key press, then retrying to change
the password succeeds, and subsequent changes succeed immediately and consistently.
But, if I cancel a pin entry, then I have a single failure, then it works (with
--change-pin).
Maybe some kind of buffer isn't flushed somewhere, and the first tries clears
it, but passwd in --card-edit doesn't...

With slightly over 1000 keys in my keyring, it is surprisingly slow to list all
865 sigs on my key:

    $ time gpg --list-sigs --with-colon $keyID >/dev/null
    real    0m22.061s

At first I naively thought the major bottleneck was caused by the trust
calculation, but changing the trust model doesn't seem to help:

    $ time gpg --trust-model=always --list-sigs --with-colon $keyID >/dev/null
    real    0m22.157s

While --fast-list-mode downs the execution time by a factor of 100 (0m0.220s),
the key UIDS are not displayed (which makes it impossible to know on which of
them the signature was added). I didn't benchmark the difference myself but I
don't expect it to be significant, as if I got RFC 4880 right, the UID packets
are being looped over when gpg inspects the signature packets. (OTOH the
primary UID of the signing keys are not printed either when --fast-list-mode is
set, which I can understand as doing so would require costly lookups through
the keyring.)

I wish the user had more fine-grain control on what to skip with
--fast-list-mode.

Thanks!

Guilhem.

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

I was using 2.0.25 at the time. I've just retried, and 2.0.26 indeed fixes this
problem. Thanks for the hint!

Not sure what you mean by "It is not useful for that purpose" what do you mean
by "It" and "that" in this context.

With regard to complaints there are reports about this that have been active
nearly all the time since this was broken by 2.2.0:
https://wald.intevation.org/forum/message.php?msg_id=2569&group_id=11

This thread triggered your initial opening of this issue.

I agree that wildcard / multifile it is not very important. But I think we
should fix it as it is a small annoyance and it worked with gpg 2.1.0. That it
stopped working was due to our switch to mingw-w64 and not due to a decision
made by us to disable this. So I would see this as a Bug.

Some more threads about this:
https://wald.intevation.org/forum/forum.php?thread_id=1119&forum_id=21&group_id=11
https://wald.intevation.org/forum/message.php?msg_id=3404

P.S.
Yes I dislike the message boards too but they are surprisingly active.

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.

It is not useful for that purpose. This is probably the reason why we received
no complaints about it unless someone uses --multifile with filenames. It is
almost always wrong to do this.

This is actually a gnupg problem. What version of GnuPG are you using?
GnuPG 2.0.26 creates the home directory even if gpgsm is used first.

I disagree, all builtin windows tools do globbing so you expect it on the
command line. And as this is default for software that is built with visual
studio and with some versions of mingw it is more likely to see a software that
supports globbing then not.

With regards to quoting problems. I think that users would prefer some problems
instead of just "no". There is no xargs equivalent in Windows by default and so
you have to fall back to really ugly batch scripts that do this in for loops.

Yes one could argue that those users should use a "real shell" on a "real
system" ;-)

Well, it's part of 2.2.2 now, lets see if we get some feedback on this and maybe
for the next release we can revisit the question again if we should enable this
or not.

It would be rather surprising if just one tool does globbing on Windows but all
the otehrs don't do it. It may actually lead to bugs due to broken quoting in
mingw. I recall than many years ago we had a lot of problems with the ever
changing quoting in the globbing implementation.

In any case using globbing with --multifile is not a good idea at all. There is
always a limit on this and thus the proper way of handling this is to use xargs
or whatever the counterpart is on Windows.

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.

Tested this myself again. And I feel comfortable that this is fixed. Still I do
not know why this works now.

Werner can you take a look at the patch I've added for this:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=patches/gnupg2-2.0.26/0001-Enable-wildcard-expansion-with-mingw-w64.patch;h=6c5b9f8b0794cf32ab909c0a340f81377dc3d42f;hb=HEAD

Is this something you would consider including in some form in gnupg or should I
move the patch into the generic gnupg patch directory?

also fixed in 2.0

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.