From wk at gnupg.org Thu May 3 17:00:40 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 May 2012 17:00:40 +0200 Subject: pinentry-qt4 breaks Alt+Tab window switching in KDE In-Reply-To: <4F816884.1040508@wp.pl> (Maciej Sitarz's message of "Sun, 08 Apr 2012 12:29:24 +0200") References: <4F80A5B4.90005@wp.pl> <4F816884.1040508@wp.pl> Message-ID: <87zk9p9unb.fsf@vigenere.g10code.de> On Sun, 8 Apr 2012 12:29, macieksitarz at wp.pl said: > I found out that confirm dialog ("echo CONFIRM | pinentry-qt4") doesn't > have this issue. So I modified the source code and got it working. I > attached a patch, tested only on my box (Arch Linux) with KDE. Did anyone else tested this patch in the meantime? Does it break something? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aheinecke at intevation.de Sun May 6 19:11:17 2012 From: aheinecke at intevation.de (Andre Heinecke) Date: Sun, 06 May 2012 19:11:17 +0200 Subject: pinentry-qt4 breaks Alt+Tab window switching in KDE In-Reply-To: <87zk9p9unb.fsf@vigenere.g10code.de> References: <4F80A5B4.90005@wp.pl> <4F816884.1040508@wp.pl> <87zk9p9unb.fsf@vigenere.g10code.de> Message-ID: <1974357.YK7YgyGmQi@esus> Hi, On Thursday 03 May 2012 17:00:40 Werner Koch wrote: > On Sun, 8 Apr 2012 12:29, macieksitarz at wp.pl said: > > I found out that confirm dialog ("echo CONFIRM | pinentry-qt4") doesn't > > have this issue. So I modified the source code and got it working. I > > attached a patch, tested only on my box (Arch Linux) with KDE. > > Did anyone else tested this patch in the meantime? Does it break > something? Just tried it. I could reproduce this problem with KDE 4.4.5 and Qt 4.6.3. But this Patch did not fix the Problem for me. After applying the patch I still get the "*** No Windows ***" Window. As far as I can tell, the patch just changes the call order bit and the showEvent code should not be causing problems as long as this is not caused by a qt bug (which I doubt). For me the problem looks much more related to grabbing. If I use pinentry-qt without global grab (echo getpin | ./pinentry-qt4 -g) the alt+tab works afterwards. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From wk at gnupg.org Tue May 8 12:39:49 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 May 2012 12:39:49 +0200 Subject: [Announce] nPth - The New GNU Portable Threads Library Message-ID: <87zk9j2byi.fsf@vigenere.g10code.de> 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 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 207 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From beebe at math.utah.edu Tue May 8 16:07:01 2012 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 8 May 2012 08:07:01 -0600 (MDT) Subject: npth-0.90 build report Message-ID: 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): Undefined first 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/ - ------------------------------------------------------------------------------- From wk at gnupg.org Wed May 9 10:42:29 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 May 2012 10:42:29 +0200 Subject: npth-0.90 build report In-Reply-To: (Nelson H. F. Beebe's message of "Tue, 8 May 2012 08:07:01 -0600 (MDT)") References: Message-ID: <87mx5h3fuy.fsf@vigenere.g10code.de> On Tue, 8 May 2012 16:07, beebe at math.utah.edu said: > 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 Thanks for that quick testing. The missing pselect on OpenBSD and derivatives is a pity. I wonder why an OS claiming to head for best security does not support this straightforward function which helps to avoid a race condition. I guess we need to provide a replacement and warn that that it is open to race conditions. I'll look into the other problems. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed May 9 20:53:57 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 May 2012 20:53:57 +0200 Subject: npth-0.90 build report In-Reply-To: (Nelson H. F. Beebe's message of "Tue, 8 May 2012 08:07:01 -0600 (MDT)") References: Message-ID: <8762c52nju.fsf@vigenere.g10code.de> On Tue, 8 May 2012 16:07, beebe at math.utah.edu said: > OpenBSD 4.9 and 5.1 x86: > > ../src/.libs/libnpth.so.0.1: undefined reference to `pselect' Fixed by using an emulation. At least it provides a guarantee that the timeout value will not change. Setting the siganl mask is of course not race free. > MirBSD 10 x86: Very likely also fixed. > However, a build with CC=c99 fails like this: Fixed. We need to add -D_POSIX_C_SOURCE=200112L when building the tests. > "npth.c", line 104: warning: implicit function declaration: usleep > "npth.c", line 154: undefined symbol: __FUNCTION__ Also fixed 0 I hope. In case it still gives error we can simply removfe the debugging code. > Mac OS X PowerPC and x86_64: > > npth.c:594: error: 'CLOCK_REALTIME' undeclared (first use in I still need to look at it. > GNU/Linux Gentoo SPARC: > > Build succeeds, but test fails: > > FAIL: t-mutex The test program did not emit an exit code, thus it is possibly fixed now. > SGI IRIX 6.5 MIPS R10000: > npth.h:342: error: syntax error before "socklen_t" Fixed. But there may be other errors. I like to write some regression tests before I do a new release. If you want to test my fixes now, I can send you a tarball. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lists at openorbit.org Fri May 11 21:38:19 2012 From: lists at openorbit.org (Mattias Holm) Date: Fri, 11 May 2012 21:38:19 +0200 Subject: npth-0.90 build report Message-ID: <08BCBB90-AEB9-41DE-86F6-B649CC380587@openorbit.org> I decided to publish some code I wrote earlier at github. It implements clock_gettime for OS X / darwin. I kindly offer it using a dual GPL v2 or LGPL v3 or later license. This may be interesting for the npth library that failed building due to this function being missing on darwin. It is available at https://github.com/kinslayer/darwin-posix-rt If you want to can clean it up and make a patch with #ifdef __APPLE__ guards, would this be OK? Kind regards, Mattias From wk at gnupg.org Sat May 12 10:19:53 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 12 May 2012 10:19:53 +0200 Subject: npth-0.90 build report In-Reply-To: <08BCBB90-AEB9-41DE-86F6-B649CC380587@openorbit.org> (Mattias Holm's message of "Fri, 11 May 2012 21:38:19 +0200") References: <08BCBB90-AEB9-41DE-86F6-B649CC380587@openorbit.org> Message-ID: <87ipg1zu8m.fsf@vigenere.g10code.de> On Fri, 11 May 2012 21:38, lists at openorbit.org said: > I decided to publish some code I wrote earlier at github. It > implements clock_gettime for OS X / darwin. I kindly offer it using a > dual GPL v2 or LGPL v3 or later license. This may be interesting for Thanks for that offer. However, I already implemented it using gettimeofday: int npth_clock_gettime (struct timespec *ts) { #if defined(CLOCK_REALTIME) && HAVE_CLOCK_GETTIME return clock_gettime (CLOCK_REALTIME, ts); #elif HAVE_GETTIMEOFDAY { struct timeval tv; if (gettimeofday (&tv, NULL)) return -1; ts->tv_sec = tv.tv_sec; ts->tv_nsec = tv.tv_usec * 1000; return 0; } #else /* FIXME: fall back on time() with seconds resolution. */ # error clock_gettime not available - please provide a fallback. #endif } The gotcha was that HAVE_CLOCK_GETTIME alone was not sufficient, a test for the CLOCK_REALTIME macro was also required. It would be better to do the test for CLOCK_REALTIME while testing for clock_gettime, but well, this was easier. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From macieksitarz at wp.pl Sat May 12 12:14:06 2012 From: macieksitarz at wp.pl (Maciej Sitarz) Date: Sat, 12 May 2012 12:14:06 +0200 Subject: pinentry-qt4 breaks Alt+Tab window switching in KDE In-Reply-To: <1974357.YK7YgyGmQi@esus> References: <4F80A5B4.90005@wp.pl> <4F816884.1040508@wp.pl> <87zk9p9unb.fsf@vigenere.g10code.de> <1974357.YK7YgyGmQi@esus> Message-ID: <4FAE37EE.2020602@wp.pl> W dniu 06.05.2012 19:11, Andre Heinecke pisze: > On Thursday 03 May 2012 17:00:40 Werner Koch wrote: >> Did anyone else tested this patch in the meantime? Does it break >> something? > Just tried it. > I could reproduce this problem with KDE 4.4.5 and Qt 4.6.3. > But this Patch did not fix the Problem for me. > After applying the patch I still get the "*** No Windows ***" Window. Maybe it's because version differences between our systems? I've upgraded my system, now I have qt 4.8.1 and kdebase-lib 4.8.3, recompiled pinentry-qt4 and the fix still works. > As far as I can tell, the patch just changes the call order bit and the > showEvent code should not be causing problems as long as this is not caused by > a qt bug (which I doubt). I just changed the call order to match with the confirm dialog call order, as confirm dialog works properly. > For me the problem looks much more related to grabbing. If I > use pinentry-qt without global grab (echo getpin | ./pinentry-qt4 -g) the > alt+tab works afterwards. Using "-g" also works for me. I did one more test, I've got Fedora 16 (qt-4.8.1-5.fc16.x86_64 kdelibs-4.8.3-1.fc16.x86_64 pinentry-qt-0.8.1-4.fc16.x86_64) and pinentry works there. I checked the patches which Fedora devs use to compile pinentry but nothing special[1]. I thought why try to run pinentry-qt4 from Fedora on Arch (both systems up to date so there's no much lib differences). I copied pinentry-qt4 and one missing library (libtinfo.so.5), after that I tried the test command[2]. After using it I got "*** No Windows ***" Window. So looks like the problem is not in pinentry-qt4 but in some other libs (qt probably?). [1] http://pkgs.fedoraproject.org/gitweb/?p=pinentry.git [2] echo getpin | LD_LIBRARY_PATH=./ ./pinentry-qt4 Regards -- Maciej Sitarz From macieksitarz at wp.pl Sat May 12 13:15:17 2012 From: macieksitarz at wp.pl (Maciej Sitarz) Date: Sat, 12 May 2012 13:15:17 +0200 Subject: pinentry-qt4 breaks Alt+Tab window switching in KDE In-Reply-To: <4FAE37EE.2020602@wp.pl> References: <4F80A5B4.90005@wp.pl> <4F816884.1040508@wp.pl> <87zk9p9unb.fsf@vigenere.g10code.de> <1974357.YK7YgyGmQi@esus> <4FAE37EE.2020602@wp.pl> Message-ID: <4FAE4645.7090200@wp.pl> Please disregard my previous comment about pinentry-qt4 from Fedora not working on Arch. It is working (forgot to add full path to binary, I ran Arch's binary instead). I decided to run some more tests... I tried to rule out the qt installed on Arch. So I copied Qt libraries from Fedora to Arch and run few test scenarios (all tests run on Arch): Libs/Bins used Result: Qt(Arch) + pinentry-qt4(Arch) "No Windows" message Qt(Arch) + pinentry-qt4(patched) OK Qt(Arch) + pinentry-qt4(Fedora) OK Qt(Fedora) + pinentry-qt4(Arch) "No Windows" message Qt(Fedora) + pinentry-qt4(patched) OK Qt(Fedora) + pinentry-qt4(Fedora) OK Qt(Arch) - Arch system qt libs Qt(Fedora) - binary qt libs taken from fedora pinentry-qt4(Arch) - Arch system pinentry-qt4 bin pinentry-qt4(Fedora) - binary qt libs taken from fedora pinentry-qt4(patched) - pinentry-qt4 bin with my patch applied All this makes me think pinentry-qt has a bug which is fixed in Fedora. I checked Fedora's build and they apply only one patch[1]. I saw it before, but description didn't seem related to my issue. I gave it a surprisingly it works! Andre please give it a try and confirm. [1] http://pkgs.fedoraproject.org/gitweb/?p=pinentry.git;a=blob_plain;f=0001-Fix-qt4-pinentry-window-created-in-the-background.patch;hb=HEAD -- Maciej Sitarz From quannguyen at mbm.vn Thu May 31 11:37:24 2012 From: quannguyen at mbm.vn (=?UTF-8?B?Tmd1eeG7hW4gSOG7k25nIFF1w6Ju?=) Date: Thu, 31 May 2012 16:37:24 +0700 Subject: APDU to generate key for OpenPGP card? Message-ID: <4FC73BD4.80008@mbm.vn> Hello, I'm trying to generate key (GENERATE ASYMMETRIC KEY PAIR command) on OpenPGP card by using APDU (with the help of OpenSC). Basing on the spec, I built APDU as: 00 47 80 00 02 B6 00 00 but the response is 67 00 (incorrect length). Is my APDU right? If I want to generate a key with modulus length = 1024, how I specify the length to make the card understand? -- Regards, Qu?n From wk at gnupg.org Thu May 31 15:04:11 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 May 2012 15:04:11 +0200 Subject: APDU to generate key for OpenPGP card? In-Reply-To: <4FC73BD4.80008@mbm.vn> (=?utf-8?Q?=22Nguy=E1=BB=85n_H?= =?utf-8?Q?=E1=BB=93ng_Qu=C3=A2n=22's?= message of "Thu, 31 May 2012 16:37:24 +0700") References: <4FC73BD4.80008@mbm.vn> Message-ID: <87y5o8biyc.fsf@vigenere.g10code.de> On Thu, 31 May 2012 11:37, quannguyen at mbm.vn said: > Is my APDU right? If I want to generate a key with modulus length = > 1024, how I specify the length to make the card understand? The OpenPGP card spec has all the details you need to know. You can't specify the length. However, some cards allow to re-configure the key size. Checkout change_keyattr for example code. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From quannguyen at mbm.vn Thu May 31 17:54:15 2012 From: quannguyen at mbm.vn (=?UTF-8?B?Tmd1eeG7hW4gSOG7k25nIFF1w6Ju?=) Date: Thu, 31 May 2012 22:54:15 +0700 Subject: APDU to generate key for OpenPGP card? In-Reply-To: <87y5o8biyc.fsf@vigenere.g10code.de> References: <4FC73BD4.80008@mbm.vn> <87y5o8biyc.fsf@vigenere.g10code.de> Message-ID: <4FC79427.3030005@mbm.vn> Thank you all! -- Regards, Qu?n