The patch is a work for problem somewhere in the PC/SC implementaion. I am also
not sure whether a pthread_cancel for a buggy PC/SC library is a good idea.
Terminating the process seems to be a better solution.

If gpgtools wants to apply this pacth, they might of course do so but I don't
want to apply it upstream in particular not to an older version (2.1 is current).

Done in c238340:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c2383407bba5eefea486464a31e02846124c9da5

I created (1938) a new issue for the extreme slowness of --list-sigs on a
keybox. 1938 is most likely a bug, while 1710 is merely a quickfix for an
algorithmic issue in --list-sigs. However if with keybox “random access to the
keys is now really fast”, maybe it a proper fix could easily be implemented
instead. See also

http://lists.gnupg.org/pipermail/gnupg-devel/2015-February/029541.html

I'm also seeing this extreme delay from gpg --list-sigs 2.1.2 on a large
keyring, particularly when using kbx. It seems likely that there is a bug here.

Pushed.

Give that the macro change is a no-brainer I will do that immediatly. Which
means this bug report can be closed.

Understood - would you like me to fix with automake 1.10, or park this
for a merge post-Jessie ?

automake 1.14 is not yet supported becuase it defaults to the new parallel tests
and automake 1.11 has no way to disable this tests (serial-tests option in 1.14).

After the release of Debian Jessie I plan to migrate to 1.14 and drop support
form earlier automakes.

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."?

There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.

Thank you for the prompt response.

I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?

This has been discussed at gnupg-users at lengths. You need to read the OpenPGP
standard to understand some of the defaults. For the others you may start yet
another disucssion thread at gnupg-users.

re 4) The iteration count used depends on the machine.

Done for 2.0.14 with commit e790671c

Oh well, backporting is easy enough. Commit id f6bd8ed, will go into 1.6.1.

This has meanwhile been fixed in master with commit 9edcf109.
I don't see a reason tobackport it to 1.6.

References:

OpenSSL
http://git.openssl.org/gitweb/?
p=openssl.git;a=blob;f=crypto/ecdsa/ecs_ossl.c;h=adab1f74b41daf6e719ca1fdae1ba81
7085c7802;hb=HEAD#l309

Nettle:
http://git.lysator.liu.se/nettle/nettle/blobs/master/ecc-ecdsa-sign.c#line86
http://git.lysator.liu.se/nettle/nettle/blobs/master/ecc-hash.c

NSS:
https://hg.mozilla.org/projects/nss/file/49360b638350/lib/freebl/ec.c#l746

Tested and works fine with current gnupg and gpgcard.

Thanks.

Inline is an extension to C90 implemented by almost all compilers.
What we do is what the gcc manual suggest for ages:

   This combination of `inline' and `extern' has almost the effect of
   a macro.  The way to use it is to put a function definition in a
   header file with these keywords, and put another copy of the
   definition (lacking `inline' and `extern') in a library file.  The
   definition in the header file will cause most calls to the function
   to be inlined.  If any uses of the function remain, they will refer
   to the single copy in the library.

I don’t know why clang seems to be the only compiler who does not grok
this. Libgcrypt has been compiled on a wide range of compilers
without any problem.

Wait, I see. Clang pretends to be gcc and defines GNUC. Thus
mpi-internal.h includes the inline functions:

  #ifdef __GNUC__
  #include "mpi-inline.h"
  #endif

which is a valid gcc construct. As with some other bug reports; I can
only suggest to fix clang and don't have it define GNUC .

It seems that my patch does actually break gcc... i'm not sure how to handle
this correctly anyway. It seems that the problem is actually unsolvable, and
there's no correct way to mix inline functions and external assembly definitions.

D154: 346_0001-Fix-use-of-inline-to-avoid-multiple-declarations.patch

please explain why this is a problem

Fixed today, thanks.

Fixed in my working copies. Thanks.

D138: 311_0002-doc-gpgsm.tex-Typo-s-full-features-full-featured.patch

Marcus, plase have a look at it.

D122: 280_gpgme-callbacks-example.patch

I've tried to reproduce the fault with 1.2.0 but could not so it seems to be
fixed.
Thanks.

I think that this is probably fixed in the gpgme 1.2.0 release. The following
patch by Werner has a similar effect to the patch provided by the submitter:

will be in 1.4.5 to be released in a few minutes.

Okay, for the development version I implemented a configure option
--disable-O-flag-munging
This is in the SVN trunk, rev 1415.
I believe that is the least intrusive change. Is it important for you; thus
shall I backport it to 1.4.5 which will be released in a few days?

Aihhh. The failure mode depends on the malloc implementation. We are only
shrinking memory and thus some implementations simply return the same pointer.
Obviously not in BSD.

Is there any chance of getting this fixed? The problem is very annoying as it
causes the library to disturb the application using it and I can't think of any
simple workaround for it.
The patch is just three lines so it should be easy to include, right?

Marcus: I recall that you recently changed something in the cancel code - is
that his problem?

D102: 246_gpgme-1.1.8-closefiledescriptor.patch

Is it possible to match at most one occurrence of a pattern without the "-r"
option? ("extended regular expression", a GNU extension unfortunately)

Sure, you are right. OTOH this code is in use by gnupg and libgcrypt for many
years without problems (twofish.c used similar code).

Hmm - I can't explain why this would have affected 1.4.4 but not 1.4.3, but that
is my experience.