From mabrand at mabrand.nl  Mon Jun  3 12:46:10 2013
From: mabrand at mabrand.nl (Mark Brand)
Date: Mon, 03 Jun 2013 12:46:10 +0200
Subject: [PATCH] avoid accidental inclusion of old winsock.h
Message-ID: <3281725.hl7lWlDiKa@hitch>

>From 956504b76dc429de2459322bf799534a1171d953 Mon Sep 17 00:00:00 2001
From: Mark Brand <mabrand at mabrand.nl>
Date: Mon, 3 Jun 2013 11:24:12 +0200
Subject: [PATCH] avoid accidental inclusion of old winsock.h

/src/gcrypt.h.in:# include <winsock2.h> implicitly includes
windows.h. Avoid including windows.h explicitly before
winsock2.h, to avoid implicit inclusion of conflicting winsock.h
from windows.h.

diff --git a/random/rndw32.c b/random/rndw32.c
index f8a83b6..d6c8e34 100644
--- a/random/rndw32.c
+++ b/random/rndw32.c
@@ -78,7 +78,6 @@
 #include <stdint.h>
 #endif
 
-#include <windows.h>
 
 
 #include "types.h"
diff --git a/src/ath.h b/src/ath.h
index 6ffa928..e52da11 100644
--- a/src/ath.h
+++ b/src/ath.h
@@ -23,7 +23,6 @@
 #include <config.h>
 
 #ifdef _WIN32
-# include <windows.h>
 #else /* !_WIN32 */
 # ifdef HAVE_SYS_SELECT_H
 #  include <sys/select.h>
diff --git a/tests/benchmark.c b/tests/benchmark.c
index 61badd5..8a9ceee 100644
--- a/tests/benchmark.c
+++ b/tests/benchmark.c
@@ -25,7 +25,6 @@
 #include <time.h>
 #include <stdarg.h>
 #ifdef _WIN32
-#include <windows.h>
 #else
 #include <sys/times.h>
 #endif
-- 
1.8.1.4



From jussi.kivilinna at iki.fi  Mon Jun 10 10:22:06 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Mon, 10 Jun 2013 11:22:06 +0300
Subject: New amd64 implementations...
Message-ID: <51B58CAE.7090603@iki.fi>

Hello,

I have pushed new optimized implementations to 'cipher-amd64-optimizations' branch at 'git.gnupg.org/libgcrypt.git'.

These changes include:
 - AMD64 implementation of blowfish
   + with 4-way parallel implementation for CBC/CFB/CTR-decryption and CTR-encryption.
 - AMD64 implementation of AES
 - AMD64 implementation of twofish
   + with 3-way parallel implementations
 - Detection for new AVX2 instruction set
 - 16-way parallel implementation for Serpent using AVX2
 - 32-way parallel implementation for Camellia using AVX2 and AES-NI
 - Generic optimization for _gcry_burn_stack

-Jussi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 730 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130610/ca38dddc/attachment.sig>

From rick at openfortress.nl  Sat Jun 15 08:44:29 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Sat, 15 Jun 2013 08:44:29 +0200
Subject: What is a "key grip"?
Message-ID: <A8EE226E-5CD0-4736-8F13-8B0F56891C81@openfortress.nl>

Hello,

I'm having trouble understanding the concept of a "key grip", and I cannot find it documented anywhere.  I'd like to generate keys in a GnuPG-friendly manner, making them available through an SCD mechanism.

As I understand it, it's a handle for the private key -- meaning it's not external stuff, but still useful to do well in a key store.  It's a hex-denoted form of a binary key identifier, right?

I wonder if it should be derivable by GnuPG to a certain value (and if so, what is the calculation?) or if it is merely a value produced by the underlying SCD.  In the latter case, I am confused that it is assumed to be 20 binary bytes long.

In short, if I store a public key and want it to be GnuPG-friendly, what should I use as the keygrip?  For instance, do I write down an S-expression and determine it's SHA-1 and use it as the binary handle to the key?


Thanks,
 -Rick

From wk at gnupg.org  Sat Jun 15 22:27:21 2013
From: wk at gnupg.org (Werner Koch)
Date: Sat, 15 Jun 2013 22:27:21 +0200
Subject: What is a "key grip"?
In-Reply-To: <A8EE226E-5CD0-4736-8F13-8B0F56891C81@openfortress.nl> (Rick van
 Rein's message of "Sat, 15 Jun 2013 08:44:29 +0200")
References: <A8EE226E-5CD0-4736-8F13-8B0F56891C81@openfortress.nl>
Message-ID: <87obb7unkm.fsf@vigenere.g10code.de>

On Sat, 15 Jun 2013 08:44, rick at openfortress.nl said:

> I'm having trouble understanding the concept of a "key grip", and I
> cannot find it documented anywhere.  I'd like to generate keys in a

You find the description in Libgcrypt:

 -- Function: unsigned char * gcry_pk_get_keygrip (gcry_sexp_t KEY,
          unsigned char *ARRAY)
     Return the so called "keygrip" which is the SHA-1 hash of the
     public key parameters expressed in a way depended on the
     algorithm.  ARRAY must either provide space for 20 bytes or be
     `NULL'. In the latter case a newly allocated array of that size is
     returned.  On success a pointer to the newly allocated space or to
     ARRAY is returned.  `NULL' is returned to indicate an error which
     is most likely an unknown algorithm or one where a "keygrip" has
     not yet been defined.  The function accepts public or secret keys
     in KEY.

It is a protocol independent way to identify a public key.  pkcs#15 has
a similar concept but the exact details for the Keygrip are defined by
Libgcrypt.


> As I understand it, it's a handle for the private key -- meaning it's
> not external stuff, but still useful to do well in a key store.  It's
> a hex-denoted form

It is used for the public key.  How it is formatted is not defined.

> I wonder if it should be derivable by GnuPG to a certain value (and if so, what is the calculation?) or if it is merely a value produced by the underlying SCD.  In the latter case, I am confused that it is assumed to be 20 binary bytes long.

  gpg2 --with-keygrip -k KEYID


> In short, if I store a public key and want it to be GnuPG-friendly, what should I use as the keygrip?  For instance, do I write down an S-expression and determine it's SHA-1 and use it as the binary handle to the key?

You need to call the above Libgcrypt function (or your own implementation
of it).  gcry_pk_get_keygrip takes an S-expression, but that is just a
part of the API and is not needed to define the keygrip.

If you look at libgcrypt/cipher/rsa.c you will find how we compute it
for RSA:

/* Compute a keygrip.  MD is the hash context which we are going to
   update.  KEYPARAM is an S-expression with the key parameters, this
   is usually a public key but may also be a secret key.  An example
   of such an S-expression is:

      (rsa
        (n #00B...#)
        (e #010001#))

   PKCS-15 says that for RSA only the modulus should be hashed -
   however, it is not clear whether this is meant to use the raw bytes
   (assuming this is an unsigned integer) or whether the DER required
   0 should be prefixed.  We hash the raw bytes.  */

In short for RSA the keygrip is the SHA-1 value of the modulus given as
the unsigned integer with leading zero bytes removed.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From teichm at in.tum.de  Tue Jun 18 08:38:08 2013
From: teichm at in.tum.de (teichm)
Date: Tue, 18 Jun 2013 08:38:08 +0200
Subject: Assertion crash in collectd 5.2.1 / libgcrypt 1.5.2
Message-ID: <6f72d96a18d8b76eeff4aa77ca1dd621@mail.fs.tum.de>

Heyho,

On our collectd 5.2.1 from the Debian Package 5.2.1-1 we encountered an 
assertion crash from libgcrypt11 1.5.2-1 that occurs aproximately once a 
day on random conditions.

I do not know, if collectd is using libgcrypt wrong or if it is a bug 
in libgcrypt.
It seems, ath_install was called with the first argument beeing NULL. 
At least i have no other explanation of why this codepath would be 
reachable.

Since i am also working on my Bachelor's thesis at the moment in which 
I am developing Monkey, a new automated bug reporting system, i 
generated a report for your convenience:
https://gnunet.org/monkey/examples/collectd-01/scrutinizer.html

If you are interested in the Debugging System, you can find more 
information on:
https://gnunet.org/monkey/

Also i have a survey (or rather ?experiment?) running, in which you 
will get three different crash reports (stack trace, stack trace + *life 
gdb session* on a core dump and of course one generated from Monkey) and 
try to find the respective bug.
You can participate here:
https://gnunet.org/monkey/survey/index.php/943594?lang=en

--Markus



From testtest_2005 at ukr.net  Wed Jun 19 19:24:05 2013
From: testtest_2005 at ukr.net (Vasiliy)
Date: Wed, 19 Jun 2013 19:24:05 +0200
Subject: Fwd: New amd64 implementations?
In-Reply-To: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
Message-ID: <CAHYyVz6PzTze16BNxH0CMNWE04P9q8+KnsmCYxxtzb9M09cO5A@mail.gmail.com>

I forgot to mention a platform: it is Cygwin 64-bit. It is my
understanding, it may need a different set of instructions.


From testtest_2005 at ukr.net  Wed Jun 19 18:45:49 2013
From: testtest_2005 at ukr.net (Vasiliy)
Date: Wed, 19 Jun 2013 18:45:49 +0200
Subject: New amd64 implementations?
Message-ID: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>

I've just tried to compile cast5-amd64.S, and it does not, however, it
does compile with -m32 option. Are you sure you've pushed up the
64-bit code?...

$ gcc -m64 -DHAVE_CONFIG_H -I.
-I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher
-I.. -I../src -I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/src
-ggdb -march=native -mtune=native -Ofast -fomit-frame-pointer -pipe
-fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/build=/usr/src/debug/libgcrypt-1.6.0-1
-fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0=/usr/src/debug/libgcrypt-1.6.0-1
-MT cast5-amd64.lo -MD -MP -MF .deps/cast5-amd64.Tpo -c
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S
 -DDLL_EXPORT -DPIC -o .libs/cast5-amd64.o
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:
Assembler messages:
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183:
Warning: .type pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219:
Warning: .size pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223:
Warning: .type pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259:
Warning: .size pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362:
Warning: .type pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387:
Warning: .size pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390:
Warning: .type pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417:
Warning: .size pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421:
Warning: .type pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475:
Warning: .size pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479:
Warning: .type pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529:
Warning: .size pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533:
Warning: .type pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533:
Error: junk at end of line, first unrecognized character is `_'
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584:
Warning: .size pseudo-op used outside of .def/.endef ignored.
/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584:
Error: junk at end of line, first unrecognized character is `_'


From jussi.kivilinna at iki.fi  Thu Jun 20 01:15:07 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Thu, 20 Jun 2013 02:15:07 +0300
Subject: Fwd: New amd64 implementations?
In-Reply-To: <CAHYyVz6PzTze16BNxH0CMNWE04P9q8+KnsmCYxxtzb9M09cO5A@mail.gmail.com>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <CAHYyVz6PzTze16BNxH0CMNWE04P9q8+KnsmCYxxtzb9M09cO5A@mail.gmail.com>
Message-ID: <51C23B7B.1000802@iki.fi>

On 19.06.2013 20:24, Vasiliy wrote:
> I forgot to mention a platform: it is Cygwin 64-bit. It is my
> understanding, it may need a different set of instructions.
> 

Ok. These implementations need additional checks for different platforms. I'll look in to it next week.

-Jussi

> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 



From jussi.kivilinna at iki.fi  Thu Jun 20 14:14:28 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Thu, 20 Jun 2013 15:14:28 +0300
Subject: New amd64 implementations?
In-Reply-To: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
Message-ID: <51C2F224.7000609@iki.fi>

Hello,

I have attached patch that is for the cipher-amd64-optimizations branch. It disables AMD64
assembly implementations if platform assembler is found to be incompatible with those
implementations.

Adding cygwin64/mingw64 support for these optimizations would require some extra work to
handle the different calling convention and I don't have licence for 64-bit Windows, so
I cannot easily do this work.

-Jussi

On 19.06.2013 19:45, Vasiliy wrote:
> I've just tried to compile cast5-amd64.S, and it does not, however, it
> does compile with -m32 option. Are you sure you've pushed up the
> 64-bit code?...
> 
> $ gcc -m64 -DHAVE_CONFIG_H -I.
> -I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher
> -I.. -I../src -I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/src
> -ggdb -march=native -mtune=native -Ofast -fomit-frame-pointer -pipe
> -fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/build=/usr/src/debug/libgcrypt-1.6.0-1
> -fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0=/usr/src/debug/libgcrypt-1.6.0-1
> -MT cast5-amd64.lo -MD -MP -MF .deps/cast5-amd64.Tpo -c
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S
>  -DDLL_EXPORT -DPIC -o .libs/cast5-amd64.o
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:
> Assembler messages:
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183:
> Warning: .type pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219:
> Warning: .size pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223:
> Warning: .type pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259:
> Warning: .size pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362:
> Warning: .type pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387:
> Warning: .size pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390:
> Warning: .type pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417:
> Warning: .size pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421:
> Warning: .type pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475:
> Warning: .size pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479:
> Warning: .type pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529:
> Warning: .size pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533:
> Warning: .type pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533:
> Error: junk at end of line, first unrecognized character is `_'
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584:
> Warning: .size pseudo-op used outside of .def/.endef ignored.
> /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584:
> Error: junk at end of line, first unrecognized character is `_'
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 06-add-check-for-assembler-compatibility.patch
Type: text/x-patch
Size: 9584 bytes
Desc: not available
URL: </pipermail/attachments/20130620/2807b684/attachment.bin>

From testtest_2005 at ukr.net  Thu Jun 20 14:26:54 2013
From: testtest_2005 at ukr.net (Vasiliy)
Date: Thu, 20 Jun 2013 14:26:54 +0200
Subject: New amd64 implementations?
In-Reply-To: <51C2F224.7000609@iki.fi>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
Message-ID: <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>

Thank you, Jussi.

If me could be of any help, you're welcome. Meanwhile, it's possible
to test a 64-bit assembler code yet on 32-bit Windows with Cygwin (aka
32-bit), with bundled cross compiler 'x86_64-pc-cygwin-gcc' or by
feeding '-m64' option to a 32-bit 'gcc'.

Kind regards,
Vasiliy

On Thu, Jun 20, 2013 at 2:14 PM, Jussi Kivilinna wrote:
> Hello,
>
> I have attached patch that is for the cipher-amd64-optimizations branch. It disables AMD64
> assembly implementations if platform assembler is found to be incompatible with those
> implementations.
>
> Adding cygwin64/mingw64 support for these optimizations would require some extra work to
> handle the different calling convention and I don't have licence for 64-bit Windows, so
> I cannot easily do this work.
>
> -Jussi
>
> On 19.06.2013 19:45, Vasiliy wrote:


From testtest_2005 at ukr.net  Thu Jun 20 19:47:01 2013
From: testtest_2005 at ukr.net (Vasiliy)
Date: Thu, 20 Jun 2013 19:47:01 +0200
Subject: Fwd: gpgsm with elliptic curve algo (Re: SHAxxxWithECDSA)
Message-ID: <CAHYyVz5Vmx--Z2SK5bcdc=dMfUZLaGhnmhRqae1HOmXjtZ4-tg@mail.gmail.com>

Could it be possible to know, how the following error has been handled?:
It appears while importing Thawte certificates bundle.

Seiji Ariga ariga at khaotic.net
Thu May 17 15:40:47 CEST 2012

Hi.

On Thu, 17 May 2012 10:26:20 +0200,
Werner Koch <wk at gnupg.org> wrote,

> > libgcrypt does not support, say, SHA384WithECDSA (*1) ? (OID is
> > 1.2.840.10045.4.3.3)
> Please try adding this OID to libgcrypt/cipher/sha512.c,
> oid_spec_sha384.

gpgpsm stopped showing "unknown hash algorithm". :-)

Now it's producing different error.
----
$ gpgsm --debug-level guru --status-fd 1 --import cert.pem
gpgsm: enabled debug flags: x509 mpi crypto memory cache memstat hashing assuan
gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 35 3A 65
63 64 73 61 28 31 3A 72 34 38 3A 66 21 0C 18 26 60 5A 38 7B 56 42 E0
A7 FC 36 84 51 91 20 2C 76 4D 43 3D C4 1D 84 23 D0 AC D6 7C 35 06 CE
CD 69 BD 90 0D DB 6C 48 42 1D 0E AA 42 29 28 31 3A 73 34 39 3A 00 9C
3D 48 39 23 39 58 1A 15 12 59 6A 9E EF D5 59 B2 1D 52 2C 99 71 CD C7
29 DF 1B 2A 61 7B 71 D1 DE F3 C0 E5 0D 3A 4A AA 2D A7 D8 86 2A DD 2E
10 29 29 28 34 3A 68 61 73 68 36 3A 73 68 61 33 38 34 29 29
gpgsm: DBG: encoded hash: 28 AC 5A D9 30 27 8C BD 27 6E ED 75 21 4D BA
04 EC 8B 1E 19 E6 3E 30 32 4F A1 BD A0 E9 E8 3B F8 E0 78 6E B8 79 2B
E4 A7 5B 20 A6 93 B9 F6 21 EF
gpgsm: DBG: gcry_pk_verify: Conflicting use
gpgsm: self-signed certificate has a BAD signature: Conflicting use
gpgsm: DBG: BEGIN Certificate `self-signing cert':
gpgsm: DBG:      serial: 2F80FE238C0E220F486712289187ACB3
gpgsm: DBG:   notBefore: 2007-11-05 00:00:00
gpgsm: DBG:    notAfter: 2038-01-18 23:59:59
gpgsm: DBG:      issuer: CN=VeriSign Class 3 Public Primary
Certification Authority - G4,OU=(c) 2007 VeriSign\, Inc. - For
authorized use only,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US
gpgsm: DBG:     subject: CN=VeriSign Class 3 Public Primary
Certification Authority - G4,OU=(c) 2007 VeriSign\, Inc. - For
authorized use only,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US
gpgsm: DBG:   hash algo: 1.2.840.10045.4.3.3
gpgsm: DBG:   SHA1 Fingerprint:
22:D5:D8:DF:8F:02:31:D1:8D:F7:9D:B7:CF:8A:2D:64:C9:3F:6C:3A
gpgsm: DBG: END Certificate
gpgsm: basic certificate checks failed - not imported
[GNUPG:] IMPORT_PROBLEM 1 22D5D8DF8F0231D18DF79DB7CF8A2D64C93F6C3A
gpgsm: total number processed: 1
gpgsm:           not imported: 1
[GNUPG:] IMPORT_RES 1 0 0 0 0 0 0 0 0 0 0 0 0 1
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 0/16384 bytes in 0 blocks
----

I guess this is because gcry_pk_verify() fails due to "pubkey algo
ECDH != signature algo ECDSA" in gpgsm_check_cert_sig().

src/gcrypt.h
----
enum gcry_pk_algos
  {
    [...]
    GCRY_PK_ECDSA = 301,
    GCRY_PK_ECDH  = 302
  };
----

// Seiji Ariga


From testtest_2005 at ukr.net  Thu Jun 20 21:05:13 2013
From: testtest_2005 at ukr.net (Vasiliy)
Date: Thu, 20 Jun 2013 21:05:13 +0200
Subject: FYI: Thawte and Siemens unsupported inquiries
Message-ID: <CAHYyVz6QrNDKUEeu3G_vep+862jFwdbJcOB3jWARQsXj=2EkRQ@mail.gmail.com>

Source: https://www.siemens.com/corp/en/index/digital_id.htm
and Thawte bundled certificates, plus one not found in there.

gpgsm --call-dirmngr loadcrl $HOME/ThawtePersonalFreemailIssuingCA.crl
...
gpgsm: unsupported inquiry 'ISTRUSTED E61883AE84CAC1C1CD52ADE8E9252B45A64FB7E2'
...

Siemens CRL's:
gpgsm: unsupported inquiry 'SENDCERT_SKI <stripped>


From jussi.kivilinna at iki.fi  Tue Jun 25 07:47:15 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 25 Jun 2013 08:47:15 +0300
Subject: New amd64 implementations?
In-Reply-To: <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
Message-ID: <51C92EE3.1060401@iki.fi>

On 20.06.2013 15:26, Vasiliy wrote:
> Thank you, Jussi.
> 
> If me could be of any help, you're welcome. Meanwhile, it's possible
> to test a 64-bit assembler code yet on 32-bit Windows with Cygwin (aka
> 32-bit), with bundled cross compiler 'x86_64-pc-cygwin-gcc' or by
> feeding '-m64' option to a 32-bit 'gcc'.

I managed to get mingw64 build of libgcrypt to work on linux. To point that even
'make check' works, thanks to wine.

Basically I added the autogen.sh mingw64 changes that appeared in libgpg-error and
worked my way through all the issues that rose (added MS ABI => SysV ABI wrapper
code for mpi&cipher assembly code, and pile of other changes).

-Jussi

> 
> Kind regards,
> Vasiliy
> 
> On Thu, Jun 20, 2013 at 2:14 PM, Jussi Kivilinna wrote:
>> Hello,
>>
>> I have attached patch that is for the cipher-amd64-optimizations branch. It disables AMD64
>> assembly implementations if platform assembler is found to be incompatible with those
>> implementations.
>>
>> Adding cygwin64/mingw64 support for these optimizations would require some extra work to
>> handle the different calling convention and I don't have licence for 64-bit Windows, so
>> I cannot easily do this work.
>>
>> -Jussi
>>
>> On 19.06.2013 19:45, Vasiliy wrote:
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 



From jussi.kivilinna at iki.fi  Tue Jun 25 07:48:26 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 25 Jun 2013 08:48:26 +0300
Subject: New amd64 implementations...
In-Reply-To: <51B58CAE.7090603@iki.fi>
References: <51B58CAE.7090603@iki.fi>
Message-ID: <51C92F2A.6020704@iki.fi>

On 10.06.2013 11:22, Jussi Kivilinna wrote:
> Hello,
> 
> I have pushed new optimized implementations to 'cipher-amd64-optimizations' branch at 'git.gnupg.org/libgcrypt.git'.

It is ok, if I push 'cipher-amd64-optimizations' to master?

-Jussi

> 
> These changes include:
>  - AMD64 implementation of blowfish
>    + with 4-way parallel implementation for CBC/CFB/CTR-decryption and CTR-encryption.
>  - AMD64 implementation of AES
>  - AMD64 implementation of twofish
>    + with 3-way parallel implementations
>  - Detection for new AVX2 instruction set
>  - 16-way parallel implementation for Serpent using AVX2
>  - 32-way parallel implementation for Camellia using AVX2 and AES-NI
>  - Generic optimization for _gcry_burn_stack
> 
> -Jussi
> 
> 
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 



From wk at gnupg.org  Tue Jun 25 10:04:56 2013
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Jun 2013 10:04:56 +0200
Subject: New amd64 implementations?
In-Reply-To: <51C92EE3.1060401@iki.fi> (Jussi Kivilinna's message of "Tue, 25
 Jun 2013 08:47:15 +0300")
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi>
Message-ID: <87r4fqmx93.fsf@vigenere.g10code.de>

On Tue, 25 Jun 2013 07:47, jussi.kivilinna at iki.fi said:

> Basically I added the autogen.sh mingw64 changes that appeared in libgpg-error and

That is the right way.

Remember not to use any build done for w64.  The RNG has not been
checked for correctness - in fact it is unlikely that it is okay.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Tue Jun 25 10:16:47 2013
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Jun 2013 10:16:47 +0200
Subject: New amd64 implementations...
In-Reply-To: <51C92F2A.6020704@iki.fi> (Jussi Kivilinna's message of "Tue, 25
 Jun 2013 08:48:26 +0300")
References: <51B58CAE.7090603@iki.fi> <51C92F2A.6020704@iki.fi>
Message-ID: <87mwqemwpc.fsf@vigenere.g10code.de>

On Tue, 25 Jun 2013 07:48, jussi.kivilinna at iki.fi said:

> It is ok, if I push 'cipher-amd64-optimizations' to master?

Please do that.  More people will test it this way.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From jussi.kivilinna at iki.fi  Wed Jun 26 12:38:24 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Wed, 26 Jun 2013 13:38:24 +0300
Subject: New amd64 implementations?
In-Reply-To: <87r4fqmx93.fsf@vigenere.g10code.de>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
Message-ID: <51CAC4A0.4090304@iki.fi>

On 25.06.2013 11:04, Werner Koch wrote:
> On Tue, 25 Jun 2013 07:47, jussi.kivilinna at iki.fi said:
> 
>> Basically I added the autogen.sh mingw64 changes that appeared in libgpg-error and
> 
> That is the right way.

Is it ok, if I make new branch for mingw64 support work?

> 
> Remember not to use any build done for w64.  The RNG has not been
> checked for correctness - in fact it is unlikely that it is okay.

What kind of problems should be checked for?

Microsoft appears to have made transition from WIN32 to WIN64 easy; the size of 'long' remains at 4 bytes and type sizes in Win API appear to remain mostly the same with exception of pointer
types (HANDLE, HWIN, etc) and pointer sized integers.

Some API functions appear to be changed, most notably GetProcessWorkingSetSize which now takes two SIZE_T* arguments, instead of two DWORD*.

-Jussi

> 
> 
> Shalom-Salam,
> 
>    Werner
> 



From funman at videolan.org  Wed Jun 26 17:52:27 2013
From: funman at videolan.org (=?ISO-8859-1?Q?Rafa=EBl_Carr=E9?=)
Date: Wed, 26 Jun 2013 17:52:27 +0200
Subject: New amd64 implementations?
In-Reply-To: <51CAC4A0.4090304@iki.fi>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
 <51CAC4A0.4090304@iki.fi>
Message-ID: <51CB0E3B.7090304@videolan.org>

Hello,

Le 26/06/2013 12:38, Jussi Kivilinna a ?crit :

> Is it ok, if I make new branch for mingw64 support work?

Small nitpicking here, the name is "mingw-w64".

Thanks,


From wk at gnupg.org  Wed Jun 26 19:15:34 2013
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Jun 2013 19:15:34 +0200
Subject: New amd64 implementations?
In-Reply-To: <51CAC4A0.4090304@iki.fi> (Jussi Kivilinna's message of "Wed, 26
 Jun 2013 13:38:24 +0300")
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
 <51CAC4A0.4090304@iki.fi>
Message-ID: <87bo6sg5e1.fsf@vigenere.g10code.de>

On Wed, 26 Jun 2013 12:38, jussi.kivilinna at iki.fi said:

> Is it ok, if I make new branch for mingw64 support work?

No, that is not needed.

> Microsoft appears to have made transition from WIN32 to WIN64 easy; the size of 'long' remains at 4 bytes and type sizes in Win API appear to remain mostly the same with exception of pointer
> types (HANDLE, HWIN, etc) and pointer sized integers.

We need to reevaluate the entire rndw32.c.  In fact a rndw64.c should be
written.  All other things will be simple to fix.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From jussi.kivilinna at iki.fi  Wed Jun 26 20:24:03 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Wed, 26 Jun 2013 21:24:03 +0300
Subject: New amd64 implementations?
In-Reply-To: <51CB0E3B.7090304@videolan.org>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
 <51CAC4A0.4090304@iki.fi> <51CB0E3B.7090304@videolan.org>
Message-ID: <51CB31C3.9000105@iki.fi>

On 26.06.2013 18:52, Rafa?l Carr? wrote:
> Hello,
> 
> Le 26/06/2013 12:38, Jussi Kivilinna a ?crit :
> 
>> Is it ok, if I make new branch for mingw64 support work?
> 
> Small nitpicking here, the name is "mingw-w64".

Ah, ok.

-Jussi

> 
> Thanks,
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 



From wk at gnupg.org  Wed Jun 26 22:57:24 2013
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Jun 2013 22:57:24 +0200
Subject: New amd64 implementations?
In-Reply-To: <51CB0E3B.7090304@videolan.org> (=?utf-8?Q?=22Rafa=C3=ABl_Car?=
 =?utf-8?Q?r=C3=A9=22's?= message of
 "Wed, 26 Jun 2013 17:52:27 +0200")
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
 <51CAC4A0.4090304@iki.fi> <51CB0E3B.7090304@videolan.org>
Message-ID: <877ghgfv4b.fsf@vigenere.g10code.de>

On Wed, 26 Jun 2013 17:52, funman at videolan.org said:

> Small nitpicking here, the name is "mingw-w64".

Which however conflicts with the CPU-VENDOR-OS triplet ;-).  A 64 bit
Windows is a still a Win32 based Windows NT OS where only the CPU is
different.  Thus it should be something amd64-mingw-w32 or
x86_64-mingw-winnt and the former Alpha version would have had a
alpha-mingw-w32 triplet.

I have understood why this 4th variant of the mingw toolchain uses a
name which so easy leads to misunderstandings.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From funman at videolan.org  Wed Jun 26 23:10:59 2013
From: funman at videolan.org (=?ISO-8859-1?Q?Rafa=EBl_Carr=E9?=)
Date: Wed, 26 Jun 2013 23:10:59 +0200
Subject: New amd64 implementations?
In-Reply-To: <877ghgfv4b.fsf@vigenere.g10code.de>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
 <51CAC4A0.4090304@iki.fi> <51CB0E3B.7090304@videolan.org>
 <877ghgfv4b.fsf@vigenere.g10code.de>
Message-ID: <51CB58E3.3070404@videolan.org>

Le 26/06/2013 22:57, Werner Koch a ?crit :
> On Wed, 26 Jun 2013 17:52, funman at videolan.org said:
> 
>> Small nitpicking here, the name is "mingw-w64".
> 
> Which however conflicts with the CPU-VENDOR-OS triplet ;-).  A 64 bit
> Windows is a still a Win32 based Windows NT OS where only the CPU is
> different.  Thus it should be something amd64-mingw-w32 or
> x86_64-mingw-winnt and the former Alpha version would have had a
> alpha-mingw-w32 triplet.

The gcc triplet is actually x86_64-w64-mingw32, although the project
name for headers/libraries is mingw-w64.
(See http://mingw-w64.sourceforge.net/)

> I have understood why this 4th variant of the mingw toolchain uses a
> name which so easy leads to misunderstandings.

Indeed it's very confusing :)

> Salam-Shalom,
> 
>    Werner


From jussi.kivilinna at iki.fi  Thu Jun 27 16:33:12 2013
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Thu, 27 Jun 2013 17:33:12 +0300
Subject: New amd64 implementations?
In-Reply-To: <87bo6sg5e1.fsf@vigenere.g10code.de>
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
 <51CAC4A0.4090304@iki.fi> <87bo6sg5e1.fsf@vigenere.g10code.de>
Message-ID: <51CC4D28.7060204@iki.fi>

On 26.06.2013 20:15, Werner Koch wrote:
> On Wed, 26 Jun 2013 12:38, jussi.kivilinna at iki.fi said:
> 
>> Is it ok, if I make new branch for mingw64 support work?
> 
> No, that is not needed.
> 
>> Microsoft appears to have made transition from WIN32 to WIN64 easy; the size of 'long' remains at 4 bytes and type sizes in Win API appear to remain mostly the same with exception of pointer
>> types (HANDLE, HWIN, etc) and pointer sized integers.
> 
> We need to reevaluate the entire rndw32.c.  In fact a rndw64.c should be
> written.  All other things will be simple to fix.
> 

Would it make sense to re-evaluate rndw32.c for current Windows versions (32/64bit) and drop support for Windows versions that have reached end of life?

As I understand it, the CryptGenRandom function is supported by all current Windows and is the '/dev/urandom' of WIN32.

-Jussi

> 
> Shalom-Salam,
> 
>    Werner
> 



From wk at gnupg.org  Thu Jun 27 20:21:57 2013
From: wk at gnupg.org (Werner Koch)
Date: Thu, 27 Jun 2013 20:21:57 +0200
Subject: New amd64 implementations?
In-Reply-To: <51CC4D28.7060204@iki.fi> (Jussi Kivilinna's message of "Thu, 27
 Jun 2013 17:33:12 +0300")
References: <CAHYyVz5np3Up=Oty969aCdX-VG+1hO5DEuEbC5cSrtWyHwPqPA@mail.gmail.com>
 <51C2F224.7000609@iki.fi>
 <CAHYyVz5M6jH=UjihLVUw1Qm=6E3RdBM-q84U8eNM5gJJf2EKow@mail.gmail.com>
 <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de>
 <51CAC4A0.4090304@iki.fi> <87bo6sg5e1.fsf@vigenere.g10code.de>
 <51CC4D28.7060204@iki.fi>
Message-ID: <87vc4zct2y.fsf@vigenere.g10code.de>

On Thu, 27 Jun 2013 16:33, jussi.kivilinna at iki.fi said:

> Would it make sense to re-evaluate rndw32.c for current Windows versions (32/64bit) and drop support for Windows versions that have reached end of life?

Better don't touch it ;-)  IIRC, I already remove some old code.

> As I understand it, the CryptGenRandom function is supported by all current Windows and is the '/dev/urandom' of WIN32.

I wouldn't trust CryptGenRandom.  It is used only as one entropy source.

What should really be done is to compare the changes Peter did in
Cryptlib and port them back to Libgcrypt. 


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From testtest_2005 at ukr.net  Fri Jun 28 21:20:53 2013
From: testtest_2005 at ukr.net (Vasiliy)
Date: Fri, 28 Jun 2013 21:20:53 +0200
Subject: 64-bit: some compilation warnings (gcc 4.8.1, Cygwin64)
Message-ID: <CAHYyVz6N8EH73k_tvT5Fg-1htQY23vs8y0gUfKAqT5Tn+EKGWg@mail.gmail.com>

typos (apdu.c, pcsc-wrapper.c): unsinged -> unsigned
also:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:
In function ?pcsc_send_apdu_direct?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1046:35:
warning: unused parameter ?pininfo? [-Wunused-parameter]
                        pininfo_t *pininfo)
                                   ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:
In function ?connect_pcsc_card?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26:
warning: passing argument 4 of ?pcsc_status? from incompatible pointer
type [enabled by default]
                          reader_table[slot].atr, &atrlen);
                          ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26:
note: expected ?pcsc_dword_t *? but argument is of type ?long int *?
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26:
warning: passing argument 5 of ?pcsc_status? from incompatible pointer
type [enabled by default]
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26:
note: expected ?pcsc_dword_t *? but argument is of type ?long int *?
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1494:20:
warning: format ?%lu? expects argument of type ?long unsigned int?,
but argument 4 has type ?pcsc_dword_t? [-Wformat=]
                    pcsc_error_string (err), err, readerlen);
                    ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:
In function ?open_pcsc_reader_direct?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1681:25:
warning: variable ?listlen? set but not used
[-Wunused-but-set-variable]
   pcsc_dword_t nreader, listlen;
                         ^
...
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c:
In function ?do_change_pin?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c:1250:9:
warning: ?pwid? may be used uninitialized in this function
[-Wmaybe-uninitialized]
     err = iso7816_change_reference_data (app->slot, pwid,
         ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c:
In function ?do_check_pin?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c:1279:3:
warning: ?pwid? may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return verify_pin (app, pwid, desc, pincb, pincb_arg);
   ^
...
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/g13/mount.c:
In function ?g13_mount_container?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/g13/mount.c:161:10:
warning: ?headerlen? may be used uninitialized in this function
[-Wmaybe-uninitialized]
   msglen = headerlen - 32;
          ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/g13/mount.c:142:10:
note: ?headerlen? was declared here
   size_t headerlen, msglen;
          ^
...
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:
In function ?pid_suffix_callback?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:542:3:
warning: passing argument 1 of ?pthread_getspecific? makes pointer
from integer without a cast [enabled by default]
   value.aptr = npth_getspecific (my_tlskey_current_fd);
   ^
In file included from /usr/include/npth.h:61:0,
                 from
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43:
/usr/include/pthread.h:145:7: note: expected ?pthread_key_t? but
argument is of type ?int?
 void *pthread_getspecific (pthread_key_t);
       ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:
In function ?main?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:651:3:
warning: passing argument 1 of ?pthread_key_create? from incompatible
pointer type [enabled by default]
   if (npth_key_create (&my_tlskey_current_fd, NULL) == 0)
   ^
In file included from /usr/include/npth.h:61:0,
                 from
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43:
/usr/include/pthread.h:147:5: note: expected ?struct __pthread_key_t
**? but argument is of type ?int *?
 int pthread_key_create (pthread_key_t *, void (*)(void *));
     ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:652:5:
warning: passing argument 1 of ?pthread_setspecific? makes pointer
from integer without a cast [enabled by default]
     if (npth_setspecific (my_tlskey_current_fd, NULL) == 0)
     ^
In file included from /usr/include/npth.h:61:0,
                 from
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43:
/usr/include/pthread.h:202:5: note: expected ?pthread_key_t? but
argument is of type ?int?
 int pthread_setspecific (pthread_key_t, const void *);
     ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:
In function ?start_connection_thread?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:1714:3:
warning: passing argument 1 of ?pthread_setspecific? makes pointer
from integer without a cast [enabled by default]
   npth_setspecific (my_tlskey_current_fd, argval.aptr);
   ^
In file included from /usr/include/npth.h:61:0,
                 from
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43:
/usr/include/pthread.h:202:5: note: expected ?pthread_key_t? but
argument is of type ?int?
 int pthread_setspecific (pthread_key_t, const void *);
     ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:1729:3:
warning: passing argument 1 of ?pthread_setspecific? makes pointer
from integer without a cast [enabled by default]
   npth_setspecific (my_tlskey_current_fd, argval.aptr);
   ^
In file included from /usr/include/npth.h:61:0,
                 from
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43:
/usr/include/pthread.h:202:5: note: expected ?pthread_key_t? but
argument is of type ?int?
 int pthread_setspecific (pthread_key_t, const void *);
     ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:
In function ?main?:
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:148:11:
warning: ?fields[3]? may be used uninitialized in this function
[-Wmaybe-uninitialized]
       err = gcry_mpi_scan (&mpi, GCRYMPI_FMT_HEX, fields[3], 0, NULL);
           ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:85:13:
note: ?fields[3]? was declared here
       char *fields[6];
             ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:141:9:
warning: ?fields[1]? may be used uninitialized in this function
[-Wmaybe-uninitialized]
       i = atoi (fields[1]);
         ^
/usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:85:13:
note: ?fields[1]? was declared here
       char *fields[6];
             ^


From testtest_2005 at ukr.net  Sat Jun 29 09:37:04 2013
From: testtest_2005 at ukr.net (Vasiliy)
Date: Sat, 29 Jun 2013 09:37:04 +0200
Subject: could not create a keypair / sign a single file
Message-ID: <CAHYyVz4Tpf4tdy0+L7dLSQL2g9_SiZ8Ay+ZFjtEJh9mQzOp9wQ@mail.gmail.com>

Dear GNUPG Team,

I couldn't get a detachable signature with the existing/imported key
which doesn't make a use of CRL's, neither could I create a new
keypair with the latest gpgsm and libraries built on my 64-bit
machine. What am I doing wrong?

Best regards,
Vasiliy

$ gpgsm --detach-sign --disable-crl-checks --verbose
libgcrypt-1.6.0.tar.bz2 > libgcrypt-1.6.0.tar.bz2.sig
gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION!
gpgsm: It is only intended for test purposes and should NOT be
gpgsm: used in a production environment or with production keys!
gpgsm: enabled debug flags: assuan
gpgsm: certificate is good
gpgsm: root certificate is good
gpgsm: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpgsm: waiting for the agent to come up ... (5s)
gpgsm: waiting for the agent to come up ... (4s)
gpgsm: DBG: chan_4 <- OK Pleased to meet you, process 9724
gpgsm: connection to agent established
gpgsm: DBG: chan_4 -> RESET
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION ttyname=/dev/pty5
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION ttytype=xterm
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION display=:0.0
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION xauthority=~/.Xauthority
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION lc-ctype=en_US.UTF-8
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION lc-messages=en_US.UTF-8
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION allow-pinentry-notify
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> ISTRUSTED FB7EAD4851BE76AF04486BA4738A744BFB50DE86
gpgsm: DBG: chan_4 <- ERR 67108961 Line too long <GPG Agent>
gpgsm: checking the trust list failed: Line too long
gpgsm: validation model used: shell
gpgsm: error creating signature: Line too long <GPG Agent>
secmem usage: 0/65536 bytes in 0 blocks
...
configure: checking for libraries
checking for gpg-error-config... (cached) /usr/bin/gpg-error-config
checking for GPG Error - version >= 1.11... yes (1.12-beta6)
checking for libgcrypt-config... (cached) /usr/bin/libgcrypt-config
checking for LIBGCRYPT - version >= 1.5.0... yes (1.6.0-beta145)
checking LIBGCRYPT API version... okay
checking for libassuan-config... (cached) /usr/bin/libassuan-config
checking for LIBASSUAN - version >= 2.1.0... yes (2.1.0)
checking LIBASSUAN API version... okay
checking for ksba-config... (cached) /usr/bin/ksba-config
checking for KSBA - version >= 1.2.0... yes (1.3.1-beta3)
checking KSBA API version... okay
checking for usb_bulk_write in -lusb... (cached) no
checking for usb_create_match... (cached) no
checking for library containing dlopen... (cached) none required
checking for encfs... (cached) /usr/bin/encfs
checking for fusermount... (cached) /usr/bin/fusermount
checking for openpty in -lutil... (cached) yes
checking for shred... (cached) /usr/bin/shred
checking for npth-config... (cached) /usr/bin/npth-config
checking for NPTH - version >= 0.91... yes (0.91)
checking NPTH API version... okay
...
checking for iconv declaration... (cached)
         extern size_t iconv (iconv_t cd, char * *inbuf, size_t
*inbytesleft, char * *outbuf, size_t *outbytesleft);
...
        GnuPG v2.1.0-beta220 has been configured as follows:

        Revision:  82c25e6  (33474)
        Platform:  Cygwin (x86_64-unknown-cygwin)

        OpenPGP:   yes
        S/MIME:    yes
        Agent:     yes
        Smartcard: yes (without internal CCID driver)
        G13:       yes
        Dirmngr:   yes
        Gpgtar:    yes

        Protect tool:      (default)
        LDAP wrapper:      (default)
        Default agent:     (default)
        Default pinentry:  /usr/bin/pinentry-gtk-2
        Default scdaemon:  (default)
        Default dirmngr:   (default)

        Use standard socket: yes
        Dirmngr auto start:  yes
...
$ gpgsm --gen-key --verbose
gpgsm (GnuPG) 2.1.0-beta220; Copyright (C) 2012 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.

gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION!
gpgsm: It is only intended for test purposes and should NOT be
gpgsm: used in a production environment or with production keys!
gpgsm: enabled debug flags: assuan
Please select what kind of key you want:
   (1) RSA
   (2) Existing key
   (3) Existing key from card
Your selection? 1
What keysize do you want? (2048) 1024
Requested keysize is 1024 bits
Possible actions for a RSA key:
   (1) sign, encrypt
   (2) sign
   (3) encrypt
Your selection? 1
Enter the X.509 subject name: 'NAME'
Enter email addresses (end with an empty line):
>
Enter DNS names (optional; end with an empty line):
>
Enter URIs (optional; end with an empty line):
>
Create self-signed certificate? (y/N) Y
These parameters are used:
    Key-Type: RSA
    Key-Length: 1024
    Key-Usage: sign, encrypt
    Serial: random
    Name-DN: 'NAME'

Proceed with creation? (y/N) Y
Now creating self-signed certificate.  This may take a while ...
gpgsm: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpgsm: waiting for the agent to come up ... (5s)
gpgsm: waiting for the agent to come up ... (4s)
gpgsm: DBG: chan_4 <- OK Pleased to meet you, process 29624
gpgsm: connection to agent established
gpgsm: DBG: chan_4 -> RESET
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION ttyname=/dev/pty5
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION ttytype=xterm
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION display=:0.0
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION xauthority=~/.Xauthority
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION lc-ctype=en_US.UTF-8
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION lc-messages=en_US.UTF-8
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> OPTION allow-pinentry-notify
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> RESET
gpgsm: DBG: chan_4 <- OK
gpgsm: DBG: chan_4 -> GENKEY
gpgsm: DBG: chan_4 <- S INQUIRE_MAXLEN 1024
gpgsm: DBG: chan_4 <- INQUIRE KEYPARAM
gpgsm: DBG: chan_4 -> D (6:genkey(3:rsa(5:nbits4:1024)))
gpgsm: DBG: chan_4 -> END
gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 14648
gpgsm: DBG: chan_4 -> END
gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 8752
gpgsm: DBG: chan_4 -> END
gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 33476
gpgsm: DBG: chan_4 -> END
gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 9628
gpgsm: DBG: chan_4 -> END
gpgsm: DBG: chan_4 <- S CACHE_NONCE C2E4CD8509DED213BFC75CC4
gpgsm: DBG: chan_4 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65
79 ...(168 byte(s) skipped) ]
gpgsm: DBG: chan_4 <- OK
gpgsm: error setting the subject's name: Not implemented
gpgsm: error creating certificate request: Not implemented <KSBA>
secmem usage: 0/65536 bytes in 0 blocks


From ametzler at downhill.at.eu.org  Sun Jun 30 19:27:28 2013
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 30 Jun 2013 19:27:28 +0200
Subject: No secmem support on kfreebsd-amd64
Message-ID: <20130630172728.GA3233@downhill.g.la>

Hello,

it looks like secmem support is broken on kfreebsd-amd64 (gcrypt 1.5.2):
----------------------
(sid_kfreebsd-amd64-dchroot)ametzler at falla:~/GCR$ gcc -O2 -o minimal-gcrypt -lgcrypt minimal-gcrypt.c && ./minimal-gcrypt
minimal-gcrypt: minimal-gcrypt.c:16: main: Assertion `! err' failed.
Aborted
----------------------

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimal-gcrypt.c
Type: text/x-csrc
Size: 406 bytes
Desc: not available
URL: </pipermail/attachments/20130630/5c04b027/attachment.c>

From wk at gnupg.org  Sun Jun 30 23:46:55 2013
From: wk at gnupg.org (Werner Koch)
Date: Sun, 30 Jun 2013 23:46:55 +0200
Subject: could not create a keypair / sign a single file
In-Reply-To: <CAHYyVz4Tpf4tdy0+L7dLSQL2g9_SiZ8Ay+ZFjtEJh9mQzOp9wQ@mail.gmail.com>
 (Vasiliy's message of "Sat, 29 Jun 2013 09:37:04 +0200")
References: <CAHYyVz4Tpf4tdy0+L7dLSQL2g9_SiZ8Ay+ZFjtEJh9mQzOp9wQ@mail.gmail.com>
Message-ID: <8761wvb7ao.fsf@vigenere.g10code.de>

On Sat, 29 Jun 2013 09:37, testtest_2005 at ukr.net said:

> gpgsm: DBG: chan_4 -> ISTRUSTED FB7EAD4851BE76AF04486BA4738A744BFB50DE86
> gpgsm: DBG: chan_4 <- ERR 67108961 Line too long <GPG Agent>
> gpgsm: checking the trust list failed: Line too long

Please check ~/.gnupg.trustlist.txt.  A line is longer that 255 bytes.
You will find the above fingerprint there - what is special with that
line?  Did you edit it manually, has it been added by GnuPG, or was it
created by Kleopatra or another tool?

> gpgsm: error setting the subject's name: Not implemented
> gpgsm: error creating certificate request: Not implemented <KSBA>

You libksba is too old.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.