From gniibe at fsij.org Wed Apr 4 03:43:55 2012 From: gniibe at fsij.org (Niibe Yutaka) Date: Wed, 04 Apr 2012 10:43:55 +0900 Subject: scd: a race condition between scd_command_handler and handle_tick Message-ID: <87vclgs23o.fsf@latx1.gniibe.org> 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). -- From dkg at fifthhorseman.net Wed Apr 4 23:06:17 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 04 Apr 2012 17:06:17 -0400 Subject: dirmngr repository? In-Reply-To: <4F611042.8010109@fifthhorseman.net> References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> <87boyfz9f8.fsf@vigenere.g10code.de> <871uovaery.fsf@pip.fifthhorseman.net> <87ty1r5zou.fsf@vigenere.g10code.de> <4F611042.8010109@fifthhorseman.net> Message-ID: <87k41vxl4m.fsf@pip.fifthhorseman.net> On Wed, 14 Mar 2012 17:40:18 -0400, Daniel Kahn Gillmor wrote: > On 03/14/2012 04:55 AM, Werner Koch wrote: > > On Wed, 14 Mar 2012 07:16, dkg at fifthhorseman.net said: > > >> I'm trying to sort out what debian should be doing with packaging these > >> parts, so i want to make sure i understand the upstream plans for them. > > > > Get the permissions for Dirmngr right; last time I checked it was still > > run as root. > > Thanks, i've forwarded this note to http://bugs.debian.org/663988 For those who care, this was resolved today in debian unstable. Thanks for the suggestion, Werner. If you have any other concerns about debian packaging for any of these tools, please don't hesitate to raise them. Regards, --dkg From gniibe at fsij.org Thu Apr 5 04:11:14 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 05 Apr 2012 11:11:14 +0900 Subject: scd: a race condition between scd_command_handler and handle_tick In-Reply-To: <87vclgs23o.fsf@latx1.gniibe.org> References: <87vclgs23o.fsf@latx1.gniibe.org> Message-ID: <1333591874.9591.1.camel@latx1.gniibe.org> On 2012-04-04 at 10:43 +0900, Niibe Yutaka wrote: > 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. [...] > It surely occured on other non-exotic architectures. In fact, I > encountered on my amd64 box too (sorry, I lost the log). I minimize reproducible test case. I tested on Debian sid amd64 environment. Here is a session log: ------------------------------------ # Confirm that libpcsclite1 $ dpkg -l libpcsclite1 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ un libpcsclite1 (no description available) # Setup GnuPG's homedir for testing, and enable debugging of scdaemon $ mkdir -p $HOME/tmp/dot-gnupg $ GNUPGHOME=$HOME/tmp/dot-gnupg $ export GNUPGHOME $ echo debug-level guru >tmp/dot-gnupg/scdaemon.conf $ echo debug-all >>tmp/dot-gnupg/scdaemon.conf $ echo log-file $HOME/tmp/dot-gnupg/scd.log >>tmp/dot-gnupg/scdaemon.conf # Run GPG-AGENT $ eval $(gpg-agent --daemon) # Using GPG-CONNECT-AGENT, try to access smartcard $ gpg-connect-agent learn /bye ERR 100663404 Card error # This is normal $ gpg-connect-agent learn /bye ERR 100663356 Not supported # This is by a bug $ gpg-connect-agent learn /bye ERR 100663404 Card error ------------------------------------ Here is a scdaemon debug output: ------------------------------------ 2012-04-05 02:04:59 scdaemon[14197] listening on socket `/tmp/gpg-oBXWNe/S.scdaemon' 2012-04-05 02:04:59 scdaemon[14197] handler for fd -1 started 2012-04-05 02:05:00 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe scdaemon[14197]: chan_7 -> OK GNU Privacy Guard's Smartcard server ready scdaemon[14197]: chan_7 <- GETINFO socket_name scdaemon[14197]: chan_7 -> D /tmp/gpg-oBXWNe/S.scdaemon scdaemon[14197]: chan_7 -> OK scdaemon[14197]: chan_7 <- OPTION event-signal=12 scdaemon[14197]: chan_7 -> OK scdaemon[14197]: chan_7 <- SERIALNO scdaemon[14197]: chan_7 -> ERR 100663404 Card error scdaemon[14197]: chan_7 <- RESTART scdaemon[14197]: chan_7 -> OK 2012-04-05 02:05:01 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe 2012-04-05 02:05:01 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe scdaemon[14197]: chan_7 <- SERIALNO 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=12 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9 le=-1 em=0 2012-04-05 02:05:02 scdaemon[14197] apdu_send_simple(0) failed: not supported 2012-04-05 02:05:02 scdaemon[14197] no supported card application found: Not supported scdaemon[14197]: chan_7 -> ERR 100663356 Not supported scdaemon[14197]: chan_7 <- RESTART scdaemon[14197]: chan_7 -> OK 2012-04-05 02:05:02 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe 2012-04-05 02:05:03 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe 2012-04-05 02:05:04 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe 2012-04-05 02:05:04 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe scdaemon[14197]: chan_7 <- SERIALNO scdaemon[14197]: chan_7 -> ERR 100663404 Card error scdaemon[14197]: chan_7 <- RESTART scdaemon[14197]: chan_7 -> OK 2012-04-05 02:05:05 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe 2012-04-05 02:05:06 scdaemon[14197] error sending PC/SC OPEN request: Broken pipe ------------------------------------ Because of the race condition, we see apdu_send_simple in the log. -- From beebe at math.utah.edu Thu Apr 5 14:54:20 2012 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 5 Apr 2012 06:54:20 -0600 (MDT) Subject: gnupg-2.0.19: make distclean removes critical file Message-ID: 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/ - ------------------------------------------------------------------------------- From beebe at math.utah.edu Thu Apr 5 17:46:39 2012 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 5 Apr 2012 09:46:39 -0600 (MDT) Subject: gnupg-2.0.19 test failures on GNU/Linux Red Hat 5.8 IA-64 (Itanium) Message-ID: 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/ - ------------------------------------------------------------------------------- From wking at drexel.edu Thu Apr 5 18:09:29 2012 From: wking at drexel.edu (W. Trevor King) Date: Thu, 05 Apr 2012 12:09:29 -0400 Subject: gnupg-2.0.19 test failures on GNU/Linux Red Hat 5.8 IA-64 (Itanium) In-Reply-To: References: Message-ID: <20120405160929.GA12342@odin.tremily.us> On Thu, Apr 05, 2012 at 09:46:39AM -0600, Nelson H. F. Beebe wrote: > 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. The Git folks have a test suite that print TAP-formatted output [1]: 1..4 ok 1 - Input file opened not ok 2 - First line of the input valid ok 3 - Read the rest of the file not ok 4 - Summarized correctly # TODO Not written yet If people want to change the test result format, you might as well use a pre-existing specification ;). [1]: http://testanything.org/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Apr 5 18:31:48 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Apr 2012 18:31:48 +0200 Subject: gnupg-2.0.19 test failures on GNU/Linux Red Hat 5.8 IA-64 (Itanium) In-Reply-To: (Nelson H. F. Beebe's message of "Thu, 5 Apr 2012 09:46:39 -0600 (MDT)") References: Message-ID: <87d37mcf7v.fsf@vigenere.g10code.de> On Thu, 5 Apr 2012 17:46, beebe at math.utah.edu said: > why do the encryption names prefix the PASS/FAIL reports? This was once added to have a progress output and to see where it fails. > PASS: DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH CAMELLIA128 CAMELLIA192 CAMELLIA256 conventional.test > FAIL: 3DES conventional-mdc.test That is not easy to implement because the test framework is generated by automake. Further we would not have the progress indicator. An extra progress line makes more sense. I assigned bug 1400 to this request. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Apr 5 20:45:53 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Apr 2012 20:45:53 +0200 Subject: gnupg-2.0.19 test failures on GNU/Linux Red Hat 5.8 IA-64 (Itanium) In-Reply-To: <87d37mcf7v.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 05 Apr 2012 18:31:48 +0200") References: <87d37mcf7v.fsf@vigenere.g10code.de> Message-ID: <878viac90e.fsf@vigenere.g10code.de> On Thu, 5 Apr 2012 18:31, wk at gnupg.org said: > An extra progress line makes more sense. I assigned bug 1400 to this > request. Done for master: The new output style is now: > MD5 SHA1 RIPEMD160 SHA256 SHA384 SHA512 SHA224 < PASS: sigs.test or if the test fails: > MD5 SHA1 sigs.test: ooops FAIL: sigs.test Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at drexel.edu Fri Apr 6 21:38:42 2012 From: wking at drexel.edu (W. Trevor King) Date: Fri, 06 Apr 2012 15:38:42 -0400 Subject: gpgme-tool socket interface In-Reply-To: <20120327180044.GA30604@odin.tremily.us> References: <87mx72t4zh.fsf@vigenere.g10code.de> <4F71CF60.2040403@ruhr-uni-bochum.de> <20120327180044.GA30604@odin.tremily.us> Message-ID: <20120406193841.GA19004@odin.tremily.us> On Tue, Mar 27, 2012 at 02:00:44PM -0400, W. Trevor King wrote: > If the documentation patches look good, I think I'll add support for a > ~/.gnupg/S.gpgme-tool socket next, to increase the similarity with > gpg-agent operation. I started looking into this today, and here are my thoughts so far. 1) Creating an Assuan server that listens at a standard socket (e.g. ~/.assuan/S.) should probably be part of libassuan. Then I could avoid duplicating a lot of gpg-agent.c's socket handling code. Should I move that code over? 2) gnupg/jnlib is ~10k lines, which seems big enough to be a stand-alone library to me ;). If you don't want to release it as a stand-alone library, it should probably at least have its own git repository. That way you could use git submodules to include it in gnupg, and still easily borrow the code to use it in other projects. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From wking at drexel.edu Fri Apr 6 22:25:57 2012 From: wking at drexel.edu (W. Trevor King) Date: Fri, 06 Apr 2012 16:25:57 -0400 Subject: gpgme-tool socket interface In-Reply-To: <20120406193841.GA19004@odin.tremily.us> References: <87mx72t4zh.fsf@vigenere.g10code.de> <4F71CF60.2040403@ruhr-uni-bochum.de> <20120327180044.GA30604@odin.tremily.us> <20120406193841.GA19004@odin.tremily.us> Message-ID: <20120406202557.GA19342@odin.tremily.us> On Fri, Apr 06, 2012 at 03:38:41PM -0400, W. Trevor King wrote: > 1) Creating an Assuan server that listens at a standard socket > (e.g. ~/.assuan/S.) should probably be part of > libassuan. Then I could avoid duplicating a lot of gpg-agent.c's > socket handling code. Should I move that code over? Since there is already a reasonable amount of socket handling code in libassuan, I though I'd be a bit more explicit about what I wanted to move over: * General server-related option definition and handling (oServer, oDaemon, oNoDetach, ?) * Server-related global variables and handling (shutdown_pending, check_own_socket_running, socket_name, socket_nonce, create_socket_name, check_for_running_agent, ?) * Cleanup and signal handling (remove_socket, handle_signal, ?). In order to allow flexible signal handling, there should be stand-alone handlers for common signals (i.e. assuan_handle_sigint, assuan_handle_sigterm). Users would have to use nPth themselves to handle signals. That would be a good start anyway ;). I'll probably run into some others if I get a green light to start working on this. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From beebe at math.utah.edu Sat Apr 7 03:22:49 2012 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 6 Apr 2012 19:22:49 -0600 (MDT) Subject: gnupg-2.0.19 test failures on GNU/Linux Red Hat 5.8 IA-64 (Itanium) Message-ID: Today, I successfully built these four latest snapshots of gcc on GNU/Linux Red Hat 5.8 IA-64 (Itanium): gcc-4.5-20120329 gcc-4.6-20120330 gcc-4.7-20120331 gcc-4.8-20120401 I then reran test builds of gnupg-2.0.19. With either -O2 or -g compilation, all four compilers produce code that fails the same one or two tests as before. Thus, if the failures I reported yesterday are indeed due to gcc code generator errors, then those errors evidently have not yet been fixed. ------------------------------------------------------------------------------- - 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 g10code.com Sat Apr 7 12:16:00 2012 From: wk at g10code.com (Werner Koch) Date: Sat, 07 Apr 2012 12:16:00 +0200 Subject: gpgme-tool socket interface In-Reply-To: <20120406193841.GA19004@odin.tremily.us> (W. Trevor King's message of "Fri, 06 Apr 2012 15:38:42 -0400") References: <87mx72t4zh.fsf@vigenere.g10code.de> <4F71CF60.2040403@ruhr-uni-bochum.de> <20120327180044.GA30604@odin.tremily.us> <20120406193841.GA19004@odin.tremily.us> Message-ID: <871unzc0f3.fsf@vigenere.g10code.de> On Fri, 6 Apr 2012 21:38, wking at drexel.edu said: > 1) Creating an Assuan server that listens at a standard socket > (e.g. ~/.assuan/S.) should probably be part of > libassuan. Then I could avoid duplicating a lot of gpg-agent.c's > socket handling code. Should I move that code over? In theory you are right. However, I prefer to keep the code separated. > 2) gnupg/jnlib is ~10k lines, which seems big enough to be a > stand-alone library to me ;). If you don't want to release it as a GIT master has no more jnlib; it is part of gnupg/common. Marcus and me already talked about having GnuPG runtime library. However, a standalone library is a lot of work because you have to design a solid and stable API and maintain it for a long time. Thus the current idea is to gradually move certain functionality over to libgpg-error and eventually rename libgpg-error. If we start to support 64 bit Windows, we will likely need something like this. > stand-alone library, it should probably at least have its own git > repository. That way you could use git submodules to include it in > gnupg, and still easily borrow the code to use it in other Hmmm, this still requires to limit changes to the API to a minumum. There is also the lincese question. Salam-Shalom, Werner -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 From wk at gnupg.org Sat Apr 7 12:30:56 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 07 Apr 2012 12:30:56 +0200 Subject: gpgme-tool socket interface In-Reply-To: <20120406202557.GA19342@odin.tremily.us> (W. Trevor King's message of "Fri, 06 Apr 2012 16:25:57 -0400") References: <87mx72t4zh.fsf@vigenere.g10code.de> <4F71CF60.2040403@ruhr-uni-bochum.de> <20120327180044.GA30604@odin.tremily.us> <20120406193841.GA19004@odin.tremily.us> <20120406202557.GA19342@odin.tremily.us> Message-ID: <87sjgfal5r.fsf@vigenere.g10code.de> On Fri, 6 Apr 2012 22:25, wking at drexel.edu said: > * Cleanup and signal handling (remove_socket, handle_signal, ?). In > order to allow flexible signal handling, there should be stand-alone I think it is better to avoid signals as much as we can. We can't use them under Windows anyway and thus we need Assuan commands insteads. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at drexel.edu Sat Apr 7 17:23:58 2012 From: wking at drexel.edu (W. Trevor King) Date: Sat, 07 Apr 2012 11:23:58 -0400 Subject: gpgme-tool socket interface In-Reply-To: <87sjgfal5r.fsf@vigenere.g10code.de> <871unzc0f3.fsf@vigenere.g10code.de> Message-ID: <20120407152358.GB22965@odin.tremily.us> On Sat, Apr 07, 2012 at 12:16:00PM +0200, Werner Koch wrote: > On Fri, 6 Apr 2012 21:38, wking at drexel.edu said: > > > 1) Creating an Assuan server that listens at a standard socket > > (e.g. ~/.assuan/S.) should probably be part of > > libassuan. Then I could avoid duplicating a lot of gpg-agent.c's > > socket handling code. Should I move that code over? > > In theory you are right. However, I prefer to keep the code separated. Separated is fine, duplicated is bad ;). I'd like to duplicate gpg-agent's approach, since it's a well-tested example of doing what I want gpgme-tool to do, but if you want me to implement that approach from scratch, I could try and do that instead? Do you mean "don't copy code from GnuPG into libassuan" or "don't put this socket handling stuff in libassuan"? > > 2) gnupg/jnlib is ~10k lines, which seems big enough to be a > > stand-alone library to me ;). If you don't want to release it as a > > GIT master has no more jnlib; it is part of gnupg/common. Ah, yes. I've pulled the Git repo now instead of looking at the tarball used to install GnuPG on my system. > Marcus and me already talked about having GnuPG runtime library. > However, a standalone library is a lot of work because you have to > design a solid and stable API and maintain it for a long time. You only have to maintain the old API it if people use it ;). In my opinion, reducing code duplication would make it easier to maintain the libassuan ecosystem, not harder. > Thus the current idea is to gradually move certain functionality > over to libgpg-error and eventually rename libgpg-error. Socket handling and filename creation are probably not going to end up in libgpg-error, are they? On Sat, Apr 07, 2012 at 12:30:56PM +0200, Werner Koch wrote: > On Fri, 6 Apr 2012 22:25, wking at drexel.edu said: > > > * Cleanup and signal handling (remove_socket, handle_signal, ?). In > > order to allow flexible signal handling, there should be stand-alone > > I think it is better to avoid signals as much as we can. We can't use > them under Windows anyway and thus we need Assuan commands insteads. While I agree that `gpg-connect-agent SHUTDOWN` would work as well as `killall gpg-agent`, some users will still be killing gpg-agent by shutting down their computer. On Linux anyway, that means you'll be getting a SIGTERM, and you'll want to unlink your socket before exiting. I don't see a way to do that without using signal handling. I suppose you could drop Unix sockets entirely in favor of inet sockets? -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From wking at drexel.edu Sat Apr 7 17:58:10 2012 From: wking at drexel.edu (W. Trevor King) Date: Sat, 07 Apr 2012 11:58:10 -0400 Subject: gpgme-tool socket interface In-Reply-To: <87sjgfal5r.fsf@vigenere.g10code.de> References: <87mx72t4zh.fsf@vigenere.g10code.de> <4F71CF60.2040403@ruhr-uni-bochum.de> <20120327180044.GA30604@odin.tremily.us> <20120406193841.GA19004@odin.tremily.us> <20120406202557.GA19342@odin.tremily.us> <87sjgfal5r.fsf@vigenere.g10code.de> Message-ID: <20120407155808.GA23354@odin.tremily.us> On Sat, Apr 07, 2012 at 12:30:56PM +0200, Werner Koch wrote: > On Fri, 6 Apr 2012 22:25, wking at drexel.edu said: > > > * Cleanup and signal handling (remove_socket, handle_signal, ?). In > > order to allow flexible signal handling, there should be stand-alone > > I think it is better to avoid signals as much as we can. We can't use > them under Windows anyway and thus we need Assuan commands insteads. Actually, this is a great reason to extract the socket server code in a sharable library. I'm definately not going to want to write Windows code for gpgme-tool, because (1) I don't know anything about Windows and (2) I don't have access to any Windows machines for testing. If libassuan had that part of the gpg-agent logic internally, libassuan-based servers would run on Windows out-of-the-box, without needing a Windows-capable dev attached to each server project. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From macieksitarz at wp.pl Sun Apr 8 12:29:24 2012 From: macieksitarz at wp.pl (Maciej Sitarz) Date: Sun, 08 Apr 2012 12:29:24 +0200 Subject: pinentry-qt4 breaks Alt+Tab window switching in KDE In-Reply-To: <4F80A5B4.90005@wp.pl> References: <4F80A5B4.90005@wp.pl> Message-ID: <4F816884.1040508@wp.pl> Hi, I'm having problems with pinentry-qt4. After each usage/password entered Alt+Tab in KDE can't switch windows, "No windows" shows instead. After that I need to switch to another window by selecting it on Task manager bar. Steps to reproduce: 1. Check Alt+Tab window list (there should be few) 2. Run in konsole: echo GETPIN | pinentry-qt4 3. Type whatever you like press 'Enter' 4. Press 'Alt+Tab' to check window list. Instead of current window list "No windows" info appears. Versions: * pinentry-qt4 0.8.1 and git * KDE 4.8.2 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. Regards -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-qt4-alt_tab_fix.patch Type: text/x-patch Size: 1217 bytes Desc: not available URL: From alphazo at gmail.com Wed Apr 11 23:50:48 2012 From: alphazo at gmail.com (Alphazo) Date: Wed, 11 Apr 2012 23:50:48 +0200 Subject: Unable to compile libassuan-git Message-ID: 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: @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 From wking at drexel.edu Thu Apr 12 03:48:37 2012 From: wking at drexel.edu (W. Trevor King) Date: Wed, 11 Apr 2012 21:48:37 -0400 Subject: Unable to compile libassuan-git In-Reply-To: References: Message-ID: <20120412014837.GA14096@odin.tremily.us> On Wed, Apr 11, 2012 at 11:50:48PM +0200, Alphazo wrote: > assuan.texi:16: @include `version.texi': No such file or directory. The snapshots need: ./configure --enable-maintainer-mode to build version.texi. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Apr 12 10:14:11 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Apr 2012 10:14:11 +0200 Subject: Unable to compile libassuan-git In-Reply-To: <20120412014837.GA14096@odin.tremily.us> (W. Trevor King's message of "Wed, 11 Apr 2012 21:48:37 -0400") References: <20120412014837.GA14096@odin.tremily.us> Message-ID: <87wr5l1i5o.fsf@vigenere.g10code.de> On Thu, 12 Apr 2012 03:48, wking at drexel.edu said: > The snapshots need: > > ./configure --enable-maintainer-mode Actually autogen.sh prints that info. This reminds me to rename README.SVN to README.GIT. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mustrum at mustrum.net Thu Apr 12 11:13:35 2012 From: mustrum at mustrum.net (Mustrum) Date: Thu, 12 Apr 2012 11:13:35 +0200 Subject: [Gpg4win-devel] Redistributing GPG In-Reply-To: <871unt2wzp.fsf@vigenere.g10code.de> References: <0d48a0d2a2d71224925cb36c26bd1d11@mail.nabber.org> <87wr66tga2.fsf@vigenere.g10code.de> <4F71FA4C.3040602@mustrum.net> <871unt2wzp.fsf@vigenere.g10code.de> Message-ID: <4F869CBF.1040305@mustrum.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Le 12/04/2012 10:08, Werner Koch a ?crit : > On Tue, 27 Mar 2012 19:35, mustrum at mustrum.net said: > >> My DNS doesn't know any www.gpgwin.org :-( > > > In this case your resolver is severely broken: > > $ host www.gpg4win.org www.gpg4win.org is an alias for > gpg4win.wald.intevation.org. gpg4win.wald.intevation.org has > address 78.47.251.62 > > > Salam-Shalom, > > Werner > I know gpg4win ;-) Since you forgot the "4", I believed it was another one. Regards. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJPhpy/AAoJEEy6/YZf1YOeks8P/A532K15MqKU8Y66d+VePC6k /dPrYawouAsJSfbMbc4Q80NOT14qlYiiRjyvi4Kvy0uE/Z37w1hlJ5npgqTDinXZ GfOgPYv5DK7P6uOZD/MjyVqUcd6d40A8p6uLjsnPDH0WQLrCmbDh6l80uk+6okZ+ 3JRmhCo0760c4UCcHwGBOCzypUQ/3ef+nHzV43QUQ5u7D6knyxdBGGbJEOcSrfbH 3Wem2GIUxB65h9gCd/bOXbWs+gV9Wede6QYJgKzdA9XHXvuATYB7t+Cre3wuf+tT djg4xdeSRiG1fPIqUtPGT8CHJ22kc1u45bG/2yoktufDLHsFkmh2wtVS19hViGSb WFLMx0v8ypzh5yfnrs7Z9rag42a/77Qt7YeaYtTBDzInc1EWSyMTGBoKx5LEeqrE TXmFBj7ilgL3yk67IckUGJNrro+Cw6tSG6uvUfLglNKUPG1A80YIz+4xEGG/Hy6j XrSlPuBC4awlL8SP6s3eYPOfbWSvZaQRvL+dlnnSfeDy7fItYdeXto8bfetpDVcz 5gai360719em3PqRkSJdIlNBwAdVaU3PULTHhjasoZy46nICn/Bny/0IWjkAWiFm jONzC5fQUXcBbnrCaFxr2THCrKr1EpWqTX2sN4Xwh4RRPOiU/bdX7mHMeX54l8Jm imi3YUIXeTPoaqRKI5yd =IXy1 -----END PGP SIGNATURE----- From alphazo at gmail.com Thu Apr 12 17:54:53 2012 From: alphazo at gmail.com (Alphazo) Date: Thu, 12 Apr 2012 17:54:53 +0200 Subject: Unable to compile libassuan-git In-Reply-To: <87wr5l1i5o.fsf@vigenere.g10code.de> References: <20120412014837.GA14096@odin.tremily.us> <87wr5l1i5o.fsf@vigenere.g10code.de> Message-ID: Thanks. I should have remembered that one. gnupg2-git is now up and running in ArchLinux AUR. Situation is kind of messy now since Arch has completely removed gnupg1 from the core repository considering that only gnupg2 should be there (/usr/bin/gpg is now a symbolic link to gpg2). Obviously they didn't realize that side effects happen when switching to gnupg2 only (psi passpharse caching, encrypted LUKS+gnupg system not booting....). Dany On Thu, Apr 12, 2012 at 10:14 AM, Werner Koch wrote: > On Thu, 12 Apr 2012 03:48, wking at drexel.edu said: > >> The snapshots need: >> >> ? ./configure --enable-maintainer-mode > > Actually autogen.sh prints that info. ?This reminds me to rename > README.SVN to README.GIT. > > > Shalom-Salam, > > ? Werner > > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > From bisson at archlinux.org Thu Apr 12 18:23:24 2012 From: bisson at archlinux.org (Gaetan Bisson) Date: Thu, 12 Apr 2012 18:23:24 +0200 Subject: Unable to compile libassuan-git In-Reply-To: References: <20120412014837.GA14096@odin.tremily.us> <87wr5l1i5o.fsf@vigenere.g10code.de> Message-ID: <20120412162324.GA510@aji.vesath.org> [2012-04-12 17:54:53 +0200] Alphazo: > Obviously they didn't realize that > side effects happen when switching to gnupg2 only (psi passpharse > caching, encrypted LUKS+gnupg system not booting....). Bug reports are always welcome to our tracker. Strangely none have been submitted for these things, neither during the two weeks when this switch was implemented in [testing] nor after it moved to [core]. For my use case, the switch was seamless... -- Gaetan From wking at drexel.edu Thu Apr 12 19:51:49 2012 From: wking at drexel.edu (W. Trevor King) Date: Thu, 12 Apr 2012 13:51:49 -0400 Subject: [PATCH 2/2] status-table.c: include string.h for strcmp. In-Reply-To: References: Message-ID: <09da4188e5a3fe733047e91b5ba84e47535ef3e9.1334252802.git.wking@drexel.edu> * status-table.c: include string.h to avoid `warning: implicit declaration of function 'strcmp'`. --- src/status-table.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/status-table.c b/src/status-table.c index 276f70e..8060bdb 100644 --- a/src/status-table.c +++ b/src/status-table.c @@ -24,6 +24,7 @@ #endif #include +#include #include "util.h" -- 1.7.3.4 From wking at drexel.edu Thu Apr 12 19:51:47 2012 From: wking at drexel.edu (W. Trevor King) Date: Thu, 12 Apr 2012 13:51:47 -0400 Subject: [PATCH 0/2] gitignore and string.h updates for GPGME Message-ID: 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 -- 1.7.3.4 From wking at drexel.edu Thu Apr 12 19:51:48 2012 From: wking at drexel.edu (W. Trevor King) Date: Thu, 12 Apr 2012 13:51:48 -0400 Subject: [PATCH 1/2] .gitignore: flesh out rules and add subdirectory-.gitignores. In-Reply-To: References: Message-ID: <364c7266694c1ed9ac2d98fe8ea0f2a2a81df2a5.1334252802.git.wking@drexel.edu> * .gitignore: ignore object files and libtool files. Move subdir-specific rules to subdir-specific .gitignores. * doc/.gitignore, lang/cl/.gitignore, src/.gitignore, tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore, tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git status` can focus on interesting changes. --- .gitignore | 13 ++++++++----- doc/.gitignore | 5 +++++ lang/cl/.gitignore | 1 + src/.gitignore | 7 +++++++ tests/.gitignore | 10 ++++++++++ tests/gpg/.gitignore | 30 ++++++++++++++++++++++++++++++ tests/gpgsm/.gitignore | 17 +++++++++++++++++ tests/opassuan/.gitignore | 3 +++ 8 files changed, 81 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 diff --git a/.gitignore b/.gitignore index 983abda..4c37222 100644 --- a/.gitignore +++ b/.gitignore @@ -2,9 +2,12 @@ /autom4te.cache /config.h.in /configure +/config.h +/config.log +/config.status +/libtool Makefile.in -/doc/gpgme.info -/doc/gpgme.info-1 -/doc/gpgme.info-2 -/doc/stamp-vti -/doc/version.texi +Makefile +stamp-h1 +*.o +*.lo diff --git a/doc/.gitignore b/doc/.gitignore new file mode 100644 index 0000000..a44d7b4 --- /dev/null +++ b/doc/.gitignore @@ -0,0 +1,5 @@ +gpgme.info +gpgme.info-1 +gpgme.info-2 +stamp-vti +version.texi diff --git a/lang/cl/.gitignore b/lang/cl/.gitignore new file mode 100644 index 0000000..abccf9c --- /dev/null +++ b/lang/cl/.gitignore @@ -0,0 +1 @@ +gpgme.asd diff --git a/src/.gitignore b/src/.gitignore new file mode 100644 index 0000000..bdf4862 --- /dev/null +++ b/src/.gitignore @@ -0,0 +1,7 @@ +.deps +.libs +gpgme-config +gpgme-tool +gpgme.h +versioninfo.rc +*.la diff --git a/tests/.gitignore b/tests/.gitignore new file mode 100644 index 0000000..e6e6a4a --- /dev/null +++ b/tests/.gitignore @@ -0,0 +1,10 @@ +.deps +.libs +run-export +run-import +run-keylist +run-sign +run-verify +t-data +t-engine-info +t-version diff --git a/tests/gpg/.gitignore b/tests/gpg/.gitignore new file mode 100644 index 0000000..e60bfe5 --- /dev/null +++ b/tests/gpg/.gitignore @@ -0,0 +1,30 @@ +.deps +.libs +gpg-agent.conf +gpg.conf +pubring.gpg +pubring.gpg~ +secring.gpg +t-decrypt +t-decrypt-verify +t-edit +t-encrypt +t-encrypt-large +t-encrypt-sign +t-encrypt-sym +t-eventloop +t-export +t-file-name +t-genkey +t-gpgconf +t-import +t-keylist +t-keylist-sig +t-sig-notation +t-sign +t-signers +t-thread1 +t-trustlist +t-verify +t-wait +trustdb.gpg diff --git a/tests/gpgsm/.gitignore b/tests/gpgsm/.gitignore new file mode 100644 index 0000000..4f1f113 --- /dev/null +++ b/tests/gpgsm/.gitignore @@ -0,0 +1,17 @@ +.deps +.libs +cms-decrypt +cms-keylist +gpgsm.conf +private-keys-v1.d +pubring.kbx +pubring.kbx~ +t-decrypt +t-encrypt +t-export +t-genkey +t-import +t-keylist +t-sign +t-verify +trustlist.txt diff --git a/tests/opassuan/.gitignore b/tests/opassuan/.gitignore new file mode 100644 index 0000000..741a197 --- /dev/null +++ b/tests/opassuan/.gitignore @@ -0,0 +1,3 @@ +.deps +.libs +t-command -- 1.7.3.4 From wk at gnupg.org Fri Apr 13 10:17:37 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Apr 2012 10:17:37 +0200 Subject: [PATCH 0/2] gitignore and string.h updates for GPGME In-Reply-To: (W. Trevor King's message of "Thu, 12 Apr 2012 13:51:47 -0400") References: Message-ID: <87obqwyrj2.fsf@vigenere.g10code.de> Hi! On Thu, 12 Apr 2012 19:51, wking at drexel.edu said: > 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 ;). Kind of: * .gitignore: ignore object files and libtool files. Move subdir-specific rules to subdir-specific .gitignores. That one is fine. * doc/.gitignore, lang/cl/.gitignore, src/.gitignore, tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore, tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git status` can focus on interesting changes. According to the GNU standards, this should be: * doc/.gitignore, lang/cl/.gitignore, src/.gitignore * tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore * tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git status` can focus on interesting changes. The backticks are a nice idea, but $(git status) is more POSIXly ;-). Two more comments: .gitignore is nothing really important and will even not be distributed in a tarball. Thus I would not mention them at all in the ChangeLog. I would have used this commit message: flesh out rules and add subdirectory-.gitignores. -- If you feel like explaining it, do it here. Everything after the tearoff line won't be copied to the CHnageLog. If the tear-off line is the first in the body, no entry will be created at all. I also prefer to have just one .gitignore in the top directory. The reason why you need the new items is that you don't do a VPATH build. Marcus and me prefer VPATH builds, because they keep the source directory clean and best of all, you can do several build using different configure options. For example, I have one work directory and several build directories: cd ~/b/gnupg ~/w/gnupg/configure ..... make cd ~/b-w32/gnupg ~/w/gnupg/autogen.sh --build-w32 make cd ~/b-w32ce/gnupg ~/w/gnupg/autogen.sh --build-w32ce make It is also possible to keep build directores for other branches, like cd ~/b/gnupg-2.0 ~/w/gnupg/configure ..... make Nevertheless, havig rules for non-VPATH buils in .gitignore is fine. I applied :status-table.c: include string.h for strcmp.". Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 13 12:59:45 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 13 Apr 2012 12:59:45 +0200 Subject: [PATCH 0/2] gitignore and string.h updates for GPGME In-Reply-To: <87obqwyrj2.fsf@vigenere.g10code.de> References: <87obqwyrj2.fsf@vigenere.g10code.de> Message-ID: <4F880721.4030204@ruhr-uni-bochum.de> On 04/13/2012 10:17 AM, Werner Koch wrote: > * doc/.gitignore, lang/cl/.gitignore, src/.gitignore, > tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore, > tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git > status` can focus on interesting changes. > > According to the GNU standards, this should be: > > * doc/.gitignore, lang/cl/.gitignore, src/.gitignore > * tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore > * tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git > status` can focus on interesting changes. Are you sure? This looks wrong to me, as a "*" starts a new item, and every item should have a file (or list of files), followed by a location within the file in () if useful and then a colon and the description of the change. Just putting * in front of every line because there is a line break doesn't seem right to me, and I never did that. It's also not how emacs fill-paragraph formats it when confronted with the situation... Thanks, Marcus From wk at gnupg.org Fri Apr 13 14:58:12 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Apr 2012 14:58:12 +0200 Subject: [PATCH 0/2] gitignore and string.h updates for GPGME In-Reply-To: <4F880721.4030204@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "13 Apr 2012 12:59:45 +0200") References: <87obqwyrj2.fsf@vigenere.g10code.de> <4F880721.4030204@ruhr-uni-bochum.de> Message-ID: <87bomvzt3v.fsf@vigenere.g10code.de> On Fri, 13 Apr 2012 12:59, marcus.brinkmann at ruhr-uni-bochum.de said: >> * doc/.gitignore, lang/cl/.gitignore, src/.gitignore >> * tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore >> * tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git >> status` can focus on interesting changes. > > Are you sure? This looks wrong to me, as a "*" starts a new item, and Yes. The asterisk indicates a list of files. The missing colon at the end of the line indcates that more lines for this item will follow. You don't use an asterisk if it is another function: * foo.c (usage_1, usage_2, usage) (help): Add help strings. > doesn't seem right to me, and I never did that. It's also not how emacs > fill-paragraph formats it when confronted with the situation... That has never worked correctly ;) The standards file doesn't tell it explicitly, probably because the case of only new files with no function names is rare. However it states: Separate unrelated change log entries with blank lines. When two entries represent parts of the same change, so that they work together, then don't put blank lines between them. Then you can omit the file name and the asterisk when successive entries are in the same file. At least this is my interpretation. BTW, did anyone worked on Magit's 'C' command so work more similar to C-x a 4 ? > > Thanks, > Marcus > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at drexel.edu Fri Apr 13 16:35:33 2012 From: wking at drexel.edu (W. Trevor King) Date: Fri, 13 Apr 2012 10:35:33 -0400 Subject: [PATCH 0/2] gitignore and string.h updates for GPGME In-Reply-To: <87obqwyrj2.fsf@vigenere.g10code.de> References: <87obqwyrj2.fsf@vigenere.g10code.de> Message-ID: <20120413143533.GA11315@odin.tremily.us> On Fri, Apr 13, 2012 at 10:17:37AM +0200, Werner Koch wrote: > The backticks are a nice idea, but $(git status) is more POSIXly ;-). Alright. I mostly use the backticks because it's also Markdown. I'm fine with $($()) though ;). > .gitignore is nothing really important and will even not be distributed > in a tarball. Thus I would not mention them at all in the ChangeLog. Ok. > I also prefer to have just one .gitignore in the top directory. The > reason why you need the new items is that you don't do a VPATH build. That's a good reason. I was mostly responding to "top-level gitignore considered harmful" [1], but with the limited number of files in the GPGME repo, I don't expect Git efficiency to become an issue. I'll send over a single-gitignore version of that patch (off list), once I write it up. [1]: http://thread.gmane.org/gmane.comp.version-control.git/194294/focus=194341 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 20 16:06:25 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 20 Apr 2012 16:06:25 +0200 Subject: [PATCH 1/2] .gitignore: flesh out rules and add subdirectory-.gitignores. In-Reply-To: <364c7266694c1ed9ac2d98fe8ea0f2a2a81df2a5.1334252802.git.wking@drexel.edu> References: <364c7266694c1ed9ac2d98fe8ea0f2a2a81df2a5.1334252802.git.wking@drexel.edu> Message-ID: <4F916D61.1080801@ruhr-uni-bochum.de> Hi, although git needs to get its act together in .gitignore handling, there is no reason not to decentralize the ignore file. This should help in other refactorisations of the code base as well. I put it in. Thanks, Marcus From gniibe at fsij.org Wed Apr 25 04:33:03 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 25 Apr 2012 11:33:03 +0900 Subject: [PATCH] tools/gpgsm-gencert.sh Message-ID: <1335321183.32744.2.camel@latx1.gniibe.org> 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 @@ -171,7 +171,7 @@ file_parameter=$(mktemp "/tmp/gpgsm.XXXXXX") outfile=$(mktemp "/tmp/gpgsm.XXXXXX") -( +{ cat < "$file_parameter" +} > "$file_parameter" echo 'Parameters for certificate request to create:' >&2 From gniibe at fsij.org Wed Apr 25 05:21:26 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 25 Apr 2012 12:21:26 +0900 Subject: [PATCH] tools/gpgsm-gencert.sh In-Reply-To: <1335321183.32744.2.camel@latx1.gniibe.org> References: <1335321183.32744.2.camel@latx1.gniibe.org> Message-ID: <1335324086.32744.4.camel@latx1.gniibe.org> On 2012-04-25 at 11:33 +0900, NIIBE Yutaka wrote: > gpgsm-gencert.sh doesn't work well with dash (version 0.5.7). Sorry, my bug report is incomplete. I noticed that gpgsm-gencert.sh is deprecated, so it would be irrelevant now. I found that it doesn't work well with bash version 4.1.5 either. In a different environment, I ran this script to create CSR and it went well last year. In the previous mail, I thought it's because of shell difference, but this is wrong. > Following is a patch to fix this problem, by not using subshell. > > This works with both of dash and bash. Anyway, I believe that this fix is correct. -- From wk at gnupg.org Wed Apr 25 09:08:04 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Apr 2012 09:08:04 +0200 Subject: [PATCH] tools/gpgsm-gencert.sh In-Reply-To: <1335324086.32744.4.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Wed, 25 Apr 2012 12:21:26 +0900") References: <1335321183.32744.2.camel@latx1.gniibe.org> <1335324086.32744.4.camel@latx1.gniibe.org> Message-ID: <87wr54i90q.fsf@vigenere.g10code.de> On Wed, 25 Apr 2012 05:21, gniibe at fsij.org said: > I noticed that gpgsm-gencert.sh is deprecated, so it would > be irrelevant now. Right. For the Windows port I had to write in C (with better error reporting): gpgsm --gen-key >> This works with both of dash and bash. > > Anyway, I believe that this fix is correct. { } does not work with old shells. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jim at meyering.net Wed Apr 25 17:42:53 2012 From: jim at meyering.net (Jim Meyering) Date: Wed, 25 Apr 2012 17:42:53 +0200 Subject: [PATCH] avoid buffer strncpy-induced buffer overrun Message-ID: <87haw73jia.fsf@rho.meyering.net> * 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 @@ -587,8 +587,14 @@ 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 From jim at meyering.net Wed Apr 25 17:40:48 2012 From: jim at meyering.net (Jim Meyering) Date: Wed, 25 Apr 2012 17:40:48 +0200 Subject: [PATCH 1] remove doubled words in a comment Message-ID: <87mx5z3jlr.fsf@rho.meyering.net> --- 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 @@ -1,5 +1,5 @@ /* 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. * @@ -24,8 +24,8 @@ #include /* 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 From jim at meyering.net Wed Apr 25 17:44:46 2012 From: jim at meyering.net (Jim Meyering) Date: Wed, 25 Apr 2012 17:44:46 +0200 Subject: [PATCH] simplify ldap URL construction Message-ID: <87bomf3jf5.fsf@rho.meyering.net> * 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 @@ -342,16 +342,11 @@ 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 From wk at gnupg.org Wed Apr 25 20:37:29 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Apr 2012 20:37:29 +0200 Subject: [PATCH] simplify ldap URL construction In-Reply-To: <87bomf3jf5.fsf@rho.meyering.net> (Jim Meyering's message of "Wed, 25 Apr 2012 17:44:46 +0200") References: <87bomf3jf5.fsf@rho.meyering.net> Message-ID: <87d36vhd3q.fsf@vigenere.g10code.de> On Wed, 25 Apr 2012 17:44, jim at meyering.net said: > - strncpy( p, sep, slen ); > - p += slen; > + p = stpncpy( p, sep, slen ); Well, stpncpy is not portable. However it looks very useful. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jim at meyering.net Wed Apr 25 20:44:15 2012 From: jim at meyering.net (Jim Meyering) Date: Wed, 25 Apr 2012 20:44:15 +0200 Subject: [PATCH] simplify ldap URL construction In-Reply-To: <87d36vhd3q.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 25 Apr 2012 20:37:29 +0200") References: <87bomf3jf5.fsf@rho.meyering.net> <87d36vhd3q.fsf@vigenere.g10code.de> Message-ID: <87pqav1wjk.fsf@rho.meyering.net> Werner Koch wrote: > On Wed, 25 Apr 2012 17:44, jim at meyering.net said: > >> - strncpy( p, sep, slen ); >> - p += slen; >> + p = stpncpy( p, sep, slen ); > > Well, stpncpy is not portable. However it looks very useful. Good catch. But gnupg uses gnulib, and there's a stpncpy module to ensure that it's available. From gniibe at fsij.org Thu Apr 26 02:55:48 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 26 Apr 2012 09:55:48 +0900 Subject: [PATCH] sm/certreqgen-ui.c Message-ID: <87wr53gvl7.fsf@latx1.gniibe.org> 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 @@ -339,12 +339,12 @@ 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? */ From jim at meyering.net Thu Apr 26 15:57:20 2012 From: jim at meyering.net (Jim Meyering) Date: Thu, 26 Apr 2012 15:57:20 +0200 Subject: [PATCH] simplify ldap URL construction In-Reply-To: <87pqav1wjk.fsf@rho.meyering.net> (Jim Meyering's message of "Wed, 25 Apr 2012 20:44:15 +0200") References: <87bomf3jf5.fsf@rho.meyering.net> <87d36vhd3q.fsf@vigenere.g10code.de> <87pqav1wjk.fsf@rho.meyering.net> Message-ID: <87wr52y4sf.fsf@rho.meyering.net> Jim Meyering wrote: > Werner Koch wrote: >> On Wed, 25 Apr 2012 17:44, jim at meyering.net said: >>> - strncpy( p, sep, slen ); >>> - p += slen; >>> + p = stpncpy( p, sep, slen ); >> >> Well, stpncpy is not portable. However it looks very useful. > > Good catch. > > But gnupg uses gnulib, and there's a stpncpy module to ensure > that it's available. gnulib's stpcpy module is also good to use, since some systems lack it: [from doc/posix-functions/stpcpy.texi] This function is missing on some platforms: AIX 4.3.2 Cygwin 1.5.x HP-UX 11 IRIX 6.5 Interix 3.5. MSVC 9 Minix 3.1.8 NetBSD 5.0 OSF/1 5.1 OpenBSD 3.8 Solaris 10 mingw From wk at gnupg.org Thu Apr 26 19:21:02 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Apr 2012 19:21:02 +0200 Subject: [PATCH] simplify ldap URL construction In-Reply-To: <87wr52y4sf.fsf@rho.meyering.net> (Jim Meyering's message of "Thu, 26 Apr 2012 15:57:20 +0200") References: <87bomf3jf5.fsf@rho.meyering.net> <87d36vhd3q.fsf@vigenere.g10code.de> <87pqav1wjk.fsf@rho.meyering.net> <87wr52y4sf.fsf@rho.meyering.net> Message-ID: <87ipgmflz5.fsf@vigenere.g10code.de> On Thu, 26 Apr 2012 15:57, jim at meyering.net said: > gnulib's stpcpy module is also good to use, since some systems lack it: We have a simple stpcpy replacement in common/stringhelp.h. Adding stpncpy is straightforward. For historic reasons GnuPG does not use gnulib properly. I also don't care about performance on platforms which don't support a certain new function; the simple replacements do their job. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.