gmane.comp.encryption.gpg.devel

Python bindings for GnuPG

Bernhard Reiter — 2012-05-11T21:17:57

For those of you seeking to use GnuPG from Python, there is an overview at

  http://wiki.python.org/moin/GnuPrivacyGuard

I've just overhauled it.
My recommendation currently is to use James Henstridge's PyGPGME.
As it is actively maintained and even supports Python 3 and 2 since March.

An interesting approach is W. Trevor King's pgp-mime which uses pyassuan 
to speak to gpgme-tool. Haven't tried it. 

Happy Hacking,
Bernhard

npth-0.90 build report

Nelson H. F. Beebe — 2012-05-08T14:07:01

This morning, I successfully built npth-0.90 on about 80% of the 25 or
so flavors of Unix in our test lab.  There were, however, some
glitches that I could overcome, some machines on which a successful
build has not been possible, and one machine on which the build
succeeds, but the test fails.

When I attempted manual rebuilds after automated procedures failed,
I set PATH to a minimal list, such as /bin:/usr/bin.

Here is a summary of problems:

------------------------------------------------------------------------

Solaris 10 (SPARC, x86, x86_64) and 11 (x86_64):

Undefinedfirst referenced
 symbol      in file
accept                              ../src/.libs/libnpth.so
recvmsg                             ../src/.libs/libnpth.so
sendmsg                             ../src/.libs/libnpth.so
connect                             ../src/.libs/libnpth.so

    Need LIBS=-lsocket to resolve symbols.  With that addition,
    the build completes and the tests pass.

------------------------------------------------------------------------

OpenBSD 4.9 and 5.1 x86:

../src/.libs/libnpth.so.0.1: undefined reference to `pselect'

    We keep a directory with the output of nm on all of the
    libraries in the system, including those in the /usr/local
    tree.  None contains the symbol pselect.

------------------------------------------------------------------------

MirBSD 10 x86:

../src/.libs/libnpth.so.0.1: undefined reference to `pselect'

    As with its OpenBSD relatives, there is no pselect on this system.

------------------------------------------------------------------------

GNU/Linux Fedora 14 x86:

    A build with CC=cc succeeds, and passes the tests.

    However, a build with CC=c99 fails like this:

c99 -DHAVE_CONFIG_H -I. -I..  -I../src   -g -O2 -MT t-mutex.o -MD -MP -MF \
    .deps/t-mutex.Tpo -c -o t-mutex.o t-mutex.c
In file included from t-mutex.c:1:0:
../src/npth.h:219:60: warning: 'struct timespec' declared inside parameter list
../src/npth.h:275:26: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'npth_rwlock_t'
../src/npth.h:280:39: error: expected ')' before '*' token
../src/npth.h:282:44: error: expected ')' before '*' token
../src/npth.h:286:39: error: expected ')' before '*' token
../src/npth.h:287:44: error: expected ')' before '*' token
../src/npth.h:303:17: warning: 'struct timespec' declared inside parameter list
../src/npth.h:347:17: warning: 'struct timespec' declared inside parameter list
../src/npth.h:361:32: warning: 'struct timespec' declared inside parameter list

    On other systems, builds with CC=c99 failed as well, with reports like this:

../src/npth.h:219:60: warning: 'struct timespec' declared inside parameter list [enabled by default]
../src/npth.h:275:1: error: unknown type name 'pthread_rwlock_t'
../src/npth.h:283:22: warning: 'struct timespec' declared inside parameter list [enabled by default]
../src/npth.h:288:22: warning: 'struct timespec' declared inside parameter list [enabled by default]
../src/npth.h:303:17: warning: 'struct timespec' declared inside parameter list [enabled by default]
../src/npth.h:347:17: warning: 'struct timespec' declared inside parameter list [enabled by default]
../src/npth.h:361:32: warning: 'struct timespec' declared inside parameter list [enabled by default]

../src/npth.h:219: warning: "struct timespec" declared inside parameter list
../src/npth.h:275: error: parse error before "npth_rwlock_t"
../src/npth.h:275: warning: type defaults to `int' in declaration of `npth_rwlock_t'
../src/npth.h:275: warning: data definition has no type or storage class
../src/npth.h:280: error: parse error before '*' token
../src/npth.h:282: error: parse error before '*' token
../src/npth.h:286: error: parse error before '*' token
../src/npth.h:287: error: parse error before '*' token
../src/npth.h:303: warning: "struct timespec" declared inside parameter list
../src/npth.h:347: warning: "struct timespec" declared inside parameter list
../src/npth.h:361: warning: "struct timespec" declared inside parameter list

"npth.c", line 104: warning: implicit function declaration: usleep
"npth.c", line 154: undefined symbol: __FUNCTION__
"npth.c", line 154: warning: improper pointer/integer combination: arg #1
...many more like that...

------------------------------------------------------------------------

Mac OS X PowerPC and x86_64:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT npth.lo \
    -MD -MP -MF .deps/npth.Tpo -c npth.c  -fno-common -DPIC -o .libs/npth.o
npth.c: In function 'npth_clock_gettime':
npth.c:594: error: 'CLOCK_REALTIME' undeclared (first use in this function)
npth.c:594: error: (Each undeclared identifier is reported only once
npth.c:594: error: for each function it appears in.)

------------------------------------------------------------------------

GNU/Linux Gentoo SPARC:

Build succeeds, but test fails:

FAIL: t-mutex
======================================
1 of 1 test failed
Please report to gnupg-devel< at >gnupg.org
======================================

------------------------------------------------------------------------

SGI IRIX 6.5 MIPS R10000:

/bin/ksh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. \
    -g -O2 -MT npth.lo -MD -MP -MF .deps/npth.Tpo -c -o npth.lo npth.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT npth.lo -MD -MP -MF \
    .deps/npth.Tpo -c npth.c  -DPIC -o .libs/npth.o
In file included from npth.c:40:
npth.h:342: error: syntax error before "socklen_t"
npth.h:343: error: syntax error before "socklen_t"
npth.c:479: error: syntax error before "socklen_t"
npth.c: In function `npth_connect':
npth.c:484: error: `s' undeclared (first use in this function)
npth.c:484: error: (Each undeclared identifier is reported only once
npth.c:484: error: for each function it appears in.)
npth.c:484: error: `addr' undeclared (first use in this function)
npth.c:484: error: `addrlen' undeclared (first use in this function)
npth.c: At top level:
npth.c:491: error: syntax error before "socklen_t"
npth.c: In function `npth_accept':
npth.c:496: error: `s' undeclared (first use in this function)
npth.c:496: error: `addr' undeclared (first use in this function)
npth.c:496: error: `addrlen' undeclared (first use in this function)

    The type socklen_t is not defined in /usr/include/*.h or /usr/include/*/*.h
    on this system.

------------------------------------------------------------------------

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe< at >math.utah.edu  -
- 155 S 1400 E RM 233                       beebe< at >acm.org  beebe< at >computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[Announce] nPth - The New GNU Portable Threads Library

Werner Koch — 2012-05-08T10:39:49

Hi!

We are pleased to announce the first tarball release of the
New GNU Portable Threads Library: nPth version 0.90.

nPth is a non-preemptive threads implementation using an API very similar
to the one known from GNU Pth.  It has been designed as a replacement of
GNU Pth for non-ancient operating systems.  In contrast to GNU Pth is is
based on the system's standard threads implementation.  Thus nPth allows
the use of libraries which are not compatible to GNU Pth.

GNU Pth is often used to provide a co-routine based framework.  GnuPG-2
makes heavy use of this concept for good audibility, general security
concerns, and ease of implementation.  However, GNU Pth has the drawback
that ugly hacks are required to work with libraries which are not GNU
Pth aware.

The nPth tarball and its signature are available as

  ftp://ftp.gnupg.org/gcrypt/npth/npth-0.90.tar.bz2
  ftp://ftp.gnupg.org/gcrypt/npth/npth-0.90.tar.bz2.sig

and at all GnuPG mirrors.  See the included README file and the npth.h
header for documentation.  Bug reports and requests for help should be
send to the gnupg-devel mailing list at gnupg.org.  nPth is available
under the terms of the LGPLv3+ or the GPLv2+.  The GIT repository is at
git://git.gnupg.org/npth.git .

The current development version of GnuPG (2.1) has already been migrated
to nPth and thus the next beta release will require it.  Obviously we
expect to fix some portability problems before we can release 1.0.  On
common Linux and kFreeBSD systems and even on Android, nPth should build
and work fine.

Background: When porting GnuPG-2 to Windows in 2004, we had the need for
a replacement of GNU Pth, which is not available for native Windows.  We
came up with an emulation based on the native Windows thread system.
Experience since then showed that such an emulation is a solid way to
provide a co-routine based framework.  Given that thread implementations
(in particular pthreads) are now in common use on all platforms, there
is not must justification left for not using them: Without considering
the GnuPG packages, Debian has only two packages requiring GNU Pth
(zhcon and jabberd14 - the latter even seems not in wide use anymore).

Many thanks to Ralf S. Engelschall for his excellent GNU PTH library,
which served GnuPG very well for many years.


Happy hacking,

  Marcus and Werner

[PATCH] sm/certreqgen-ui.c

NIIBE Yutaka — 2012-04-26T00:55:48

Hello, 

While trying to use gpgsm --gen-key, I found two mistakes.

diff --git a/sm/certreqgen-ui.c b/sm/certreqgen-ui.c
index 236d53b..41492f5 100644
--- a/sm/certreqgen-ui.c
+++ b/sm/certreqgen-ui.c
< at >< at > -339,12 +339,12 < at >< at > gpgsm_gencertreq_tty (ctrl_t ctrl, estream_t output_stream)
   /* DNS names.  */
   tty_printf (_("Enter DNS names"));
   tty_printf (_(" (optional; end with an empty line):\n"));
-  ask_mb_lines (&mb_email, "Name-DNS: ");
+  ask_mb_lines (&mb_dns, "Name-DNS: ");
 
   /* URIs.  */
   tty_printf (_("Enter URIs"));
   tty_printf (_(" (optional; end with an empty line):\n"));
-  ask_mb_lines (&mb_email, "Name-URI: ");
+  ask_mb_lines (&mb_uri, "Name-URI: ");
 
 
   /* Want a self-signed certificate?  */

[PATCH] simplify ldap URL construction

Jim Meyering — 2012-04-25T15:44:46

* dirmngr/ldap-url.c (ldap_charray2str): Remove unwarranted uses of
strncpy, and simplify.
---
Looking at the other strncpy uses, I found these two and saw that they
are unnecessary, since we know in each case that the specified length
is also the length of the source string.  Using stpcpy makes it
simpler/clearer.

 dirmngr/ldap-url.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/dirmngr/ldap-url.c b/dirmngr/ldap-url.c
index 7b27a30..47441b1 100644
--- a/dirmngr/ldap-url.c
+++ b/dirmngr/ldap-url.c
< at >< at > -342,16 +342,11 < at >< at > char * ldap_charray2str( char **a, const char *sep )
 p = s;
 for ( v = a; *v != NULL; v++ ) {
 if ( v != a ) {
-strncpy( p, sep, slen );
-p += slen;
+p = stpncpy( p, sep, slen );
 }
-
-len = strlen( *v );
-strncpy( p, *v, len );
-p += len;
+p = stpcpy( p, *v );
 }

-*p = '\0';
 return s;
 }

--
1.7.10.335.g879d8

[PATCH 1] remove doubled words in a comment

Jim Meyering — 2012-04-25T15:40:48

---
 common/gettime.h |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/gettime.h b/common/gettime.h
index 4199369..bc914ad 100644
--- a/common/gettime.h
+++ b/common/gettime.h
< at >< at > -1,5 +1,5 < at >< at >
 /* gettime.h - Wrapper for time functions
- * Copyright (C) 2010 Free Software Foundation, Inc.
+ * Copyright (C) 2010, 2012 Free Software Foundation, Inc.
  *
  * This file is part of GnuPG.
  *
< at >< at > -24,8 +24,8 < at >< at >
 #include <gpg-error.h> /* We need gpg_error_t. */


-/* A type to hold the ISO time.  Note that this this is the same as
-   the the KSBA type ksba_isotime_t. */
+/* A type to hold the ISO time.  Note that this is the same as
+   the KSBA type ksba_isotime_t. */
 typedef char gnupg_isotime_t[16];

 time_t gnupg_get_time (void);
--
1.7.10.335.g879d8

[PATCH] avoid buffer strncpy-induced buffer overrun

Jim Meyering — 2012-04-25T15:42:53

* dirmngr/crlcache.c (open_dir): Ensure that both this_update
and next_update member strings are NUL-terminated.
---
this_update and next_update are sometimes expected to
be NUL-terminated strings, we must ensure it here.
Otherwise, the readers may access beyond the end of those buffers.

 dirmngr/crlcache.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/dirmngr/crlcache.c b/dirmngr/crlcache.c
index edf3837..768d446 100644
--- a/dirmngr/crlcache.c
+++ b/dirmngr/crlcache.c
< at >< at > -587,8 +587,14 < at >< at > open_dir (crl_cache_t *r_cache)
                 case 2: entry->issuer_hash = p; break;
                 case 3: entry->issuer = unpercent_string (p); break;
                 case 4: entry->url = unpercent_string (p); break;
-                case 5: strncpy (entry->this_update, p, 15); break;
-                case 6: strncpy (entry->next_update, p, 15); break;
+                case 5:
+  strncpy (entry->this_update, p, 15);
+  entry->this_update[15] = 0;
+  break;
+                case 6:
+  strncpy (entry->next_update, p, 15);
+  entry->next_update[15] = 0;
+  break;
                 case 7: entry->dbfile_hash = p; break;
                 case 8: if (*p) entry->crl_number = p; break;
                 case 9:
--
1.7.10.335.g879d8

[PATCH] tools/gpgsm-gencert.sh

NIIBE Yutaka — 2012-04-25T02:33:03

Hello,

gpgsm-gencert.sh doesn't work well with dash (version 0.5.7).

When URI_ADDRESSES is null, it exits without emitting
CSR.  It exits after the line:

[ -n "$URI_ADDRESSES" ] && echo "$URI_ADDRESSES"

When I change it to:

[ -n "$URI_ADDRESSES" ] && echo "$URI_ADDRESSES" || exit 0

it works.

It seems that dash's subshell with -e behavior is different.

Following is a patch to fix this problem, by not using subshell.

This works with both of dash and bash.

----------------------
diff --git a/tools/gpgsm-gencert.sh b/tools/gpgsm-gencert.sh
index b209c8e..28c3792 100755
--- a/tools/gpgsm-gencert.sh
+++ b/tools/gpgsm-gencert.sh
< at >< at > -171,7 +171,7 < at >< at > file_parameter=$(mktemp "/tmp/gpgsm.XXXXXX")
 outfile=$(mktemp "/tmp/gpgsm.XXXXXX")
 

-(
+{
 cat <<EOF
 Key-Type: $KEY_TYPE
 Key-Length: $KEY_LENGTH
< at >< at > -182,7 +182,7 < at >< at > EOF
 [ -n "$EMAIL_ADDRESSES" ] && echo "$EMAIL_ADDRESSES"
 [ -n "$DNS_ADDRESSES" ] && echo "$DNS_ADDRESSES"
 [ -n "$URI_ADDRESSES" ] && echo "$URI_ADDRESSES"
-) > "$file_parameter"
+} > "$file_parameter"
 

 echo 'Parameters for certificate request to create:' >&2

GnuPG 2.0 decryption of two PGP Message blocks in one Message

Ajay Kallur — 2012-04-24T16:13:48

Dear Developer,

Here's a peculiar scenario, I have a file which has 2 pgp messages or
blocks embedded in a single file one below the other.

Can GPG 2.0 be able to decrypt both the blocks and concatenate the messages
inside same single file?

I have attached the sample PGP file for reference and more clear picture of
the scenario.

Any help is greatly appreciated.

Thanks.

[PATCH 0/2] gitignore and string.h updates for GPGME

W. Trevor King — 2012-04-12T17:51:47

While I'm waiting for the go-ahead for more major socket changes to
GPGME, here are a few more minor cleanups.  I think I got the ChangeLog
commit message format right this time ;).


W. Trevor King (2):
  .gitignore: flesh out rules and add subdirectory-.gitignores.
  status-table.c: include string.h for strcmp.

 .gitignore                |   13 ++++++++-----
 doc/.gitignore            |    5 +++++
 lang/cl/.gitignore        |    1 +
 src/.gitignore            |    7 +++++++
 src/status-table.c        |    1 +
 tests/.gitignore          |   10 ++++++++++
 tests/gpg/.gitignore      |   30 ++++++++++++++++++++++++++++++
 tests/gpgsm/.gitignore    |   17 +++++++++++++++++
 tests/opassuan/.gitignore |    3 +++
 9 files changed, 82 insertions(+), 5 deletions(-)
 create mode 100644 doc/.gitignore
 create mode 100644 lang/cl/.gitignore
 create mode 100644 src/.gitignore
 create mode 100644 tests/.gitignore
 create mode 100644 tests/gpg/.gitignore
 create mode 100644 tests/gpgsm/.gitignore
 create mode 100644 tests/opassuan/.gitignore

Unable to compile libassuan-git

Alphazo — 2012-04-11T21:50:48

Hello,

I'm trying to maintain as much as I can the ArchLinux AUR package for
GnuPG2-git. To build the latest version libassuan>2.1 and ntph are
mandatory. Building ntph was an easy one but I'm getting an error with
libassuan-git. Can someone give me a hint?

Thanks
alphazo

.....
mv -f .deps/funopen.Tpo .deps/funopen.Plo
/bin/sh ../libtool --tag=CC   --mode=link gcc  -march=x86-64
-mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4
-D_FORTIFY_SOURCE=2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes
-Wpointer-arith -fPIC -DPIC    -Wl,--version-script=./libassuan.vers
-version-info 3:0:3
-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -o
libassuan.la -rpath /usr/lib  libassuan_la-assuan.lo
libassuan_la-context.lo libassuan_la-system.lo libassuan_la-debug.lo
libassuan_la-conversion.lo libassuan_la-sysutils.lo
libassuan_la-client.lo libassuan_la-server.lo
libassuan_la-assuan-error.lo libassuan_la-assuan-buffer.lo
libassuan_la-assuan-handler.lo libassuan_la-assuan-inquire.lo
libassuan_la-assuan-listen.lo libassuan_la-assuan-pipe-server.lo
libassuan_la-assuan-socket-server.lo
libassuan_la-assuan-pipe-connect.lo
libassuan_la-assuan-socket-connect.lo libassuan_la-assuan-uds.lo
libassuan_la-assuan-logging.lo libassuan_la-assuan-socket.lo
libassuan_la-system-posix.lo libassuan_la-assuan-io.lo  funopen.lo
-lgpg-error
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libassuan_la-assuan.o
.libs/libassuan_la-context.o .libs/libassuan_la-system.o
.libs/libassuan_la-debug.o .libs/libassuan_la-conversion.o
.libs/libassuan_la-sysutils.o .libs/libassuan_la-client.o
.libs/libassuan_la-server.o .libs/libassuan_la-assuan-error.o
.libs/libassuan_la-assuan-buffer.o .libs/libassuan_la-assuan-handler.o
.libs/libassuan_la-assuan-inquire.o .libs/libassuan_la-assuan-listen.o
.libs/libassuan_la-assuan-pipe-server.o
.libs/libassuan_la-assuan-socket-server.o
.libs/libassuan_la-assuan-pipe-connect.o
.libs/libassuan_la-assuan-socket-connect.o
.libs/libassuan_la-assuan-uds.o .libs/libassuan_la-assuan-logging.o
.libs/libassuan_la-assuan-socket.o .libs/libassuan_la-system-posix.o
.libs/libassuan_la-assuan-io.o .libs/funopen.o   -lgpg-error
-march=x86-64 -mtune=generic -O2 -Wl,--version-script=./libassuan.vers
-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro
-Wl,--hash-style=gnu   -Wl,-soname -Wl,libassuan.so.0 -o
.libs/libassuan.so.0.3.0
libtool: link: (cd ".libs" && rm -f "libassuan.so.0" && ln -s
"libassuan.so.0.3.0" "libassuan.so.0")
libtool: link: (cd ".libs" && rm -f "libassuan.so" && ln -s
"libassuan.so.0.3.0" "libassuan.so")
libtool: link: ( cd ".libs" && rm -f "libassuan.la" && ln -s
"../libassuan.la" "libassuan.la" )
make[3]: Leaving directory
`/home/alpha/PERSO/DOCS/arch-packages/libassuan-git/src/libassuan-build/src'
make[2]: Leaving directory
`/home/alpha/PERSO/DOCS/arch-packages/libassuan-git/src/libassuan-build/src'
Making all in doc
make[2]: Entering directory
`/home/alpha/PERSO/DOCS/arch-packages/libassuan-git/src/libassuan-build/doc'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
rm -rf $backupdir && mkdir $backupdir && \
if (/bin/sh /home/alpha/PERSO/DOCS/arch-packages/libassuan-git/src/libassuan-build/missing
--run makeinfo --version) >/dev/null 2>&1; then \
  for f in assuan.info assuan.info-[0-9] assuan.info-[0-9][0-9]
assuan.i[0-9] assuan.i[0-9][0-9]; do \
    if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
cd "$am__cwd"; \
if /bin/sh /home/alpha/PERSO/DOCS/arch-packages/libassuan-git/src/libassuan-build/missing
--run makeinfo   -I . \
 -o assuan.info assuan.texi; \
then \
  rc=0; \
  CDPATH="${ZSH_VERSION+.}:" && cd .; \
else \
  rc=$?; \
  CDPATH="${ZSH_VERSION+.}:" && cd . && \
  $restore $backupdir/* `echo "./assuan.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
assuan.texi:16: < at >include `version.texi': No such file or directory.
assuan.texi:70: warning: undefined flag: EDITION.
assuan.texi:70: warning: undefined flag: UPDATED.
assuan.texi:71: warning: undefined flag: VERSION.
makeinfo: Removing output file `assuan.info' due to errors; use
--force to preserve.
make[2]: *** [assuan.info] Error 1
make[2]: Leaving directory
`/home/alpha/PERSO/DOCS/arch-packages/libassuan-git/src/libassuan-build/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/alpha/PERSO/DOCS/arch-packages/libassuan-git/src/libassuan-build'
make: *** [all] Error 2

gnupg-2.0.19 test failures on GNU/Linux Red Hat 5.8 IA-64 (Itanium)

Nelson H. F. Beebe — 2012-04-05T15:46:39

I've just made a series of experiments with builds of gnupg-2.0.19 on
Red Hat 5.8 IA-64 (Itanium) with multiple compilers:

cc  (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)

gcc (GCC) 4.1.3 20080630 (prerelease)
gcc (GCC) 4.2.5 20090325 (prerelease)
gcc (GCC) 4.3.0 20071123 (experimental)
gcc (GCC) 4.4.6 20110301 (prerelease)
gcc (GCC) 4.5.3 20110303 (prerelease)
gcc (GCC) 4.6.1 20110429 (prerelease)
gcc (GCC) 4.7.0 20110430 (experimental)

icc (ICC) 9.1 20080314

Only the build with icc passed all of the tests, so I have
installed that one.

Builds typically look like this:

env CC=gcc-4.7 CFLAGS=-I/usr/local/include ./configure --libdir=/usr/local/lib && make all check

With the 8 different gcc versions, I get one or two test failures:

cc
3DES FAIL: conventional-mdc.test

gcc-4.1
FAIL: genkey1024.test
3DES FAIL: conventional-mdc.test

gcc-4.2
FAIL: genkey1024.test
FAIL: conventional.test

gcc-4.3
FAIL: conventional.test

gcc-4.4
FAIL: genkey1024.test

gcc-4.5
FAIL: genkey1024.test
FAIL: conventional.test

gcc-4.6
3DES FAIL: conventional-mdc.test

gcc-4.7
FAIL: conventional.tes
3DES FAIL: conventional-mdc.test

Here is one of the log files:

% cat tests/openpgp/conventional-mdc.test.log
Test: conventional-mdc.test
GNUPGHOME=/local/build/cc/gnupg-2.0.19/tests/openpgp
GPG_AGENT_INFO=/tmp/gpg-o1ynlU/S.gpg-agent:24658:1
gpg: WARNING: unsafe permissions on homedir `.'
gpg: problem with the agent: Broken pipe

Here are the home directory permissions:

% ls -lFd ~/.
drwxr-xr-x 309 XXXXXX wheel 1434 Apr  5 08:29 /XXXXXX

They look okay to me, and in any event, the tests pass with icc, so
the same test with gcc compilation should not fail either.

The configure script by default chooses -O2 optimization, so in
another experiment with gcc-4.7, I removed the -O2 option from all
Makefiles and rebuilt.  Now all of the tests pass!

I also did yet another experiment, replacing -O2 by -O1 everywhere:
that produces two failures:

gcc-4.7 -O1
FAIL: genkey1024.test
FAIL: conventional.test

Perhaps, a small piece of gnupg code is triggering a long-standing gcc
optimizer error for the IA-64 architecture.  It would be nice to find
a code workaround that would produce successful passes on this
platform, and, if the code that triggers the error can be reduced to a
simple test case, then there is a chance that the gcc developers can
repair it.

I may also try building some newer gcc-4.x releases, including the new
4.8 series, and then see whether they still cause gnupg test failures.
However, that is a much larger task, and harder as well, because
gcc-4.x snapshot builds generally fail almost everywhere at my site.

Also, in the output

3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH CAMELLIA128 CAMELLIA192 CAMELLIA256 | PASS: conventional.test
3DES FAIL: conventional-mdc.test

why do the encryption names prefix the PASS/FAIL reports?

In my view, that makes it harder to scan the output for problems. I
sometimes do 100 to 150 different builds of single packages in
multiple O/S and compiler environments, so test-report clarity matters
to me.

I suggest that

PASS: DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH CAMELLIA128 CAMELLIA192 CAMELLIA256 conventional.test
FAIL: 3DES conventional-mdc.test

would be better.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe< at >math.utah.edu  -
- 155 S 1400 E RM 233                       beebe< at >acm.org  beebe< at >computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

gnupg-2.0.19: make distclean removes critical file

Nelson H. F. Beebe — 2012-04-05T12:54:20

A "make distclean" operation in gnupg-2.0.19 removes a
critical file: 

make[1]: Entering directory `/export/home/build/bare/gnupg-2.0.19/common'
test -z "audit-events.h status-codes.h" || rm -f audit-events.h status-codes.h

common/audit-events.h is part of the original distribution,
and gnupg-2.0.19 cannot be rebuilt without it.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe< at >math.utah.edu  -
- 155 S 1400 E RM 233                       beebe< at >acm.org  beebe< at >computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

scd: a race condition between scd_command_handler and handle_tick

Niibe Yutaka — 2012-04-04T01:43:55

This is a bug report for GnuPG 2.0.19 (or 2.0.18).  I have not yet
checked if there is this bug in the development version or not.

This bug was found at "make check" of building scute 1.4.0 for Debian.
I think that it is a bug of a race condition.

Here are failure logs:

https://buildd.debian.org/status/fetch.php?pkg=scute&arch=armel&ver=1.4.0-2&stamp=1333006067
https://buildd.debian.org/status/fetch.php?pkg=scute&arch=ia64&ver=1.4.0-3&stamp=1333361223

It surely occured on other non-exotic architectures.  In fact, I
encountered on my amd64 box too (sorry, I lost the log).


NORMAL CASE:
Since the build environment doesn't have libpcsclite.so.1, pcsc daemon
wrappers fails at start up, and it results "Card error".

In the log, it's like:
-----------------------
gpg-agent[27706]: can't create directory `/home/buildd/.gnupg': No such file or directory
scdaemon[27707]: error sending PC/SC OPEN request: Broken pipe
gpg-agent[27706]: command learn failed: Card error
Skipping test because no token is present.
PASS: t-opensession
-----------------------

BUG CASE:
It seemed that opening PC/SC driver somehow succeeded wrongly after an
failure, and it tried to send APDUs to a reader which failed.  In this
case, the error code is "Not supported", and it resulted failure of
scute's test.

In the log, it's like:
-----------------------
gpg-agent[27735]: can't create directory `/home/buildd/.gnupg': No such file or directory
scdaemon[27736]: error sending PC/SC OPEN request: Broken pipe
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: apdu_send_simple(0) failed: not supported
scdaemon[27736]: no supported card application found: Not supported
gpg-agent[27735]: command learn failed: Not supported
t-closeallsessions.c:48: Function failed
FAIL: t-closeallsessions
-----------------------

For NORMAL CASE, the function open_card failed correctly, as
apdu_connect failed because reader_table[slot].used == 0.

For the BUG CASE, there is a race condition between two threads, the
command handler thread and handle_tick thread.

COMMAND HANDLER THREAD's call-chain is like:
-> scd_command_handler
  -> cmd_serialno
    -> open_card
      ->apdu_connect

HANDLE_TICK THREAD's call-chain is like:
-> handle_tick
  -> scd_update_reader_status_file
    -> update_reader_status_file
      -> get_reader_slot
        -> apdu_open_reader
          -> open_pcsc_reader
            -> open_pcsc_reader_wrapper
              -> new_reader_slot
              Then, forking gnupg-pcsc-wrapper...

For the BUG CASE, it could be considered it goes like this: 

HANDLE_TICK_THREAD                  COMMAND HANDLER THREAD

                                    enter scd_command_handler
                                          ctrl->reader_slot = 0
enter handle_tick
...
enter new_reader_slot
      reader_table[slot].used = 1
forking gnupg-pcsc-wrapper and
thread switch occurs
                                    enter cmd_serialno
                                    enter open_card
                                    enter apdu_connect
                                    *** It succeeds,                    ***
                                    *** as reader_table[slot].used == 1 ***
                                    exit  apdu_connect with success
failure of gnupg-pcsc-wrapper...
                                    tries sending apdu... 


I think that we need mutual exclusion between threads as
there is a shared resource (the connection to gnupg-pcsc-wrapper).

gnupg-2.0.19: common/estream.c mixes void and int

Nelson H. F. Beebe — 2012-03-28T16:06:23

While builds of gnupg-2.0.19 were successful on most of my roughly
25 flavors of Unix, compilations fail on two Solaris Intel systems.
The cause appears to be mixing of void and int in the file
common/estream.c in the definitions of the macros
ESTREAM_MUTEX_LOCK() .. ESTREAM_MUTEX_INITIALIZE() in
lines 177--188.

In function es_ftrylockfile() at line 2619, the value of
ESTREAM_TRYLOCK() is returned as an int, but a void cannot
be cast to an int.

Another minor problem is that configure.ac at line 1473 says

*** It is now required to build with support for the
*** GNU Portable Threads Library (Pth).

However, running 

% ./configure --help | grep pth
  --with-pth-prefix=PFX   prefix where GNU Pth is installed (optional)

says that Pth is optional.  Either it is optional, or it is
required, but only one can be true.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe< at >math.utah.edu  -
- 155 S 1400 E RM 233                       beebe< at >acm.org  beebe< at >computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[Announce] GnuPG 2.0.19 released

Werner Koch — 2012-03-27T09:20:14

Hello!

We are pleased to announce the availability of a new stable GnuPG-2
release:  Version 2.0.19.

The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication
and data storage.  It can be used to encrypt data, create digital
signatures, help authenticating using Secure Shell and to provide a
framework for public key cryptography.  It includes an advanced key
management facility and is compliant with the OpenPGP and S/MIME
standards.

GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.12) in
that it splits up functionality into several modules.  However, both
versions may be installed alongside without any conflict.  In fact,
the gpg version from GnuPG-1 is able to make use of the gpg-agent as
included in GnuPG-2 and allows for seamless passphrase caching.  The
advantage of GnuPG-1 is its smaller size and the lack of dependency on
other modules at run and build time.  We will keep maintaining GnuPG-1
versions because they are very useful for small systems and for server
based applications requiring only OpenPGP support.

GnuPG is distributed under the terms of the GNU General Public License
(GPLv3+).  GnuPG-2 works best on GNU/Linux and *BSD systems but is
also available for other Unices, Microsoft Windows and Mac OS X.


What's New in 2.0.19
====================

 * GPG now accepts a space separated fingerprint as a user ID.  This
   allows to copy and paste the fingerprint from the key listing.

 * GPG now uses the longest key ID available.  Removed support for the
   original HKP keyserver which is not anymore used by any site.

 * Rebuild the trustdb after changing the option --min-cert-level.

 * Ukrainian translation.

 * Honor option --cert-digest-algo when creating a cert.

 * Emit a DECRYPTION_INFO status line.

 * Improved detection of JPEG files.


Getting the Software
====================

Please follow the instructions found at http://www.gnupg.org/download/
or read on:

GnuPG 2.0.19 may be downloaded from one of the GnuPG mirror sites or
direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ .  The list of mirrors
can be found at http://www.gnupg.org/mirrors.html .  Note, that GnuPG
is not available at ftp.gnu.org.

On the FTP server and its mirrors you should find the following files
in the gnupg/ directory:

  gnupg-2.0.19.tar.bz2 (4089k)
  gnupg-2.0.19.tar.bz2.sig

      GnuPG source compressed using BZIP2 and OpenPGP signature.

  gnupg-2.0.18-2.0.19.diff.bz2 (305k)

      A patch file to upgrade a 2.0.18 GnuPG source tree.  This patch
      does not include updates of the language files.

Note, that we don't distribute gzip compressed tarballs for GnuPG-2.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a trusted version of GnuPG installed, you
   can simply check the supplied signature.  For example to check the
   signature of the file gnupg-2.0.19.tar.bz2 you would use this command:

     gpg --verify gnupg-2.0.19.tar.bz2.sig

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by that signing key.  Make sure that you have the right key,
   either by checking the fingerprint of that key with other sources
   or by checking that the key has been signed by a trustworthy other
   key.  Note, that you can retrieve the signing key using the command

     finger wk ,at' g10code.com

   or using a keyserver like

     gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6

   The distribution key 4F25E3B6 is signed by the well known key
   1E42B367.

   NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE
   INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION!

 * If you are not able to use an old version of GnuPG, you have to verify
   the SHA-1 checksum.  Assuming you downloaded the file
   gnupg-2.0.19.tar.bz2, you would run the sha1sum command like this:

     sha1sum gnupg-2.0.19.tar.bz2

   and check that the output matches the first line from the
   following list:

190c09e6688f688fb0a5cf884d01e240d957ac1f  gnupg-2.0.19.tar.bz2
d5e5643dc5ecb4e5296f1a9500f850cfbfd0f8ff  gnupg-2.0.18-2.0.19.diff.bz2


Documentation
=============

The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well; however they have not all the
details available in the manual.  It is also possible to read the
complete manual online in HTML format at

  http://www.gnupg.org/documentation/manuals/gnupg/

or in Portable Document Format at

  http://www.gnupg.org/documentation/manuals/gnupg.pdf .

The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing.  You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems.  Many of the new features are around for
several years and thus enough public knowledge is already available.

Almost all mail clients support GnuPG-2.  Mutt users may want to use
the configure option "--enable-gpgme" during build time and put a "set
use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the
reworked OpenPGP support.


Support
=======

Please consult the archive of the gnupg-users mailing list before
reporting a bug <http://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <http://bugs.gnupg.org>.  We also have a dedicated
service directory at:

  http://www.gnupg.org/service.html

Maintaining and improving GnuPG is costly.  For more than 10 years
now, g10 Code, a German company owned and headed by GnuPG's principal
author Werner Koch, is bearing the majority of these costs.  To help
them carry on this work, they need your support.  Please consider to
visit the GnuPG donation page at:

  http://g10code.com/gnupg-donation.html


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word or answering questions on the mailing
lists.


Happy Hacking,

  The GnuPG Team

bug tracker is down

Werner Koch — 2012-03-20T21:06:06

Hi!

Our bug tracker is currently down.  I'll fix it tomorrow.


Salam-Shalom,

   Werner

Stable GnuPG: 1.4.12 vs 2.0.18

Gaetan Bisson — 2012-03-19T06:20:14

Dear GnuPG developers,

Over at Arch Linux (see [1] and surrounding messages) we are slightly
confused by the statuses of GnuPG-1 and GnuPG-2, and more specifically
the following sentences:

"1.4.12 is the stable version of GnuPG. (2.0.18 is the unstable
development version)." [2]

"We are pleased to announce the availability of a new stable
GnuPG-2 release:  Version 2.0.18." [3]

We understand the GnuPG-2 branch is very different to GnuPG-1. Hence our
question: will you consider the GnuPG-2 branch as stable as GnuPG-1 some
day in the future, or is this already the case?

Cheers.

[1] http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022704.html
[2] http://www.gnupg.org/download/release_notes.en.html
[3] http://lists.gnupg.org/pipermail/gnupg-announce/2011q3/000312.html

secure memory for decryption buffer

Martin Stenberg — 2012-03-16T16:31:26

Hello,

I sent a previous message (subject: gpgme not using secure memory?) to
the list but I assume it got lost in moderation (was not subscribed).

I'm writing a password manager and want it to use a gpg-encrypted file
for storing passwords. I figured that gpgme would be the right tool to
use to integrate gpg encryption/decryption in my application. However,
I'm unsure if gpgme stores decrypted data in secure memory. I don't want
passwords to be swapped to disk.

As far as I can tell from peeking at the gpgme source code, it reads
decrypted data using assuan_read_line, and I cannot find any mlock's
either in libassuan nor in gpgme.

I'm new to the gpg-related libraries so I might very well have missed
something, could someone please confirm if decrypted data can indeed be
swapped when using gpgme?

Thanks in advance!

/Martin
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel< at >gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

gpg-agent and AIX

Albert Chin — 2012-03-15T17:41:57

We have GnuPG 2.0.18 built on AIX. gpg-agent --help takes forever to
start. The reason is because get_max_fds() in common/exechelp.c
returns 2147483647 for max_fds. This is regardless of the limit placed
on file descriptors:
  $ limit
  cputime         unlimited
  filesize        unlimited
  datasize        unlimited
  stacksize       128MB
  coredumpsize    unlimited
  resident        unlimited
  addressspace    unlimited
  descriptors     2048

So I guess we have to come up with an alternate way to get the max_fds
on this platform?

2.1.0beta3 missing man pages?

Daniel Kahn Gillmor — 2012-03-14T06:55:09

it looks to me like the following binaries in 2.1.0beta3 don't yet have 
a manual page:

  gpg-check-pattern
  kbxutil
  g13
  gpgkey2ssh

Are there plans to document them with manual pages?

There is also a manpage for gpg-zip.1, but the tool appears to be named 
gpgtar.

Thanks (and apologies for the minor flood here, i'm trying to document 
the issues as i see them)

--dkg